ah ha!

We are backing up the amanda server, a FW, the old database
system behind the FW and this new system. The DBA has been
installing/configuring additional SW and databases and the
non-global zone has grown to over 200 Gig.

We are still using an SDLT 320 as the SL24/LTO4 hasn't been
delivered.

No wonder my backups keep failing. We are simply out of
capacity - I know amanda timeout didn't feel right. I failed
to recheck that the DBA had done and the limits on the
available HW.

Thanks for your time... I now have a definite direction to
move in, one that is outside the scope of amanda. [Too bad,
I know how to cadjole amanda, there is little I can do to
finess more space out of the SDLT.]

						 thank you,

						 Brian


On Wed, Nov 18, 2009 at 05:20:36PM -0500, Nathan Stratton Treadway wrote:
> On Wed, Nov 18, 2009 at 16:56:47 -0500, Brian Cuttler wrote:
> >
> > Yes, I saw what you saw in the gtar report - I can only
> > surmize that the error is written in a confusing mannor.
> >
> > /proc is definitely a directory that contains files that
> > are named for process ids that can be found on the system.
>
> Well, I suppose it's possible that for some version or other of GNU tar
> this could just be because of a misleading error message, but my hunch
> would be that someting more tricky is going on.  (In other words, I
> don't think tar would output that error message unless it really was
> trying to back up "proc" as a file -- which seems like it would be a bad
> sign....  As long as it was treating "proc" as a directory, you'd expect
> tar to report changes with "file changed as we read it" or "cannot stat:
> no such file or directory" errors on the files found underneath that
> directory, and not as a message realted to the directory itself.)
>
> I take it you did tests like running
>   ls -l /export/zones/dorldom1z1/root
>   ls -ld /export/zones/dorldom1z1/root/proc
>   ls -l /export/zones/dorldom1z1/root/proc
>
> from within the environment that the Amanda client software would run
> while doing this backup?
>
> (I don't know that this necessarily has anything to do with your timeout
> problem; I'm just saying that message seems like a red flag worth
> investigating to make sure it doesn't indicate a deeper problem.  Though
> it's certainly possible that it's just an artifact related to Solaris
> zones, which I don't have any experience with myself.)
>
> 					 Nathan
>
>
>
> ----------------------------------------------------------------------------
> Nathan Stratton Treadway  -  nathanst@...  -  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


---
    Brian R Cuttler                 brian.cuttler@...
    Computer Systems Support        (v) 518 486-1697
    Wadsworth Center                (f) 518 473-6384
    NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

WE just recently rebuilt 2.6.1 on FreeBSD 7.2 STABLE, and this mornign I
went to do a restore, to find out that the "header" in the file contains
an incorect invocation of the FreeBSD resore command. here is what is in
the file:

To restore, position tape at start of file and run:
dd if=<tape> bs=32k skip=1 | /usr/bin/gzip -dc | /sbin/restore -xpGf - ...

Problem is FreeBSD's restore does not support the -p nor -G flags. At what
point in the configure/build process is this string determined?


--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Amanda users,

I check using amstatus this morning, we where pushing 70% and then
the dump failed... We seem very consistent on the failure point.

Tried the following from the command line, was in global-zone
"dorldom", which is an ldom (logical domain) on host "sc1"
Attempting to backup files that are within the non-global-zone
"dorldom1z1"

# gtar --exclude=./root/proc -cf /tmp/1z1.gtar /export/zones/dorldom1z1

so I'm not sure my exlude of "./root/proc" is right yet...

but I don't know that that explains the failure either.

Will see if I can't locate a meaningful debug file to forward.

						 thanks,

						 Brian

On Wed, Nov 18, 2009 at 05:20:36PM -0500, Nathan Stratton Treadway wrote:
> On Wed, Nov 18, 2009 at 16:56:47 -0500, Brian Cuttler wrote:
> >
> > Yes, I saw what you saw in the gtar report - I can only
> > surmize that the error is written in a confusing mannor.
> >
> > /proc is definitely a directory that contains files that
> > are named for process ids that can be found on the system.
>
> Well, I suppose it's possible that for some version or other of GNU tar
> this could just be because of a misleading error message, but my hunch
> would be that someting more tricky is going on.  (In other words, I
> don't think tar would output that error message unless it really was
> trying to back up "proc" as a file -- which seems like it would be a bad
> sign....  As long as it was treating "proc" as a directory, you'd expect
> tar to report changes with "file changed as we read it" or "cannot stat:
> no such file or directory" errors on the files found underneath that
> directory, and not as a message realted to the directory itself.)
>
> I take it you did tests like running
>   ls -l /export/zones/dorldom1z1/root
>   ls -ld /export/zones/dorldom1z1/root/proc
>   ls -l /export/zones/dorldom1z1/root/proc
>
> from within the environment that the Amanda client software would run
> while doing this backup?
>
> (I don't know that this necessarily has anything to do with your timeout
> problem; I'm just saying that message seems like a red flag worth
> investigating to make sure it doesn't indicate a deeper problem.  Though
> it's certainly possible that it's just an artifact related to Solaris
> zones, which I don't have any experience with myself.)
>
> 					 Nathan
>
>
>
> ----------------------------------------------------------------------------
> Nathan Stratton Treadway  -  nathanst@...  -  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


---
    Brian R Cuttler                 brian.cuttler@...
    Computer Systems Support        (v) 518 486-1697
    Wadsworth Center                (f) 518 473-6384
    NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

Yes Chris you are right it's an OS issue and I've opened a case with SUN
support. We want to use the
sgen - Generic SCSI device driver to access the library in Solaris and the tape
drivers. And then hopefully
the mtx changer support in Amanda.

Thanks Gunnar Gunnarsson

Gunnarsson, Gunnar wrote:
> Hi
>
> I'm trying to configure Sun SL48 autloader with Amanda on Solaris 10
> 10/09  sparc system.  SL48 library is connected to our SAN  switches
> and disk are beeing used and configured on the SAN but I'm not seeing
> the the tape driver.
>
> # ls /dev/rmt/
> #
>
> # /usr/sbin/add_drv -v  st
> exit status = 0
> devfsadm: driver failed to attach: st
> exit status = 1
> Warning: Driver (st) successfully added to system but failed to attach
> Driver (st) installed.

Your post is really an OS question rather than an Amanda question. I see that
you also posted on the Sun forums, so that's good. I also found a post (I just
googled "sl48 san solaris") by someone else that has a fair number of replies
that might help. It's someone trying to do the same thing, but with NetBackup
(which is really irrelevant). The clues appear to be related to configuring
sg.conf and st.conf. That makes sense to me, but I've never messed with devices
connected through SAN switches.
The thread is here
http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/\
symantec-netbackup-18/solaris-10-run-netbackup-cannot-detect-sun-storageteksl48-\
96060/


--
---------------

Chris Hoogendyk

-
    O__  ---- Systems Administrator
   c/ /'_ --- Biology & Geology Departments
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst

<hoogendyk@...>

---------------

Erdös 4

On Wed, Nov 18, 2009 at 16:56:47 -0500, Brian Cuttler wrote:
>
> Yes, I saw what you saw in the gtar report - I can only
> surmize that the error is written in a confusing mannor.
>
> /proc is definitely a directory that contains files that
> are named for process ids that can be found on the system.

Well, I suppose it's possible that for some version or other of GNU tar
this could just be because of a misleading error message, but my hunch
would be that someting more tricky is going on.  (In other words, I
don't think tar would output that error message unless it really was
trying to back up "proc" as a file -- which seems like it would be a bad
sign....  As long as it was treating "proc" as a directory, you'd expect
tar to report changes with "file changed as we read it" or "cannot stat:
no such file or directory" errors on the files found underneath that
directory, and not as a message realted to the directory itself.)

I take it you did tests like running
   ls -l /export/zones/dorldom1z1/root
   ls -ld /export/zones/dorldom1z1/root/proc
   ls -l /export/zones/dorldom1z1/root/proc

from within the environment that the Amanda client software would run
while doing this backup?

(I don't know that this necessarily has anything to do with your timeout
problem; I'm just saying that message seems like a red flag worth
investigating to make sure it doesn't indicate a deeper problem.  Though
it's certainly possible that it's just an artifact related to Solaris
zones, which I don't have any experience with myself.)

						 Nathan



----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst@...  -  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

Nathan,

Yes, I saw what you saw in the gtar report - I can only
surmize that the error is written in a confusing mannor.

/proc is definitely a directory that contains files that
are named for process ids that can be found on the system.

I've updated the exclude command... we'll see if it helps.

						 thanks,

						 Brian

On Wed, Nov 18, 2009 at 04:49:26PM -0500, Nathan Stratton Treadway wrote:
> On Wed, Nov 18, 2009 at 16:27:44 -0500, Brian Cuttler wrote:
> [...]
> > I had an exclude for "./root/proc/*", which may have been invalid
> > and found nothing, I've changed it to "./root/proc" and will keep
> > my fingers crossed for tonight.
>
> [...]
> > > > ----- Forwarded message from Amanda on Gat0 <amanda@...> -----
> > > > FAILED AND STRANGE DUMP DETAILS:
> > > > /-- dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read:
Connection timed out]
> [...]
> > > > ? /usr/sfw/bin/gtar: ./root/proc: file changed as we read it
>
> For what it's worth, tar's message here indicates that the "./root/proc"
> path references a file, not a directory.
>
> (So your original exclude pattern definitely wouldn't have matched it...
> and I'm a little curious to know more about this file came to have such
> a confusing name :) .)
>
> 						 Nathan
>
> ----------------------------------------------------------------------------
> Nathan Stratton Treadway  -  nathanst@...  -  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


---
    Brian R Cuttler                 brian.cuttler@...
    Computer Systems Support        (v) 518 486-1697
    Wadsworth Center                (f) 518 473-6384
    NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

On Wed, Nov 18, 2009 at 16:27:44 -0500, Brian Cuttler wrote:
[...]
> I had an exclude for "./root/proc/*", which may have been invalid
> and found nothing, I've changed it to "./root/proc" and will keep
> my fingers crossed for tonight.

[...]
> > > ----- Forwarded message from Amanda on Gat0 <amanda@...> -----
> > > FAILED AND STRANGE DUMP DETAILS:
> > > /-- dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read:
Connection timed out]
[...]
> > > ? /usr/sfw/bin/gtar: ./root/proc: file changed as we read it

For what it's worth, tar's message here indicates that the "./root/proc"
path references a file, not a directory.

(So your original exclude pattern definitely wouldn't have matched it...
and I'm a little curious to know more about this file came to have such
a confusing name :) .)

							 Nathan

----------------------------------------------------------------------------
Nathan Stratton Treadway  -  nathanst@...  -  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

Frank,

Dustin suggested the same, just checked and to my suprise the
switch was present, up'd it from 1800 to 2400 (seconds).

It was the only DLE in the test though and had progressed to
70% the last time I'd checked. I don't think it was idle...

I had an exclude for "./root/proc/*", which may have been invalid
and found nothing, I've changed it to "./root/proc" and will keep
my fingers crossed for tonight.

						 thanks,

						 Brian

> You're probably on the edge of either the estimate or data timeout
> values (etimeout or dtimeout).  You could try increasing those
> values.  I'm not familiar with Solaris zones, but if ./root/proc
> is really the proc filesystem, you should exclude that from
> your backup as it can be quite a rabbit hole. Try  using an
> exclude file or exclude list to exclude ./root/proc and see if
> that speeds things up.


On Wed, Nov 18, 2009 at 03:17:41PM -0600, Frank Smith wrote:
> Brian Cuttler wrote:
> > Amanda users,
> >
> > The backup of this particular DLE is pretty much hit or miss,
> > it'll run great for a week and then fail for a week, I haven't
> > been able to disern a pattern nor reason.
> >
> > The amanda server is old, 2.4.4 on a Solaris/Sparc system,
> > the newest client is a Solaris/x86 with a current version
> > 2.6.1 of amanda.
> >
> > The client "sc1" backs up up fine, we backup the "ldom" logical
> > domain separately since it lives on a ZFS partition that is not
> > available to the underlying OS.
> >
> > Because of the size of the dorldom1z1 partition, which is a
> > non-global zone running oracle, we back it up separately from
> > the other non-global zones, which run other, lighter apps.
> >
> > The base system "sc1" backups up fine, the ldom and 3 of the 4
> > non-global zones backup without error, its just this one additional
> > non-global zone that has been problematic.
> >
> > We are in process of upgrading the amanda server, but that will
> > come along with an upgrade of the box it sits on, a fire wall
> > we plan to replace.
> >
> > 					 thank you,
> >
> > 					 Brian
> >
> > ----- Forwarded message from Amanda on Gat0 <amanda@...> -----
>
> >
> > These dumps were to tape MIMOSA15.
> > The next tape Amanda expects to use is: MIMOSA16.
> >
> > FAILURE AND STRANGE DUMP SUMMARY:
> >   dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read: Connection
timed out]
> >
> >
> > STATISTICS:
> >                           Total       Full      Daily
> >                         --------   --------   --------
> > Estimate Time (hrs:min)    0:03
> > Run Time (hrs:min)         2:13
> > Dump Time (hrs:min)        0:00       0:00       0:00
> > Output Size (meg)           0.0        0.0        0.0
> > Original Size (meg)         0.0        0.0        0.0
> > Avg Compressed Size (%)     --         --         --
> > Filesystems Dumped            0          0          0
> > Avg Dump Rate (k/s)         --         --         --
> >
> > Tape Time (hrs:min)        0:00       0:00       0:00
> > Tape Size (meg)             0.0        0.0        0.0
> > Tape Used (%)               0.0        0.0        0.0
> > Filesystems Taped             0          0          0
> > Avg Tp Write Rate (k/s)     --         --         --
> >
> > USAGE BY TAPE:
> >   Label          Time      Size      %    Nb
> >   MIMOSA15       0:00       0.0    0.0     0
> >
> >
> > FAILED AND STRANGE DUMP DETAILS:
> >
> > /-- dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read: Connection
timed out]
> > sendbackup: start [dorldom1:/export/zones/dorldom1z1 level 0]
> > sendbackup: info BACKUP=/usr/sfw/bin/gtar
> > sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sfw/bin/gtar -xpGf - ...
> > sendbackup: info COMPRESS_SUFFIX=.gz
> > sendbackup: info end
> > ? /usr/sfw/bin/gtar: ./root/proc: file changed as we read it
> > \--------
> >
> >
> > NOTES:
> >   planner: Forcing full dump of dorldom1:/export/zones/dorldom1z1 as
directed.
> >   driver: WARNING: /amanda/work: 57344000 KB requested, but only 57092025 KB
available.
> >   taper: tape MIMOSA15 kb 0 fm 0 [OK]
> >
> >
> > DUMP SUMMARY:
> >                                       DUMPER STATS                TAPER
STATS
> > HOSTNAME DISK           L   ORIG-KB    OUT-KB COMP% MMM:SS   KB/s MMM:SS  
KB/s
> > ------------------------ ---------------------------------------
-------------
> > dorldom -es/dorldom1z1 0 FAILED
----------------------------------------------
> >
> > (brought to you by Amanda version 2.4.4)
> >
> > ----- End forwarded message -----
> >
>
> You're probably on the edge of either the estimate or data timeout
> values (etimeout or dtimeout).  You could try increasing those
> values.  I'm not familiar with Solaris zones, but if ./root/proc
> is really the proc filesystem, you should exclude that from
> your backup as it can be quite a rabbit hole. Try  using an
> exclude file or exclude list to exclude ./root/proc and see if
> that speeds things up.
>
> --
> Frank Smith                                      fsmith@...
> Sr. Systems Administrator                       Voice: 512-374-4673
> Hoover's Online                                   Fax: 512-374-4501
---
    Brian R Cuttler                 brian.cuttler@...
    Computer Systems Support        (v) 518 486-1697
    Wadsworth Center                (f) 518 473-6384
    NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

Brian Cuttler wrote:
> Amanda users,
>
> The backup of this particular DLE is pretty much hit or miss,
> it'll run great for a week and then fail for a week, I haven't
> been able to disern a pattern nor reason.
>
> The amanda server is old, 2.4.4 on a Solaris/Sparc system,
> the newest client is a Solaris/x86 with a current version
> 2.6.1 of amanda.
>
> The client "sc1" backs up up fine, we backup the "ldom" logical
> domain separately since it lives on a ZFS partition that is not
> available to the underlying OS.
>
> Because of the size of the dorldom1z1 partition, which is a
> non-global zone running oracle, we back it up separately from
> the other non-global zones, which run other, lighter apps.
>
> The base system "sc1" backups up fine, the ldom and 3 of the 4
> non-global zones backup without error, its just this one additional
> non-global zone that has been problematic.
>
> We are in process of upgrading the amanda server, but that will
> come along with an upgrade of the box it sits on, a fire wall
> we plan to replace.
>
> 					 thank you,
>
> 					 Brian
>
> ----- Forwarded message from Amanda on Gat0 <amanda@...> -----

>
> These dumps were to tape MIMOSA15.
> The next tape Amanda expects to use is: MIMOSA16.
>
> FAILURE AND STRANGE DUMP SUMMARY:
>   dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read: Connection
timed out]
>
>
> STATISTICS:
>                           Total       Full      Daily
>                         --------   --------   --------
> Estimate Time (hrs:min)    0:03
> Run Time (hrs:min)         2:13
> Dump Time (hrs:min)        0:00       0:00       0:00
> Output Size (meg)           0.0        0.0        0.0
> Original Size (meg)         0.0        0.0        0.0
> Avg Compressed Size (%)     --         --         --
> Filesystems Dumped            0          0          0
> Avg Dump Rate (k/s)         --         --         --
>
> Tape Time (hrs:min)        0:00       0:00       0:00
> Tape Size (meg)             0.0        0.0        0.0
> Tape Used (%)               0.0        0.0        0.0
> Filesystems Taped             0          0          0
> Avg Tp Write Rate (k/s)     --         --         --
>
> USAGE BY TAPE:
>   Label          Time      Size      %    Nb
>   MIMOSA15       0:00       0.0    0.0     0
>
>
> FAILED AND STRANGE DUMP DETAILS:
>
> /-- dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read: Connection
timed out]
> sendbackup: start [dorldom1:/export/zones/dorldom1z1 level 0]
> sendbackup: info BACKUP=/usr/sfw/bin/gtar
> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sfw/bin/gtar -xpGf - ...
> sendbackup: info COMPRESS_SUFFIX=.gz
> sendbackup: info end
> ? /usr/sfw/bin/gtar: ./root/proc: file changed as we read it
> \--------
>
>
> NOTES:
>   planner: Forcing full dump of dorldom1:/export/zones/dorldom1z1 as directed.
>   driver: WARNING: /amanda/work: 57344000 KB requested, but only 57092025 KB
available.
>   taper: tape MIMOSA15 kb 0 fm 0 [OK]
>
>
> DUMP SUMMARY:
>                                       DUMPER STATS                TAPER STATS
> HOSTNAME DISK           L   ORIG-KB    OUT-KB COMP% MMM:SS   KB/s MMM:SS  
KB/s
> ------------------------ --------------------------------------- -------------
> dorldom -es/dorldom1z1 0 FAILED ----------------------------------------------
>
> (brought to you by Amanda version 2.4.4)
>
> ----- End forwarded message -----
>

You're probably on the edge of either the estimate or data timeout
values (etimeout or dtimeout).  You could try increasing those
values.  I'm not familiar with Solaris zones, but if ./root/proc
is really the proc filesystem, you should exclude that from
your backup as it can be quite a rabbit hole. Try  using an
exclude file or exclude list to exclude ./root/proc and see if
that speeds things up.

--
Frank Smith                                      fsmith@...
Sr. Systems Administrator                       Voice: 512-374-4673
Hoover's Online                                   Fax: 512-374-4501

On Wed, Nov 18, 2009 at 2:50 PM, Brian Cuttler <brian@...> wrote:
> The backup of this particular DLE is pretty much hit or miss,
> it'll run great for a week and then fail for a week, I haven't
> been able to disern a pattern nor reason.

It looks like a timeout of some sort.  Have you increased the various
timeout parameters for this DLE?

Dustin

--
Open Source Storage Engineer
http://www.zmanda.com

Hi Dustin,

On Wed, Nov 18, 2009 at 03:02:54PM -0600, Dustin J. Mitchell wrote:
> On Wed, Nov 18, 2009 at 2:50 PM, Brian Cuttler <brian@...> wrote:
> > The backup of this particular DLE is pretty much hit or miss,
> > it'll run great for a week and then fail for a week, I haven't
> > been able to disern a pattern nor reason.
>
> It looks like a timeout of some sort.  Have you increased the various
> timeout parameters for this DLE?

I think the same but I haven't adjusted anything yet.

Other than etimeout, what knobs do I have it 2.4.4 ?

I thought timeouts where only an issue if dumps had stalled,
I'd checked on it a while before it quit and it had dumped
70% of the DLE, so I'd assumed it wasn't an inactivity issue.

Are there other timers and how can I adjust them ?

How did your talk go ? Well attendance ? Interesting questions ?

						 thanks,

						 Brian

> Dustin
>
> --
> Open Source Storage Engineer
> http://www.zmanda.com
---
    Brian R Cuttler                 brian.cuttler@...
    Computer Systems Support        (v) 518 486-1697
    Wadsworth Center                (f) 518 473-6384
    NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

On Wed, Nov 18, 2009 at 3:06 PM, Brian Cuttler <brian@...> wrote:
> Other than etimeout, what knobs do I have it 2.4.4 ?

I would think dtimeout would be the knob to tweak.  I have no idea if
that was present in 2.4.4 though.

> How did your talk go ? Well attendance ? Interesting questions ?

The talk went well -- Nick did a great job and prompted a lot of good
questions.  The wadsworth example was a helpful counterpoint to Nick's
installation at Hamilton.

Sadly, the BoF was sparsely attended.  OK, ok, it was unattended.
Which was a little depressing.

Dustin

--
Open Source Storage Engineer
http://www.zmanda.com

Amanda users,

The backup of this particular DLE is pretty much hit or miss,
it'll run great for a week and then fail for a week, I haven't
been able to disern a pattern nor reason.

The amanda server is old, 2.4.4 on a Solaris/Sparc system,
the newest client is a Solaris/x86 with a current version
2.6.1 of amanda.

The client "sc1" backs up up fine, we backup the "ldom" logical
domain separately since it lives on a ZFS partition that is not
available to the underlying OS.

Because of the size of the dorldom1z1 partition, which is a
non-global zone running oracle, we back it up separately from
the other non-global zones, which run other, lighter apps.

The base system "sc1" backups up fine, the ldom and 3 of the 4
non-global zones backup without error, its just this one additional
non-global zone that has been problematic.

We are in process of upgrading the amanda server, but that will
come along with an upgrade of the box it sits on, a fire wall
we plan to replace.

						 thank you,

						 Brian

----- Forwarded message from Amanda on Gat0 <amanda@...> -----

X-Sieve: CMU Sieve 2.3
X-Wadsworth-MailScanner-Watermark: 1259181455.66801@4bAJfDx2TcafjZRjBRXIKw
Date: Wed, 18 Nov 2009 15:37:34 -0500 (EST)
From: Amanda on Gat0 <amanda@...>
To: amanda-adm@...
Subject: Mimosa AMANDA MAIL REPORT FOR November 18, 2009
X-Wadsworth-MailScanner-Information: Please contact CSS for more information
X-MailScanner-ID: nAIKbYiq009086
X-Wadsworth-MailScanner: Found to be clean
X-Wadsworth-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	 score=-1.151, required 5, autolearn=not spam, AWL -1.15)
X-MailScanner-From: amanda@...

These dumps were to tape MIMOSA15.
The next tape Amanda expects to use is: MIMOSA16.

FAILURE AND STRANGE DUMP SUMMARY:
   dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read: Connection timed
out]


STATISTICS:
                           Total       Full      Daily
                         --------   --------   --------
Estimate Time (hrs:min)    0:03
Run Time (hrs:min)         2:13
Dump Time (hrs:min)        0:00       0:00       0:00
Output Size (meg)           0.0        0.0        0.0
Original Size (meg)         0.0        0.0        0.0
Avg Compressed Size (%)     --         --         --
Filesystems Dumped            0          0          0
Avg Dump Rate (k/s)         --         --         --

Tape Time (hrs:min)        0:00       0:00       0:00
Tape Size (meg)             0.0        0.0        0.0
Tape Used (%)               0.0        0.0        0.0
Filesystems Taped             0          0          0
Avg Tp Write Rate (k/s)     --         --         --

USAGE BY TAPE:
   Label          Time      Size      %    Nb
   MIMOSA15       0:00       0.0    0.0     0


FAILED AND STRANGE DUMP DETAILS:

/-- dorldom1   /export/zones/dorldom1z1 lev 0 FAILED [mesg read: Connection
timed out]
sendbackup: start [dorldom1:/export/zones/dorldom1z1 level 0]
sendbackup: info BACKUP=/usr/sfw/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/sfw/bin/gtar -xpGf - ...
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? /usr/sfw/bin/gtar: ./root/proc: file changed as we read it
\--------


NOTES:
   planner: Forcing full dump of dorldom1:/export/zones/dorldom1z1 as directed.
   driver: WARNING: /amanda/work: 57344000 KB requested, but only 57092025 KB
available.
   taper: tape MIMOSA15 kb 0 fm 0 [OK]


DUMP SUMMARY:
                                       DUMPER STATS                TAPER STATS
HOSTNAME DISK           L   ORIG-KB    OUT-KB COMP% MMM:SS   KB/s MMM:SS   KB/s
------------------------ --------------------------------------- -------------
dorldom -es/dorldom1z1 0 FAILED ----------------------------------------------

(brought to you by Amanda version 2.4.4)

----- End forwarded message -----
---
    Brian R Cuttler                 brian.cuttler@...
    Computer Systems Support        (v) 518 486-1697
    Wadsworth Center                (f) 518 473-6384
    NYS Department of Health        Help Desk 518 473-0773



IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure.  It
is intended only for the addressee.  If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments.  Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.

Mike R wrote:

>>
>> NOTE: skipping tape-writable test
>> Tape daily-010 label ok
>> Server check took 0.410 seconds
>>
>> The flush worked but I think I screwed up the labeling of the vtapes
>> in the process
>>
>
> So should I be concerned about this? Are the tapes alright based on the
> results of the relabeling and is incorrect labeling something I should
> be concerned about? Any suggestions on my /var/www dump that reports
> problems due to files changing?
>

I've lost the beginning of this thread, but considering that flushing to
daily-010 worked it should be fine. Maybe the labels do not look as nice as
you'd want, but as long as they match the labelstr parameter in amanda.conf
you're technically OK. If you want, you can always re-label the tapes
manually later (just before the tape is about to be reused). I'd recommend
doing this one tape at a time and avoiding fancy shell scripting stuff that
might break in your particular environment.

--
Toomas Aas

On 11/18/2009 12:02 AM, Stefan G. Weichinger wrote:
> Paul Bijnens schrieb:
>> On 2009-11-17 02:18, Yadda wrote:
>>> Total Newbie with Amanda.   I only want to backup my WinXP PC to an
>>> external USB drive and am lost on how to set this up.  Please help!!! :(
>
>> Airports are where airplaines land, not a place to park your bicycle.
>
> [...]
>
>> (Ok, I'm parking my wifes bike on that runway too, but just because
>> that runway is already there, not because it's the best bike park).
>
> respect, Paul, what an analogy .... ;-)

http://www.bing.com/maps/?v=2&cp=sggbbshc5fs4&scene=21014403&lvl=2&sty=b

Right in the center you see the bike park, for about 15 bicycles even,
with a transparant roof.

And when you move the scene a little bit to the northwest, you can see
the DHL plane loaded with Amanda tapes for offshore storage.

Mike R wrote:
> Jean-Louis Martineau wrote:
>> What are in those slots?
>> use 'amlabel' to label them.
>>
>> Jean-Louis
>>> slot 10: not an amanda tape (Read 0 bytes)
>>> slot 11: not an amanda tape (Read 0 bytes)
>>> slot 12: not an amanda tape (Read 0 bytes)
>>> slot 13: not an amanda tape (Read 0 bytes)
>>> slot 14: not an amanda tape (Read 0 bytes)
>>> slot 15: not an amanda tape (Read 0 bytes)
>>> slot 16: not an amanda tape (Read 0 bytes)
>>> slot 17: not an amanda tape (Read 0 bytes)
>>> slot 18: not an amanda tape (Read 0 bytes)
>>> slot 19: not an amanda tape (Read 0 bytes)
>>> slot 20: not an amanda tape (Read 0 bytes)
>>> slot 21: not an amanda tape (Read 0 bytes)
>>> slot 22: not an amanda tape (Read 0 bytes)
>>> slot 23: not an amanda tape (Read 0 bytes)
>>> slot 24: not an amanda tape (Read 0 bytes)
>>> slot 25: not an amanda tape (Read 0 bytes)
>>>
>>
>>
>
> Hmm, I'm noticing the command that I was instructed to use to label the
> tapes are as follows from http://www.zmanda.com/quick-backup-setup.html
>
> 7.    Just as with physical tapes, the virtual tapes now need to be
> labeled. (Please note that the output below has been truncated.)
>
> bash-3.00$ for ((i=1; $i<=9;i++)); do amlabel DailySet1 DailySet1-0$i
> slot $i; done
> changer: got exit: 0 str: 1 file://space/vtapes/DailySet1/slots
> labeling tape in slot 1 (file://space/vtapes/DailySet1/slots):
> rewinding, reading label, not an amanda tape (Read 0 bytes)
> rewinding, writing label DailySet1-01, checking label, done.
> ...
> changer: got exit: 0 str: 9 file://space/vtapes/DailySet1/slots
> labeling tape in slot 9 (file://space/vtapes/DailySet1/slots):
> rewinding, reading label, not an amanda tape (Read 0 bytes)
> rewinding, writing label DailySet1-09, checking label, done.
>
> -bash-3.00$ for ((i=10; $i<=25;i++)); do amlabel DailySet1 DailySet1-$i
> slot $i; done
> changer: got exit: 0 str: 10 file://space/vtapes/DailySet1/slots
> labeling tape in slot 10 (file://space/vtapes/DailySet1/slots):
> rewinding, reading label, not an amanda tape (Read 0 bytes)
>  rewinding, writing label DailySet1-10, checking label, done.
> ...
> changer: got exit: 0 str: 25 file://space/vtapes/DailySet1/slots
> labeling tape in slot 25 (file://space/vtapes/DailySet1/slots):
> rewinding, reading label, not an amanda tape (Read 0 bytes)
> rewinding, writing label DailySet1-25, checking label, done.
>
>
> /SNIP
>
> SO I guess that was what was culpable of the initial problem but I think
> I might have screwed it up even worse. I noticed that the relabeling
> command that was provided in the how-to only had disk 1-9 set for the
> labeling and obviously, like a lemming, i simply copy and pasted it from
> the manual. Thinking I could fix the problem with the following command:
>
> for ((i=10; $i<=25;i++)); do /usr/sbin/amlabel daily daily-0$i slot $i;
> done
>
> Now my amcheck is showing the following
>
> Holding disk /opt/dumps: 1246830 MB disk space available, using 1246730 MB
> slot 25: read label `daily-025', date `20091118'
> slot 1: read label `daily-01', date `20091109'
> slot 2: read label `daily-02', date `20091109'
> slot 3: read label `daily-03', date `20091109'
> slot 4: read label `daily-04', date `20091109'
> slot 5: read label `daily-05', date `20091110'
> slot 6: read label `daily-06', date `20091111'
> slot 7: read label `daily-07', date `20091112'
> slot 8: read label `daily-08', date `20091113'
> slot 9: read label `daily-09', date `20091116'
> slot 10: read label `daily-010', date `X'
>
> NOTE: skipping tape-writable test
> Tape daily-010 label ok
> Server check took 0.410 seconds
>
> The flush worked but I think I screwed up the labeling of the vtapes in
> the process
>

So should I be concerned about this? Are the tapes alright based on the
results of the relabeling and is incorrect labeling something I should
be concerned about? Any suggestions on my /var/www dump that reports
problems due to files changing?

Jean-Louis Martineau wrote:
> What are in those slots?
> use 'amlabel' to label them.
>
> Jean-Louis
>> slot 10: not an amanda tape (Read 0 bytes)
>> slot 11: not an amanda tape (Read 0 bytes)
>> slot 12: not an amanda tape (Read 0 bytes)
>> slot 13: not an amanda tape (Read 0 bytes)
>> slot 14: not an amanda tape (Read 0 bytes)
>> slot 15: not an amanda tape (Read 0 bytes)
>> slot 16: not an amanda tape (Read 0 bytes)
>> slot 17: not an amanda tape (Read 0 bytes)
>> slot 18: not an amanda tape (Read 0 bytes)
>> slot 19: not an amanda tape (Read 0 bytes)
>> slot 20: not an amanda tape (Read 0 bytes)
>> slot 21: not an amanda tape (Read 0 bytes)
>> slot 22: not an amanda tape (Read 0 bytes)
>> slot 23: not an amanda tape (Read 0 bytes)
>> slot 24: not an amanda tape (Read 0 bytes)
>> slot 25: not an amanda tape (Read 0 bytes)
>>
>
>

Hmm, I'm noticing the command that I was instructed to use to label the
tapes are as follows from http://www.zmanda.com/quick-backup-setup.html

7.    Just as with physical tapes, the virtual tapes now need to be
labeled. (Please note that the output below has been truncated.)

bash-3.00$ for ((i=1; $i<=9;i++)); do amlabel DailySet1 DailySet1-0$i
slot $i; done
changer: got exit: 0 str: 1 file://space/vtapes/DailySet1/slots
labeling tape in slot 1 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-01, checking label, done.
...
changer: got exit: 0 str: 9 file://space/vtapes/DailySet1/slots
labeling tape in slot 9 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-09, checking label, done.

-bash-3.00$ for ((i=10; $i<=25;i++)); do amlabel DailySet1 DailySet1-$i
slot $i; done
changer: got exit: 0 str: 10 file://space/vtapes/DailySet1/slots
labeling tape in slot 10 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
   rewinding, writing label DailySet1-10, checking label, done.
...
changer: got exit: 0 str: 25 file://space/vtapes/DailySet1/slots
labeling tape in slot 25 (file://space/vtapes/DailySet1/slots):
rewinding, reading label, not an amanda tape (Read 0 bytes)
rewinding, writing label DailySet1-25, checking label, done.


/SNIP

SO I guess that was what was culpable of the initial problem but I think
I might have screwed it up even worse. I noticed that the relabeling
command that was provided in the how-to only had disk 1-9 set for the
labeling and obviously, like a lemming, i simply copy and pasted it from
the manual. Thinking I could fix the problem with the following command:

for ((i=10; $i<=25;i++)); do /usr/sbin/amlabel daily daily-0$i slot $i; done

Now my amcheck is showing the following

Holding disk /opt/dumps: 1246830 MB disk space available, using 1246730 MB
slot 25: read label `daily-025', date `20091118'
slot 1: read label `daily-01', date `20091109'
slot 2: read label `daily-02', date `20091109'
slot 3: read label `daily-03', date `20091109'
slot 4: read label `daily-04', date `20091109'
slot 5: read label `daily-05', date `20091110'
slot 6: read label `daily-06', date `20091111'
slot 7: read label `daily-07', date `20091112'
slot 8: read label `daily-08', date `20091113'
slot 9: read label `daily-09', date `20091116'
slot 10: read label `daily-010', date `X'

NOTE: skipping tape-writable test
Tape daily-010 label ok
Server check took 0.410 seconds

The flush worked but I think I screwed up the labeling of the vtapes in
the process

What are in those slots?
use 'amlabel' to label them.

Jean-Louis
> slot 10: not an amanda tape (Read 0 bytes)
> slot 11: not an amanda tape (Read 0 bytes)
> slot 12: not an amanda tape (Read 0 bytes)
> slot 13: not an amanda tape (Read 0 bytes)
> slot 14: not an amanda tape (Read 0 bytes)
> slot 15: not an amanda tape (Read 0 bytes)
> slot 16: not an amanda tape (Read 0 bytes)
> slot 17: not an amanda tape (Read 0 bytes)
> slot 18: not an amanda tape (Read 0 bytes)
> slot 19: not an amanda tape (Read 0 bytes)
> slot 20: not an amanda tape (Read 0 bytes)
> slot 21: not an amanda tape (Read 0 bytes)
> slot 22: not an amanda tape (Read 0 bytes)
> slot 23: not an amanda tape (Read 0 bytes)
> slot 24: not an amanda tape (Read 0 bytes)
> slot 25: not an amanda tape (Read 0 bytes)
>

Jean-Louis Martineau wrote:
> What's the complete output of: amcheck -s daily
>
>
> Mike R wrote:
>> Jean-Louis Martineau wrote:
>>> What is your tapecycle?
>>> How many vtapes do you have?
>>> What is the output of amcheck?
>>>
>>> Jean-Louis
>>>
>>> Mike R wrote:
>>>> Good day all. I'm a fairly new amanda user, I used the 15 minute
>>>> backup guide for my setup. During the first week my backups seemed
>>>> to have gone off without a hitch as indicated by the backup reports.
>>>> Now beginning on Monday I've been getting failed backup reports, as
>>>> follows:
>>>>
>>>> *** A TAPE ERROR OCCURRED: [No writable valid tape found].
>>>> Some dumps may have been left in the holding disk.
>>>> Run amflush to flush them to tape.
>>>> The next tape Amanda expects to use is: a new tape.
>>>>
>>>> FAILURE AND STRANGE DUMP SUMMARY:
>>>> epsilon.bleh.com /var/www lev 1 STRANGE
>>>>
>>>>
>>>> STATISTICS:
>>>> Total Full Incr.
>>>> -------- -------- --------
>>>> Estimate Time (hrs:min) 0:00
>>>> Run Time (hrs:min) 0:02
>>>> Dump Time (hrs:min) 0:01 0:00 0:01
>>>> Output Size (meg) 79.9 0.0 79.9
>>>> Original Size (meg) 919.2 0.0 919.2
>>>> Avg Compressed Size (%) 8.7 -- 8.7 (level:#disks ...)
>>>> Filesystems Dumped 3 0 3 (1:3)
>>>> Avg Dump Rate (k/s) 1110.8 -- 1110.8
>>>>
>>>> Tape Time (hrs:min) 0:00 0:00 0:00
>>>> Tape Size (meg) 0.0 0.0 0.0
>>>> Tape Used (%) 0.0 0.0 0.0
>>>> Filesystems Taped 0 0 0
>>>>
>>>> Chunks Taped 0 0 0
>>>> Avg Tp Write Rate (k/s) -- -- --
>>>>
>>>>
>>>> FAILED AND STRANGE DUMP DETAILS:
>>>>
>>>> /-- epsilon.bleh.com /var/www lev 1 STRANGE
>>>> sendbackup: start [epsilon.bleh.com:/var/www level 1]
>>>> sendbackup: info BACKUP=/bin/tar
>>>> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
>>>> sendbackup: info COMPRESS_SUFFIX=.gz
>>>> sendbackup: info end
>>>> ? gtar: ./cacti/log/cacti.log: file changed as we read it
>>>> | Total bytes written: 946503680 (903MiB, 14MiB/s)
>>>> sendbackup: size 924320
>>>> sendbackup: end
>>>> \--------
>>>>
>>>>
>>>> DUMP SUMMARY:
>>>> DUMPER STATS TAPER STATS
>>>> HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
>>>> -------------------------- -------------------------------------
>>>> -------------
>>>> epsilon.bleh /etc/nagios 1 0 0 10.0 0:01 1.3 N/A N/A
>>>> epsilon.bleh /var/www 1 903 75 8.3 1:08 1132.5 N/A N/A
>>>> gamma.bleh.com /websites 1 17 5 28.1 0:05 979.1 N/A N/A
>>>>
>>>> (brought to you by Amanda version 2.5.0p2)
>>>>
>>>>
>>>> I'm starting to think that I might have ran too many testing backups
>>>> after the implementation and might have thrown the vtape usage off
>>>> course if it's technically possible. I ran amflush daily as amanda
>>>> and there were no results from it, the report I got said the same
>>>> thing. I'm also concerned with the strange dump failure for cacti,
>>>> due to its nature and the fact that it is configured to spread the
>>>> load out evenly it is probably constantly writing data to the rra
>>>> files, so I need to make sure I'm getting reliable dumps. Any
>>>> additional insight in my paltry problems would help as I will be
>>>> spending the day researching it on my end. Thanks!
>>>
>>>
>>
>> Thank you for your response.
>>
>> dumpcycle 4 weeks
>> runspercycle 20
>> tapecycle 25 tapes
>>
>> there are 25 "slots" in my vtape directory (I believe a slot = a tape
>> correct?)
>>
>> [root@sigma daily]# su - amanda
>> -bash-3.2$ /usr/sbin/amflush daily
>> Scanning /opt/dumps...
>>   20091117010001: found Amanda directory.
>>   20091118010001: found Amanda directory.
>>
>> Multiple Amanda directories, please pick one by letter:
>>   A. 20091117010001
>>   B. 20091118010001
>> Select directories to flush [A..B]: [ALL]
>>
>> Today is: 20091118
>> Flushing dumps in 20091117010001, 20091118010001 using tape changer
>> "chg-disk".
>> Expecting a new tape.  (The last dumps were to tape daily-09)
>> Are you sure you want to do this [yN]? y
>> Running in background, you can log off now.
>> You'll get mail when amflush is finished.
>>
>> RESULT
>>
>> *** A TAPE ERROR OCCURRED: [No writable valid tape found].
>> Some dumps may have been left in the holding disk.
>> Run amflush again to flush them to tape.
>> The next tape Amanda expects to use is: a new tape.
>>
>>
>> Also I have posted my config here: http://pastebin.ca/1676675
>>
>> Also, when setting up the system I followed these directions:
>>
>> http://www.zmanda.com/quick-backup-setup.html
>>
>> Thank you for your help!
>>
>
>

[root@sigma daily]# su - amanda
-bash-3.2$ /usr/sbin/amcheck -s daily
Amanda Tape Server Host Check
-----------------------------
Holding disk /opt/dumps: 1246831 MB disk space available, using 1246731 MB
slot 5: read label `daily-05', date `20091110'
slot 6: read label `daily-06', date `20091111'
slot 7: read label `daily-07', date `20091112'
slot 8: read label `daily-08', date `20091113'
slot 9: read label `daily-09', date `20091116'
slot 10: not an amanda tape (Read 0 bytes)
slot 11: not an amanda tape (Read 0 bytes)
slot 12: not an amanda tape (Read 0 bytes)
slot 13: not an amanda tape (Read 0 bytes)
slot 14: not an amanda tape (Read 0 bytes)
slot 15: not an amanda tape (Read 0 bytes)
slot 16: not an amanda tape (Read 0 bytes)
slot 17: not an amanda tape (Read 0 bytes)
slot 18: not an amanda tape (Read 0 bytes)
slot 19: not an amanda tape (Read 0 bytes)
slot 20: not an amanda tape (Read 0 bytes)
slot 21: not an amanda tape (Read 0 bytes)
slot 22: not an amanda tape (Read 0 bytes)
slot 23: not an amanda tape (Read 0 bytes)
slot 24: not an amanda tape (Read 0 bytes)
slot 25: not an amanda tape (Read 0 bytes)
slot 1: read label `daily-01', date `20091109'
slot 2: read label `daily-02', date `20091109'
slot 3: read label `daily-03', date `20091109'
slot 4: read label `daily-04', date `20091109'

         (expecting a new tape)
Server check took 0.903 seconds

(brought to you by Amanda 2.5.0p2)

What's the complete output of: amcheck -s daily


Mike R wrote:
> Jean-Louis Martineau wrote:
>> What is your tapecycle?
>> How many vtapes do you have?
>> What is the output of amcheck?
>>
>> Jean-Louis
>>
>> Mike R wrote:
>>> Good day all. I'm a fairly new amanda user, I used the 15 minute
>>> backup guide for my setup. During the first week my backups seemed
>>> to have gone off without a hitch as indicated by the backup reports.
>>> Now beginning on Monday I've been getting failed backup reports, as
>>> follows:
>>>
>>> *** A TAPE ERROR OCCURRED: [No writable valid tape found].
>>> Some dumps may have been left in the holding disk.
>>> Run amflush to flush them to tape.
>>> The next tape Amanda expects to use is: a new tape.
>>>
>>> FAILURE AND STRANGE DUMP SUMMARY:
>>> epsilon.bleh.com /var/www lev 1 STRANGE
>>>
>>>
>>> STATISTICS:
>>> Total Full Incr.
>>> -------- -------- --------
>>> Estimate Time (hrs:min) 0:00
>>> Run Time (hrs:min) 0:02
>>> Dump Time (hrs:min) 0:01 0:00 0:01
>>> Output Size (meg) 79.9 0.0 79.9
>>> Original Size (meg) 919.2 0.0 919.2
>>> Avg Compressed Size (%) 8.7 -- 8.7 (level:#disks ...)
>>> Filesystems Dumped 3 0 3 (1:3)
>>> Avg Dump Rate (k/s) 1110.8 -- 1110.8
>>>
>>> Tape Time (hrs:min) 0:00 0:00 0:00
>>> Tape Size (meg) 0.0 0.0 0.0
>>> Tape Used (%) 0.0 0.0 0.0
>>> Filesystems Taped 0 0 0
>>>
>>> Chunks Taped 0 0 0
>>> Avg Tp Write Rate (k/s) -- -- --
>>>
>>>
>>> FAILED AND STRANGE DUMP DETAILS:
>>>
>>> /-- epsilon.bleh.com /var/www lev 1 STRANGE
>>> sendbackup: start [epsilon.bleh.com:/var/www level 1]
>>> sendbackup: info BACKUP=/bin/tar
>>> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
>>> sendbackup: info COMPRESS_SUFFIX=.gz
>>> sendbackup: info end
>>> ? gtar: ./cacti/log/cacti.log: file changed as we read it
>>> | Total bytes written: 946503680 (903MiB, 14MiB/s)
>>> sendbackup: size 924320
>>> sendbackup: end
>>> \--------
>>>
>>>
>>> DUMP SUMMARY:
>>> DUMPER STATS TAPER STATS
>>> HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
>>> -------------------------- -------------------------------------
>>> -------------
>>> epsilon.bleh /etc/nagios 1 0 0 10.0 0:01 1.3 N/A N/A
>>> epsilon.bleh /var/www 1 903 75 8.3 1:08 1132.5 N/A N/A
>>> gamma.bleh.com /websites 1 17 5 28.1 0:05 979.1 N/A N/A
>>>
>>> (brought to you by Amanda version 2.5.0p2)
>>>
>>>
>>> I'm starting to think that I might have ran too many testing backups
>>> after the implementation and might have thrown the vtape usage off
>>> course if it's technically possible. I ran amflush daily as amanda
>>> and there were no results from it, the report I got said the same
>>> thing. I'm also concerned with the strange dump failure for cacti,
>>> due to its nature and the fact that it is configured to spread the
>>> load out evenly it is probably constantly writing data to the rra
>>> files, so I need to make sure I'm getting reliable dumps. Any
>>> additional insight in my paltry problems would help as I will be
>>> spending the day researching it on my end. Thanks!
>>
>>
>
> Thank you for your response.
>
> dumpcycle 4 weeks
> runspercycle 20
> tapecycle 25 tapes
>
> there are 25 "slots" in my vtape directory (I believe a slot = a tape
> correct?)
>
> [root@sigma daily]# su - amanda
> -bash-3.2$ /usr/sbin/amflush daily
> Scanning /opt/dumps...
>   20091117010001: found Amanda directory.
>   20091118010001: found Amanda directory.
>
> Multiple Amanda directories, please pick one by letter:
>   A. 20091117010001
>   B. 20091118010001
> Select directories to flush [A..B]: [ALL]
>
> Today is: 20091118
> Flushing dumps in 20091117010001, 20091118010001 using tape changer
> "chg-disk".
> Expecting a new tape.  (The last dumps were to tape daily-09)
> Are you sure you want to do this [yN]? y
> Running in background, you can log off now.
> You'll get mail when amflush is finished.
>
> RESULT
>
> *** A TAPE ERROR OCCURRED: [No writable valid tape found].
> Some dumps may have been left in the holding disk.
> Run amflush again to flush them to tape.
> The next tape Amanda expects to use is: a new tape.
>
>
> Also I have posted my config here: http://pastebin.ca/1676675
>
> Also, when setting up the system I followed these directions:
>
> http://www.zmanda.com/quick-backup-setup.html
>
> Thank you for your help!
>

Jean-Louis Martineau wrote:
> What is your tapecycle?
> How many vtapes do you have?
> What is the output of amcheck?
>
> Jean-Louis
>
> Mike R wrote:
>> Good day all. I'm a fairly new amanda user, I used the 15 minute
>> backup guide for my setup. During the first week my backups seemed to
>> have gone off without a hitch as indicated by the backup reports. Now
>> beginning on Monday I've been getting failed backup reports, as follows:
>>
>> *** A TAPE ERROR OCCURRED: [No writable valid tape found].
>> Some dumps may have been left in the holding disk.
>> Run amflush to flush them to tape.
>> The next tape Amanda expects to use is: a new tape.
>>
>> FAILURE AND STRANGE DUMP SUMMARY:
>> epsilon.bleh.com /var/www lev 1 STRANGE
>>
>>
>> STATISTICS:
>> Total Full Incr.
>> -------- -------- --------
>> Estimate Time (hrs:min) 0:00
>> Run Time (hrs:min) 0:02
>> Dump Time (hrs:min) 0:01 0:00 0:01
>> Output Size (meg) 79.9 0.0 79.9
>> Original Size (meg) 919.2 0.0 919.2
>> Avg Compressed Size (%) 8.7 -- 8.7 (level:#disks ...)
>> Filesystems Dumped 3 0 3 (1:3)
>> Avg Dump Rate (k/s) 1110.8 -- 1110.8
>>
>> Tape Time (hrs:min) 0:00 0:00 0:00
>> Tape Size (meg) 0.0 0.0 0.0
>> Tape Used (%) 0.0 0.0 0.0
>> Filesystems Taped 0 0 0
>>
>> Chunks Taped 0 0 0
>> Avg Tp Write Rate (k/s) -- -- --
>>
>>
>> FAILED AND STRANGE DUMP DETAILS:
>>
>> /-- epsilon.bleh.com /var/www lev 1 STRANGE
>> sendbackup: start [epsilon.bleh.com:/var/www level 1]
>> sendbackup: info BACKUP=/bin/tar
>> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
>> sendbackup: info COMPRESS_SUFFIX=.gz
>> sendbackup: info end
>> ? gtar: ./cacti/log/cacti.log: file changed as we read it
>> | Total bytes written: 946503680 (903MiB, 14MiB/s)
>> sendbackup: size 924320
>> sendbackup: end
>> \--------
>>
>>
>> DUMP SUMMARY:
>> DUMPER STATS TAPER STATS
>> HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
>> -------------------------- -------------------------------------
>> -------------
>> epsilon.bleh /etc/nagios 1 0 0 10.0 0:01 1.3 N/A N/A
>> epsilon.bleh /var/www 1 903 75 8.3 1:08 1132.5 N/A N/A
>> gamma.bleh.com /websites 1 17 5 28.1 0:05 979.1 N/A N/A
>>
>> (brought to you by Amanda version 2.5.0p2)
>>
>>
>> I'm starting to think that I might have ran too many testing backups
>> after the implementation and might have thrown the vtape usage off
>> course if it's technically possible. I ran amflush daily as amanda and
>> there were no results from it, the report I got said the same thing.
>> I'm also concerned with the strange dump failure for cacti, due to its
>> nature and the fact that it is configured to spread the load out
>> evenly it is probably constantly writing data to the rra files, so I
>> need to make sure I'm getting reliable dumps. Any additional insight
>> in my paltry problems would help as I will be spending the day
>> researching it on my end. Thanks!
>
>

Thank you for your response.

dumpcycle 4 weeks
runspercycle 20
tapecycle 25 tapes

there are 25 "slots" in my vtape directory (I believe a slot = a tape
correct?)

[root@sigma daily]# su - amanda
-bash-3.2$ /usr/sbin/amflush daily
Scanning /opt/dumps...
    20091117010001: found Amanda directory.
    20091118010001: found Amanda directory.

Multiple Amanda directories, please pick one by letter:
    A. 20091117010001
    B. 20091118010001
Select directories to flush [A..B]: [ALL]

Today is: 20091118
Flushing dumps in 20091117010001, 20091118010001 using tape changer
"chg-disk".
Expecting a new tape.  (The last dumps were to tape daily-09)
Are you sure you want to do this [yN]? y
Running in background, you can log off now.
You'll get mail when amflush is finished.

RESULT

*** A TAPE ERROR OCCURRED: [No writable valid tape found].
Some dumps may have been left in the holding disk.
Run amflush again to flush them to tape.
The next tape Amanda expects to use is: a new tape.


Also I have posted my config here: http://pastebin.ca/1676675

Also, when setting up the system I followed these directions:

http://www.zmanda.com/quick-backup-setup.html

Thank you for your help!

What is your tapecycle?
How many vtapes do you have?
What is the output of amcheck?

Jean-Louis

Mike R wrote:
> Good day all. I'm a fairly new amanda user, I used the 15 minute
> backup guide for my setup. During the first week my backups seemed to
> have gone off without a hitch as indicated by the backup reports. Now
> beginning on Monday I've been getting failed backup reports, as follows:
>
> *** A TAPE ERROR OCCURRED: [No writable valid tape found].
> Some dumps may have been left in the holding disk.
> Run amflush to flush them to tape.
> The next tape Amanda expects to use is: a new tape.
>
> FAILURE AND STRANGE DUMP SUMMARY:
> epsilon.bleh.com /var/www lev 1 STRANGE
>
>
> STATISTICS:
> Total Full Incr.
> -------- -------- --------
> Estimate Time (hrs:min) 0:00
> Run Time (hrs:min) 0:02
> Dump Time (hrs:min) 0:01 0:00 0:01
> Output Size (meg) 79.9 0.0 79.9
> Original Size (meg) 919.2 0.0 919.2
> Avg Compressed Size (%) 8.7 -- 8.7 (level:#disks ...)
> Filesystems Dumped 3 0 3 (1:3)
> Avg Dump Rate (k/s) 1110.8 -- 1110.8
>
> Tape Time (hrs:min) 0:00 0:00 0:00
> Tape Size (meg) 0.0 0.0 0.0
> Tape Used (%) 0.0 0.0 0.0
> Filesystems Taped 0 0 0
>
> Chunks Taped 0 0 0
> Avg Tp Write Rate (k/s) -- -- --
>
>
> FAILED AND STRANGE DUMP DETAILS:
>
> /-- epsilon.bleh.com /var/www lev 1 STRANGE
> sendbackup: start [epsilon.bleh.com:/var/www level 1]
> sendbackup: info BACKUP=/bin/tar
> sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
> sendbackup: info COMPRESS_SUFFIX=.gz
> sendbackup: info end
> ? gtar: ./cacti/log/cacti.log: file changed as we read it
> | Total bytes written: 946503680 (903MiB, 14MiB/s)
> sendbackup: size 924320
> sendbackup: end
> \--------
>
>
> DUMP SUMMARY:
> DUMPER STATS TAPER STATS
> HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
> -------------------------- -------------------------------------
> -------------
> epsilon.bleh /etc/nagios 1 0 0 10.0 0:01 1.3 N/A N/A
> epsilon.bleh /var/www 1 903 75 8.3 1:08 1132.5 N/A N/A
> gamma.bleh.com /websites 1 17 5 28.1 0:05 979.1 N/A N/A
>
> (brought to you by Amanda version 2.5.0p2)
>
>
> I'm starting to think that I might have ran too many testing backups
> after the implementation and might have thrown the vtape usage off
> course if it's technically possible. I ran amflush daily as amanda and
> there were no results from it, the report I got said the same thing.
> I'm also concerned with the strange dump failure for cacti, due to its
> nature and the fact that it is configured to spread the load out
> evenly it is probably constantly writing data to the rra files, so I
> need to make sure I'm getting reliable dumps. Any additional insight
> in my paltry problems would help as I will be spending the day
> researching it on my end. Thanks!

Good day all. I'm a fairly new amanda user, I used the 15 minute backup
guide for my setup. During the first week my backups seemed to have gone
off without a hitch as indicated by the backup reports. Now beginning on
Monday I've been getting failed backup reports, as follows:

*** A TAPE ERROR OCCURRED: [No writable valid tape found].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: a new tape.

FAILURE AND STRANGE DUMP SUMMARY:
epsilon.bleh.com /var/www lev 1 STRANGE


STATISTICS:
Total Full Incr.
-------- -------- --------
Estimate Time (hrs:min) 0:00
Run Time (hrs:min) 0:02
Dump Time (hrs:min) 0:01 0:00 0:01
Output Size (meg) 79.9 0.0 79.9
Original Size (meg) 919.2 0.0 919.2
Avg Compressed Size (%) 8.7 -- 8.7 (level:#disks ...)
Filesystems Dumped 3 0 3 (1:3)
Avg Dump Rate (k/s) 1110.8 -- 1110.8

Tape Time (hrs:min) 0:00 0:00 0:00
Tape Size (meg) 0.0 0.0 0.0
Tape Used (%) 0.0 0.0 0.0
Filesystems Taped 0 0 0

Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --


FAILED AND STRANGE DUMP DETAILS:

/-- epsilon.bleh.com /var/www lev 1 STRANGE
sendbackup: start [epsilon.bleh.com:/var/www level 1]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? gtar: ./cacti/log/cacti.log: file changed as we read it
| Total bytes written: 946503680 (903MiB, 14MiB/s)
sendbackup: size 924320
sendbackup: end
\--------


DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
-------------------------- -------------------------------------
-------------
epsilon.bleh /etc/nagios 1 0 0 10.0 0:01 1.3 N/A N/A
epsilon.bleh /var/www 1 903 75 8.3 1:08 1132.5 N/A N/A
gamma.bleh.com /websites 1 17 5 28.1 0:05 979.1 N/A N/A

(brought to you by Amanda version 2.5.0p2)


I'm starting to think that I might have ran too many testing backups
after the implementation and might have thrown the vtape usage off
course if it's technically possible. I ran amflush daily as amanda and
there were no results from it, the report I got said the same thing. I'm
also concerned with the strange dump failure for cacti, due to its
nature and the fact that it is configured to spread the load out evenly
it is probably constantly writing data to the rra files, so I need to
make sure I'm getting reliable dumps. Any additional insight in my
paltry problems would help as I will be spending the day researching it
on my end. Thanks!

Gunnarsson, Gunnar wrote:
> Hi
>
> I'm trying to configure Sun SL48 autloader with Amanda on Solaris 10
> 10/09  sparc system.  SL48 library is connected to our SAN  switches and
> disk are beeing used and configured on the SAN but I'm not seeing the
> the tape driver.
>
> # ls /dev/rmt/
> #
>
> # /usr/sbin/add_drv -v  st
> exit status = 0
> devfsadm: driver failed to attach: st
> exit status = 1
> Warning: Driver (st) successfully added to system but failed to attach
> Driver (st) installed.

Your post is really an OS question rather than an Amanda question. I see
that you also posted on the Sun forums, so that's good. I also found a
post (I just googled "sl48 san solaris") by someone else that has a fair
number of replies that might help. It's someone trying to do the same
thing, but with NetBackup (which is really irrelevant). The clues appear
to be related to configuring sg.conf and st.conf. That makes sense to
me, but I've never messed with devices connected through SAN switches.
The thread is here
http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/\
symantec-netbackup-18/solaris-10-run-netbackup-cannot-detect-sun-storageteksl48-\
96060/


--
---------------

Chris Hoogendyk

-
    O__  ---- Systems Administrator
   c/ /'_ --- Biology & Geology Departments
  (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst

<hoogendyk@...>

---------------

Erdös 4

On Sun, Nov 15, 2009 at 10:39 PM, Gene Heskett <gene.heskett@...> wrote:
> Someday, all this ipv6 stuff will need to work.  But this is probably not the
> list to ask how to do it on.

Yeah -- there's nothing to worry about regarding Amanda.

Dustin

--
Open Source Storage Engineer
http://www.zmanda.com

On 2009-11-17 02:18, Yadda wrote:
> Total Newbie with Amanda.   I only want to backup my WinXP PC to an external
USB drive and am lost on how to set this up.  Please help!!! :(
>

Airports are where airplaines land, not a place to park your bicycle.

You're looking in the wrong software.  Amanda is aimed for a network
of computers which are trying to do their backups over the network
on a central server, which has lots of capacity in disk and/or tape.
And that server is best some modern Unix variant as well :-).

(Ok, I'm parking my wifes bike on that runway too, but just because
that runway is already there, not because it's the best bike park).

--
Paul Bijnens, Xplanation Technology Services        Tel  +32 16 397.525
Interleuvenlaan 86, B-3001 Leuven, BELGIUM          Fax  +32 16 397.552
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, ~., *
* stop, end, ^]c, +++ ATH, disconnect,  halt,  abort,  hangup,  KJOB, *
* ^X^X,  :D::D,  kill -9 1,  kill -1 $$,  shutdown,  init 0,  Alt-F4, *
* Alt-f-e, Ctrl-Alt-Del, Alt-SysRq-reisub, Stop-A, AltGr-NumLock, ... *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************

Total Newbie with Amanda.   I only want to backup my WinXP PC to an external USB
drive and am lost on how to set this up.  Please help!!! :(

+----------------------------------------------------------------------
|This was sent by earthbased@... via Backup Central.
|Forward SPAM to abuse@....
+----------------------------------------------------------------------

On Sunday 15 November 2009, Dustin Mitchell wrote:
>On Nov 14, 2009, at 9:55 PM, Gene Heskett <gene.heskett@...>
>
>wrote:
>> Nor tonight.  But in building the 20091114 version, I saw that the
>> ./configure script thinks I have a working ipv6 network.  Sorry.
>> While I do
>> have some ipv6 entries in my host file, the _working_ setup here is
>> 100%
>> ipv4.  So you may want to see if some site that has a known ipv6
>> address can
>> be ping6'd.  I apparently do not even have an ipv6 dns server, or it
>> cannot
>> get through an x86 version of dd-wrt, my router.
>
>That just means that the kernel supports ipv6. The only time this can
>cause problems is if you have a partial ipv6 config on your system -
>for example, if you resolver returns ipv6 addresses but you don't have
>your network interfaces set up. In practice this is really only a
>problem on some Solaris systems.
>
>Dustin

I just noted in the messages log, that amanda _is_ using ipv6 in its system
logging reports:

Nov 14 21:53:17 coyote xinetd[2491]: START: amanda pid=4159
from=::ffff:192.168.71.3
Nov 14 21:53:47 coyote xinetd[2491]: EXIT: amanda status=0 pid=4159
duration=30(sec)
Nov 15 00:18:47 coyote ntpd[2503]: synchronized to 66.250.45.2, stratum 2
Nov 15 01:15:01 coyote xinetd[2491]: START: amanda pid=8340
from=::ffff:192.168.71.3
Nov 15 01:20:32 coyote xinetd[2491]: EXIT: amanda status=0 pid=8340
duration=331(sec)
Nov 15 01:20:33 coyote xinetd[2491]: START: amanda pid=8813
from=::ffff:192.168.71.3
Nov 15 01:21:33 coyote xinetd[2491]: EXIT: amanda status=0 pid=8813
duration=60(sec)
Nov 15 01:21:45 coyote xinetd[2491]: START: amanda pid=8880
from=::ffff:192.168.71.3
Nov 15 01:22:15 coyote xinetd[2491]: EXIT: amanda status=0 pid=8880
duration=30(sec)
Nov 15 01:22:15 coyote xinetd[2491]: START: amanda pid=8906
from=::ffff:192.168.71.3
Nov 15 01:51:46 coyote xinetd[2491]: EXIT: amanda status=0 pid=8906
duration=1771(sec)
Nov 15 01:51:53 coyote xinetd[2491]: START: amanda pid=9672
from=::ffff:192.168.71.3
Nov 15 02:50:53 coyote xinetd[2491]: EXIT: amanda status=0 pid=9672
duration=3540(sec)
Nov 15 02:50:54 coyote xinetd[2491]: START: amanda pid=11522
from=::ffff:192.168.71.3
Nov 15 02:51:24 coyote xinetd[2491]: EXIT: amanda status=0 pid=11522
duration=30(sec)
Nov 15 02:51:25 coyote xinetd[2491]: START: amanda pid=11557
from=::ffff:192.168.71.3
Nov 15 02:51:56 coyote xinetd[2491]: EXIT: amanda status=0 pid=11557
duration=30(sec)

So, I guess it does work locally.  But I don't notice it making a report for
the 4 dle's on the shop's emc machine?  All addresses above are this machine.
Or would that be logged via that machines log?  But they are not logged there
either, I just looked.  Maybe I have a debug level set here that is not set
there?

It seems to work, but one gets curious & follows the trail with more
questions. Maybe it only logs ipv6 usage?

I have the shop box defined in hosts as:
192.168.71.4    shop.coyote.den         shop
::ffff:192.168.71.4 shop.coyote.den6    shop6

But:
[root@coyote MyGuns]# ping6 shop6
PING shop6(shop.coyote.den) 56 data bytes
ping: sendmsg: Network is unreachable

So it appears I need to work on my if-cfg-eth0 setups?

Someday, all this ipv6 stuff will need to work.  But this is probably not the
list to ask how to do it on.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

The last person that quit or was fired will be held responsible for
everything that goes wrong -- until the next person quits or is fired.

On Friday 13 November 2009, Gene Heskett wrote:
>On Friday 13 November 2009, Dustin J. Mitchell wrote:
>>On Fri, Nov 13, 2009 at 9:52 PM, Gene Heskett <gene.heskett@...>
>
>wrote:
>>> Explain why my amanda.config says the option I'm using is deprecated?
>>
>>That's not in the example configurations, so I assume that you wrote
>>it.  A google for the phrase "use amanda_changer now" only turns up
>>references to this thread.
>>
>>Also, it says that tpchanger is deprecated and to use amanda_changer
>>instead, which is flagrantly incorrect - the two are completely
>>unrelated.  So if someone told you that they should be chided
>>vigorously.
>>
>>Dustin
>
>Ok, I now see where I saw the mention of it, in the new
> example/amanda.conf, it says:
>======================
>tapedev "tape:/dev/YOUR-TAPE-DEVICE-HERE"       # tape changer or device to
>use
>
># To use vtapes, create some slotN directories (slot0, slot1, etc.) under
># /var/amanda/vtapes and use this tapedev:
>## tapedev "chg-disk:/var/amanda/vtapes"
>======================
>
>Now, I can do the above, and I also assume I can move them to
>/usr.local/var/amanda, (and that this does not effect my present location
> for the vtapes themselves, which is a separate 1 terrabyte drive mounted
> to /amandatapes, ) where amanda keeps some other records also, but then
> what do I do with the tpchanger setting?  You say its unrelated?  It is
> not used in the new amanda.conf except inside a definition, but mine is
> not inside a define {}.
>
>That original advice did come from this list, but my corpus of old messages
>doesn't reach back that far as it was at least a year ago, maybe even 2.
>
>No actions are planned yet tonight though.
>
>Thanks Dustin.
>
Nor tonight.  But in building the 20091114 version, I saw that the
./configure script thinks I have a working ipv6 network.  Sorry.  While I do
have some ipv6 entries in my host file, the _working_ setup here is 100%
ipv4.  So you may want to see if some site that has a known ipv6 address can
be ping6'd.  I apparently do not even have an ipv6 dns server, or it cannot
get through an x86 version of dd-wrt, my router.

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

Honk if you hate bumper stickers that say "Honk if ..."