Paul Wouters [[EMAIL PROTECTED]] writes:
> 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.
Well, as you note, you wouldn't likely be using --delete for the large
log files, so on the off chance that they get blown away, nothing
would get copied.
My thoughts were really just for the specific question you raised
about incremental large log files. It sounds like you have other
requirements for which a log file solution might not be appropriate.
I guess it depends on what you're really trying to achieve with the
backup of log files. I guess I read your note as you just wanting to
have a current backup of what was on the remote system, but I agree it
may not be as suitable in terms of a daily snapshot if you also want
to cross a case where the log file is deleted and recreated. Deleted
is ok, but recreated would then lose the older information.
> 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.
But for log files do they really need a copy of just what it was on
that day as a separate file or do they just want the log data. If the
log is timestamped on the lines, you could always filter by that too
if you had to.
Web files are probably quite different, but I wasn't suggesting you'd
use this approach for anything other than the incrementally growing
log files.
> 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.
Of course, then you'd have the issue of the file to reference when you
wanted to backup the next day. Unless you also modified rsync to
reference an original file as patched by 'n' deltas before it tried to
compute the new delta - either that or you'd have to go back to the
last week's full file and each day replicate the prior days
information as well.
Hmm, if you really want to store pure deltas from a common base (say
from the first day of the week), how about just doing it externally to
rsync - just transfer day n's file using rsync, and then when you have
the full file, use diff (or xdelta if you want an rsync-like
algorithm) to create a patch from whatever baseline you like. If you
store diffs for each day from the prior day, you could automate
applying the necessary patches to days 1-(n-1) to create the file used
during the rsync and subsequent diff on an as-needed basis.
> (Okay, the third is getting an insane amount of diskspace so I don't care
> anymore)
Might be a really cheap option all things considered nowadays :-)
-- David
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: [EMAIL PROTECTED] /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
