Re: Index issue with amrecover
follows: /sbin/restore -ivf /data/hope Verify tape and initialize maps /data/sbin/restore: /data/hope: File too large try cat /data/hope | /sbin/restore -ivf - My most humble and sincere gratitude for Alexandre's and John's help in assisting me with my various problems, and thanks to anyone else who answered my questions. Just wanted you guys to know that some people out here consider what you are doing as far as donation of time and energy to this list to be rather noble, and I hope that one day more things in the world can be as open and giving as this community seems to be. Thank you. Eric Helms
Re: Index issue with amrecover
Jean-Louis Martineau wrote: backup server. I ran the restore on a Linux box with the 2.4 kernel, hoping that this would alleviate the 2GB file size limitation, but so far the output/errors continue. Once again, thanks for your help. Each chunk contains the absolute path of the next chunk, you can add a symlink in /bkup03/amanda/20010213/ to point to the actual file. Or you can try this patch (untested) which will look in the current directory if it doesn't find the file in the appropriate place. Jean-Louis Okay, I did as you suggested, Jean-Louis, by symlinks and split went ahead and made the file that could be piped into restore just fine. Now, I cat'ed the split files together into a new file called 'hope' 8) and freed up enough drive space to work with. Command line reads as follows: /sbin/restore -ivf /data/hope Verify tape and initialize maps /data/sbin/restore: /data/hope: File too large Restore gives me 'file too large' regardless of what exact options I pass it, and the file that I am trying to restore is actually around 4.2GB! (Level 0 backup, of course...) /hope is a different directory than the one I am trying to restore to, but I understand that with the -f option that specifying files across drives should not be the issue. I am literally ready to try just about anything at this point. Any suggestions will be taken heartily. -Eric
Re: Index issue with amrecover
On Feb 28, 2001, Eric Helms [EMAIL PROTECTED] wrote:
follows: /sbin/restore -ivf /data/hope
Verify tape and initialize maps
/data/sbin/restore: /data/hope: File too large
try
cat /data/hope | /sbin/restore -ivf -
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
[Fwd: Re: Index issue with amrecover]
Original Message Subject: Re: Index issue with amrecover Date: Fri, 23 Feb 2001 07:56:00 -0500 From: Patrick LIN [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: Steltor To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] "John R. Jackson" a crit : The backup that I need restored is 20010213.sda5.0 from deepblue ... ... the files located in /var/log/amanda/DailySet1/index/deepblue/sda5, which are 20010213_0 (0 byte file) and 20010213_0.gz. ... Huh? 20010213_0 is zero bytes? That's why amrecover is not happy. Something went wrong with the decrompress. What happens if you "zcat 20010213_0.gz | head"? Is there anything in there? ... Any help that anyone can provide is greatly appreciated, (and needed severely, as in the case of all backup recoveries ! 8) If it's so severe, why not stop trying to use amrecover and go to amrestore? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] i have the same problem with amrecover but when i zcat the gzip everything is good why not amrestore ? because amrestore pout the dump file on the disk before start select anything so you need the double space to restore thanks Patrick -- __( / | | / \ | This message is transmitted by | \ \ | 100 % recycled electrons |___\ / |__( /__)
Re: Index issue with amrecover
The backup that I need restored is 20010213.sda5.0 from deepblue ... ... the files located in /var/log/amanda/DailySet1/index/deepblue/sda5, which are 20010213_0 (0 byte file) and 20010213_0.gz. ... Huh? 20010213_0 is zero bytes? That's why amrecover is not happy. Something went wrong with the decrompress. What happens if you "zcat 20010213_0.gz | head"? Is there anything in there? ... Any help that anyone can provide is greatly appreciated, (and needed severely, as in the case of all backup recoveries ! 8) If it's so severe, why not stop trying to use amrecover and go to amrestore? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Index issue with amrecover
The backup that I need restored is 20010213.sda5.0 from deepblue ... ... the files located in /var/log/amanda/DailySet1/index/deepblue/sda5, which are 20010213_0 (0 byte file) and 20010213_0.gz. ... Huh? 20010213_0 is zero bytes? That's why amrecover is not happy. Something went wrong with the decrompress. What happens if you "zcat 20010213_0.gz | head"? Is there anything in there? ... Any help that anyone can provide is greatly appreciated, (and needed severely, as in the case of all backup recoveries ! 8) If it's so severe, why not stop trying to use amrecover and go to amrestore? John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] The gzipped files are empty. As far as amrestore goes, I have experienced issues there as well, and decided to try to find the solution to amrecover first, for whatever reason. The problem with amrestore is as follows: [root@mother /bkup03]# /usr/local/amanda/sbin/amrestore /bkup03/amanda/20010213/deepblue.sda5.0 amrestore: 0: restoring deepblue.sda5.20010213.0 gzip: stdout: File too large Error 32 (Broken pipe) offset 1756921856+32768, wrote 0 amrestore: pipe reader has quit in middle of file. amrestore: skipping ahead to start of next file, please wait... ...and then it just drops back to a console prompt. If this is any clue, the backup file(s) is rather large, the sda5.0 and sda5.0.1 files are just over a GB each, and sda5.0.2 is almost half a gig. I will attempt to make work first whichever I can, of course. Thanks as always for the help, John. It is sincerely appreciated.
Re: Index issue with amrecover
The gzipped files are empty. Then the indexing didn't work and you won't be able to use amrecover. I don't know why that would have happened. I'd start by looking at the sendbackup*debug file on the client and see if there is anything odd about the index pipeline. Then I'd make sure the server side has proper access to gzip. Are all your index files empty, or just some of them? [root@mother /bkup03]# /usr/local/amanda/sbin/amrestore /bkup03/amanda/20010213/deepblue.sda5.0 amrestore: 0: restoring deepblue.sda5.20010213.0 gzip: stdout: File too large Let me guess. You're running on Linux. You told amrestore to bring back the image as a file in the current directory. But Linux (at least the file system you're in) has a 2 GByte file size limit. So you can't do that with the large image you're trying to work with. The general solution is to use the -p option to amrestore and send the output to a pipe. You can either send that into your restore program and recover the files right there, or send it into split to break the file into chunks the OS can handle, then use cat to pipe them into the restore program later. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
