Re: using dump?

["bostonlinuxandunix" <user=37@nabble.blu.org>]

 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
>