Re: non-interactive ftp

[Craig Sanders <cas@taz.net.au>]

On Sun, Nov 27, 2005 at 04:00:00PM -0500, Phil Dyer wrote:
> but if you do it like above, won't you only have 7 days, and then it
> starts overwriting? No need to rotate. I see a script doing something
> like this:
> 
> #!/bin/bash
> 
> weekday=`date +'%a'`

personally, i'd use '%u' (numerical day of week) so that directory
listings sort correctly. or '%u_%a' so that it sorts correctly AND is
human readable. but it doesn't really matter.

actually, i'd be more likely to use '%Y%m%d' (YYYYMMDD) and delete any
excess backups, either manually or in a cron job.

> tar cvf - /home | ncftpput -u operator -c server \
> /backups/home_$weekday.tar

and i'd certainly use ssh rather than ftp. even on a local network, ftp
is exposing the operator account's password in cleartext.

ssh can be set up for passwordless access (public key authentication),
and can restrict what can be done in the ssh session with the
"command=..." option in the authorized_keys file.

to use ssh rather than ftp:

tar cvf - /home | ssh operator@server "cat >/backups/home_$weekday.tar"


if disk space is an issue, then compress the tar file.  either before
transferring it over the network like so:

tar cvfz - /home | ssh operator@server "cat >/backups/home_$weekday.tar.gz"

or after, like this:

tar cvf - /home | ssh operator@server "gzip >/backups/home_$weekday.tar.gz"






overall, though, i'd only use a scheme like this for backing up small
quantities of data - configuration files and so on. for large data sets
like /home, i'd buy a decent tape drive (preferably an autoloader with
at least 7 cartridges, one for each day. they're expensive new, but can
be quite cheap second hand. buy the best you can afford - there's not
much point in backing up important data to unreliable equipment) and set
up amanda.

BTW, another useful backup technique for small data sets like config
files is to use a revision control system like RCS or subversion. if
you get into the habit of checking in files whenever you change them,
you not only have a backup, you have a complete history of changes to
them (with comments describing the change if you're disciplined about
leaving comments when asked). i often make this a part of the procedure
for common tasks - e.g. i usually set up systems so that in order to
make a change to a configuration, you edit the relevant config file and
run "make". the Makefile script then does whatever is needed to activate
the changes, and checks in the changed files to RCS.

craig

-- 
craig sanders <cas@taz.net.au>           (part time cyborg)