nate wrote: > Brian Victor said: > > I backed up my debian installation with the following: > > > > tar --preserve -cv / | ssh 192.168.2.10 'cat > linuxbackup.tar.bz2' > > may I ask why? I have never heard of someone attempting such > a task in that manor. I would say that the above is the source of > the problems. Checking tar's manpage reveals no mention of the > preserve option either.
The manpage for tar 1.13.25-5 (unstable) does indeed document
--preserve. It's the same as "-p -s".
Tar shouldn't care where it's output is going, so symlinks should have
been stored properly in the above example as far as I can tell.
Personally, I have always preferred a multi-stage approach to backups,
like this:
1. Build a list of files that need to be backed up
2. Build encrypted tarball of said files
3. Transmit files to remote site
For example, for a daily incremental backup relative to the most recent
weekly backup:
find $(cat backuppables) -newer $datadir/stamp_weekly '(' -type f -o -type l ')' |
sed -f $datadir/excludables >backup-$$
tar --create --absolute-names --atime-preserve --bzip2 --sparse
--files-from=$datadir/backup-$$ | mcrypt -q >daily.tar.bz2.nc
rsync --rsh="ssh -i $idfile" --times --verbose * $remotedir/
The backuppables file is a simple list of directories that are to be
backed up. The excludables file is a sed script (really just a series of
"remove lines matching this regexp" commands) to filter out things that
I don't want to back up, like CVS subdirectories, .o files, and so on.
Craig
pgp00000.pgp
Description: PGP signature
