On 14:19 22 Jun 2003, Ashley M. Kirchner <[EMAIL PROTECTED]> wrote:
| Cameron Simpson wrote:
| >How sure are you? Rsync on its own doesn't do that - you need to have
| >a separate pass that makes a link tree and then rsync that. Is that
| >your setup?
|
| Oh yeah, daily.01 gets linked to daily.02 by running a 'cp -al' on
| them. Then Rsync runs on daily.01.
Ah - excellent.
| >A "df -k ." on your backup directory after each backup run will tell
| >you if you're copying everything fresh or making linked trees with
| >few differences.
|
| Surely you meant du, not df. :)
No, I meant df. Because that will tell you how much space is really being
used up _without_ having to run a du over the tree (which can lie unless
it sees every link).
| Hmm okay, maybe I'm not patient
| enough to sit and watch the very lengthy output of -k... I realize what
| I really wanted was 'du -k --max-depth=1 .' This will list all those
| daily's without their contents scrolling off my screen.
Well, "du -ks" if you want to be portable (and succinct).
| >My suspiscion is that unless you've neglected to mention some part of
| >your backup arrangements you're getting complete copies, not "incremental"
| >trees.
|
| I just did a dry run on one of the smaller backups and it appears to
| be doing what you said it should be. So I think all is well. I think I
| also found the problem that lead me to believe it wasn't doing what it
| should've been doing. The backup I was checking had a large (2.7 GB)
| file in it that was being backed up every single day because it's a log
| file. Consequently, the daily differences were rather small. Now that
| I've removed it, it appears to be working properly.
Glad to hear it.
I presume you removed it with --exclude, yes? Otherwise you'll be copying it
and _then_ removing it - wasteful.
You may be interested in this:
http://www.cskk.ezoshosting.com/cs/scripts/histbackup-prune
which I wrote yesterday. It takes a directory like yours with lots of backups
and removes the oldest until a certain amount of free space is present.
It assumes each backup dir is named yyyy-mm-dd rather than daily.01 etc,
but otherwise is handy when your backups start to fill the disc, which
was the circumstance which prompted its coding. It's part of the css
scripts collection:
http://www.cskk.ezoshosting.com/cs/css/
specificly it wants a few other scripts from there so it's easier to just
grab the tarball.
The naming issue can be hacked by adjusting the "ls ... | sort" code just
ahead of the main loop. Note that the ordering is important for the $keepn
stuff (which protects you from ever removing your latest backup(s)).
Or, of course, by changing your backup naming to use ISO dates (which I prefer
because I then know the backup date at a glance).
Cheers,
--
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/
Win3.1, MSDOS and Win95 will not recognise FAT32[...]. MS's plans for
supporting FAT32 in NT are still being determined[...] At minimum, MS
will provide a utility to convert FAT32 to NTFS.
- MS introduce yet another incompatible and unsupported-on-
other-platforms data format with Win97, from May 1996's
http://www.microsoft.com/windows/pr/fat32.htm, paraphrased
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
