Comments on: Introducing Backup-Bouncer http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/ distraction in action Thu, 21 Aug 2008 18:33:23 +0000 http://wordpress.org/?v=2.5.1 By: Backup-Bouncer | Raam Dev’s Weblog http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22590 Backup-Bouncer | Raam Dev’s Weblog Thu, 21 Aug 2008 13:19:57 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22590 [...] haven’t tried it yet, but Backup-Bouncer looks like a very useful tool for verifying backup methods (it doesn’t actually verify [...] [...] haven’t tried it yet, but Backup-Bouncer looks like a very useful tool for verifying backup methods (it doesn’t actually verify [...]

]]> By: n8 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22082 n8 Tue, 29 Jul 2008 08:38:49 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22082 RobK: You've got a very good point WRT locking. I changed the "lots of metadata" test so that the file is locked as well, and indeed, it does change at least one result. The version of xar I've got (1.6dev) fails in this case despite passing all other tests. I didn't check the before and after results on the other copiers so I'm not sure if it changed them. Unfortunately, the "lots of metadata" test can fail for lots of reasons -- a copier can fail because it totally fails to preserve one or many metadata items, or it can also fail because it locks the destination file too early. I'm not sure how to communicate this result to the user in a useful way. As for the inability to do a perfect duplication, it's interesting, but not alarming IMHO. I wouldn't expect the user or the system to care about the creation date of symlinks. I'll consider adding a test for it just for the sake of completeness. Thanks for the interesting feedback! RobK: You’ve got a very good point WRT locking. I changed the “lots of metadata” test so that the file is locked as well, and indeed, it does change at least one result. The version of xar I’ve got (1.6dev) fails in this case despite passing all other tests. I didn’t check the before and after results on the other copiers so I’m not sure if it changed them.

Unfortunately, the “lots of metadata” test can fail for lots of reasons — a copier can fail because it totally fails to preserve one or many metadata items, or it can also fail because it locks the destination file too early. I’m not sure how to communicate this result to the user in a useful way.

As for the inability to do a perfect duplication, it’s interesting, but not alarming IMHO. I wouldn’t expect the user or the system to care about the creation date of symlinks. I’ll consider adding a test for it just for the sake of completeness.

Thanks for the interesting feedback!

]]> By: n8 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22080 n8 Tue, 29 Jul 2008 08:01:08 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22080 MrWizard: Good catch! This was a really sneaky bug. Notice the difference in the output of <code>ls -lo</code> under <code>sudo</code>: <pre>[n8gray@golux]% ls -lo README -rw-r--r-- 1 n8gray staff - 5020 Jun 9 12:49 README [n8gray@golux]% sudo ls -lo README -rw-r--r-- 1 n8gray 5020 Jun 9 12:49 README</pre> The "-" in the regular user output shows the BSD flags. So my test works as a regular user but not as root. Changing the command to <code>ls -ldO</code> fixes the problem. Thanks! MrWizard: Good catch! This was a really sneaky bug. Notice the difference in the output of ls -lo under sudo:

[n8gray@golux]% ls -lo README
-rw-r–r–  1 n8gray  staff  - 5020 Jun  9 12:49 README
[n8gray@golux]% sudo ls -lo README
-rw-r–r–  1 n8gray  5020 Jun  9 12:49 README

The “-” in the regular user output shows the BSD flags. So my test works as a regular user but not as root. Changing the command to ls -ldO fixes the problem. Thanks!

]]> By: MrWizard http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22075 MrWizard Tue, 29 Jul 2008 05:22:04 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-22075 On my Leopard machine, the bsd-flags test is always succeeding. I think you need to use ls -d -l -O instead of ls -lo. At least then it's conclusive. Rsync 3.0.3 plus fileflags plus crtime is quite a good thing! On my Leopard machine, the bsd-flags test is always succeeding. I think you need to use ls -d -l -O instead of ls -lo. At least then it’s conclusive.

