Re: amfetchdump: Chunk out of order
* Dustin J. Mitchell [20091201 15:19]: > On Tue, Dec 1, 2009 at 2:08 PM, Jean-Francois Malouin > wrote: > > I'm testing a DLE restore (it spans 2 tapes) with amfetchdump on a > > server running 2.6.1p1, a thing I do once in while and it's the first > > time I see this: amfetchdump is requesting the tapes in the wrong > > order (the amfetchdump debug file is attached) > > This was a known bug in p1 - a sort was happening lexically, instead > of numericaly. Can you upgrade to p2? I guess it's this one from the ChangeLog: 2009-05-22 Jean-Louis Martineau * restore-src/amfetchdump.c: Fix sort_needed_tapes_by_write_timestamp. Darn, that's a real bummer. I guess I'll have to bite the bullet and upgrade. It's just that I have 4 servers to do :( Thanks for the fast reply, jf > > Dustin > > -- > Open Source Storage Engineer > http://www.zmanda.com -- <° >< Jean-François Malouin McConnell Brain Imaging Centre Systems/Network Administrator Montréal Neurological Institute 3801 Rue Université, Suite WB219 Montréal, Québec, H3A 2B4 Phone: 514-398-8924 Fax: 514-398-8948
Re: amfetchdump: Chunk out of order
On Tue, Dec 1, 2009 at 2:08 PM, Jean-Francois Malouin wrote: > I'm testing a DLE restore (it spans 2 tapes) with amfetchdump on a > server running 2.6.1p1, a thing I do once in while and it's the first > time I see this: amfetchdump is requesting the tapes in the wrong > order (the amfetchdump debug file is attached) This was a known bug in p1 - a sort was happening lexically, instead of numericaly. Can you upgrade to p2? Dustin -- Open Source Storage Engineer http://www.zmanda.com
amfetchdump: Chunk out of order
Hi, I'm testing a DLE restore (it spans 2 tapes) with amfetchdump on a server running 2.6.1p1, a thing I do once in while and it's the first time I see this: amfetchdump is requesting the tapes in the wrong order (the amfetchdump debug file is attached) su amanda -c "~amanda/sbin/amfetchdump -p -d tape:/dev/nst1 right1 \ gloria /raid/noel 20091201" | tar -xpGf - 2 tape(s) needed for restoration amfetchdump: Using tapedev tape:/dev/nst1 The following tapes are needed: av24-1_right1_T00041L3 av24-1_right1_T00040L3 Press enter when ready Insert tape labeled av24-1_right1_T00041L3 in device tape:/dev/nst1 and press enter, ^D to finish reading tapes Scanning volume av24-1_right1_T00041L3 amfetchdump: 1: restoring split dumpfile: date 20091201031101 host gloria disk /raid/noel part 36/83 lev 0 comp N program /bin/tar amfetchdump: Chunk out of order, will save to disk and append to output. amfetchdump: 2: restoring split dumpfile: date 20091201031101 host gloria disk /raid/noel part 37/83 lev 0 comp N program /bin/tar amfetchdump: appending to gloria._raid_noel.20091201031101.0.36 . . . Any ideas what's going on? jf -- <° >< Jean-François Malouin McConnell Brain Imaging Centre Systems/Network Administrator Montréal Neurological Institute 3801 Rue Université, Suite WB219 Montréal, Québec, H3A 2B4 Phone: 514-398-8924 Fax: 514-398-8948
Re: full dumps not getting timestamp
Re: full dumps not getting timestamp
Do the backup succeeded? It looks it failed. flow...@hagsc.org wrote: I'm running a fresh install of amanda 2.6.1pl1 (I recently upgraded to p2 and experienced the same problem). When performing full dumps, the curinfo/machine/disk/info files are getting updated (they have proper ownership), but the stats: line for level 0 is mostly filled with 0's. version: 0 command: 0 full-rate: 13929.010897 13776.895360 full-comp: incr-rate: incr-comp: stats: 0 0 0 0 -1 31 GSC_FULL12 last_level: -1 -1 // This is after amanda has finished its run. As you can see, it was dumped to tape, and has the proper tape label and file number on the tape. But it's missing the timestamp and size of dump information. I'm kind of at a loss as to what I've done wrong. Previously, I've been using a modified version of 2.4.1, which has worked fine. For the new install, I replaced both clients and servers with the new software, and decided not to copy over the old database, instead starting fresh (I needed to do a full set of dumps anyway). It appears to work in all other ways, but the lack of proper info in the info files prevents the usual cycle (I can't do incrementals, since the full doesn't have a time). Any ideas?