(no subject)
[email protected] (Joerg Schilling) Thu, 20 Mar 2008 12:08:58 +0100
| Newsgroups | gmane.comp.archivers.star.user |
|---|---|
| Message-ID | <47e245ca.hpjYqR7R9mzIrWtY%[email protected]> |
Lasse Kliemann <[email protected]> wrote: > > My example from the man page > > = > > = > > echo > /tmp/snapstamp > > = > > mount -r `fssnap -F ufs -o \ > > backing-store=3D/var/tmp/EXPORT-NFS.snap /export/nfs` /mnt > > = > > star -c -xdev -sparse -acl -link-dirs level=3D0 -wtardumps \ > > f=3Darchive-name dumpdate=3D/tmp/snapstamp \ > > = > > = > > will also archive some files twice although not needed because /tmp/sn= apstamp is > > older than the snapshot itself. > > Yes, and a sleep would have no effect here (save for the whole procedure = > taking one second longer then necessary :-). > > > By the way, this three-step-method (touch file, take fs snapshot, dump) c= an = > in fact lead to a significant amount of data archived twice, at least on = > Linux and under extreme conditions. I did tests once with blogbench runni= ng = It may do even on Solaris, as it takes more than a minute to set up a snaps= hot for a big filesystem. If this is really a problem is hard to tell as fssnap= (1) = first applies a write lock to the filesystem... > If one does that rsync-mirror-method I described earlier (keep a mirror o= f = > the filesystem via rsync, use star on the mirror) this no longer is an is= sue. = > For rsync works without timestamps, and star, in that case, can work with= out = > dumpdate=3D..., because star can rely on the ctimes on the mirror; they a= re = > updated by rsync. But since this method itself brings a significant space= and = > time overhead, it should be rarely prefered. I have no problem with the backup method that is described in the star man = page. It is run once every night on Berlios and we have approx. 10 GB data change= and > 5000 changed files every day. J=F6rg -- = EMail:[email protected] (home) J=F6rg Schilling D-13353 Be= rlin [email protected] (uni) = [email protected] (work) Blog: http://schily.blogspo= t.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/sch= ily