On Wed, Aug 06, 2014 at 09:49:54AM -0400, Jan Harkes wrote:
> On Wed, Aug 06, 2014 at 03:21:17PM +0200, u-codalist-z149_at_aetey.se wrote:
> > That's why we backup on file level despite the shortcomings of such
> > a fashion.
> 
> For people who are not aware, the problems with file level backup are:

- I may add, lost consistency between files being concurrently updated
  in different parts of the file tree, during the time of the backup

> - Coda's inodes have no guarantee of being unique as the internal
>   identifier is a 128-bit file identifier. So any backup program that
>   tries to identify hardlinks based on only the 32-bit inode number
>   value may skip files believing they were already backed up.

We do not support any use of hard links in the deployment (by design they
suit distributed environments very badly). They used to work to certain
degree in Coda but they are more confusing the users and the programs than
helping anything, so frankly I hardly see any point in supporting them.

> - When there is a conflict, all files underneath the conflict are
>   invisible to the backup program.
> 
> - (this one may be a benefit) when parts of the tree are inconstent
>   between servers backup is slowed down because it triggers
>   server-server resolution for all inconsistent objects.

Yes. Backup taking by itself :) contributes to consistency of different
replicas and hence to the resilience against hadrware failures (when
servers or volume replicas are to be replaced and repopulated).

> - Backup tools don't know how to backup/restore ACLs.

> I've thought about adding a shell script in the
> archive that an admin can run to set the ACLs after a restore.

We are using such scripts. If one's file tree is sufficiently static
during the backup time, the collected acl information remains consistent.
For atomic snapshots it is to be collected instead from the readonly backup
volume, I guess it is what you mean.

> We actually use Coda's built in volume dump backup mechanism which has
> the ability to create consistent atomic snapshots across all replicas of
> a volume which are then efficiently streamed from the server using
> volutil dump.

I agree this mechanism is certainly useful, but unfortunately it is
quite long from a clean solution (it would be _much_ more usable if one
could transform a restored readonly volume to a readwrite one, instead
of resorting to tar).

worked on Ulocoda (for the Apple's platform which they successfully
rendered unusable with Coda anyway) instead of the multilevel backups
which was the possible alternative. Multilevel online backup volumes
would make the tape/offline ones almost unnecessary (similarly to orifs).

Regards,
Rune