Structure of the d2dbackup backup store
=======================================

The target (backup) drives in d2dbackup replicate the structure of the 
source drives, with some straightforward differences. 

Consider the file /home/user/file.foo. The first version of the file will 
be copied to (for example):

   /bkup4/home/user/file.foo;1

or to 

   /bkup4/home/user/file.foo;1.gz

if it wants/needs compression. The next time the source file is
modified, the new version is copied to some other destination drive,
for example:

   /bkup2/home/user/file.foo;2.gz

and the version number is incremented. 

If the user compresses the file in the source, then the next backup run 
will create:

   /bkup5/home/user/file/file.foo.gz;1

so the information about the compression state on the source filesystem is
not lost, but of course there will be additional copies stored. Symbolic
links are backed up, and point back to the source filesystem, as expected.

The first element of the path (bkup1, bkup2...) is the drive and is
selected by d2dbackup for each file according to an algorithm that keeps
versions of the same file on different drives, and free space well
distributed. There is no database to tell you which drive has any
particular file, you have to look everywhere:

   ls -lt /bkup*/home/userid/file.foo\;*

will list all the versions in date order.

The permissions on a file reflect the permissions when the file was copied
to the target store, including the owner, group, creation and modification
dates. A mere change in file metadata (other than modification date) will
NOT trigger a change in the backup. So the backup can get out of date with
respect to changes in ownership or permissions. 

A directory copied to the backup store loses its metadata entirely, and is
always owned by root with mode 755. The actual metadata from the source is
stored as the metadata for a zero length file in the superdirectory with a
".dirinfo"  suffix added after the version number, thus:
 
   /bkup4/home/userid/directory;1.dirinfo

has the correct ownership and permissions for the directory
/home/userid/directory on the source filesystem when that directory was
first noticed by d2dbackup. Again, changes in metadata do not trigger
updates.

During garbage collection, files which are deleted on the source
filesystem have an extra version created by copying the last version
again, with a .deleted extension:

 /bkup4/home/userid/file.foo;3.gz.deleted

If a file with that name again appears on the source, a new version
will be created.

During a restore, by default deleted files are NOT restored (restoring
a directory to its last known state), but you can get them with
--rdeleted.

File names with embedded shell metacharacters (including ';') will be
faithfully reproduced on backup and restore, those metacharacters are
all appropriately escaped.

See the README for a description of the algorithm used to decide when to
delete old versions, and for choosing which old versions to delete.