Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: dump/restore and external hard drive



 By default, dump wants to write to a tape device, e.g. /dev/st0. 
To dump to the external disk, you used the -f option to indicate 
the file to write to, correct? I.e. 

    dump -0f /media/BigDisk/dumpfile-level0 
    dump -9f /media/BigDisk/dumpfile-level9 

So your BigDisk contains two files, dumpfile-level0 and 
dumpfile-level9, each containing the corresponding dump image. 

To restore from this, you'd first restore from the level 0 image, 
and then restore from the level 9 image on top of the already 
restored level 0 files. I.e. 

    restore -f /media/BigDisk/dumpfile-level0 
    restore -f /media/BigDisk/dumpfile-level9 

If you're only restoring a subset of files, and you know in 
advance that everything you want to restore is entirely 
within one of the dump images, you can restore just from 
that one image; otherwise, you want to restore the identical 
subset from both dump images, starting with the level 0 
image and overlaying with the level 9 image. 


On 10/5/07, Scott Ehrlich <[hidden email]> wrote: 
> I've got a 1 TB external hard drive that I performed a level 0 dump to, 
> with compression, then a subsequent backup at normal level  (9?). 
> 
> I attempted to at least view the dump with restore, and keep getting a 
> /dev/tape isn't found. 
> 
> If I want to perform a reliable backup to any medium, in this case an 
> external hard drive, I want to reliably be able to view and access the 
> contents.   I reviewed  restore's man page but nothing was very obvious. 
> 
> I could just as easily tar the directory of choice to back up then gzip 
> it, but incrementals would obviously be helpful in catching only changes 
> and saving space, and having several tar balls can add up quickly, unless 
> I offload them to DVD... 
> 
> Insights/ideas welcome. 
> 
> Thanks. 
> 
> Scott 
> 
> -- 
> This message has been scanned for viruses and 
> dangerous content by MailScanner, and is 
> believed to be clean. 
> 
> _______________________________________________ 
> Discuss mailing list 
> [hidden email] 
> http://lists.blu.org/mailman/listinfo/discuss
> 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org