backup strategy (Re: dump | restore fails)
mi+thun at aldan.algebra.com
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-fs