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
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
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/
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 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
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