Taken from xfsdum man:
Each invocation of xfsdump dumps just one filesystem. That invocation
is termed a dump session. The dump session splits the filesystem
into
one or more dump streams, one per destination. The split is done
in
filesystem inode number (ino) order, at boundaries selected to
equalize
the size of each stream. Furthermore, the breakpoints between
streams
may be in the middle of very large files (at extent boundaries) if
nec-
essary to achieve reasonable stream size equalization. Each
dump
stream can span several media objects, and a single media object
can
contain several dump streams. The typical media object is a tape
car-
tridge. The media object records the dump stream as one or more
media
files. A media file is a self-contained partial dump. The portion
of
a dump stream contained on a media object can be split into
several
media files. This minimizes the impact of media dropouts on the
entire
dump stream, and speeds subtree restores.
> > No xfsdump is a filesystem dump utility. It means that it
> deals with
> > the filesystem at block level not at file level.
> > It acts like dd, but while dd is dumb as it reads all
> bloacks, xfsdump
> > only read used blocks avoiding backup of empty blocks.
> > The resulting file is not an image but is browsable via xfsrestore.
> > Xfsrestore is able to restore such a file to any xfs partition
> > provided there is enough place on it:
>
> The question is: does it keep the original inode numbers on
> the restored partition or does it have to keep track of where
> it put the first link in order to reproduce all the subsequent
> hardlinks? If it is the latter, you may see the same problem
> as file based systems that can take days to copy a backuppc
> archive. Or perhaps even if the inodes are renumbered the
> lookups are more efficient - I'd be happy to hear that is the case.
This is the case as it can restore a dump to an existing filesystem: if
inodes were not renumered, then you whoud have duplicated inodes.
XFS is imho the best filesystem for linux because of such utilities that are
shipped with (and it has proved to be efficient under IRIX).
> > Example: you have a 1.6TB partition used at 30%: you can
> restore the
> > stuff on a 600GB partition without any problem. Don't fdorget that
> > during a DRP (disaster Recovery Procedure) you often don't
> have tyhe
> > same hardware as in normal production state.
> > Being able to restore on smaler hardware can save lifes ;-)
>
> If it's going to save lives, it should already be on a
> suitable spare disk ready for instant use instead of having
> to do an intermediate restore. If you can keep the total
> size under 400 GB you can fit it on a single, fairly
> inexpensive drive with the copy ready to plug into any box
> with a suitable interface.
I have a 1.6TB hardware RAID5 system.
In case of fire, the ready for instant use disk will burn too. (or if stored
away, will not be up to date).
Tapes are on another building + offsite.
BTW, in case of burn, your first aim is not to restore, but to find hardware
or room to place users, thus leaving plenty of time to xfsrestore 600GB of
data on a simple hardware.
> > xfsdump is definitely far better than dd. (IMHO)
>
> I'm doing mine with software RAID1 which doesn't take any
> downtime on the server although I suppose it would be cleaner
> if I unmounted the partition before breaking the raid. I'm
> hoping the filesystem journal will do the right thing - but I
> do keep 3 copies on the rotating external drives.
>
> --
> Les Mikesell
> [EMAIL PROTECTED]
>
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
BackupPC-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
