backup strategy (Re: dump | restore fails)

Mikhail T. mi+thun at
Thu Mar 26 18:52:48 PDT 2009

Greg Black написав(ла):
> Sorry, this person is *not* making backups in any meaningful fashion.
> Unless you verify regularly (preferably every time you make a backup)
> that you can restore both parts of the backup and the entire thing, you
> are not making backups.
To qualify for your (and your kind's) recognition then, a person needs 
to have at least as much extra storage capacity as the largest 
filesystem they are backing up. They also need non-trivial scripting 
abilities, because the OS doesn't include anything like what you are 
describing (and I already do consider scheduling dumps via cron 
"trivial", which may be a stretch). Yours may thus be an acceptable 
requirement for a multi-computer shop with dedicated system 
administration personnel, but for a private home user with only one 
computer this simply is not reasonable.

Stating this as a requirement is ridiculous -- unless you are prepared 
to say, that such people should not own a computer (with worthy data) at 
all. And that's even more ridiculous... Make your pick.

I would agree with you, if the chosen backup method involved some 
complex or third-party tools. But if the simple, OS-supplied orthogonal 
dump/restore don't work together, then the OS is broken -- plain and 
simple, and pointing a finger at the user: "Well, it is all your fault, 
because you relied on us providing you with working utilities, 
ha-ha-ha!" -- is the lamest excuse imaginable.


P.S. Some people have actually volunteered to help debug this problem 
and I'm working on providing them with data (the troublesome partition 
is, sadly, over 170Gb, so it takes a while). Any results/conclusions 
will be posted under the original subject.
P.P.S. The data transferred fine using tar, but that is not the point -- 
the bug (confirmed by at least one more person) -- needs to be fixed 
before a higher-profile embarrassment...

More information about the freebsd-stable mailing list