(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