On Fri, Feb 10, 2012 at 6:05 AM, Joerg Schilling <
Joerg.Schilling@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
