Re: Stranded on waitq failure (planner: Message too long)

[Jean-Louis Martineau]

Ian Turner wrote:
I don't know if 2.5.1 is old enough to qualify for this issue, but it used to 
be the case that the entire set of disklists for a client had to fit in a 
single packet. What that meant is that if you had more than a few dozen disks 
on one client (depending on disklist options), you would run into this issue.


The solution is to upgrade, but a workaround is to create a second IP address 
and DNS name on the same physical client, and move some of the disklist 
entries to the latter.
  


Or change to the 'bsdtcp' auth.

Jean-Louis

--Ian

On Wednesday 05 November 2008 13:57:22 Dustin J. Mitchell wrote:
  

On Fri, Oct 31, 2008 at 9:01 AM, Leon Meßner

<[EMAIL PROTECTED]> wrote:


i get the following message with Amanda-2.5.1p3 on FreeBSD7.0:

   FAILED [hmm, disk was stranded on waitq]

planner: ERROR Request to myhostandserver failed: error sending REQ:
send REQ to myhostandserver failed: Message too long
  

As you've no doubt discovered, this means that the REQ packet was too
large to fit into a single UDP datagram.  I know that we've added some
additional information to the packets in recent versions, but I don't
know why that would be the case in 2.5.1.  Have others seen a similar
error?

Dustin

[Amanda-users] amcheckdump output - questions :)

[rory_f]

rory_f wrote:
> 
> Paul Bijnens wrote:
> > 
> > Indeed, use a changer and set "runtapes" to something greater than 1.
> > Amanda will write a tape until she hits End Of Tape (signaled by a write
> > error actually), and then move to a new tape. The whole backup image 
> > will be restarted on the next tape.  (With using "tape_splitsize" you
> > avoid starting the whole image, but start only the last chunk again)
> > 
> > When using a holdingdisk, the dumps are collected in the holdingdisk
> > unless the estimated backup image is larger than the holdingdisk.
> > When one complete backup image is finished, Amanda start to put it on tape.
> > Because many dumps can be collected simultaneously to holdingdisk,
> > several of them may be waiting to be written to tape.  If there are 
> > several to choose from, then the "taperalgo" setting decides which one 
> > will get tried first. A good setting is "largestfit" (see the wiki url 
> > above).  If no backupimage that is ready will fit in the estimated
> > available tapespace, then amanda will try the smallest, which has
> > the largest chance of fitting in the unknown free space.
> > 
> > The free space at the end of a tape is indeed unknown, because
> > tapes do not always have exactly the same length; and when using
> > software compression, the remaining space is even more uncertain, 
> > because it depends on the compressability of the previous tape images.
> 
> 
> backup image, meaning DLE? so if it runs out of space, it will right, for 
> instance, 35% of the DLE to the last bit of the tpae, then start again on the 
> new tape, thus meaning all data, in teh end, will get written to tape.  and 
> we can use amadmin  find to see what tape the whole DLE was dumped to, 
> right?
> 
> we currently have our runtapes to 28. as that is what our library can hold.
> 
> it all seems a lot clearer now. thanks

just as something more to this. last night i backed up what i thought was 
~340gb. it was actually a lot more than that (3 tapes worth) - i did this for 
DLEs:

site.com /array/sata-1/aaa/020 root-tar
site.com /array/sata-1/aaa/030 root-tar
site.com /array/sata-1/aaa/040 root-tar
site.com /array/sata-1/aaa/050 root-tar
site.com /array/sata-1/aaa/001 root-tar
site.com /array/sata-1/aaa/014 root-tar
site.com /array/sata-1/aaa/S020 root-tar
site.com /array/sata-1/aaa/S035 root-tar
site.com /array/sata-1/aaa/S039 root-tar
site.com /array/sata-1/aaa/S040 root-tar
site.com /array/sata-1/aaa/S045 root-tar

and it ended up being about 1.3tb, so it went onto 3 tapes. i got errors doing 
amcheckdump but i succesfully restored files from the tapes. 

two of the DLE's got 'PARTIAL' then 'OK" results in `amadmin tor find ` - so i 
am to assume they worked.

am i missing anything?

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--

Re: Stranded on waitq failure (planner: Message too long)

[Ian Turner]

I don't know if 2.5.1 is old enough to qualify for this issue, but it used to 
be the case that the entire set of disklists for a client had to fit in a 
single packet. What that meant is that if you had more than a few dozen disks 
on one client (depending on disklist options), you would run into this issue.

The solution is to upgrade, but a workaround is to create a second IP address 
and DNS name on the same physical client, and move some of the disklist 
entries to the latter.

--Ian

On Wednesday 05 November 2008 13:57:22 Dustin J. Mitchell wrote:
> On Fri, Oct 31, 2008 at 9:01 AM, Leon Meßner
>
> <[EMAIL PROTECTED]> wrote:
> > i get the following message with Amanda-2.5.1p3 on FreeBSD7.0:
> >
> >FAILED [hmm, disk was stranded on waitq]
> >
> > planner: ERROR Request to myhostandserver failed: error sending REQ:
> > send REQ to myhostandserver failed: Message too long
>
> As you've no doubt discovered, this means that the REQ packet was too
> large to fit into a single UDP datagram.  I know that we've added some
> additional information to the packets in recent versions, but I don't
> know why that would be the case in 2.5.1.  Have others seen a similar
> error?
>
> Dustin
-- 
Zmanda: Byte & Switch "Top 10 Storage Startups", July 2008

Re: Two can this be done question

[Ian Turner]

Robert,

For question #1: You can fudge the disklist file manually, since it just keeps 
the tape in order. Or you can relabel the tape with amlabel, which will do 
what you want.

For question #2: Read the manpages for the -o option, which lets you override 
any configuration directive for any Amanda command.

Cheers,

--Ian

On Wednesday 05 November 2008 15:17:19 McGraw, Robert P wrote:
> 1) I ran a backup several days ago but it had some errors but it did
> write some data to tape. I would like to remove this backup and reuse
> the tape. Is there an Amanda command that can remove all the necessary
> files for a particular backup or is this something that I need to do
> manually.
>
>
> 2) Is there a way that I can pass the "incronly" parameter in the amdump
> command line so that only incrementals will be preformed for that days
> backup?
>
> Thanks
>
> Robert
>
>
> _
> Robert P. McGraw, Jr.
> Manager, Computer SystemEMAIL: [EMAIL PROTECTED]
> Purdue UniversityROOM: MATH-807
> Department of Mathematics   PHONE: (765) 494-6055
> 150 N. University Street
> West Lafayette, IN 47907-2067
-- 
Zmanda: Byte & Switch "Top 10 Storage Startups", July 2008

[Amanda-users] amcheckdump output - questions :)

[rory_f]

Paul Bijnens wrote:
> 
> Indeed, use a changer and set "runtapes" to something greater than 1.
> Amanda will write a tape until she hits End Of Tape (signaled by a write
> error actually), and then move to a new tape. The whole backup image 
> will be restarted on the next tape.  (With using "tape_splitsize" you
> avoid starting the whole image, but start only the last chunk again)
> 
> When using a holdingdisk, the dumps are collected in the holdingdisk
> unless the estimated backup image is larger than the holdingdisk.
> When one complete backup image is finished, Amanda start to put it on tape.
> Because many dumps can be collected simultaneously to holdingdisk,
> several of them may be waiting to be written to tape.  If there are 
> several to choose from, then the "taperalgo" setting decides which one 
> will get tried first. A good setting is "largestfit" (see the wiki url 
> above).  If no backupimage that is ready will fit in the estimated
> available tapespace, then amanda will try the smallest, which has
> the largest chance of fitting in the unknown free space.
> 
> The free space at the end of a tape is indeed unknown, because
> tapes do not always have exactly the same length; and when using
> software compression, the remaining space is even more uncertain, 
> because it depends on the compressability of the previous tape images.


backup image, meaning DLE? so if it runs out of space, it will right, for 
instance, 35% of the DLE to the last bit of the tpae, then start again on the 
new tape, thus meaning all data, in teh end, will get written to tape.  and we 
can use amadmin  find to see what tape the whole DLE was dumped to, right?

we currently have our runtapes to 28. as that is what our library can hold.

it all seems a lot clearer now. thanks

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--

Re: amfetchdump: running as user "root" instead of "amanda" ??

[Jean-Louis Martineau]

Jean-Francois Malouin wrote:

* Jean-Louis Martineau <[EMAIL PROTECTED]> [20081104 13:46]:
  

Jean-Francois Malouin wrote:


Is this a new feature? I've done restore as root in the past I'm sure
and never seen this before. Have been living blind all this time? :)
So I guess I was lucky enough to do the amfetchdump in a dir owned by
amanda and then it could recreate the dir structure and file
ownerships...
 
  

Maybe you were using amrestore? It doesn't need amanda privilege.



I've used both for testing purposes before.
I've just finished a new restore test on a new piece of hardware:

# su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d
tape:/dev/nst0 top gustav /raid/ipl 20081104 | tar -xpGf -"
  
amfetchdump must be run by amanda, tar must be run by root. Logged as 
root, you do:


# su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d tape:/dev/nst0 top 
gustav /raid/ipl 20081104" | tar -xpGf -

Look where I put the ".

completes ok, looks good, the dle was successfully restored but tar
didn't restore the original ownerships of the dirs and files, they all
belong to user 'amanda' and group 'disk', its primary group, as I was
suspicious it would do in the first place, but I wanted to be 100%
sure before posting.

# tar --version
tar (GNU tar) 1.16

I don't see this on a another system, running the same amanda version,
2.5.2p1, but from a much earlier configured and compiled tarball

Proof is in the pudding. From a debug amandad:

amandad: time 0.016: build: VERSION="Amanda-2.5.2p1"
amandad: time 0.016:BUILT_DATE="Fri Jul 6 12:27:48 EDT 2007"
amandad: time 0.016:BUILT_MACH="IRIX64 wart 6.5 01062343 IP27"

yorick 117# /opt/amanda/amanda1/sbin/amfetchdump -p -d
/hw/tape/tps21d1nrnsv stk_80-conf1 yorick /data/speechprod/speechprod2
20081030 | /usr/freeware/bin/tar -xpGf -
1 tape(s) needed for restoration
The following tapes are needed: 38
Press enter when ready

Scanning 38 (slot 1)

and the restore completes ok. That's with tar (GNU tar) 1.13.25.

So that leads me to believe that it's either something that has been
backported in the tarball for 2.5.2p1 since then or is it a problem
with tar 1.16 on a Debian Etch machine?

thanks,
jf


  

Jean-Louis



  

Re: [Amanda-users] amcheckdump output - questions :)

[Paul Bijnens]

rory_f wrote:

Paul Bijnens wrote:

These two concepts are orthogonal:
- Amanda can use multiple tapes for one backup run.
- Amanda can split one backup image over multiple tapes.

It is only the second feature using the "tape_splitsize" parameter that makes
restores more difficult.
See: http://wiki.zmanda.com/index.php/How_To:Split_Dumps_Across_Tapes

But instead of dumping one enourmous DLE in one backup image, you can use
the include/exclude options with gnutar to split the DLE into smaller ones,
each fitting on a tape.
See: http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists

Figuring out tapecapacity and optimizing tape usage is handled with the
parameter "taperalgo largestfit", as explained here:
http://wiki.zmanda.com/index.php/How_To:Fill_tapes_to_100%25



ok,
smaller DLEs is fine. we have been doing this. i just thought using
span was the only way for amanda to intelligently change tapes when a
tape got full. we use a changer script. is that all we need to ensure it
will change tapes when a tape gets full? for instance, we just want to
make sure amanda will look at the size of the next dump, and move onto a
new tape if needed. right? we use a holding disk also, which im sure
makes it easier for amanda to know when to change tapes.

ultimately we want to setup the right DLEs, and archive a whole
proejct, around 6tb at at time. no interaction in this process is key.


Indeed, use a changer and set "runtapes" to something greater than 1.
Amanda will write a tape until she hits End Of Tape (signaled by a write
error actually), and then move to a new tape. The whole backup image 
will be restarted on the next tape.  (With using "tape_splitsize" you

avoid starting the whole image, but start only the last chunk again)

When using a holdingdisk, the dumps are collected in the holdingdisk
unless the estimated backup image is larger than the holdingdisk.
When one complete backup image is finished, Amanda start to put it on tape.
Because many dumps can be collected simultaneously to holdingdisk,
several of them may be waiting to be written to tape.  If there are 
several to choose from, then the "taperalgo" setting decides which one 
will get tried first. A good setting is "largestfit" (see the wiki url 
above).  If no backupimage that is ready will fit in the estimated

available tapespace, then amanda will try the smallest, which has
the largest chance of fitting in the unknown free space.

The free space at the end of a tape is indeed unknown, because
tapes do not always have exactly the same length; and when using
software compression, the remaining space is even more uncertain, 
because it depends on the compressability of the previous tape images.

Re: amfetchdump: running as user "root" instead of "amanda" ??

[Jean-Francois Malouin]

* Jean-Louis Martineau <[EMAIL PROTECTED]> [20081105 15:28]:
> >  
> amfetchdump must be run by amanda, tar must be run by root. Logged as 
> root, you do:
> 
> # su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d tape:/dev/nst0 
> top gustav /raid/ipl 20081104" | tar -xpGf -
> 
> Look where I put the ".

Indeed!

Thanks Jean-Louis!

jf
--
<° >< Jean-François Malouin  McConnell Brain Imaging Centre
System/Network AdministratorMontréal Neurological Institute
3801 Rue University, Suite WB219, Montréal, Québec, H3A 2B4, Canada

Re: amfetchdump: running as user "root" instead of "amanda" ??

[Paul Bijnens]

Jean-Francois Malouin wrote:

* Jean-Louis Martineau <[EMAIL PROTECTED]> [20081104 13:46]:

Jean-Francois Malouin wrote:

Is this a new feature? I've done restore as root in the past I'm sure
and never seen this before. Have been living blind all this time? :)
So I guess I was lucky enough to do the amfetchdump in a dir owned by
amanda and then it could recreate the dir structure and file
ownerships...
 

Maybe you were using amrestore? It doesn't need amanda privilege.


I've used both for testing purposes before.
I've just finished a new restore test on a new piece of hardware:

# su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d
tape:/dev/nst0 top gustav /raid/ipl 20081104 | tar -xpGf -"


You've put the quotes too far.  Put them only around the amfetchdump
command, and pipe the result to tar, which still has root priviliges
then:

  su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d
  tape:/dev/nst0 top gustav /raid/ipl 20081104" | tar -xpGf -



completes ok, looks good, the dle was successfully restored but tar
didn't restore the original ownerships of the dirs and files, they all
belong to user 'amanda' and group 'disk', its primary group, as I was
suspicious it would do in the first place, but I wanted to be 100%
sure before posting.



Tar needs root privileges indeed to restore ownership.
But amfetchdump needs to run as amanda.

There could maybe a case for allowing to run as root, but that
would open a whole lot of other problems, e.g. the debug directories 
like /tmp/amanda etc would be created with root ownership. That

would give trouble for the next command, run as amanda, which would
get permission to add its debug files to that directory.

Besides, in general, it is safer and giving less chance to hit security
problems when not running programs as root unless strictly necessary.

[Amanda-users] amcheckdump output - questions :)

[rory_f]

Paul Bijnens wrote:
> On 2008-11-05 17:53, rory_f wrote:
> 
> 
> > Um, haha. its all on the same machine. i dont think thats the case.
> > Im actually finishing up a backing up a 6tb project right now using
> > tape_splitsize, and perhaps from now on i wont use it. we have a
> > system in place to breakdown folder sizes for our whole file system
> > here, so using just single tapes and doing root-tar whilst figuring
> > out tape capacities ourself isnt actually out of the question.
> > 
> 
> 
> I'm not sure if I misunderstood you, just to be sure you understand me...
> 
> These two concepts are orthogonal:
> - Amanda can use multiple tapes for one backup run.
> - Amanda can split one backup image over multiple tapes.
> 
> It is only the second feature using the "tape_splitsize" parameter that makes
> restores more difficult.
> See: http://wiki.zmanda.com/index.php/How_To:Split_Dumps_Across_Tapes
> 
> But instead of dumping one enourmous DLE in one backup image, you can use
> the include/exclude options with gnutar to split the DLE into smaller ones,
> each fitting on a tape.
> See: http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists
> 
> Figuring out tapecapacity and optimizing tape usage is handled with the
> parameter "taperalgo largestfit", as explained here:
> http://wiki.zmanda.com/index.php/How_To:Fill_tapes_to_100%25
> 
> -- 
> Paul Bijnens, xplanation Technology ServicesTel  +32 16 397.511
> Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
> http://www.xplanation.com/  email:  Paul.Bijnens < at > xplanation.com
> ***
> * 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, *
> * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
> * ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
> ***


ok,
smaller DLEs is fine. we have been doing this. i just thought using span was 
the only way for amanda to intelligently change tapes when a tape got full.  we 
use a changer script. is that all we need to ensure it will change tapes when a 
tape gets full? for instance, we just want to make sure amanda will look at the 
size of the next dump, and move onto a new tape if needed. right? we use a 
holding disk also,  which im sure makes it easier for amanda to know when to 
change tapes.

ultimately we want to setup the right DLEs, and archive a whole proejct, around 
6tb at at time. no interaction in this process is key.

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--

Two can this be done question

[McGraw, Robert P]

1) I ran a backup several days ago but it had some errors but it did
write some data to tape. I would like to remove this backup and reuse
the tape. Is there an Amanda command that can remove all the necessary
files for a particular backup or is this something that I need to do
manually.


2) Is there a way that I can pass the "incronly" parameter in the amdump
command line so that only incrementals will be preformed for that days
backup?

Thanks

Robert


_
Robert P. McGraw, Jr.
Manager, Computer SystemEMAIL: [EMAIL PROTECTED]
Purdue UniversityROOM: MATH-807
Department of Mathematics   PHONE: (765) 494-6055
150 N. University Street  
West Lafayette, IN 47907-2067
 

Re: amfetchdump: running as user "root" instead of "amanda" ??

[Dustin J. Mitchell]

On Tue, Nov 4, 2008 at 12:08 PM, Jean-Francois Malouin
<[EMAIL PROTECTED]> wrote:
> Is this a new feature? I've done restore as root in the past I'm sure
> and never seen this before. Have been living blind all this time? :)
> So I guess I was lucky enough to do the amfetchdump in a dir owned by
> amanda and then it could recreate the dir structure and file
> ownerships...

We improved how Amanda checks userids.  There may have been a bug that
accidentally allowed amfetchdump to run as root in a previous version.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com

Re: amfetchdump: running as user "root" instead of "amanda" ??

[Jean-Francois Malouin]

* Jean-Louis Martineau <[EMAIL PROTECTED]> [20081104 13:46]:
> Jean-Francois Malouin wrote:
> >Is this a new feature? I've done restore as root in the past I'm sure
> >and never seen this before. Have been living blind all this time? :)
> >So I guess I was lucky enough to do the amfetchdump in a dir owned by
> >amanda and then it could recreate the dir structure and file
> >ownerships...
> >  
> 
> Maybe you were using amrestore? It doesn't need amanda privilege.

I've used both for testing purposes before.
I've just finished a new restore test on a new piece of hardware:

# su amanda -c "/opt/amanda/sbin/amfetchdump -b 2048k -p -d
tape:/dev/nst0 top gustav /raid/ipl 20081104 | tar -xpGf -"

completes ok, looks good, the dle was successfully restored but tar
didn't restore the original ownerships of the dirs and files, they all
belong to user 'amanda' and group 'disk', its primary group, as I was
suspicious it would do in the first place, but I wanted to be 100%
sure before posting.

# tar --version
tar (GNU tar) 1.16

I don't see this on a another system, running the same amanda version,
2.5.2p1, but from a much earlier configured and compiled tarball

Proof is in the pudding. From a debug amandad:

amandad: time 0.016: build: VERSION="Amanda-2.5.2p1"
amandad: time 0.016:BUILT_DATE="Fri Jul 6 12:27:48 EDT 2007"
amandad: time 0.016:BUILT_MACH="IRIX64 wart 6.5 01062343 IP27"

yorick 117# /opt/amanda/amanda1/sbin/amfetchdump -p -d
/hw/tape/tps21d1nrnsv stk_80-conf1 yorick /data/speechprod/speechprod2
20081030 | /usr/freeware/bin/tar -xpGf -
1 tape(s) needed for restoration
The following tapes are needed: 38
Press enter when ready

Scanning 38 (slot 1)

and the restore completes ok. That's with tar (GNU tar) 1.13.25.

So that leads me to believe that it's either something that has been
backported in the tarball for 2.5.2p1 since then or is it a problem
with tar 1.16 on a Debian Etch machine?

thanks,
jf


> 
> Jean-Louis

-- 
<° >< Jean-François Malouin  McConnell Brain Imaging Centre
System/Network AdministratorMontréal Neurological Institute
  3801 Rue University, Suite WB219
(514) 398-8924Montréal, Québec, H3A 2B4, Canada

Re: Stranded on waitq failure (planner: Message too long)

[Dustin J. Mitchell]

On Fri, Oct 31, 2008 at 9:01 AM, Leon Meßner
<[EMAIL PROTECTED]> wrote:
> i get the following message with Amanda-2.5.1p3 on FreeBSD7.0:
>
>FAILED [hmm, disk was stranded on waitq]
>
> planner: ERROR Request to myhostandserver failed: error sending REQ:
> send REQ to myhostandserver failed: Message too long

As you've no doubt discovered, this means that the REQ packet was too
large to fit into a single UDP datagram.  I know that we've added some
additional information to the packets in recent versions, but I don't
know why that would be the case in 2.5.1.  Have others seen a similar
error?

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com

Re: [Amanda-users] amcheckdump output - questions :)

[Paul Bijnens]

On 2008-11-05 17:53, rory_f wrote:


Um, haha. its all on the same machine. i dont think thats the case.

> Im actually finishing up a backing up a 6tb project right now using
> tape_splitsize, and perhaps from now on i wont use it. we have a
> system in place to breakdown folder sizes for our whole file system
> here, so using just single tapes and doing root-tar whilst figuring
> out tape capacities ourself isnt actually out of the question.


I'm not sure if I misunderstood you, just to be sure you understand me...

These two concepts are orthogonal:
- Amanda can use multiple tapes for one backup run.
- Amanda can split one backup image over multiple tapes.

It is only the second feature using the "tape_splitsize" parameter that makes
restores more difficult.
See: http://wiki.zmanda.com/index.php/How_To:Split_Dumps_Across_Tapes

But instead of dumping one enourmous DLE in one backup image, you can use
the include/exclude options with gnutar to split the DLE into smaller ones,
each fitting on a tape.
See: http://wiki.zmanda.com/index.php/How_To:Split_DLEs_With_Exclude_Lists

Figuring out tapecapacity and optimizing tape usage is handled with the
parameter "taperalgo largestfit", as explained here:
http://wiki.zmanda.com/index.php/How_To:Fill_tapes_to_100%25

--
Paul Bijnens, xplanation Technology ServicesTel  +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, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***

[Amanda-users] amcheckdump output - questions :)

[rory_f]

Jon LaBadie wrote:
> On Wed, Nov 05, 2008 at 09:39:36AM -0500, rory_f wrote:
> 
> > 
> > the question again then i guess?
> > 
> > hi guys.
> > 
> > we're run amcheckdump on a backup we just did and it has given us a few 
> > outputs we're not sure about -whether it is tar being non-understanding of 
> > a backup using spanned tapes, or something else? we're a bit lost so 
> > hopefully someone can help
> > 
> > ps. ignore the file paths below, i just changed them to cover our 
> > hostname/directories.
> > 
> > 
> > ..20081029235711 level 0 part 4 on tape AmaTor-007 file #1
> > "/dev/nst0" uses deprecated device naming convention;
> > using "tape:/dev/nst0" instead.
> > /bin/gtar: Read 2048 bytes from -
> > /bin/gtar: Unexpected EOF in archive
> > /bin/gtar: Error is not recoverable: exiting now
> > Validation process returned 2 (full status 512)
> > 
> 
> As above, a good number of the error messages were generated
> by /bin/gtar itself.  Is it possible that the backups were
> made with one version of gnutar and amcheckdump is calling
> a different one with some incompatibilities?
> 
> Nah, that never happens ;)
> 
> jl
> 
> 
> 
> > using '/bin/gtar tf - > /tmp/amanda_amcheckdump && cat > 
> > /tmp/amanda_amcheckdump'.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 5 on tape AmaTor-007 file #2
> > Continuing with previously started validation process.
> > Error reading 32768 bytes from /dev/nst0: Input/output error
> > Error reading device or writing data to validation command.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 1 on tape AmaTor-007 file #3
> > Could not seek to file 3 of volume AmaTor-007.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 2 on tape AmaTor-007 file #4
> > Details of dump at file 4 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 3 on tape AmaTor-007 file #5
> > Details of dump at file 5 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 4 on tape AmaTor-007 file #6
> > Details of dump at file 6 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 5 on tape AmaTor-007 file #7
> > Details of dump at file 7 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 6 on tape AmaTor-007 file #8
> > Details of dump at file 8 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 7 on tape AmaTor-007 file #9
> > Details of dump at file 9 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 8 on tape AmaTor-007 file #10
> > Details of dump at file 10 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 9 on tape AmaTor-007 file #11
> > Details of dump at file 11 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 10 on tape AmaTor-007 file #12
> > Details of dump at file 12 of volume AmaTor-007 do not match logfile.
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 11 on tape AmaTor-008 file #1
> > "/dev/nst0" uses deprecated device naming convention;
> > using "tape:/dev/nst0" instead.
> > using '/bin/gtar tf - > /tmp/amanda_amcheckdump && cat > 
> > /tmp/amanda_amcheckdump'.
> > /bin/gtar: This does not look like a tar archive
> > /bin/gtar: Skipping to next header
> > /bin/gtar: Archive contains obsolescent base-64 headers
> > Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
> > 20081029235711 level 0 part 12 on tape AmaTor-008 file #2
> > Continuing with previously started validation process.
> > /bin/gtar: Error exit delayed from previous errors
> > Validation process returned 2 (full status 512)
> > 
> > 
> > Whats the easiest way to figure out what file(s) the error is refering to? 
> > And/Or is it really something to worry about.
> > 
> > What about the last error, validation process returned 2? What does this 
> > mean? is there any way to run a check on the tape itself, and not the whole 
> > backup again, to save time?
> > 
> > Thanks.
> > 
> > +--
> > |This was sent by rory < at > mrxfx.com via Backup Central.
> > |Forward SPAM to abuse < at > backupcentral.com.
> > +--

Re: [Amanda-users] amcheckdump output - questions :)

[Paul Bijnens]

Ok, because I complained to repeat the question in full, here
is my short answer.

I don't know.

I never use amcheckdump (I only tested it once in a small test environment).

Instead of using amcheckdump, I do this:
If no user asked me to restore a file for two weeks, I do a test restore
of a file myself, choosing a from a DLE that is important, and/or has given
trouble recently, and/or is near the end of a tape (we have multiple tape
backups).

If possible, I try to avoid the split_tape feature (one backup image spanning
multiple tapes) of amanda as well; and until now, I could always find a way
to avoid it. The split_tape feature makes a bare metal restore without a
recent amanda version much more difficult.  Instead I use larger tapes,
and splitting up a large DLE into many smaller ones using gnutar include/exclude
features.

It would be good for the Amanda community to find out once and for all.

Oh, you say, "it takes 5+ hours to read one image? I have no time to test that!"
That's exactly one of the reasons to avoid such enormous backup images as well.
My users are usually too impatient to wait 5+ hours to restore one file, which
happens to be located near the end of the backup image, were Murphy usually puts
those.


On 2008-11-05 15:39, rory_f wrote:

the question again then i guess?

hi guys.

we're run amcheckdump on a backup we just did and it has given us a few outputs 
we're not sure about -whether it is tar being non-understanding of a backup 
using spanned tapes, or something else? we're a bit lost so hopefully someone 
can help

ps. ignore the file paths below, i just changed them to cover our 
hostname/directories.


..20081029235711 level 0 part 4 on tape AmaTor-007 file #1
"/dev/nst0" uses deprecated device naming convention;
using "tape:/dev/nst0" instead.
/bin/gtar: Read 2048 bytes from -
/bin/gtar: Unexpected EOF in archive
/bin/gtar: Error is not recoverable: exiting now
Validation process returned 2 (full status 512)
using '/bin/gtar tf - > /tmp/amanda_amcheckdump && cat > 
/tmp/amanda_amcheckdump'.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 5 on tape AmaTor-007 file #2
Continuing with previously started validation process.
Error reading 32768 bytes from /dev/nst0: Input/output error
Error reading device or writing data to validation command.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 1 on tape AmaTor-007 file #3
Could not seek to file 3 of volume AmaTor-007.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 2 on tape AmaTor-007 file #4
Details of dump at file 4 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 3 on tape AmaTor-007 file #5
Details of dump at file 5 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 4 on tape AmaTor-007 file #6
Details of dump at file 6 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 5 on tape AmaTor-007 file #7
Details of dump at file 7 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 6 on tape AmaTor-007 file #8
Details of dump at file 8 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 7 on tape AmaTor-007 file #9
Details of dump at file 9 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 8 on tape AmaTor-007 file #10
Details of dump at file 10 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 9 on tape AmaTor-007 file #11
Details of dump at file 11 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 10 on tape AmaTor-007 file #12
Details of dump at file 12 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 11 on tape AmaTor-008 file #1
"/dev/nst0" uses deprecated device naming convention;
using "tape:/dev/nst0" instead.
using '/bin/gtar tf - > /tmp/amanda_amcheckdump && cat > 
/tmp/amanda_amcheckdump'.
/bin/gtar: This does not look like a tar archive
/bin/gtar: Skipping to next header
/bin/gtar: Archive contains obsolescent base-64 headers
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 12 on tape AmaTor-008 file #2
Continuing with previously started validation process.
/bin/gtar: Error exit delayed from previou

[Amanda-users] amcheckdump output - questions :)

[rory_f]

the question again then i guess?

hi guys.

we're run amcheckdump on a backup we just did and it has given us a few outputs 
we're not sure about -whether it is tar being non-understanding of a backup 
using spanned tapes, or something else? we're a bit lost so hopefully someone 
can help

ps. ignore the file paths below, i just changed them to cover our 
hostname/directories.


..20081029235711 level 0 part 4 on tape AmaTor-007 file #1
"/dev/nst0" uses deprecated device naming convention;
using "tape:/dev/nst0" instead.
/bin/gtar: Read 2048 bytes from -
/bin/gtar: Unexpected EOF in archive
/bin/gtar: Error is not recoverable: exiting now
Validation process returned 2 (full status 512)
using '/bin/gtar tf - > /tmp/amanda_amcheckdump && cat > 
/tmp/amanda_amcheckdump'.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 5 on tape AmaTor-007 file #2
Continuing with previously started validation process.
Error reading 32768 bytes from /dev/nst0: Input/output error
Error reading device or writing data to validation command.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 1 on tape AmaTor-007 file #3
Could not seek to file 3 of volume AmaTor-007.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 2 on tape AmaTor-007 file #4
Details of dump at file 4 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 3 on tape AmaTor-007 file #5
Details of dump at file 5 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 4 on tape AmaTor-007 file #6
Details of dump at file 6 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 5 on tape AmaTor-007 file #7
Details of dump at file 7 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 6 on tape AmaTor-007 file #8
Details of dump at file 8 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 7 on tape AmaTor-007 file #9
Details of dump at file 9 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 8 on tape AmaTor-007 file #10
Details of dump at file 10 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 9 on tape AmaTor-007 file #11
Details of dump at file 11 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 10 on tape AmaTor-007 file #12
Details of dump at file 12 of volume AmaTor-007 do not match logfile.
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 11 on tape AmaTor-008 file #1
"/dev/nst0" uses deprecated device naming convention;
using "tape:/dev/nst0" instead.
using '/bin/gtar tf - > /tmp/amanda_amcheckdump && cat > 
/tmp/amanda_amcheckdump'.
/bin/gtar: This does not look like a tar archive
/bin/gtar: Skipping to next header
/bin/gtar: Archive contains obsolescent base-64 headers
Validating image .com:/array/sata-1/.../SHOTS/something/ datestamp 
20081029235711 level 0 part 12 on tape AmaTor-008 file #2
Continuing with previously started validation process.
/bin/gtar: Error exit delayed from previous errors
Validation process returned 2 (full status 512)


Whats the easiest way to figure out what file(s) the error is refering to? 
And/Or is it really something to worry about.

What about the last error, validation process returned 2? What does this mean? 
is there any way to run a check on the tape itself, and not the whole backup 
again, to save time?

Thanks.

+--
|This was sent by [EMAIL PROTECTED] via Backup Central.
|Forward SPAM to [EMAIL PROTECTED]
+--

Re: [Amanda-users] amcheckdump output - questions :)

[Paul Bijnens]

On 2008-11-04 17:45, rory_f wrote:

Hi guys,

any ideas??


My crystal ball is broken currently.
It would help to spell out the question.


--
Paul Bijnens, xplanation Technology ServicesTel  +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, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out  *
***