Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> On Mon, 2005-10-10 at 04:13, Joerg Schilling wrote:
> > >
> > > Depending on why the original died and what I wanted to have when I got
> > > done rebuilding, changing filesystem types and/or mount points might be
> > > a good thing.  Certainly the ability to make those decisions at restore
> > > time is a good thing. 
> > 
> > Well, you told me that you use Amanda. A decent Backup control system should
> > be able to be able to handle your problem together with a backup system.
>
> Yes, but the GNUtar incremental mode has fewer constraints than dump
> or star.  Amanda can work with dump, but then you have to work on
> filesystem boundaries and make the restore mount topology exactly
> match the source.

Plese tell me where GNU tar should have fewer constraints and please
prove this.

GNU tar has even more constraints than star or ufsdump.

star and ufsdump only rely on one single time stamp in /etc/dumpdates
or /etc/tardumps while GNU tar in relies on a complete list of directories
and their inode numbers to be retained over the whole incremental backup period.

In addition, all these programs rely on st_ctime or st_mtime being newer
on files that did change in order to make it on the incremental backup.

Note that if you carefully read this, you will find that GNU tar definitely
not less fragile than star or ufsdump:

-	GNU tar depends on the inode numbers of directories and on
	ctime/mtime

-	star & ufsdump depend on the inode numbers for all files and
	on ctime/mtime. 

As GNU tar does not work _without_ the need to check inode numbers,
it depends the same way on them as star/ufsdump do. Star/ufsdump may detect
_and_ "replay" file renaming if the ctime for the file does not change, 
GNU tar may detect file renaming but will just remove the old file name
instead of renaming it during restore.

NOTE: you definitely do not need to create the same topology at restore time
when using star or ufsdump. You only need to restore backups from nested mounts
_after_ dou did complerely restore the higher level parts of the directory tree.


> > -	The usual way for a backup is to backup whole filesystems.
> > 
> > 	However, star allows you to backup _partial_ filesystems if you
> > 	care about the constraints. The constraints are that (on a fully
> > 	POSIX compliant system) no directory from outside the scoped area
> > 	may be renamed _into_ the scoped area and (in case ctime is not
> > 	following POSIX rules) no _file_ is moved from outside the scoped
> > 	area _into_ the scoped area.
>
> Exclusions are important.  For example I never back up /var/spool/squid
> but that seems to fit your constraint since I can count on nothing being
> renamed in or out of the cache.

Wit ufsdump you are not able to exclude anything, with star you may do this
if you care about constraints. So you may call ufsdump less functional.



> > -	If you are talking about mount points inside a _logigal_ area, then
> > 	any part of a directory tree that is below the mount point is
> > 	a complete filesystem to backup.
>
> The piece I consider a valuable difference for gnutar is that it would
> be reasonable to back up a single file system (for example where /home
> and /var are included as part of /) and restore it to a different
> topology, perhaps with /home and or /var as mount points.  Gnutar
> would only have issues with hardlinks spanning the filesystems which
> are unlikely to exist in cases like that. The rest of what happens
> in an incremental restore would still work correctly.  The other
> advantage of tar-style file handling is that I would expect less
> to go wrong with changing portions when backing up active filesystems.

See above and read what I did write in earlier mails. Star also does not
have any problems to do the backup in this case.

Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily