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?



 LTO3 shows a 400 GB uncompressed capacity. Hardware compression 
makes it difficult to accurately forecast tape capacity, and if a 
tape is damaged, all data on the tape after the damaged block is 
probably lost as well. I'd recommend not using hardware compression. 

Trying to juggle multiple backup sessions per tape can be complicated 
and messy. It makes finding the data to restore more complicated, too. 
Tapes are cheap, and downtime while waiting for a restore is expensive. 

The mt command manages the tape drive; the mtx command manages 
the tape changer (the robot arm, etc., but not the tape drive itself). 
Neither of these commands can copy data from your servers to the 
tape; you still need something like dump or tar to do that part. 

Personally, I use a combination of rsync and amanda for my backups. 
I've got a big server with 1.5 TB of disk, expandable to about 8 TB, 
which I rsync all my backups to using rsnapshot. Then I use amanda 
to do weekly backups to tape. Amanda handles scheduling, arranging 
what to write to the weekly tape, and maintaining a database of 
what's on each tape. Then it uses tar to write the data to tape and 
both mt and mtx to manage which tape to write to each week. 


Scott Ehrlich 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). 
>> 
> 
> Ahh - Here's the setup: 
> 
> - RHEL5 64-bit server w/oob install (all packages selected) 
> 
> - 200 GB /home on local disk to be backed up 
> 
> - handful of bytes in /var/log on local disk to be backed up 
> 
> - Overland LTO3 drive with 15 LTO3 tapes in a library - drive 
> connected via SCSI card to server 
> 
> - Some data may be actively used when the backup is going - I just 
> need tow live with that 
> 
> 
> Among mt, dump, and mtx, what is the best option for backing up? 
> 
> With the capacity of the tapes themselves, and even with dump's 
> software compression, I can't imagine we'd go through many tapes that 
> quickly.  I plan to back up once a week - differential weekly, and 
> full at month's end (well, the OS can always be reinstalled from 
> on-hand media, so full could be a relative term...). 
> 
> 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
>> 


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