Re: Issue with amrecover from 2nd tape
On Mon, May 17, 2010 at 05:17:19PM -0400, Dustin J. Mitchell wrote: On Wed, May 12, 2010 at 12:54 PM, Mark Adams m...@campbell-lange.net wrote: 1273659791.836703: sendbackup: critical (fatal): index tee cannot write [Broken pipe] This means that the index tee (which splits off the 'tar' output to generate the index) cannot write to its output, which is the client-side compression. Since the error is EPIPE, this means either that pbzip2 exited, or that it closed its standard input prematurely. The next step would be to figure out why pbzip2 would do that. Does it automatically compress its stdin and pipe it to stdout? Dustin You need to specify -c with pbzip2 to have it compress to stdout I believe. If you just run it by itself; pbzip2 pbzip2: *ERROR: Won't write compressed data to terminal. Aborting! pbzip2 -h Usage: pbzip2 [-1 .. -9] [-b#cdfhklm#p#qrS#tVz] filename filename2 filenameN -1 .. -9set BWT block size to 100k .. 900k (default 900k) -b# Block size in 100k steps (default 9 = 900k) -c,--stdout Output to standard out (stdout) -d,--decompress Decompress file -f,--force Overwrite existing output file -h,--help Print this help message -k,--keep Keep input file, don't delete -l,--loadavgLoad average determines max number processors to use -m# Maximum memory usage in 1MB steps (default 100 = 100MB) -p# Number of processors to use (default: autodetect [2]) -q,--quiet Quiet mode (default) -r,--read Read entire input file into RAM and split between processors -t,--test Test compressed file integrity -v,--verboseVerbose mode -V,--versionDisplay version info for pbzip2 then exit -z,--compress Compress file (default)
Re: Issue with amrecover from 2nd tape
On Tue, May 18, 2010 at 5:26 AM, Mark Adams m...@campbell-lange.net wrote: You need to specify -c with pbzip2 to have it compress to stdout I believe. If you just run it by itself; Ah! Then, for the moment at least, you'll need to write a wrapper script that doesn't require any arguments. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Tue, May 18, 2010 at 10:26:00 +0100, Mark Adams wrote: You need to specify -c with pbzip2 to have it compress to stdout I believe. If you just run it by itself; pbzip2 pbzip2: *ERROR: Won't write compressed data to terminal. Aborting! pbzip2 -h Usage: pbzip2 [-1 .. -9] [-b#cdfhklm#p#qrS#tVz] filename filename2 filenameN I'm not familiar with bpzip2 specifically, but note that the error message includes the words to terminal, which makes me think it probably acts like gzip and bzip2. In the case of those programs, at least, the compression command actually behaves differently when run with stdout connected to a terminal as opposed to within a pipe: $ echo some content | gzip gzip: compressed data not written to a terminal. Use -f to force compression. For help, type: gzip -h $ echo some content | gzip | cat [actual compressed data here ...] $ echo some content | bzip2 bzip2: I won't write compressed data to a terminal. bzip2: For help, type: `bzip2 --help'. $ echo some content | bzip2 | cat [actual compressed data here ...] Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: Issue with amrecover from 2nd tape
On Wed, May 12, 2010 at 12:54 PM, Mark Adams m...@campbell-lange.net wrote: 1273659791.836703: sendbackup: critical (fatal): index tee cannot write [Broken pipe] This means that the index tee (which splits off the 'tar' output to generate the index) cannot write to its output, which is the client-side compression. Since the error is EPIPE, this means either that pbzip2 exited, or that it closed its standard input prematurely. The next step would be to figure out why pbzip2 would do that. Does it automatically compress its stdin and pipe it to stdout? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
Hi, On Fri, May 07, 2010 at 10:10:27AM -0500, Dustin J. Mitchell wrote: On Fri, May 7, 2010 at 4:22 AM, Mark Adams m...@campbell-lange.net wrote: Does this help at all? as it read the 2nd tape does this mean the data is on the tapes and it's a problem with amrecover? Basically. It could mean that the data on the tapes is corrupt, although the basic structure of the data is intact (that is, the filemarks are in the right place and the headers are right). Also for future ref, do I actually need around 1.5* the space of the DLE to do amfetchdump? (to include the merging..) I don't recall which version you're using. This is no longer the case in 3.1. I'm going to try now using plain gzip instead of pigz, just incase this is causing my issues. It's quite possible.. This was the problem. Using gzip it retrieves from the 2nd tape just fine. It takes twice as long to run the backup though! Is anyone using pigz and is successfully retrieving data from the 2nd tape on? or has anyone used pbzip2? Cheers, Mark Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Wed, May 12, 2010 at 4:39 AM, Mark Adams m...@campbell-lange.net wrote: This was the problem. Using gzip it retrieves from the 2nd tape just fine. It takes twice as long to run the backup though! Is anyone using pigz and is successfully retrieving data from the 2nd tape on? or has anyone used pbzip2? Interesting! We're hoping to implement official support for this in the next (3.2) release, so I'm curious to know more about why pigz failed. In theory, it's a drop-in gzip replacement, right? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Wed, May 12, 2010 at 09:55:05AM -0500, Dustin J. Mitchell wrote:
On Wed, May 12, 2010 at 4:39 AM, Mark Adams m...@campbell-lange.net wrote:
This was the problem. Using gzip it retrieves from the 2nd tape just
fine. It takes twice as long to run the backup though! Is anyone using
pigz and is successfully retrieving data from the 2nd tape on? or has
anyone used pbzip2?
Interesting! We're hoping to implement official support for this in
the next (3.2) release, so I'm curious to know more about why pigz
failed. In theory, it's a drop-in gzip replacement, right?
As far as I know, yes. Might be something to do with the merging of the
tar parts? Maybe you should try in your labs and see how you get
on! :)
In the mean time I can't get pbzip2 to work at all. It just crashes out
with the following:
--snip
programGNUTAR/program
disk/upbackup/disk
level0/level
authbsd/auth
compressSERVER-CUSTOMcustom-compress-program/usr/bin/pbzip2/custom-compress-program
/compress
recordYES/record
indexYES/index
/dle
1273659787.671710: dumper: is_partial = 0
1273659787.671714: dumper: partnum = 0
1273659787.671717: dumper: totalparts = 0
1273659787.671720: dumper: blocksize= 32768
1273659791.836144: dumper: security_stream_close(0x1c14990)
1273659791.836191: dumper: security_stream_close(0x1c1c9f0)
1273659791.836215: dumper: security_stream_close(0x1c24a50)
1273659791.836277: dumper: putresult: 10 FAILED
1273659792.404559: dumper: getcmd: QUIT
1273659792.404617: dumper: pid 741 finish time Wed May 12 11:23:12 2010
230,1
snip--
This is my dumptype:
define dumptype upbackup {
program GNUTAR
compress server custom
server_custom_compress /usr/bin/pbzip2
tape_splitsize 40Gb
split_diskbuffer /tapehold/
fallback_splitsize 10Gb
comment UPBACKUP
index
priority high
auth bsd
}
Dustin
Re: Issue with amrecover from 2nd tape
On Wed, May 12, 2010 at 11:17 AM, Mark Adams m...@campbell-lange.net wrote: In the mean time I can't get pbzip2 to work at all. It just crashes out with the following: Please attach the whole sendbackup log. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
1273659787.668231: sendbackup: pid 1529 ruid 34 euid 34 version 2.6.1p1: start at Wed May 12 11:23:07 2010 1273659787.668261: sendbackup: Version 2.6.1p1 1273659787.668465: sendbackup: pid 1529 ruid 34 euid 34 version 2.6.1p1: rename at Wed May 12 11:23:07 2010 1273659787.668839: sendbackup: Parsed request as: program `GNUTAR' 1273659787.668847: sendbackup: disk `/upbackup' 1273659787.668851: sendbackup: device `/upbackup' 1273659787.668854: sendbackup: level 0 1273659787.668857: sendbackup: since NODATE 1273659787.668860: sendbackup: options `' 1273659787.668928: sendbackup: start: localhost:/upbackup lev 0 1273659787.669014: sendbackup: doing level 0 dump as listed-incremental to '/var/lib/amanda/gnutar-lists/localhost_upbackup_0.new' 1273659787.669561: sendbackup: pipespawnv: stdoutfd is 50 1273659787.669716: sendbackup: Spawning /usr/lib/amanda/runtar runtar up /bin/tar --create --file - --directory /upbackup --one-file-system --listed-incremental /var/ 1273659787.669747: sendbackup: Started index creator: /bin/tar -tf - 2/dev/null | sed -e 's/^\.//' 1273659787.669846: sendbackup: gnutar: /usr/lib/amanda/runtar: pid 1533 1273659787.669867: sendbackup: Started backup 1273659791.836703: sendbackup: critical (fatal): index tee cannot write [Broken pipe] /usr/lib/amanda/libamanda-2.6.1p1.so[0x7f3d7e034a21] /lib/libglib-2.0.so.0(g_logv+0x1a7)[0x7f3d7d2bb6f7] /lib/libglib-2.0.so.0(g_log+0x83)[0x7f3d7d2bbad3] /usr/lib/amanda/sendbackup(start_index+0x28e)[0x403bfe] /usr/lib/amanda/sendbackup[0x407e22] /usr/lib/amanda/sendbackup(main+0x11c1)[0x405dc1] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f3d7c8f6abd] /usr/lib/amanda/sendbackup[0x403519] On Wed, May 12, 2010 at 11:33:15AM -0500, Dustin J. Mitchell wrote: On Wed, May 12, 2010 at 11:17 AM, Mark Adams m...@campbell-lange.net wrote: In the mean time I can't get pbzip2 to work at all. It just crashes out with the following: Please attach the whole sendbackup log. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
Hi There, I'm not so worried about the data, im just testing backing up to multiple tapes at present. I've retrieved using the following; sudo -u backup amfetchdump up localhost /upbackup which has given me 2 files; -rw-r- 1 backup backup 1350349324288 2010-05-07 03:11 localhost._upbackup.20100430113529.0.001 drwxr-xr-x 2 backup backup 108 2010-05-06 20:03 . -rw-r- 1 backup backup 649939222528 2010-05-06 19:47 localhost._upbackup.20100430113529.0.020 Unfortunately I ran out of space on the device I was restoring the dumps to at this stage; Merging localhost._upbackup.20100430113529.0.020 with localhost._upbackup.20100430113529.0.001 Error writing fd 7: No space left on device amfetchdump: Error copying data from file localhost._upbackup.20100430113529.0.020 to fd 7. Does this help at all? as it read the 2nd tape does this mean the data is on the tapes and it's a problem with amrecover? Also for future ref, do I actually need around 1.5* the space of the DLE to do amfetchdump? (to include the merging..) I'm going to try now using plain gzip instead of pigz, just incase this is causing my issues. Thanks for your help so far. Regards, Mark On Wed, May 05, 2010 at 10:16:50AM -0500, Dustin J. Mitchell wrote: On Wed, May 5, 2010 at 3:55 AM, Mark Adams m...@campbell-lange.net wrote: Why would the file not be in the archive if it is showing in the index? Is there anything else I can try before I try to retrieve the whole DLE? So this is a new dump? No, I can't see any reason it would do that. Hopefully retrieving the entire DLE will offer some clues (and get you access to your data). Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Fri, May 7, 2010 at 4:22 AM, Mark Adams m...@campbell-lange.net wrote: Does this help at all? as it read the 2nd tape does this mean the data is on the tapes and it's a problem with amrecover? Basically. It could mean that the data on the tapes is corrupt, although the basic structure of the data is intact (that is, the filemarks are in the right place and the headers are right). Also for future ref, do I actually need around 1.5* the space of the DLE to do amfetchdump? (to include the merging..) I don't recall which version you're using. This is no longer the case in 3.1. I'm going to try now using plain gzip instead of pigz, just incase this is causing my issues. It's quite possible.. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
Hi All, I've run this backup again with smaller chunks (40Gb, not that this should make a difference?) and it is now saying it can't find anything I try to recover in the archive. tar: ./path/here/IMG_4254.jpg: Not found in archive tar: Error exit delayed from previous errors Why would the file not be in the archive if it is showing in the index? Is there anything else I can try before I try to retrieve the whole DLE? On Wed, Apr 28, 2010 at 02:57:32PM +0100, Mark Adams wrote: On Fri, Apr 23, 2010 at 10:26:52AM -0700, Dustin J. Mitchell wrote: On Fri, Apr 23, 2010 at 9:59 AM, Mark Adams m...@campbell-lange.net wrote: I've determined that when I try to retrieve files from the 2nd tape in my set it won't work. Tar crashes out with the helpful error due to previous errors -- no errors show before this apart from tar skipping to the next tape. Retrieves from the first tape work fine. Hmm, that's odd, because as far as tar is concerned, there aren't separate tapes - just a single datastream. Even when recovering a file only on the first tape, amrecover will still read the entire dumpfile (and thus require the second tape). I assume that you've seen files recovered successfully before you swapped to the second tape. In that case, did you kill amrecover after getting the desired files? If not, did it finish reading the second tape without error? Yes once I've seen the files restored I've always killed amrecover. I would recommend using 'amfetchdump' for the same dumpfile, and examining the resulting tarfile. I assume this will require space the size of the DLE? (in my case 2T) Dustin -- Open Source Storage Engineer http://www.zmanda.com -- Mark Adams Technical Manager m...@campbell-lange.net . Campbell-Lange Workshop www.campbell-lange.net 0207 6311 555 3 Tottenham Street London W1T 2AF Registered in England No. 04551928
Re: Issue with amrecover from 2nd tape
On Wed, May 5, 2010 at 3:55 AM, Mark Adams m...@campbell-lange.net wrote: Why would the file not be in the archive if it is showing in the index? Is there anything else I can try before I try to retrieve the whole DLE? So this is a new dump? No, I can't see any reason it would do that. Hopefully retrieving the entire DLE will offer some clues (and get you access to your data). Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Wed, 2010-05-05 at 10:16 -0500, Dustin J. Mitchell wrote: On Wed, May 5, 2010 at 3:55 AM, Mark Adams m...@campbell-lange.net wrote: Why would the file not be in the archive if it is showing in the index? Is there anything else I can try before I try to retrieve the whole DLE? So this is a new dump? No, I can't see any reason it would do that. Hopefully retrieving the entire DLE will offer some clues (and get you access to your data). Yes, if it is in the index, it got backed up. The only option I can think of, other than retrieving the full backup, is to use amfetchdump with the -p flag piped to tar. You can at least see if this shows any more tar errors than Amanda is showing. Paul
Re: Issue with amrecover from 2nd tape
On Fri, Apr 23, 2010 at 10:26:52AM -0700, Dustin J. Mitchell wrote: On Fri, Apr 23, 2010 at 9:59 AM, Mark Adams m...@campbell-lange.net wrote: I've determined that when I try to retrieve files from the 2nd tape in my set it won't work. Tar crashes out with the helpful error due to previous errors -- no errors show before this apart from tar skipping to the next tape. Retrieves from the first tape work fine. Hmm, that's odd, because as far as tar is concerned, there aren't separate tapes - just a single datastream. Even when recovering a file only on the first tape, amrecover will still read the entire dumpfile (and thus require the second tape). I assume that you've seen files recovered successfully before you swapped to the second tape. In that case, did you kill amrecover after getting the desired files? If not, did it finish reading the second tape without error? Yes once I've seen the files restored I've always killed amrecover. I would recommend using 'amfetchdump' for the same dumpfile, and examining the resulting tarfile. I assume this will require space the size of the DLE? (in my case 2T) Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Wed, Apr 28, 2010 at 6:57 AM, Mark Adams m...@campbell-lange.net wrote: I assume this will require space the size of the DLE? (in my case 2T) Yes, it will. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
Hi Guys, Sorry for the stupid questions, but I've no idea how to identify *which* file needs to be selected in amrecover in order for it to restore from the start of the 10th chunk. Or should I be trying to recover this some other way? using tar or amrestore? Cheers Mark On Thu, Apr 22, 2010 at 12:28:32PM -0700, Paul Yeatman wrote: On Thu, 2010-04-22 at 12:00 -0700, Paul Yeatman wrote: On Thu, 2010-04-22 at 09:07 -0700, Dustin J. Mitchell wrote: On Thu, Apr 22, 2010 at 6:49 AM, Mark Adams m...@campbell-lange.net wrote: 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-021 10/-1 OK This is part 10 of the dump, at filemark 1 on UPSNAPSHOT-02. is that what you were looking for? Thus the first file on the second tape, file number=0. Are we understanding the question? Paul Mark, sorry. It is actually file number=1 or filemark 1 as Dustin said. 0 is the tape label. Always trust Dustin first! Paul
Re: Issue with amrecover from 2nd tape
On Fri, Apr 23, 2010 at 3:29 AM, Mark Adams m...@campbell-lange.net wrote: Sorry for the stupid questions, but I've no idea how to identify *which* file needs to be selected in amrecover in order for it to restore from the start of the 10th chunk. I had been wondering why you were so concerned with which part (chunks are different) was on which tape. What is the task you're tring to accomplish here? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
I guess this is a reason not to snip out bits from the thread history! I've determined that when I try to retrieve files from the 2nd tape in my set it won't work. Tar crashes out with the helpful error due to previous errors -- no errors show before this apart from tar skipping to the next tape. Retrieves from the first tape work fine. Paul suggested I try to retrieve a file from the *very* beginning of the 2nd tape, I'm trying to find out how to do that. Cheers, Mark On Fri, Apr 23, 2010 at 08:31:57AM -0700, Dustin J. Mitchell wrote: On Fri, Apr 23, 2010 at 3:29 AM, Mark Adams m...@campbell-lange.net wrote: Sorry for the stupid questions, but I've no idea how to identify *which* file needs to be selected in amrecover in order for it to restore from the start of the 10th chunk. I had been wondering why you were so concerned with which part (chunks are different) was on which tape. What is the task you're tring to accomplish here? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Fri, Apr 23, 2010 at 9:59 AM, Mark Adams m...@campbell-lange.net wrote: I've determined that when I try to retrieve files from the 2nd tape in my set it won't work. Tar crashes out with the helpful error due to previous errors -- no errors show before this apart from tar skipping to the next tape. Retrieves from the first tape work fine. Hmm, that's odd, because as far as tar is concerned, there aren't separate tapes - just a single datastream. Even when recovering a file only on the first tape, amrecover will still read the entire dumpfile (and thus require the second tape). I assume that you've seen files recovered successfully before you swapped to the second tape. In that case, did you kill amrecover after getting the desired files? If not, did it finish reading the second tape without error? I would recommend using 'amfetchdump' for the same dumpfile, and examining the resulting tarfile. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
Hi Paul, How can I tell what file will be on the start of the 2nd tape? You can run amadmin with the find option. This will show which parts of the backup are on which tapes. Reading the 32k block at the beginning of each tape file should agree with this information. I have tried this and get the following; 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-011 1/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-012 2/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-013 3/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-014 4/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-015 5/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-016 6/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-017 7/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-018 8/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-019 9/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-01 10 10/-1 PARTIAL 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-021 10/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-022 11/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-023 12/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-024 13/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-025 14/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-026 15/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-027 16/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-028 17/-1 OK 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-029 18/-1 OK How can I find out what File to retrieve at the start of the 2nd tape? Regards, Mark
Re: Issue with amrecover from 2nd tape
On Thu, Apr 22, 2010 at 6:49 AM, Mark Adams m...@campbell-lange.net wrote: 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-02 1 10/-1 OK This is part 10 of the dump, at filemark 1 on UPSNAPSHOT-02. is that what you were looking for? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Thu, 2010-04-22 at 09:07 -0700, Dustin J. Mitchell wrote: On Thu, Apr 22, 2010 at 6:49 AM, Mark Adams m...@campbell-lange.net wrote: 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-021 10/-1 OK This is part 10 of the dump, at filemark 1 on UPSNAPSHOT-02. is that what you were looking for? Thus the first file on the second tape, file number=0. Are we understanding the question? Paul
Re: Issue with amrecover from 2nd tape
On Thu, Apr 22, 2010 at 12:00 PM, Paul Yeatman pyeat...@zmanda.com wrote: Thus the first file on the second tape, file number=0. Tape file numbers are one-based, because they reflect the number of filemarks that precede the file data, and the tape always begins with a tape header and a filemark: tape header FILEMARK first data file FILEMARK second data file ... Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: Issue with amrecover from 2nd tape
On Thu, 2010-04-22 at 12:00 -0700, Paul Yeatman wrote: On Thu, 2010-04-22 at 09:07 -0700, Dustin J. Mitchell wrote: On Thu, Apr 22, 2010 at 6:49 AM, Mark Adams m...@campbell-lange.net wrote: 2010-04-09 16:55:11 localhost /upbackup 0 UPSNAPSHOT-021 10/-1 OK This is part 10 of the dump, at filemark 1 on UPSNAPSHOT-02. is that what you were looking for? Thus the first file on the second tape, file number=0. Are we understanding the question? Paul Mark, sorry. It is actually file number=1 or filemark 1 as Dustin said. 0 is the tape label. Always trust Dustin first! Paul
Re: Issue with amrecover from 2nd tape
Hello Mark, On Tue, 2010-04-20 at 09:45 +0100, Mark Adams wrote: Hi Paul, On Mon, Apr 19, 2010 at 04:39:06PM -0700, Paul Yeatman wrote: Mark, On Mon, 2010-04-19 at 20:42 +0100, Mark Adams wrote: Hi Paul, this is my issue, it doesn't appear to show any previous errors I see! The only thing before the message is tar saying it is skipping to the next header, which I've assumed is tar moving to the chunk on the next tape. Yes, I'm guessing that there is some failure to read the data on the next tape and tar is left with nothing to read and fails. Is there a way to run amrecover in 'debug' mode? Not that I am aware of. I think I would begin carefully reading the second tape (with the tape write-locked :) to see if I can successfully read back at least the first file or so. If so, I would also check that file's Amanda header. How can I tell what file will be on the start of the 2nd tape? You can run amadmin with the find option. This will show which parts of the backup are on which tapes. Reading the 32k block at the beginning of each tape file should agree with this information. If you are fortunate enough to have 2T of free disk space, I would also give using amfetchdump a try to first read back the full image to disk before sending it to tar. In absence of a free 2T, you could use the -p option to pipe it to tar but may be only right back at the same spot. There does seem to be some issue with continuing the read on the second tape. Regards, Paul
Re: Issue with amrecover from 2nd tape
Hi, Thanks for your response. Please see my questions line
On Thu, Apr 15, 2010 at 10:37:29AM -0700, Paul Yeatman wrote:
Hi!
On Thu, 2010-04-15 at 10:18 +0100, Mark Adams wrote:
Hi All,
Debian lenny, Amanda 2.6.1p1-2
I'm backing up a single 1.9T xfs filesystem to an LTO4 drive with
changer. The backup seems to complete correctly and recovering files
that are on the first tape complete correctly.
However, when trying to retrieve and files that are on the 2nd tape, the
tape is loaded correctly by the changer (after first spooling through
the first tape, as a side note is there a way to skip this?) then after
some time the following error is shown
You would not be able to skip the first tape if this is where the backup
image begins
Ok. It doesn't help if it is in 80G chunks?
tar: Error exit delayed from previous errors
Extractor child exited with status 2
How can I find out what the previous errors were?
You need to look in the debug log for the backup application you are
using on the client in /var/log/amanda/client/config/.
I don't have any amgtar logs, just the amrecover logs - which have the
security stream_stream_close message I noted below. Is there some
additional logging I can add?
For amgtar, it will be amgtar.datestamp.debug
Cheers,
Paul
In the amrecover log I also see
1271275442.543746: amrecover: security_stream_close(0xd89180)
1271275520.583556: amrecover: security_stream_close(0xd99f30)
My tape and dump config is as follows
define tapetype LTO4 {
comment HP LTO4
length 804191104 kbytes
filemark 0 kbytes
speed 90511 kps
blocksize 32 kbytes
}
define dumptype upbackup {
program GNUTAR
compress server custom
server_custom_compress /usr/bin/pigz
tape_splitsize 80Gb
split_diskbuffer /tapehold/
fallback_splitsize 10Gb
comment UPBACKUP
index
priority high
auth bsd
}
Help would be very much appreciated!
Cheers,
Mark
Re: Issue with amrecover from 2nd tape
Hi!
On Thu, 2010-04-15 at 10:18 +0100, Mark Adams wrote:
Hi All,
Debian lenny, Amanda 2.6.1p1-2
I'm backing up a single 1.9T xfs filesystem to an LTO4 drive with
changer. The backup seems to complete correctly and recovering files
that are on the first tape complete correctly.
However, when trying to retrieve and files that are on the 2nd tape, the
tape is loaded correctly by the changer (after first spooling through
the first tape, as a side note is there a way to skip this?) then after
some time the following error is shown
You would not be able to skip the first tape if this is where the backup
image begins
tar: Error exit delayed from previous errors
Extractor child exited with status 2
How can I find out what the previous errors were?
You need to look in the debug log for the backup application you are
using on the client in /var/log/amanda/client/config/.
For amgtar, it will be amgtar.datestamp.debug
Cheers,
Paul
In the amrecover log I also see
1271275442.543746: amrecover: security_stream_close(0xd89180)
1271275520.583556: amrecover: security_stream_close(0xd99f30)
My tape and dump config is as follows
define tapetype LTO4 {
comment HP LTO4
length 804191104 kbytes
filemark 0 kbytes
speed 90511 kps
blocksize 32 kbytes
}
define dumptype upbackup {
program GNUTAR
compress server custom
server_custom_compress /usr/bin/pigz
tape_splitsize 80Gb
split_diskbuffer /tapehold/
fallback_splitsize 10Gb
comment UPBACKUP
index
priority high
auth bsd
}
Help would be very much appreciated!
Cheers,
Mark
--
Paul Yeatman
Technical Support Engineer
Zmanda, Inc.
http://www.zmanda.com
