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
Attachment:
pgpIFlRFAuXt2.pgp
Description: PGP signature