Rsync 3.0.3 plus fileflags plus crtime is quite a good thing!

]]> By: RobK http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21675 RobK Sun, 13 Jul 2008 13:23:37 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21675 I don't think your test suite tests for this common problem that exists in many Mac OS X backup software. It existed in CCC until the recent version 3.1.1 got released a few days ago. See http://forums.bombich.com/viewtopic.php?t=12013&highlight= If the file is locked and the backup programs copies the locked flag too early from the source file to the backup file, the backup programs will be unable to copy ANY other metadata such as extended attributes. To get around this limitation in Mac OS X, the backup programs MUST copy ALL other metadata first and then copy the LOCKED flag LAST. If the destination file is locked TOO early, other metadata such as extended attributes and possibly other BSD flags will NOT be copied to the destination file. I do hope you test for this condition. On another note, you should note that Mac OS X makes it impossible to make a perfect clone of a disk drive. One cannot clone of copy the CREATION dates of symlinks. Apple does not provide an API to do so. RobK I don’t think your test suite tests for this common problem that exists in many Mac OS X backup software. It existed in CCC until the recent version 3.1.1 got released a few days ago.

See http://forums.bombich.com/viewtopic.php?t=12013&highlight=

If the file is locked and the backup programs copies the locked flag too early from the source file to the backup file, the backup programs will be unable to copy ANY other metadata such as extended attributes.

To get around this limitation in Mac OS X, the backup programs MUST copy ALL other metadata first and then copy the LOCKED flag LAST.

If the destination file is locked TOO early, other metadata such as extended attributes and possibly other BSD flags will NOT be copied to the destination file.

I do hope you test for this condition.

On another note, you should note that Mac OS X makes it impossible to make a perfect clone of a disk drive. One cannot clone of copy the CREATION dates of symlinks. Apple does not provide an API to do so.

RobK

]]> By: blue http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21464 blue Fri, 04 Jul 2008 22:46:48 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21464 Lastest version of rsync 3.0.3 with patches for fileflags and crtimes works just the same. All bb tests pass. (Follow instructions at http://www.bombich.com/mactips/rsync.html and change 3.0.2 to 3.0.3.) Lastest version of rsync 3.0.3 with patches for fileflags and crtimes works just the same. All bb tests pass.

(Follow instructions at http://www.bombich.com/mactips/rsync.html and change 3.0.2 to 3.0.3.)

]]> By: blue http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21332 blue Sat, 28 Jun 2008 06:12:15 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21332 Bombich http://www.bombich.com/mactips/rsync.html recommends: rsync -aNHAX --fileflags --force-change Without root permissions (using sudo), device copy fails. All other bb tests pass. Bombich http://www.bombich.com/mactips/rsync.html recommends:
rsync -aNHAX –fileflags –force-change

Without root permissions (using sudo), device copy fails. All other bb tests pass.

]]> By: blue http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21330 blue Sat, 28 Jun 2008 06:04:10 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21330 (Sorry - forgot to run detailed test. Still a perfect score.) backup-bouncer-0.1.3 $ sudo ./bbouncer verify -d /Volumes/Src /Volumes/Dst/14-rsync302 Password: Verifying: basic-permissions ... ok (Critical) Verifying: timestamps ... ok (Critical) Verifying: symlinks ... ok (Critical) Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok (Important) Verifying: resource-forks ... Sub-test: on files ... ok (Critical) Sub-test: on hardlinked files ... ok (Important) Verifying: finder-flags ... ok (Critical) Verifying: finder-locks ... ok Verifying: creation-date ... ok Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok (Important) Sub-test: on directories ... ok (Important) Sub-test: on symlinks ... ok Verifying: access-control-lists ... Sub-test: on files ... ok (Important) Sub-test: on dirs ... ok (Important) Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok (Sorry - forgot to run detailed test. Still a perfect score.)

