On Tue, Feb 7, 2012 at 12:03 PM, Joerg Schilling
<Joerg.Schilling@xxxxxxxxxxxxxxxxxxx> wrote:
>>> >
>> > When I implemented incremental restores for star in September 2004, I wrote a
>> > simple script for a incremental testcase and tested the deltas with
>> > ufsdump/ufsrestore, gtar and the star version at that time. Gtar was unable to
>> > deal with my testcase, so I stopped testing it any further.
>>
>> 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.
> 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.
> 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?
> Star on the other side just needs to remember dump dates and creates a full
> data base et extract side when doing incremental restores.
So what happens when you don't exactly match the source mount tree
configuration when you try to restore? You complain about GNUtar not
working in some special case - how is that worse than star not working
in the very common case of moving some mount points around? I do
that all the time. I don't think I've ever done the weird sequence
that causes trouble with a gnutar incremental restore.
> This is also more
> reliable than what gtar does as all needed information for the restore is in
> the archives.
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.
>> > If you like to discuss incrementals, you definitely need to discuss behavior at
>> > restore time and restoring incrementals definitely does not work correclty with
>> > gtar if you renamed directories.
>>
>> If that is the issue I recall, you can recover without losing data.
>
> You are correct, you could in theory recover the data but this must be done
> manually.
How do you recover from the mount point change case for star? If it
happens on the source side, do you lose data?
>> So it all that time you have not mounted a new volume somewhere? No
>> remote backups of hosts where someone else might add space? No one
>> ever wanted to restore onto a different mount topology than the one
>> where the backups were taken? Being able to do those things is the
>> reason I use tar instead of filesystem-dependent dump.
>
> Star of course can do what you like. You just need to create more than one
> backup once you split filesystems. It would be easy to handle if you like to
> use it....
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.
> The reason for not adopting star was that RMS did send me a contract that was
> illegal in Europe and RMS was unwilling to convert his contract into something
> that I could legally sign.
Well, no one has ever accused RMS of being reasonable...
>> And I thought there was another reason regarding features
>> that amanda used gtar as well - maybe it was the ability to quickly
>> estimate sizes of incrementals. If it had worked for amanda, I would
>> probably have been using it for ages. When I looked at it, it
>> couldn't because of missing features. These days I mostly use
>> backuppc with rsync as the transport since online access is so much
>> nicer than tapes and rsync obviously excels at detecting differences
>> in incrementals, but I suppose there is still a place for archives.
>
> 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.
> 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
made things from several machines fit on my one non-changer tape drive
every night for more than a decade with nothing on my part except
swapping the tape sometime during the day (and handled things
gracefully if I forgot). I don't think there was any alternative that
could have worked as well.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
