On Tue, Feb 7, 2012 at 9:26 AM, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de> 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 at gmail.com