On Wed, Aug 06, 2014 at 03:21:17PM +0200, u-codalist-z149_at_aetey.se wrote:
> Backup is one of the subsystems in Coda which I do not see as satisfactory.
> 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:

- 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.

- 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.

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

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. Our last three backup setups (Amanda based, BackupPC based
and custom) all used volutil dump | codadump2tar, which returns a
standard tar archive of all files in a volume replica, but we do also
lose ACL information. I've thought about adding a shell script in the
archive that an admin can run to set the ACLs after a restore.

Jan