![]() |
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 |
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 & 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 | |
We also thank MIT for the use of their facilities. |