On Wed, Feb 8, 2012 at 6:20 AM, Joerg Schilling <
Joerg.Schilling@xxxxxxxxxxxxxxxxxxx> wrote:
> Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
>
>
(For bystanders following this conversion, it is only about the
non-standard extensions (--listed-incremental, etc.) to tar. Standard
modes are fine on either gnutar or star).
> >> My testcase for star was moving a subdirectory of what my backup runs
> > >> covered onto a mounted volume. Star failed and I stopped testing it
> > >> any further.
> > >
> > > So you tried to do something that cannot work for a filesystem
> oriented program.
> >
> > It does work with GNUtar.
>
> In general, this does not work with gtar. You are exactly in the area that
> caused my conclusion that gtar is not useful at all for incremental
> backups.
>
>
No, a general file-oriented case would handle FAT and NTFS filesystems, and
continue to work even if you mount one of those in the path of your planned
backup or restore. Star fails that.
> > > This is not a problem from star but you just did not use star the
> right way.
> >
> > No, star does not do what I need, so I don't use it at all.
>
> Star does what you need, you are just using it the wrong way.
>
>
I don't plan to arrange my life or my data around star's restricted
capabilities.
> > Note that gtar uses a big database that is needed at the dump side and
that
> > still does not hold enough data to let gtar work correctly.
>
> How is it not correct?
As mentioned, gtar has major problems whe directory is envolved. How many
> successful restores did you pass?
>
All of them. Even the contrived case you sent me when we had this same
conversation years ago. The saves always work and the only issue there
has ever been is when a restored directory is supposed to be deleted and
replaced by a file of the same name as an incremental update (or maybe the
other way around...). It's something that has never happened in years of
operations and recoverable if it does - just delete the offending item and
repeat the restore of the thing that ends up there. And it might be fixed
now - I haven't been concerned enough to check.
> The difference between gtar and star is that gtar never works correctly
for all
> possible changes, while star works correct and you just need to follow it's
> constraints. As gtar does not work on a simple testcase, I am not willing
> to
> trust in gtar's incrementals.
>
Here's the simple test case. Plug in a FAT-formatted USB key in the path
of your backup. Change something on it and repeat with your incremental
mode. Restore it with or without the key mounted in that position. If
that doesn't preserve the data in a way you can restore, I'm not willing to
trust it for my backups. Or if you are biased against FAT, use the
filesystem of your choice, just do it dynamically.
> Except when it isn't, because it is tied to the filesystem, not the
> directory tree structure. If I wanted filesystem dependencies I'd use
> dump. I expect tar to follow directory trees and be agnostic to mount
> points.
It may be that you miss the fact that modern filesystems like e.g. ZFS may
> be
> able to move a directory tree into a "new filesystem" without affecting
> ctime.
>
>
That breaks the definition of ctime, doesn't it? But it doesn't matter to
GNUtar because if it hits a directory in a location that doesn't match what
is listed in its -listed-incremental file it will back it up with
everything below it.
If gtar would be implemented correctly, it would need to maintain a huge
> database for the lifetime of the filesystems tobackup.
>
No, it needs a small file for each state of a tree where you plan to do a
subsequent higher level incremental. And amanda manages this for you.
> You also seem to miss the point that in case you like to move a sub-tree
> into a
> different filesystem (something that is extremely unlikely to happen with
> modern
> filesystems), you need to do a lot of adminstrative work anyway.
Sometimes it is, sometimes it is plugging in a usb device, and sometimes it
is someone else's administrative work, unrelated to the backup
configuration.
Adding a new
> FS to the list of FSs in the backup system is a minor task in this context.
>
> What star allows you to do is to have incrementals that are as reliable as
> ufsdump but that are independent from the OS and the FS.
>
>
That would be better stated as 'as filesytem dependent as ufsdump'. It is
not independent from the FS at all or I'd be able to point it at an
arbitrary directory without knowing or caring if it encompasses a whole
filesystem or has additional mounts. Or if the layout is the same during
the restore.
> I handled it by pointing amanda at remote systems. And I expected it
> > to keep those systems backed up even if someone else mounted some new
> > disks in places where they needed some more space. I don't see how
> > star fits into that scheme.
>
> Well as mentioned before, if you reconfigure your server, you also need to
> reconfigure the backup to match the new situation at the server.
>
They are different machines. Why should I need to know if someone else
moved /home to a separate volume just to correctly copy the data that has
changed since the last backup run?
> > AFAIK, amanda has too few features or there are no people who are
> willing to
> > > put efforts in adopting to star.
> >
> > Star simply does not do what amanda needs - or did not the last time I
> > looked. Amanda needs a way to quickly estimate the size of a run for
> > its brilliant feature of automatically balancing the mix of fulls and
> > incrementals to ensure that you get at least an incremental of every
> > target every night plus a full within the number of tapes in your
> > rotation. And it can't fail on incrementals just because someone
> > replaced a directory on a remote machine with a mount point.
>
> This is an unproven claim from you. I grant you that star supports all you
> need
> for a reliable incremental backup and restore.
>
It does, under the same restricted conditions dump would - and amanda
already works with dump. The reason I use tar instead of dump is to not be
restricted to those conditions.
> > I currently cannot believe that there is really any important feature
> that is
> > > missing in star.
> >
> > Those features obviously aren't important to you, but they are enough
> > to keep me - or any amanda user - from considering star. And amanda
>
> If amanda does not support star, it seems that the amanda people are not
> interested in reliable backups.
>
No, they already have dump for the things that star could do.
> Star supports everything you need, if Amanda does not support star, this is
> obviously a filure at amanda's side.
>
It just doesn't add capabilities the way GNUtar does so there is no need
for it. And I don't see any support for size estimates like dump provides,
which are very necessary for amanda to arrange each set of incremental and
full runs to fill a tape. Can you do anything that matches the speed of a
gnutar run of : 'tar --totals -cf /dev/null /path' ? I'll agree that what
GNUtar does in that special case is weird (or at least that the reason it
does it is weird) if you'll agree that it is necessary for practical
reasons.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
