List,
I've implemented backups with dump/restore over ssh to a remote server. The backups work just fine, basically doing something like
dump -0au -f - / | bzip2 | ssh remote.host \ dd of=/backup/root.bz2
Now backups are only useful if you can restore from them... so I deleted a file and then tried to restore it. I figured the command would be
ssh remote.host dd if=/backup/root.bz2 | bunzip2 \ | restore -vxf - etc/foo
This produces the following output:
[...]
And my file hasn't been restored :(
I could always ferry the entire dump file over, decompress it and then restore from it, but the files in question are pretty colossal, and at some point down the road I won't have enough free space to do it anyway.
Answering my own question, should people ever encounter the same problem.
Sending the dump over to the remote system works fine, what doesn't work is bringing it back and trying to restore from it. The other night I had a 3:00am brainwave, and realised that I should try and restore locally on the machine that received the dump file.
Logging into that remote server, I ran
bzcat root.bz2 | restore -vxf - etc/foo
and Bingo! after some 4 minutes of CPU time it asked me "set owner/mode for '.'? [yn]" question. I answered yes, and received my file, although the ownerships were a bit messed up because of uid/gid mismatches between the two systems, but that's easy enough to fix.
Now that I know the approach works this way I think I actually prefer it, because at least this way I know there's absolutely no way the restored file can clobber the file to be restored, since I'm doing it on a different system. (I have done this before; it's quite painful to explain to the luser).
It's interesting to note in passing that today's current high-end servers - Pentium Xeon 3GHz, 15krpm SCSI disks, 1000Base-T - offer such performance that you can do backups this way and still have plenty of headroom left on your CPU, disks and network to do your usual work.
So, hope this helps someone.
David
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
