On Fri, Feb 10, 2012 at 6:05 AM, Joerg Schilling < Joerg.Schilling at fokus.fraunhofer.de> wrote: > > 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. > > Well, I verified that gtar fails with even a simple case and I did not see > any > problem with star since 6 years even with thousands of incremental > restores. > So I am not sure what you are talkin about. > Gtar doesn't fail, it just requires some extra steps to accommodate some very unlikely circumstances. Your star runs will not work at all in very likely circumstances (which you conveniently avoid testing). > How many successful automatical incremental restores did you try with gtar > so > far? 1/12 dozen? > Enough to know it works. Star's incrementals are file oriented and this is why it is able to offer a > OS > and FS independent incremental backup. > > Our definitions of 'OS and FS independent' are very different. I expect that to mean that I can actually change the FS and have things keep working. Star doesn't. And it doesn't work over nfs, on fat, ntfs, and on and on. > I don't plan to arrange my life or my data around star's restricted > > capabilities. > > This is a really strange claim, as you obviously follow the rules in case > you > create a new filesystem. > > What rules? If you are FS independent, you follow a directory tree, not a rulebook. I want the content of my files backed up whether they are stored in a way that matches your restricted rules or not. I don't want to have to take a whole filesystem. I don't want a run to be restricted to a single filesystem. Now please explain me why you are doing backups with a program that is known > to fail with incremental restores? > > In a word, amanda. If my backups don't fit on the tape there are no backups at all, and the only reason for doing incrementals at all is that you have to use them to make the data fit. I'm not interested in calculating the right mix of incremental levels on a whole bunch of directory trees to make each night's run fit. Amanda does that automatically. Amanda can use dump or gnutar. Linus Torvald has claimed that dump is not safe on live filesystems. I assume he's an expert on the topic (and without looking at the code, I'd guess that star uses the same approach to determine what to take in incrementals). That leaves gnutar. I can live with a very unlikely chance that I'll have to give a few extra commands to restore compared to not getting backups or having to compute the size of incremental levels manually every day. And then there was the fact that at the time I implemented amanda, star did not do incremental restores anyway... > Well gtar failed with my first simple test already, why do you still > believe it > works? > > Because the data is on the tape and can be extracted if you move the same-named but different object type thing out of the way first (and admit that it wouldn't be there except in a contrived test). The commands to do it might not be convenient, but it is much, much better than using a tool that in many circumstances won't have the data at all, or can't restore it onto a different mount topology. > 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. > > Why do you like me to do some really strange test while your backup method > is > know not to work at all? > OK, here's a test that is a very common scenario. Boot a dual-boot windows/linux laptop into linux, back it up in a way that includes the mounted VFAT and NTFS partitions. Make changes on the VFAT or NTFS locations under linux or windows. Make an incremental backup that includes all the changes. > Would'nt it be better to first switch to a working backup program? > > As you stay with gtar, it seems that rather you are biased. > > Strictly a pragmatic choice. GNUtar works, where star did not. > Also note that reliable backups need to use snapshots, so please rethink > your > backup method under the right constraints. > > But FS snapshots take extra disk space and not all file systems provided them back then. That does not make the file contents less important. So if really like you move a sub-tree into a separate filesystem, only the > top > level directories are granted to get ctime updated. > > BTW: Why should gtar work in your case when it already fails with > incremental > restores for simple directory rename operations? > > The one incremental restore inconvenience you found has nothing to do with the way --listed-incremental backups work. They are not tied to filesystems or mount points. They follow directory trees. > 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 seem to have a strange concept of what's a "small" file. > > The file we are talking about may easily reach a size of several GB. > > So first we need room for filesystem snapshots, but now storing a file big enough to hold the equivalent of a directory listing is a problem? > > 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. ??? > Can you, using star, make incremental backups of a directory tree that work without knowing./caring what file systems hold that tree or where the roots or mount points are? If you have incremental backups that were made under the restrictive conditions that star requires, can you restore them correctly on a different topology? For example, you backed up / from a small machine with no mounted partitions. It breaks and you replace it with a new machine that has an additional drive that you mount as /home. Can you restore the incremental levels of the /home portion of the backup onto this replacement system, along with some things still on the root partition? > > > No, they already have dump for the things that star could do. > > Did you ever think about the fact that the various BSD dump descendants do > not > share a common archive format? > > Does that matter if I have the code for the one that reads my format? Star being OS and FS independent allows you to e.g. restore any incremental > on > any OS and does not force you to first manually port the actual "restore" > program to your current restore OS. > > That would be nice if it were true. The most likely non-native target would be windows. Should I plan on that working? What about the simpler case of the same OS but an added mount point in the layout where I want a portion of the restore to go? I cannot tell when gtar introduced this strange method that makes > performance > tests hard.... > > I expect actual backups to be i/o bound to a point that whatever else they do performance-wise is irrelevant. Star introduced the -onull option more than 15 years ago and I asume that > potential users start with reading the man page. > > I didn't see an option for reporting size in the man page - it might actually be adaptable if anyone still cared about tapes. But, I find the man page very confusing. Most of the incremental options say it has to be a single Posix-conforming FS but the -dump section talks about spanning more than one. Anyway it is mostly irrelevant for me now that online backups are feasible in terms of disk space and bandwidth to offsite storage. It is so much easier to click on a version of a file you want in backuppc's web interface than to request the right series of offsite tapes to be shipped back and restore them in the right order to get to the date it should have been there. -- Les Mikesell lesmikesell at gmail.com