backup-bouncer-0.1.3 $ sudo ./bbouncer verify -d /Volumes/Src /Volumes/Dst/14-rsync302
Password:
Verifying: basic-permissions … ok (Critical)
Verifying: timestamps … ok (Critical)
Verifying: symlinks … ok (Critical)
Verifying: symlink-ownership … ok
Verifying: hardlinks … ok (Important)
Verifying: resource-forks …
Sub-test: on files … ok (Critical)
Sub-test: on hardlinked files … ok (Important)
Verifying: finder-flags … ok (Critical)
Verifying: finder-locks … ok
Verifying: creation-date … ok
Verifying: bsd-flags … ok
Verifying: extended-attrs …
Sub-test: on files … ok (Important)
Sub-test: on directories … ok (Important)
Sub-test: on symlinks … ok
Verifying: access-control-lists …
Sub-test: on files … ok (Important)
Sub-test: on dirs … ok (Important)
Verifying: fifo … ok
Verifying: devices … ok
Verifying: combo-tests …
Sub-test: xattrs + rsrc forks … ok
Sub-test: lots of metadata … ok

]]> By: blue http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21329 blue Sat, 28 Jun 2008 06:00:21 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21329 Latest version test - still looks fine (rsync 3.02 patched on OS 10.5.3): backup-bouncer-0.1.3 $ sudo rsync -aNHAXx --protect-args --fileflags --force-change /Volumes/Src/* /Volumes/Dst/14-rsync302 backup-bouncer-0.1.3 $ sudo ./bbouncer verify /Volumes/Src /Volumes/Dst/14-rsync302 Verifying: basic-permissions ... ok (Critical) Verifying: timestamps ... ok (Critical) Verifying: symlinks ... ok (Critical) Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok (Important) Verifying: resource-forks ... ok (Critical) Verifying: finder-flags ... ok (Critical) Verifying: finder-locks ... ok Verifying: creation-date ... ok Verifying: bsd-flags ... ok Verifying: extended-attrs ... ok (Important) Verifying: access-control-lists ... ok (Important) Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... ok Latest version test - still looks fine (rsync 3.02 patched on OS 10.5.3):
backup-bouncer-0.1.3 $ sudo rsync -aNHAXx –protect-args –fileflags –force-change /Volumes/Src/* /Volumes/Dst/14-rsync302
backup-bouncer-0.1.3 $ sudo ./bbouncer verify /Volumes/Src /Volumes/Dst/14-rsync302
Verifying: basic-permissions … ok (Critical)
Verifying: timestamps … ok (Critical)
Verifying: symlinks … ok (Critical)
Verifying: symlink-ownership … ok
Verifying: hardlinks … ok (Important)
Verifying: resource-forks … ok (Critical)
Verifying: finder-flags … ok (Critical)
Verifying: finder-locks … ok
Verifying: creation-date … ok
Verifying: bsd-flags … ok
Verifying: extended-attrs … ok (Important)
Verifying: access-control-lists … ok (Important)
Verifying: fifo … ok
Verifying: devices … ok
Verifying: combo-tests … ok

]]> By: n8 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21176 n8 Thu, 19 Jun 2008 18:06:50 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21176 You might want to try again with the latest version of BB. I added a new test that's caused problems for Apple's rsync. It should also be more clear which tests are really important and which are not. You might want to try again with the latest version of BB. I added a new test that’s caused problems for Apple’s rsync. It should also be more clear which tests are really important and which are not.

]]> By: blue http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21165 blue Thu, 19 Jun 2008 11:23:13 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21165 rsync3.0.2 test on OS 10.5.3: $ sudo rsync -aNHAXx --protect-args --fileflags --force-change /Volumes/Src/* /Volumes/Dst/ $ ./bbouncer verify -d /Volumes/Src /Volumes/Dst Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... ok Verifying: creation-date ... ok Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... ok ok Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... ok ok rsync3.0.2 test on OS 10.5.3:

$ sudo rsync -aNHAXx –protect-args –fileflags –force-change /Volumes/Src/* /Volumes/Dst/

$ ./bbouncer verify -d /Volumes/Src /Volumes/Dst
Verifying: basic-permissions … ok
Verifying: timestamps …
Sub-test: modification time … ok
ok
Verifying: symlinks … ok
Verifying: symlink-ownership … ok
Verifying: hardlinks … ok
Verifying: resource-forks … ok
Verifying: finder-flags … ok
Verifying: finder-locks … ok
Verifying: creation-date … ok
Verifying: bsd-flags … ok
Verifying: extended-attrs …
Sub-test: on files … ok
Sub-test: on directories … ok
Sub-test: on symlinks … ok
ok
Verifying: access-control-lists …
Sub-test: on files … ok
Sub-test: on dirs … ok
ok
Verifying: fifo … ok
Verifying: devices … ok
Verifying: combo-tests …
Sub-test: xattrs + rsrc forks … ok
Sub-test: lots of metadata … ok
ok

]]> By: blue http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21164 blue Thu, 19 Jun 2008 10:41:02 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-21164 Latest patched version of rsync is perfect - see: http://www.bombich.com/mactips/rsync.html Bombich reports a perfect score with BackupBouncer! Mission accomplished??? Latest patched version of rsync is perfect - see:
http://www.bombich.com/mactips/rsync.html

Bombich reports a perfect score with BackupBouncer! Mission accomplished???

]]> By: johannes http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20911 johannes Sun, 01 Jun 2008 08:48:06 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20911 Hey n8, the problem was, that I checked the before and after version using SuperDuper and bbouncer told me that EVERY metadata was kept. When I checked the programme two month ago, I had another result. But somehow I managed to convince bbouncer to cast a more critical look. The results of a little collection of backup-tools can be found here: http://forum.macsofa.net/viewtopic.php?t=30508 The thread is in German, but I'm quite sure you'll figure out the important points... :-) Hey n8,

the problem was, that I checked the before and after version using SuperDuper and bbouncer told me that EVERY metadata was kept. When I checked the programme two month ago, I had another result.

But somehow I managed to convince bbouncer to cast a more critical look.

The results of a little collection of backup-tools can be found here:

http://forum.macsofa.net/viewtopic.php?t=30508

The thread is in German, but I’m quite sure you’ll figure out the important points… :-)

]]> By: n8 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20909 n8 Sun, 01 Jun 2008 05:13:34 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20909 @johannes: I'm sorry, I'm afraid I don't understand the problem you're having. Can you try to explain it once more? @johannes: I’m sorry, I’m afraid I don’t understand the problem you’re having. Can you try to explain it once more?

]]> By: n8 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20908 n8 Sun, 01 Jun 2008 05:12:09 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20908 @toubabou: Good to see you're paying attention, but there's nothing to worry about here. In the first case, the two volumes were not created in the same way for the simple reason that they weren't created at the same <i>time</i>. I generally tried to ensure that the BB tests would not be time-dependent, but it turns out the finder flags test is (modification time is one of the finder flags). So the files you created had different finder flags and BB correctly reported that. (That's the same reason for the "lots of metadata" failure, btw.) I'll change the finder flags test to be time-independent, but this isn't an issue that would cause problems verifying backups made with a backup tool. In the second case, the problem is caused by the way you mounted the Dst volume. When mounting disk images, the Finder by default treats all files as being owned by you. This is generally a sensible thing to do, but not in this case. BB creates files that aren't owned by you and checks to see that they stay that way. If you want to mount a volume preserving file ownership you need to do it from Terminal: <code>hdiutil attach -owners on Foo.sparseimage</code> Perhaps I should add a <code>bbouncer mount-vol</code> command for this... Thanks for the feedback. @toubabou: Good to see you’re paying attention, but there’s nothing to worry about here. In the first case, the two volumes were not created in the same way for the simple reason that they weren’t created at the same time. I generally tried to ensure that the BB tests would not be time-dependent, but it turns out the finder flags test is (modification time is one of the finder flags). So the files you created had different finder flags and BB correctly reported that. (That’s the same reason for the “lots of metadata” failure, btw.) I’ll change the finder flags test to be time-independent, but this isn’t an issue that would cause problems verifying backups made with a backup tool.

In the second case, the problem is caused by the way you mounted the Dst volume. When mounting disk images, the Finder by default treats all files as being owned by you. This is generally a sensible thing to do, but not in this case. BB creates files that aren’t owned by you and checks to see that they stay that way. If you want to mount a volume preserving file ownership you need to do it from Terminal: hdiutil attach -owners on Foo.sparseimage Perhaps I should add a bbouncer mount-vol command for this…

Thanks for the feedback.

]]> By: toubabou http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20907 toubabou Sun, 01 Jun 2008 02:31:30 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20907 FWIW I decided to try a little control group test. <code>bbouncer create-vol Src bbouncer create-vol Dst bbouncer create /Volumes/Src bbouncer create /Volumes/Dst</code> Now, when I compare these two, I should get identical files, because they have been created the same way. Not so. <code>sudo ./bbouncer verify -d /Volumes/Src /Volumes/Dst Verifying: basic-permissions ... ok Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... ok Verifying: hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... FAIL Verifying: finder-locks ... ok Verifying: creation-date ... ok Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... ok ok Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... FAIL FAIL</code> I also made a Finder copy of the Src disk image, mounted it as Dst and got : <code>sudo ./bbouncer verify -d /Volumes/Src /Volumes/Dst Verifying: basic-permissions ... FAIL Verifying: timestamps ... Sub-test: modification time ... ok ok Verifying: symlinks ... ok Verifying: symlink-ownership ... FAIL Verifying: hardlinks ... ok Verifying: resource-forks ... ok Verifying: finder-flags ... ok Verifying: finder-locks ... ok Verifying: creation-date ... ok Verifying: bsd-flags ... ok Verifying: extended-attrs ... Sub-test: on files ... ok Sub-test: on directories ... ok Sub-test: on symlinks ... ok ok Verifying: access-control-lists ... Sub-test: on files ... ok Sub-test: on dirs ... ok ok Verifying: fifo ... ok Verifying: devices ... ok Verifying: combo-tests ... Sub-test: xattrs + rsrc forks ... ok Sub-test: lots of metadata ... FAIL FAIL</code> G4 FW800 Mirrored drive doors, 1GHz, 1GB RAM Mac OS X Tiger 10.4.11 FWIW I decided to try a little control group test.

bbouncer create-vol Src
bbouncer create-vol Dst
bbouncer create /Volumes/Src
bbouncer create /Volumes/Dst

Now, when I compare these two, I should get identical files, because they have been created the same way. Not so.

sudo ./bbouncer verify -d /Volumes/Src /Volumes/Dst
Verifying: basic-permissions … ok
Verifying: timestamps …
Sub-test: modification time … ok
ok
Verifying: symlinks … ok
Verifying: symlink-ownership … ok
Verifying: hardlinks … ok
Verifying: resource-forks … ok
Verifying: finder-flags … FAIL
Verifying: finder-locks … ok
Verifying: creation-date … ok
Verifying: bsd-flags … ok
Verifying: extended-attrs …
Sub-test: on files … ok
Sub-test: on directories … ok
Sub-test: on symlinks … ok
ok
Verifying: access-control-lists …
Sub-test: on files … ok
Sub-test: on dirs … ok
ok
Verifying: fifo … ok
Verifying: devices … ok
Verifying: combo-tests …
Sub-test: xattrs + rsrc forks … ok
Sub-test: lots of metadata … FAIL
FAIL
I also made a Finder copy of the Src disk image, mounted it as Dst and got :
sudo ./bbouncer verify -d /Volumes/Src /Volumes/Dst
Verifying: basic-permissions … FAIL
Verifying: timestamps …
Sub-test: modification time … ok
ok
Verifying: symlinks … ok
Verifying: symlink-ownership … FAIL
Verifying: hardlinks … ok
Verifying: resource-forks … ok
Verifying: finder-flags … ok
Verifying: finder-locks … ok
Verifying: creation-date … ok
Verifying: bsd-flags … ok
Verifying: extended-attrs …
Sub-test: on files … ok
Sub-test: on directories … ok
Sub-test: on symlinks … ok
ok
Verifying: access-control-lists …
Sub-test: on files … ok
Sub-test: on dirs … ok
ok
Verifying: fifo … ok
Verifying: devices … ok
Verifying: combo-tests …
Sub-test: xattrs + rsrc forks … ok
Sub-test: lots of metadata … FAIL
FAIL

G4 FW800 Mirrored drive doors, 1GHz, 1GB RAM Mac OS X Tiger 10.4.11

]]> By: johannes http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20815 johannes Mon, 26 May 2008 18:16:00 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20815 Could anyone please perform a test of SuperDuper (latest version)? I tested them all bbounces tells me, that ALL of them made NO mistake at all, which can't be true, because my SuperDuper-version hasnt changed a bit since my last test. Something went wrong but I have no clou where to look. Could anyone please perform a test of SuperDuper (latest version)?

I tested them all bbounces tells me, that ALL of them made NO mistake at all, which can’t be true, because my SuperDuper-version hasnt changed a bit since my last test. Something went wrong but I have no clou where to look.

]]> By: Zemran http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20787 Zemran Sun, 25 May 2008 05:34:12 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20787 Thanks a lot for this. I recently had to restore from a Time Machine backup and found that it was total rubbish. It took me a couple of days to update and fix the problems with the data that Time Machine missed. I still find it hard to accept how much TM failed to back up although I accept it did save my data, just not the system. It restores the system to the original install (from the install disk) state before updates and I, being a *nix fan, had also made a lot of changes to make my system more like *nix. I had to run all the system updates all over again and download and install all the *nix stuff. I want to be able to run a restore that actually restores my system to a running system. It even trashed Aperture which is an Apple programme... I had to reinstall that from the original disk and update it again, but as I said, all my data was safe. I am now deciding on which 'real' backup solution to use in the future and this tool will be great in evaluating which is the best one to stick with. Thanks a lot. Thanks a lot for this. I recently had to restore from a Time Machine backup and found that it was total rubbish. It took me a couple of days to update and fix the problems with the data that Time Machine missed. I still find it hard to accept how much TM failed to back up although I accept it did save my data, just not the system. It restores the system to the original install (from the install disk) state before updates and I, being a *nix fan, had also made a lot of changes to make my system more like *nix. I had to run all the system updates all over again and download and install all the *nix stuff. I want to be able to run a restore that actually restores my system to a running system. It even trashed Aperture which is an Apple programme… I had to reinstall that from the original disk and update it again, but as I said, all my data was safe.

I am now deciding on which ‘real’ backup solution to use in the future and this tool will be great in evaluating which is the best one to stick with.

Thanks a lot.

]]> By: daisy http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20062 daisy Tue, 15 Apr 2008 23:13:47 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20062 Thanks for the tips and reassurance! I hope metadata preservation will soon be taken more seriously by all applications and backup solutions. The software should IMO clearly specify upfront what happens to the various metadata during any given operation. We need more tools like yours! All the best in your endeavors. Thanks for the tips and reassurance!

I hope metadata preservation will soon be taken more seriously by all applications and backup solutions. The software should IMO clearly specify upfront what happens to the various metadata during any given operation.

We need more tools like yours! All the best in your endeavors.

]]> By: n8 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20060 n8 Tue, 15 Apr 2008 22:57:54 +0000 http://www.n8gray.org/blog/2007/04/27/introducing-backup-bouncer/#comment-20060 No problem. I'm not a windows user but I'd assume the metadata you're talking about should be safe under any backup tool. Photo metadata generally lives inside the file itself, so as long as the file has been copied intact all the metadata should be safe. You *do* have to watch out for photo editors -- they'll sometimes drop metadata from files. (I'm big on photo metadata as well as filesystem metadata, by the way... :) ) No problem. I’m not a windows user but I’d assume the metadata you’re talking about should be safe under any backup tool. Photo metadata generally lives inside the file itself, so as long as the file has been copied intact all the metadata should be safe. You *do* have to watch out for photo editors — they’ll sometimes drop metadata from files. (I’m big on photo metadata as well as filesystem metadata, by the way… :) )

]]>