[CentOS] schily tools

[Joerg Schilling]

Les Mikesell <lesmikesell at gmail.com> wrote:

> >> 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.

In general, this does not work with gtar. You are exactly in the area that 
caused my conclusion that gtar is not useful at all for incremental backups.


> > 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.

Star does what you need, you are just using it the wrong way.


> > 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?

As mentioned, gtar has major problems whe directory is envolved. How many 
successful restores did you pass?


> > 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.

The difference between gtar and star is that gtar never works correctly for all 
possible changes, while star works correct and you just need to follow it's 
constraints. As gtar does not work on a simple testcase, I am not willing to 
trust in gtar's incrementals.

> > 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.

It may be that you miss the fact that modern filesystems like e.g. ZFS may be 
able to move a directory tree into a "new filesystem" without affecting ctime.

If gtar would be implemented correctly, it would need to maintain a huge 
database for the lifetime of the filesystems tobackup.

Star on the other side only needs to remember the last backup dates for every 
different incremental level.

You also seem to miss the point that in case you like to move a sub-tree into a 
different filesystem (something that is extremely unlikely to happen with modern 
filesystems), you need to do a lot of adminstrative work anyway. Adding a new 
FS to the list of FSs in the backup system is a minor task in this context.

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.


> > 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?

Star handles directory changes correctly, there is no loss of data.

If you remove a sub-tree on the source side, this is also done at incremental 
restore time. 

> >> 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.

Well as mentioned before, if you reconfigure your server, you also need to 
reconfigure the backup to match the new situation at the server.

> > 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.

This is an unproven claim from you. I grant you that star supports all you need 
for a reliable incremental backup and  restore. 

> > 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

If amanda does not support star, it seems that the amanda people are not 
interested in reliable backups.

Star supports everything you need, if Amanda does not support star, this is 
obviously a filure at amanda's side.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily