On Thu, 15 Feb 2001, David Bolen wrote:
> Is there a reason that you can't just use a single backup location
> based on a weekly cycle even if you're backing them up daily? (E.g.,
> rather than $DATE for the output directory on your daily runs, compute
> a target directory based on week rather than day)
Yes, imagine your nice logfiles being reduced to 0 bytes because someone
removed them on the server. My backups will vanish as soon as rsynch is
done (assuming --delete). I'm not using --delete on the incremental, but
want to use it on the week-old copy. Also, logrotate scripts could spoil
the fun here. And not only logfiles. Imagine one client who plays with
Frontpage and wait until they accidently delete their entire webtree 5
minutes before rsynch starts. (okay, not using --delete helps a bit here)
> You'll always have the most recent backup in that directory
> (incrementally updated by rsync), but each daily copy will update the
> same file centrally for that week, rather than making separate copies.
But I don't want that. The reason I want the entire directory tree like
this is that I can go back 1-7 days without much problems, so if clients
delete their files (web OR log) that I can give them back an old copy.
This works fine, except for big files who get some data appended. Actually,
the cool way would be a switch to rsync saving just its internal 'diff state'
and store only that to disk. This way you only have the big file, and the
incremental changes of single files as well.
Also, since I want clients to be able to ftp their logfiles, and I use
proftpd to limit their access on the server (chroot them into their "homedir")
the original logfiles can't be in some dedicated logdir, but have to reside
within each clients "homedir", so they are scattered all over.
There are two ways out that I can see:
1) Change the weblogs (system logs aren't _that_ big, those aren't the real
problem here) to lots of small files (weekly or daily files). This is a
pain again for the statistics programs that need them, as well as the
potential client who just wants one file.
2) Use exclude patterns for the logfiles with rsync, and use a seperate script
alltogether that only does logfiles, and will perform some sanity checks
before transfering (checking if size really increased) the files with rsync,
so it becomes safe to only stash one copy of the logfiles on the backup
server.
(Okay, the third is getting an insane amount of diskspace so I don't care
anymore)
Paul
