Oops - I just sent the following to Rob only, here's the same thing
for the list. Apologies for my incompetence with webmail (and its
horrible line wrapping) - it will have to do this time, I'm afraid.
Also, as a PS (where P=pre): I'm currently running another restore
from the same backup below, to see if the same files are affected.
On 12 May 2012 20:58, Rob Browning <
r...@defaultvalue.org> wrote:
> If anyone's willing, it would be really nice (when feasible) if you
> could add a cross-check like this to your normal backup routine and let
> us know if rsync reports any unexpected differences.
Hi Rob,
Thanks so much for all the hard work on bup-meta. I've switched to
using tmp/pending/meta (to be precise: bup-version says
"0.25-rc1-35-gce29408"), and I'm now working on putting that
cross-check in place.
For my first "data point", I'm afraid I didn't get to check against
rsync due to time constraints, but instead I checked against dar (see
http://dar.linux.free.fr/ -- for some background: before now, I had
mostly used bup as a "storage backend" for dar...). Among backup
tools, I believe dar stands out as being especially careful preserving
metadata, so it should be a useful check.
First of all the good news: all the hard links were properly restored.
However, some unexpected differences turned up on 16 files (out of
more than 200000) which for some reason did not have their mtimes
restored.
Backup commands were these, where the source was an ext3, non-system
partition on a Ubuntu system and the destination was OS X (and so
restore testing was onto hfs+):
$ bup index -vx .
$ bup save -r mac1: -n d630_lab .
$ dar --create - --noconf --alter=atime --no-mount-points | bup split
-r mac1: -n d630_lab.1.dar
where dar's summary for this backup set read:
--------------------------------------------
229331 inode(s) saved
with 24 hard link(s) recorded
0 inode(s) changed at the moment of the backup
0 inode(s) not saved (no inode/file change)
0 inode(s) failed to save (filesystem error)
0 inode(s) ignored (excluded by filters)
0 inode(s) recorded as deleted from reference backup
--------------------------------------------
Total number of inodes considered: 229331
--------------------------------------------
EA saved for 0 inode(s)
--------------------------------------------
Ok, so on to restoring (this is on the remote machine) and testing:
$ mkdir /tmp/bup_tmp_restore
$ cd /tmp/bup_tmp_restore
$ sudo sh -c "BUP_DIR=/Users/yungchin/.bup bup restore --numeric-ids
/d630_lab/latest/home/yungchin/lab"
$ bup join d630_lab.1.dar > /tmp/dar_tmp_restore.1.dar
$ sudo dar --diff /tmp/dar_tmp_restore > /tmp/dar_diff.out
This results in a bunch of lines like these:
DIFF /private/tmp/bup_tmp_restore/lab/tracserver/trac/db/trac.db:
difference of last modification date: Wed Dec 14 18:52:23 2011 <-->
Sat May 19 21:07:33 2012
DIFF /private/tmp/bup_tmp_restore/lab/tracserver/repos_091109.tar.gz:
difference of last modification date: Mon Nov 9 20:30:00 2009 <-->
Sat May 19 21:07:33 2012
DIFF /private/tmp/bup_tmp_restore/lab/tracserver/repos/.bzr/repository/packs/2bdb93e9209a86e01677b6bb1dc897be.pack:
difference of last modification date: Mon Jul 12 12:06:36 2010 <-->
Sat May 19 21:07:33 2012
...etc etc. The latter happens to be a file in a long unused
repository. And indeed:
$ sudo ls -lhat tracserver/repos/.bzr/repository/packs
total 4504
-rw-r--r-- 1 1000 1000 1.4M May 19 21:07
2bdb93e9209a86e01677b6bb1dc897be.pack
drwxr-xr-x 11 1000 1000 374B Aug 17 2011 ..
drwxr-xr-x 15 1000 1000 510B Aug 17 2011 .
-rw-r--r-- 1 1000 1000 26K Aug 17 2011
f415a51660d01c7b3e80bd05a6c07d13.pack
-rw-r--r-- 1 1000 1000 19K Jul 11 2011
ce262d4c43b084a126627fffc371dcc2.pack
-rw-r--r-- 1 1000 1000 52K Jun 20 2011
473d735fe62cdcfa77ad051549376fb5.pack
-rw-r--r-- 1 1000 1000 54K Oct 8 2010
02b66f31ce7c5c1b0d477996b34fac07.pack
-rw-r--r-- 1 1000 1000 34K Sep 23 2010
f33f0e0f89fd90ecfa537828d4c155d6.pack
-rw-r--r-- 1 1000 1000 50K Sep 18 2010
5624f8a2b328904d0c989b2199bba112.pack
-rw-r--r-- 1 1000 1000 45K Aug 26 2010
ad02fc459823092a0eef04f5d5f09a9e.pack
-rw-r--r-- 1 1000 1000 40K Aug 24 2010
cb6c50970edd57b13b8e32e22ee26e92.pack
-rw-r--r-- 1 1000 1000 45K Jul 28 2010
b3f9af034c856c20030a2ed27ed4cd46.pack
-rw-r--r-- 1 1000 1000 19K Jul 13 2010
349b768635f0589d81f77df771f56b1f.pack
-rw-r--r-- 1 1000 1000 80K Nov 19 2009
67a664df19e01c3aa72497ce92d42070.pack
-rw-r--r-- 1 1000 1000 362K Nov 9 2009
6d227213472f5c4b852a0d3acbacee86.pack
... I've no idea why that one file in the directory was different.
Similarly for all the other files: they had mtimes between 21:04 and
21:09 today, that is, restore time. Any thoughts?
I'll do some more tests, also involving system partitions (thus more
special files) very soon.
Greetings, YC