Re: problem with amrestore

[Jon LaBadie]

On Thu, May 25, 2006 at 03:53:40PM -0700, William Yardley wrote:
> On Thu, May 25, 2006 at 03:23:13PM -0700, William Yardley wrote:
> [ Sorry for the self-followup ]
> > I'm having problems restoring data from a particular machine / partition
> > using amanda and "restore".
> > 
> > $ amrestore -p /dev/nst0 somemachine /home  | /sbin/restore -ivf -
> > Verify tape and initialize maps
> > Input is from a local file/pipe
> > amrestore: missing file header block
> > amrestore:   2: skipping xxx._.20060524.1
> > amrestore:  10: reached end of information
> [...]
> > This is with RHEL4u3 (has always worked fine with RHEL3, and almost the
> > same versions - dump v 0.4b37 and same Amanda version).
> 
> Actually, I stand corrected... this only worked with Amanda 2.4, so I
> guess it didn't break when we switched machines.
> 
> I found a workaround that works for my particular situation - use
> amadmin to get the tape and file #, then do:
> 
> $ amrestore -p /dev/nst0 -f 20 | /sbin/restore -ivf -
> 
> Still would be interested if anyone has any insight as to why the other
> way doesn't work... maybe the syntax just needs to be slightly
> different? From a quick look at TFM, I'm pretty sure I'm doing it the
> "right" way.
> 

Seems right to me.

I did note a typo error in the latest manpage for amrestore.

The old version said:

... tapedev | holdfile  [  host ...

The new version changes the "[" to a "|" as in

... tapedev | holdfile  |  host ...

I highly doubt that reflects a change in the code.

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: problem with amrestore

[William Yardley]

On Thu, May 25, 2006 at 03:23:13PM -0700, William Yardley wrote:
[ Sorry for the self-followup ]
> I'm having problems restoring data from a particular machine / partition
> using amanda and "restore".
> 
> $ amrestore -p /dev/nst0 somemachine /home  | /sbin/restore -ivf -
> Verify tape and initialize maps
> Input is from a local file/pipe
> amrestore: missing file header block
> amrestore:   2: skipping xxx._.20060524.1
> amrestore:  10: reached end of information
[...]
> This is with RHEL4u3 (has always worked fine with RHEL3, and almost the
> same versions - dump v 0.4b37 and same Amanda version).

Actually, I stand corrected... this only worked with Amanda 2.4, so I
guess it didn't break when we switched machines.

I found a workaround that works for my particular situation - use
amadmin to get the tape and file #, then do:

$ amrestore -p /dev/nst0 -f 20 | /sbin/restore -ivf -

Still would be interested if anyone has any insight as to why the other
way doesn't work... maybe the syntax just needs to be slightly
different? From a quick look at TFM, I'm pretty sure I'm doing it the
"right" way.

w

problem with amrestore

[William Yardley]

I'm having problems restoring data from a particular machine / partition
using amanda and "restore".

$ amrestore -p /dev/nst0 somemachine /home  | /sbin/restore -ivf -
Verify tape and initialize maps
Input is from a local file/pipe
amrestore: missing file header block
amrestore:   2: skipping xxx._.20060524.1
amrestore:  10: reached end of information

running "mt tell" at this point:
At block 22

if I run the same thing a second time, I get:
[...]
Input is from a local file/pipe
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore:  10: reached end of information
/sbin/restore: Tape read error on first record

If I just do
$ amrestore -p /dev/nst0 | /sbin/restore -ivf -
the machine shown being skipped above is the first one that comes up. If
I then quit and restart, I can go through all the other hosts backed up
here one at a time; however this isn't very time-effective or convenient.

This is with RHEL4u3 (has always worked fine with RHEL3, and almost the
same versions - dump v 0.4b37 and same Amanda version).

dump-0.4b39-3.EL4.2

Amanda version is amanda-2.5.0p2, packaged locally.

Any ideas on what the problem might be?

w

Re: RAIT1 without tape in drive

[Paul Bijnens]

[EMAIL PROTECTED] schreef:

Dear Listers,

I am running a RAIT1 configuration with vtapes and a LTO1 without problems.
Today is a public holiday and it's the first day that nobody is there to
insert the correct tape.

What will happen with the (cron) dump tonight, will it run to the holding
disk only?


I believe it will.  Because on of the members of the mirror is wrong
(wrong label, or empty), the check of the label will not succeed.
You'll get a "numerical argument out of domain" error.




Will the flush tomorrow to the correct tape also be flushed to the vtape?


Yes.



Maybe someone can have a look in his/her crystal ball?


Just to calibrate my crystal ball, let us know the result too.


--
Paul Bijnens, XplanationTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...*
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***

RAIT1 without tape in drive

[uwe . kaufmann]

Dear Listers,

I am running a RAIT1 configuration with vtapes and a LTO1 without problems.
Today is a public holiday and it's the first day that nobody is there to
insert the correct tape.

What will happen with the (cron) dump tonight, will it run to the holding
disk only?

Will the flush tomorrow to the correct tape also be flushed to the vtape?

Maybe someone can have a look in his/her crystal ball?

TIA
Uwe



Virus checked by G DATA AntiVirusKit
Version: AVK 16.7566 from 25.05.2006

Any experience with Quantum Superloader 3 LTO-3 16 tape library?

[Tanniel Simonian]

We are looking into purchasing a new tape library. Our current choice is
an Overland 11 tape LTO-3 library. However, the Quantum Superloader 3
option recently fell on our laps and we're trying to decide if it is
reliable and if it will work with Amanda/Debian.

Anyone have any experience with the Quantum Superloader 3 or similar
Quantum product and if you could describe your experience with the unit.

Our current tape hardware is an Exabyte 1x7 Mammoth 2 (60/150) drives.

regards,

Tano

Re: tapetape (not in faq-o-matic)

[Joshua Baker-LePain]

On Thu, 25 May 2006 at 10:44am, Brian Cuttler wrote


slow for this drive. I just have to perform a number of dumps and
check the actual speed if its below the shoe-shine limit... what is
that for this drive anyway, with the noise in my computer room I'm
not certain that I'll be able to hear it if its in trouble.


AIUI, the drive can throttle back to 1/2 its native write speed of 80MB/s.

--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Re: missing result ... in ... response ???

[Michael D Schleif]

* Jean-Louis Martineau <[EMAIL PROTECTED]> [2006:05:25:10:16:56-0400] scribed:
> Michael,
> 
> If the problem is that you have too many DLE for a udp packet, try the 
> attached patch which will double the size of the packet.

Thank you, for your participation in this matter.

Yes, I can get this source, and compile it myself.

However, I have two issues with that solution:

[1] Did this _change_ between v2.4.5 and v2.5.x?  If so, why?

If so, at which version?  Perhaps, I can down-grade?

[2] One reason for using debian is, package management is so easy.

Managing one, or dozens, or hundreds of personally compiled programs
is a mess that I prefer to avoid.

what do you think?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know.  The more I know, the more I know I don't know . . .
--


signature.asc
Description: Digital signature

Re: tapetape (not in faq-o-matic)

[Brian Cuttler]

Jon,

On Thu, May 25, 2006 at 10:33:48AM -0400, Jon LaBadie wrote:
> Well, actually a little different.  I got my Ultrium 1 from ebay and
> like a kid with a new toy ran several tapetypes on it.  Three different
> physical tapes (two brands), one two times, and with 3 different block
> sizes, and a couple with and without compression on.
> 
> The thing that flabbergasted me was the absolute consistancy of the
> total blocks written (adjusted for block size).
> Two of your report lines were like mine:
> 
> > > > wrote 12386304 32Kb blocks in 189 files in 6539 seconds (short write)
> > wrote 12386304 32Kb blocks in 189 files in 6487 seconds (short write)
> 
> Oh, I did some with a different scsi controller too as the first one I
> used was too low performance.  Same block count though.

Actually I'm now wondering how to keep the drive busy, what can be
done to feed it better. I'm pretty sure I'm going to need a second
work area as I add partitions but disk to tape speed might be too
slow for this drive. I just have to perform a number of dumps and
check the actual speed if its below the shoe-shine limit... what is
that for this drive anyway, with the noise in my computer room I'm
not certain that I'll be able to hear it if its in trouble.

thanks,

Brian
---
   Brian R Cuttler [EMAIL PROTECTED]
   Computer Systems Support(v) 518 486-1697
   Wadsworth Center(f) 518 473-6384
   NYS Department of HealthHelp Desk 518 473-0773

Re: tapetape (not in faq-o-matic)

[Jon LaBadie]

On Thu, May 25, 2006 at 08:49:47AM -0400, Brian Cuttler wrote:
> Jon,
> 
> On Wed, May 24, 2006 at 07:25:46PM -0400, Jon LaBadie wrote:
> > On Wed, May 24, 2006 at 02:54:34PM -0400, Brian Cuttler wrote:
> > > The -e made a huge difference in runtime.
> > > # date ; amtapetype -e 400g -f /dev/rmt/3n ; date
> > > Wed May 24 09:23:58 EDT 2006
> > > Writing 2048 Mbyte   compresseable data:  33 sec
> > > Writing 2048 Mbyte uncompresseable data:  33 sec
> > > Estimated time to write 2 * 409600 Mbyte: 912 sec = 0 h 15 min
> > > wrote 12386304 32Kb blocks in 189 files in 6539 seconds (short write)
> > > define tapetype unknown-tapetype {
> > > comment "just produced by tapetype prog (hardware compression off)"
> > > length 386048 mbytes
> > > filemark 0 kbytes
> > > speed 61853 kps
> > > }
> > > 
> > > I really should run it again with HW compresson ON.
> > 
> > If like my ultrium 1, the block count will be exactly the same,
> > but the speed will be slower.
> 
> You are right, largely the same, run time of 3h 38 min and the speed
> was a little lower, but only by about 1%, but I don't know enough 
> about the amtapetype and maybe the pattern of the data written has
> a lot to do with that.
> 
> > date ; amtapetype -e 400g -f /dev/rmt/3un ; date
> Wed May 24 14:55:53 EDT 2006
> Writing 2048 Mbyte   compresseable data:  34 sec
> Writing 2048 Mbyte uncompresseable data:  33 sec
> Estimated time to write 2 * 409600 Mbyte: 912 sec = 0 h 15 min
> wrote 12320768 32Kb blocks in 94 files in 6320 seconds (short write)
> wrote 12386304 32Kb blocks in 189 files in 6487 seconds (short write)
> define tapetype unknown-tapetype {
> comment "just produced by tapetype prog (hardware compression off)"
> length 386048 mbytes
> filemark 0 kbytes
> speed 61742 kps
> }

Well, actually a little different.  I got my Ultrium 1 from ebay and
like a kid with a new toy ran several tapetypes on it.  Three different
physical tapes (two brands), one two times, and with 3 different block
sizes, and a couple with and without compression on.

The thing that flabbergasted me was the absolute consistancy of the
total blocks written (adjusted for block size).
Two of your report lines were like mine:

> > > wrote 12386304 32Kb blocks in 189 files in 6539 seconds (short write)
> wrote 12386304 32Kb blocks in 189 files in 6487 seconds (short write)

Oh, I did some with a different scsi controller too as the first one I
used was too low performance.  Same block count though.

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: missing result ... in ... response ???

[Jean-Louis Martineau]

Michael,

If the problem is that you have too many DLE for a udp packet, try the 
attached patch which will double the size of the packet.


Jean-Louis

Michael D Schleif wrote:

Something has changed in amanda.

I have been running amanda on this lan for several years.  For the most
part, DLE's have been constant for at least six months.  I have six
linux servers, all running debian.  Regarding amanda-server, my records
show that I upgraded amanda to version:

2.4.5 on 16JUN05

Everything was backing up, and restoring, to my satisfaction, until last
week.  At that time, two servers (brono & jord) were terribly old,
regarding kernel and debian os.  So, I upgraded via aptitude, which also
upgraded amanda-client to version:

2.5.0

Since that time, many -- but, NOT all -- DLE's on brono and jord are
FAIL'ing, e.g.:

brono  /var  lev 0  FAILED [missing result for /var in brono response]
jord   /var  lev 0  FAILED [missing result for /var in jord response]

Yes, both of these servers have many DLE's; but, as stated above, this
HAS been working without incident at the older version.  Numbers of
DLE's:

brono  137
jord   219

At first, I thought that this maybe conflict between amanda-server and
amanda-client versions; so, I upgraded amanda-server:

2.5.0 on 23MAY06

NO difference.

So, I searched these archives, and I googled.  All I found was this URL:



amanda.conf has never had `etimeout' configured.  Yesterday, I set it:

etimeout  600

NO difference.  Remember, this exact same configuration has been working
WITHOUT incident at older version for eleven months!

This is NOT a firewall issue, since this is only for my internal lan.

Regarding maximum udp datagram size:

net.inet.udp.maxdgram=63535

Apparently, sysctl on linux/debian does NOT support this.  I have pinged
debian-user on this issue; but, there has been NO response.  I do NOT
know what the current, default size is; nor do I know how to change it.

I prefer NOT to combine DLE's; which will pose other challenges, not the
least of which is DLE larger than tape.  These DLE's are very dynamic.
I cannot predict when a particular DLE will contain enormous data; and
the nature of this dynamic data is already compressed ...

What am I missing?  This used to work; then, it b0rk; and the only
change was a newer amanda version.

What do you think?

  


diff -u -r --show-c-function --exclude-from=amanda.diff amanda-2.5.0p2.orig/server-src/amcheck.c amanda-2.5.0p2.new/server-src/amcheck.c
--- amanda-2.5.0p2.orig/server-src/amcheck.c	2006-05-12 15:26:12.0 -0400
+++ amanda-2.5.0p2.new/server-src/amcheck.c	2006-05-25 10:11:46.0 -0400
@@ -1329,7 +1332,7 @@ void start_host(hostp)
 	/*
 	 * Allow 2X for err response.
 	 */
-	if(req_len + l_len > MAX_PACKET / 2) {
+	if(req_len + l_len >= MAX_PACKET) {
 		amfree(l);
 		break;
 	}
diff -u -r --show-c-function --exclude-from=amanda.diff amanda-2.5.0p2.orig/server-src/planner.c amanda-2.5.0p2.new/server-src/planner.c
--- amanda-2.5.0p2.orig/server-src/planner.c	2006-04-24 07:16:43.0 -0400
+++ amanda-2.5.0p2.new/server-src/planner.c	2006-05-25 10:11:28.0 -0400
@@ -1338,7 +1338,7 @@ am_host_t *hostp;
 		/*
 		 * Allow 2X for err response.
 		 */
-		if(req_len + s_len > MAX_PACKET / 2) {
+		if(req_len + s_len >= MAX_PACKET) {
 		amfree(s);
 		break;
 		}

missing result ... in ... response ???

[Michael D Schleif]

Something has changed in amanda.

I have been running amanda on this lan for several years.  For the most
part, DLE's have been constant for at least six months.  I have six
linux servers, all running debian.  Regarding amanda-server, my records
show that I upgraded amanda to version:

2.4.5 on 16JUN05

Everything was backing up, and restoring, to my satisfaction, until last
week.  At that time, two servers (brono & jord) were terribly old,
regarding kernel and debian os.  So, I upgraded via aptitude, which also
upgraded amanda-client to version:

2.5.0

Since that time, many -- but, NOT all -- DLE's on brono and jord are
FAIL'ing, e.g.:

brono  /var  lev 0  FAILED [missing result for /var in brono response]
jord   /var  lev 0  FAILED [missing result for /var in jord response]

Yes, both of these servers have many DLE's; but, as stated above, this
HAS been working without incident at the older version.  Numbers of
DLE's:

brono  137
jord   219

At first, I thought that this maybe conflict between amanda-server and
amanda-client versions; so, I upgraded amanda-server:

2.5.0 on 23MAY06

NO difference.

So, I searched these archives, and I googled.  All I found was this URL:



amanda.conf has never had `etimeout' configured.  Yesterday, I set it:

etimeout  600

NO difference.  Remember, this exact same configuration has been working
WITHOUT incident at older version for eleven months!

This is NOT a firewall issue, since this is only for my internal lan.

Regarding maximum udp datagram size:

net.inet.udp.maxdgram=63535

Apparently, sysctl on linux/debian does NOT support this.  I have pinged
debian-user on this issue; but, there has been NO response.  I do NOT
know what the current, default size is; nor do I know how to change it.

I prefer NOT to combine DLE's; which will pose other challenges, not the
least of which is DLE larger than tape.  These DLE's are very dynamic.
I cannot predict when a particular DLE will contain enormous data; and
the nature of this dynamic data is already compressed ...

What am I missing?  This used to work; then, it b0rk; and the only
change was a newer amanda version.

What do you think?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know.  The more I know, the more I know I don't know . . .
--


signature.asc
Description: Digital signature

Re: tapetape (not in faq-o-matic)

[Brian Cuttler]

Jon,

On Wed, May 24, 2006 at 07:25:46PM -0400, Jon LaBadie wrote:
> On Wed, May 24, 2006 at 02:54:34PM -0400, Brian Cuttler wrote:
> > The -e made a huge difference in runtime.
> > # date ; amtapetype -e 400g -f /dev/rmt/3n ; date
> > Wed May 24 09:23:58 EDT 2006
> > Writing 2048 Mbyte   compresseable data:  33 sec
> > Writing 2048 Mbyte uncompresseable data:  33 sec
> > Estimated time to write 2 * 409600 Mbyte: 912 sec = 0 h 15 min
> > wrote 12386304 32Kb blocks in 189 files in 6539 seconds (short write)
> > define tapetype unknown-tapetype {
> > comment "just produced by tapetype prog (hardware compression off)"
> > length 386048 mbytes
> > filemark 0 kbytes
> > speed 61853 kps
> > }
> > 
> > I really should run it again with HW compresson ON.
> 
> If like my ultrium 1, the block count will be exactly the same,
> but the speed will be slower.

You are right, largely the same, run time of 3h 38 min and the speed
was a little lower, but only by about 1%, but I don't know enough 
about the amtapetype and maybe the pattern of the data written has
a lot to do with that.

> date ; amtapetype -e 400g -f /dev/rmt/3un ; date
Wed May 24 14:55:53 EDT 2006
Writing 2048 Mbyte   compresseable data:  34 sec
Writing 2048 Mbyte uncompresseable data:  33 sec
Estimated time to write 2 * 409600 Mbyte: 912 sec = 0 h 15 min
wrote 12320768 32Kb blocks in 94 files in 6320 seconds (short write)
wrote 12386304 32Kb blocks in 189 files in 6487 seconds (short write)
define tapetype unknown-tapetype {
comment "just produced by tapetype prog (hardware compression off)"
length 386048 mbytes
filemark 0 kbytes
speed 61742 kps
}
Wed May 24 18:33:20 EDT 2006

thank you,

Brian

Holding area has files that are quite old Can I remove as I am doing some house keeping.

[Chuck Amadi Systems Administrator]

Hi List

I am just doing a bit of house keeping and in my holding disk partition

I have 

[EMAIL PROTECTED]:/backup/amanda-daily # du /backup | sort -nr | head
6417567 /backup
5400953 /backup/amanda-daily
636267  /backup/amanda-monthly/20060331
636267  /backup/amanda-monthly
297081  /backup/amanda-daily/20050923
296328  /backup/amanda-daily/20060111
294270  /backup/amanda-daily/20051027
293762  /backup/amanda-daily/20060102
293605  /backup/amanda-daily/20051227
293169  /backup/amanda-daily/20060215

Thus when I had a look in  /backup/amanda-daily The files are below The
first file is dated 13/07/2005 Can these files be deleted I assume that
because I haven't run amlflush at some point there still in the holding
disk.

drwxr-xr-x  26 amanda disk 624 2006-05-24 22:45 .
drwxr-xr-x   9 amanda disk 952 2006-05-12 16:21 ..
drwx--   2 amanda disk  88 2005-07-13 19:48 20050713
drwx--   2 amanda disk  88 2005-07-14 19:50 20050714
drwx--   2 amanda disk  88 2005-08-29 16:32 20050829
drwx--   2 amanda disk  88 2005-09-05 19:51 20050905
drwx--   2 amanda disk 328 2005-09-23 20:21 20050923
drwx--   2 amanda disk 240 2005-10-24 09:59 20051018
drwx--   2 amanda disk 376 2005-10-24 20:10 20051024
drwx--   2 amanda disk 288 2005-10-27 20:06 20051027
drwx--   2 amanda disk 344 2005-12-14 20:07 20051214
drwx--   2 amanda disk 104 2005-12-15 20:11 20051215
drwx--   2 amanda disk 392 2005-12-27 20:10 20051227
drwx--   2 amanda disk 248 2005-12-28 20:05 20051228
drwx--   2 amanda disk 344 2006-01-02 20:05 20060102
drwx--   2 amanda disk 336 2006-01-04 20:22 20060104
drwx--   2 amanda disk 296 2006-01-10 20:19 20060110
drwx--   2 amanda disk 336 2006-01-11 20:21 20060111
drwx--   2 amanda disk 376 2006-02-10 20:18 20060210
drwx--   2 amanda disk 424 2006-02-15 20:20 20060215
drwx--   2 amanda disk 424 2006-02-28 20:19 20060228
drwx--   2 amanda disk 336 2006-03-01 20:15 20060301
drwx--   2 amanda disk 320 2006-03-29 20:20 20060329
drwx--   2 amanda disk 368 2006-04-14 20:13 20060414
drwx--   2 amanda disk 320 2006-04-17 20:16 20060417
drwx--   2 amanda disk 320 2006-05-01 20:14 20060501

Thus please advise if it's OK to cleanup and remove these files.

Cheers


-- 
Unix/ Linux Systems Administrator
Chuck Amadi
The Surgical Material Testing Laboratory (SMTL), 
Princess of Wales Hospital 
Coity Road 
Bridgend, 
United Kingdom, CF31 1RQ.
Email chuck.smtl.co.uk
Tel: +44 1656 752820 
Fax: +44 1656 752830