On Tue, 2005-08-16 at 11:15, [EMAIL PROTECTED] wrote:
> >
> > 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.
I thought that would have to be the way it works. Now, have you
actually restored a backuppc archive larger than 100gigs or so
containing many duplicates/links? If so, how long does it take?
The part I expect to be slow is where it has to look up the new target
for the renumbered inodes. I think most utilities use a linear search
for this because it is rare to have very many hard links.
> 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).
Other filesystems include a corresponding dump utility too, but perhaps
this one uses a hash table for the lookups.
> 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.
Why would the offsite disk copy have to be any more out of date than the
offsite tape copy?
> 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.
OK, if you've actually done that restore of a real backuppc archive and
are happy with the time it took. I can plug my external drive into my
laptop's USB 2.0 and grab files within minutes. I'd probably do this
immediately at another existing office while someone else decided what
to do about the main office replacements.
--
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/
