On Tue, Feb 7, 2012 at 9:26 AM, 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.
> 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.
> Star is used to do incremental backups/restores on a dayly base in Berlios
> since September 2004. Since Spring 2005, not a single problem was seen, so
> there are more that 2500 successful incremental restores that verify no problem
> even under stange conditions.
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.
> This problem is not caused by compression or not, it is a general gtar bug that
> I reported in 1993 already. Nobody knows why it hits and the structure of the
> gtar sources makes it really hard to debug this problem. The FSF was interested
> to throw aywa gtar and replace it by star 10 years ago for this kind of
> problems in gtar.
So, you have a repeatable test case for this and no one has looked
into it? That's surprising considering the number of people who have
contributed to gnutar. And what drove the decision not to adopt
star?
> The following other problems are known with gtar:
>
> - gtar is with aprox. 5% probability unable to read it's own
> continuation archives from multi volume archives. This cannot be fixed
> as it is caused by the concept used for multi volume archives in gtar.
I assume you mean the version where you let the tape drive hit the
end, not where you tell it the length. Does star always work in that
scenario?
> - gtar has much less features than star
Unless you would like it to do incrementals properly across mount
points... 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.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
