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 | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


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

Re: using dump?



 I'm slowly, but steadily, reviewing the Amanda docs for Linux.   Give me 
some time ;-) 

Thanks again. 

Scott 

On Wed, 26 Dec 2007, John Abreau wrote: 

> I don't remember all the details of how dump(1) works, 
> and I don't know if the Linux implementation differs 
> at all from the Solaris version. 
> 
> However, I can tell you that dump does(1) not rewind 
> the tape.  If you use /dev/st0, then the device driver 
> in the kernel rewinds the tape after dump(1) exits, and 
> if you use /dev/nst0, then the device driver doesn't 
> rewind the tape. 
> 
> I use Amanda to manage my dumps after rsync'ing 
> them to a central disk-based file server. Amanda 
> defaults to using gnu tar to create on-disk images 
> of the backups, then writes as many of those images 
> to tape as will fit on a single tape. Amanda also 
> maintains a database of what's in each image and 
> which images are on each tape in what order. 
> Amanda assumes you're using the nst0 device driver, 
> and it manages the tape changer with mtx(1) and the 
> tape drive itself with mt(1). 
> 
> 
> On Dec 26, 2007 10:07 AM, Scott Ehrlich <[hidden email]> wrote: 
>> On Thu, 20 Dec 2007, John Abreau wrote: 
>> 
>>> Hi, Scott. 
>>> 
>>> 
>>> If you used "mt rewind", that would just rewinds the tape, 
>>> and then it would get overwritten. I specified "mt rewoffl", 
>>> which rewinds and ejects the tape. Then you insert the next 
>>> tape for the next day's backups. So the first tape doesn't get 
>>> overwritten unless you reinsert the same tape. 
>>> 
>>> In a real-world situation, you'd actually use a tape library, 
>>> which would hold multiple tapes, and the mtx command 
>>> to tell the tape library to grab the ejected tape and insert 
>>> the next tape. Then you'd only change the tapes once a week 
>>> (for a 7-tape library) or once a month (for a 30-tape library). 
>> 
>> I performed my first full dump over the weekend, and the last two lines 
>> were interesting - 
>> 
>> You can't update the dumpdates files when dumping a subdirectory 
>> The ENTIRE dump is aborted. 
>> 
>> What, then, is the step-by-step process for what the server does and how 
>> the tape drive and tape respond?   Does data ever get written to tape?  If 
>> yes, and the dump aborts, does the server rewind the tape to the start of 
>> this dump as though nothing got backed up? 
>> 
>> Thanks. 
>> 
>> Scott 
>> 
>> 
>>> 
>>> 
>>> 
>>> Scott Ehrlich wrote: 
>>>> Hi John: 
>>>> 
>>>> I'm not sure your response answered what I was looking for... 
>>>> 
>>>> If I am dumping files for backup, why would I want to rewind the tape 
>>>> to be overwritten (I assume they'd be overwritten when performing the 
>>>> next scheduled dump), or is dump smart enough to forward past the 
>>>> written data and not overwrite it, unless, of course, I used /dev/st0, 
>>>> which _would_ overwrite? 
>>>> 
>>>> Thanks. 
>>>> 
>>>> Scott 
>>>> 
>>>> On Thu, 20 Dec 2007, John Abreau wrote: 
>>>> 
>>>>> 
>>>>> 
>>>>> Scott Ehrlich wrote: 
>>>>>> Clarification request - why rewind the tape after all dumps have 
>>>>>> completed?  Wouldn't that be the same as using /dev/st0?  If not, 
>>>>>> what's the difference? 
>>>>>> 
>>>>>> Thanks. 
>>>>>> 
>>>>>> Scott 
>>>>> 
>>>>> If you're doing 10 dumps to the tape, you could use nst0 for the first 9 
>>>>> and then use st0 for the 10th.  But that's less elegant, as seen below: 
>>>>> 
>>>>>    #! /bin/sh 
>>>>> 
>>>>>    export TAPE=/dev/nst0 
>>>>>    for fs in /foo /bar /baz ; do 
>>>>>        dump -0 $fs 
>>>>>    done 
>>>>>    mt rewoffl 
>>>>> 
>>>>> vs 
>>>>> 
>>>>>    #! /bin/sh 
>>>>> 
>>>>>    export TAPE=/dev/nst0 
>>>>>    for fs in /foo /bar ; do 
>>>>>        dump -0 $fs 
>>>>>    done 
>>>>>    dump -0 -f /dev/st0 /baz 
>>>>> 
>>>>> If you want to add /zoidberg to the list, and you have scripts with 
>>>>> dependencies on the order that the filesystems appear on the tapes, 
>>>>> then /zoidberg needs to be dumped after /baz. In the first case, 
>>>>> you could add it to the for... line, after /baz; in the latter, you'd 
>>>>> have 
>>>>> to move /baz to the for... line, and replace /baz in the final dump 
>>>>> line. 
>>>>> That's more complicated and error-prone. 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> John Abreau 
>>>>> IT Manager 
>>>>> Zuken USA 
>>>>> 238 Littleton Rd., Suite 100 
>>>>> Westford, MA 01886 
>>>>> T: 978-392-1777            F: 978-692-4725 
>>>>> M: 978-764-8934 
>>>>> E: [hidden email]  W: www.zuken.com 
>>>>> 
>>>>> 
>>> 
>>> -- 
>>> John Abreau 
>>> IT Manager 
>>> Zuken USA 
>>> 238 Littleton Rd., Suite 100 
>>> Westford, MA 01886 
>>> T: 978-392-1777            F: 978-692-4725 
>>> M: 978-764-8934 
>>> E: [hidden email]  W: www.zuken.com 
>>> 
>>> 
>>> -- 
>>> 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
>>> 
>> 
>> -- 
>> 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
>> 
> 
> 
> 
> -- 
> John Abreau / Executive Director, Boston Linux &amp; Unix 
> GnuPG KeyID: 0xD5C7B5D9 / Email: [hidden email] 
> GnuPG FP: 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 
> 
> -- 
> 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