[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Seeking Wisdom Concerning Backups



On Fri, Feb 29, 2008 at 04:39:02PM -0600, Kent West wrote:
> Douglas A. Tutty wrote:
 >
> >First decide if you want to have a local tarball on the box and then
> >transfer the tarball, or if you want to create and transfer the tarball
> >in one step.
> I'd prefer to not have to create the tarball locally first, but rather 
> the create it on the fly as it's being transferred to the backup server.
> 
> >  Either way, I would use a tarball.  You say you wish to
> >backup /home so that's easy (assuming no --excludes).
> At this point, no I'm not worrying about excluding anything, except 
> perhaps for mounts under /home (such as networked drives or flash drives 
> -- (I sometimes will mount a network drive under my home directory)).

I think you have a couple of options: read man tar (actualy, you'll need
the non-free tar docs.  They're in info format use either info or pinfo
to read it).  My script uses an --exclude which reads a file of files to
exclude.  That exclude file I have under /etc/backup/exclude.  I also
have an /etc/backup/include file but if you just want /home then you
don't need that.

> 
> >  Note that if you
> >don't want a copy of the tarball locally, you'll need an ftp client that
> >can take stdin as input.  If that doesn't work, see if it can take a
> >named pipe (fifo); you would make a fifo in, e.g. /var/local/backup and
> >pipe things to that then pipe from that to the ftp client.
> >  
> 
> I'm afraid you made me dizzy here.

Read man 7 fifo.  You create the fifo, almost like creating an empty
file with touch, then in your pipe-dream :) instead of, e.g. 

cat README | less

You could do:

cat README > /var/local/backup/pipe

less /var/local/backup/pipe

The fifo itself has no size.  Processes writing to it block until
something tries to read from it.
 
> >Then compress the tarball.  Just use gzip.  bzip2 makes slightly smaller

> >archives but uses a lot more CPU time and isn't available on default
> >installs.
> >
> >Then if you want to encrypt the tarball, run it through OpenSSL's
> >encryption, e.g.:
> >
> >openssl bf -a -e -salt -in {file} -out {file.bf}
> >
> >If this is going into a pipe-line, then -in and -out would not be needed
> >as they default to stdin and stdout.  You'd also want to provide it with
> >a password source if you want it automated.
> >
> >This file.tar.gz.bf (or file.tgz.bf) tarball would then get sent via ftp
> >to the backup server.
> >
> >To make this automated, you'll need to write a simple script.
> >
> >We can work on the details but let me know if my assumptions are valid
> >(e.g. standard ftp will work).
> >
> >  
> 
> Encrypting the tarball as it goes across the 'Net would be fine, as long 
> as it doesn't cause problems later on when it comes time to restore files.

When you go to restore files, you'll just need to ensure that you have
openssl installed and that you remember the password/passphrase.  This
is one reason why I use openssl instead of gpg.  Gpg has to be set up,
it needs its own infrastructure.  Its also not in the base install of,
eg OpenBSD whereas OpenSSL is.  

To pull back your encrypted tarball from the server and deposit the
contents on the local disk, you'd use the ftp client, have it transfer
the file to stdout (or the fifo) then pipe that through openssl (using
the info I supplied [or from the man page for enc] and pipe the output
to tar.
> 
> Thanks for the response!

You're welcome.

Verify the nuts and bolts of using a fifo; I haven't done it in years
and then only once.  

Doug.


Reply to: