On Wed, Feb 8, 2012 at 6:20 AM, Joerg Schilling < Joerg.Schilling@fokus.fraunhofer.de> wrote:
Les Mikesell lesmikesell@gmail.com 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.