Re: DLE RESULTS MISSING after failed backup due to drive not being turned on

[Exuvo]

amdump now seems to think it should include the old test DLE in new backups.
The test DLE is not actually included in the backup as it has no information on 
where to get it from but it still shows up in the status screen from amdump.

When i removed it i ran amadmin delete for the test DLE and then removed it 
from the disklist.
Log has "INFO planner Adding new disk localhost:test" and amdump log has 
"localhost:test overdue 19105 days for level 0".

I removed the tape which the test DLE was on (and some actual backups with it) 
with 'amrmtape backup --keep-label --cleanup ROT09' and now amadmin find does 
not see the test DLE anymore and seems to also have resolved amdump.
Do i really need to do it this way or should i have done something else to 
remove the old DLE?

Anton "exuvo" Olsson
   ex...@exuvo.se

On 2022-04-20 15:58, Exuvo wrote:


Resolved, had an old test DLE on the tape it was trying to use. I don't 
understand why it still loaded the tape and did not give any useful error 
message about it.

My testing:
If i make a new logs directory the estimate actually runs. Tried moving out all 
the logs from that day but it still fails which i found weird.
Tried moving out one log at a time to find the culprit but it seems that as 
long as any one of the old logs is there my storage DLE fails.
I was only running the storage DLE as that was the only one that failed during 
the normal backup schedule.
I also tried clearing the curinfo file for the DLE.

Next i tried running a full backup with all DLEs and now they all showed as 
MISSING immediately. Which was very interesting.
The only common thing for when the DLEs started being missing is that they want 
to use tape ROT09. Which is the first tape i did a test backup on.
I think the actual issue is that it is not finding a usable tape even tho it 
loads the tape first as if it thinks it is an valid tape to use.

Removing the test DLE with amadmin delete made it start working again.

Anton "exuvo" Olsson
ex...@exuvo.se
On 2022-04-19 03:54, Exuvo wrote:


The disk was full of old partial dumps from testing of another backup set so i 
did not want to flush them to any tapes.

The logs "driver: adding holding disk 0 dir /dumps/ size 1949288448 chunksize 
9007199254740896" indicate that it is finding the dump disk with correct size of 2TB 
free.
Even if the dump drive was full i should be getting "FAILED [can't dump required 
holdingdisk when no holdingdisk space available ]" not MISSING on the DLE.
I even tested with the holding disk disabled and it still says it is missing. 
The path is most certainly not missing from the filesystem. I also tried 
changing to another file path but still MISSING.
It must be something in the database that got stuck, i will have to parse it 
myself and see if i can figure out what.

Anton "exuvo" Olsson
ex...@exuvo.se
On 2022-04-18 02:34, John Lauro wrote:

I normally use amflush to clear the holding disk.  Not saying rm doesn't work, 
but that will not update the Amanda info database.  It might think that space 
is still being used.


On Sun, Apr 17, 2022 at 2:09 PM Exuvo  wrote:

I take it you did not read what i wrote. The holding disk is already empty 
after i 'rm -r':ed it.

But even if i tell amanda to never use the holding disk for the failing DLE 
it just stops immediately when trying to run the planner (it normally takes a 
few minutes for that DLE). All other DLEs run fine.

Re: DLE RESULTS MISSING after failed backup due to drive not being turned on

[Exuvo]

Resolved, had an old test DLE on the tape it was trying to use. I don't 
understand why it still loaded the tape and did not give any useful error 
message about it.

My testing:
If i make a new logs directory the estimate actually runs. Tried moving out all 
the logs from that day but it still fails which i found weird.
Tried moving out one log at a time to find the culprit but it seems that as 
long as any one of the old logs is there my storage DLE fails.
I was only running the storage DLE as that was the only one that failed during 
the normal backup schedule.
I also tried clearing the curinfo file for the DLE.

Next i tried running a full backup with all DLEs and now they all showed as 
MISSING immediately. Which was very interesting.
The only common thing for when the DLEs started being missing is that they want 
to use tape ROT09. Which is the first tape i did a test backup on.
I think the actual issue is that it is not finding a usable tape even tho it 
loads the tape first as if it thinks it is an valid tape to use.

Removing the test DLE with amadmin delete made it start working again.

Anton "exuvo" Olsson
   ex...@exuvo.se

On 2022-04-19 03:54, Exuvo wrote:


The disk was full of old partial dumps from testing of another backup set so i 
did not want to flush them to any tapes.

The logs "driver: adding holding disk 0 dir /dumps/ size 1949288448 chunksize 
9007199254740896" indicate that it is finding the dump disk with correct size of 2TB 
free.
Even if the dump drive was full i should be getting "FAILED [can't dump required 
holdingdisk when no holdingdisk space available ]" not MISSING on the DLE.
I even tested with the holding disk disabled and it still says it is missing. 
The path is most certainly not missing from the filesystem. I also tried 
changing to another file path but still MISSING.
It must be something in the database that got stuck, i will have to parse it 
myself and see if i can figure out what.

Anton "exuvo" Olsson
ex...@exuvo.se
On 2022-04-18 02:34, John Lauro wrote:

I normally use amflush to clear the holding disk.  Not saying rm doesn't work, 
but that will not update the Amanda info database.  It might think that space 
is still being used.


On Sun, Apr 17, 2022 at 2:09 PM Exuvo  wrote:

I take it you did not read what i wrote. The holding disk is already empty 
after i 'rm -r':ed it.

But even if i tell amanda to never use the holding disk for the failing DLE 
it just stops immediately when trying to run the planner (it normally takes a 
few minutes for that DLE). All other DLEs run fine.

Re: DLE RESULTS MISSING after failed backup due to drive not being turned on

[Exuvo]

The disk was full of old partial dumps from testing of another backup set so i 
did not want to flush them to any tapes.

The logs "driver: adding holding disk 0 dir /dumps/ size 1949288448 chunksize 
9007199254740896" indicate that it is finding the dump disk with correct size of 2TB 
free.
Even if the dump drive was full i should be getting "FAILED [can't dump required 
holdingdisk when no holdingdisk space available ]" not MISSING on the DLE.
I even tested with the holding disk disabled and it still says it is missing. 
The path is most certainly not missing from the filesystem. I also tried 
changing to another file path but still MISSING.
It must be something in the database that got stuck, i will have to parse it 
myself and see if i can figure out what.

Anton "exuvo" Olsson
   ex...@exuvo.se

On 2022-04-18 02:34, John Lauro wrote:

I normally use amflush to clear the holding disk.  Not saying rm doesn't work, 
but that will not update the Amanda info database.  It might think that space 
is still being used.


On Sun, Apr 17, 2022 at 2:09 PM Exuvo  wrote:

I take it you did not read what i wrote. The holding disk is already empty 
after i 'rm -r':ed it.

But even if i tell amanda to never use the holding disk for the failing DLE 
it just stops immediately when trying to run the planner (it normally takes a 
few minutes for that DLE). All other DLEs run fine.

Re: DLE RESULTS MISSING after failed backup due to drive not being turned on

[Exuvo]

I take it you did not read what i wrote. The holding disk is already empty 
after i 'rm -r':ed it.

But even if i tell amanda to never use the holding disk for the failing DLE it 
just stops immediately when trying to run the planner (it normally takes a few 
minutes for that DLE). All other DLEs run fine.

Anton "exuvo" Olsson
   ex...@exuvo.se

On 2022-04-17 01:54, badd...@ingodsfamily.com wrote:

I have frequently done an "ls"  on my holding disk, and manually deleted files 
and directories older than 7 days ago, which clearly amanda is not planning to flush to 
tape.   7 days because I ran amanda nightly.  Your time window is up to you.

I'm not sure  'amcleanup -rv backup'  gets everything.  I had an "onboot" job 
to send me email and remind me of that command, but perhaps I didn't reboot often, or 
perhaps amanda didn't register those files any more.

If amanda hasn't flushed them during normal backups (assuming autoflush = ALL, 
i think it is),  then it isn't planning to.  Manual deletions never hurt my 
setup.  If your holding disk isn't empty, but amanda sees nothing she wants to 
backup, then I suggest a manual cleanup.

Deb Baddorf
retired from Fermilab







On Saturday, April 16, 2022, 01:27:15 PM EDT, Exuvo  wrote:





My backup failed tonight as i forgot to turn on my tape drive before i went to 
bed. Nothing was written to my dump drive as it was too full from a previous 
aborted backup i had done.
When i woke up i turned on the tape drive and ran the backup again as i have 
done before when this has happend, most DLEs ran fine but the one DLE i have 
with 'holdingdisk required' failed as there was too little space left on the 
holding disk.

I cleared out the holding disk and ran just that one failed DLE but it fails 
instantly and i get:
FAILURE DUMP SUMMARY:
   planner: FATAL find_est_for_dp return NULL
   localhost storage RESULTS MISSING

I tried running 'amcleanup -rv backup' but it did not do anything:
# sudo -u amanda amcleanup -rv backup
amcleanup: pid 2972312 is done
amcleanup: pid 2972313 is done
amcleanup: pid 2972311 is done
amcleanup: pid 2972309 is done
amcleanup: pid 2972305 is done
amcleanup: no unprocessed logfile to clean up

I also tested removing 'holdingdisk required' from the affected DLE but same 
result.

Any ideas about what i should try?


The logs don't seem to hold any more information (partial log from a RESULTS 
MISSING run):
SENDING FLUSHES...
Cleaning up holding disk '/dumps/'
driver: adding holding disk 0 dir /dumps/ size 1949288448 chunksize 
9007199254740896
ENDFLUSH

SETTING UP FOR ESTIMATES...
reserving 1949288448 out of 1949288448 for degraded-mode dumps
driver: taper taper0 storage backup-storage tape_size 1499463680
driver: started dumper0 pid 2972312
driver: send-cmd time 0.001 to dumper0: START 20220416185052
planner: time 0.000: setting up estimates for localhost:storage
driver: started dumper1 pid 2972313
driver: send-cmd time 0.001 to dumper1: START 20220416185052
setup_estimate: localhost:storage: command 0, options: none last_level 3 
next_level0 14 level_days 1    getting estimates 0 (-3) 3 (-3) -1 (-3)
planner: time 0.001: setting up estimates took 0.000 secs

GETTING ESTIMATES...
planner: find_est_for_dp return NULL
driver: send-cmd time 0.001 to taper0: START-TAPER taper0 worker0-0 
backup-storage 20220416185052
more about starting dumpers which never get used here until quitting.


-Mail report 03:14 with drive off-

Hostname: minerva
Org : exuvo
Config  : backup
Date    : april 16, 2022

*** A TAPE ERROR OCCURRED: ['/dev/tape/by-id/scsi-DEC8320699' not found].
Some dumps may have been left in the holding disk.

The next 2 tapes Amanda expects to use are: ROT09, ROT07.


FAILURE DUMP SUMMARY:
   localhost efi lev 0  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
   localhost boot lev 0  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
   localhost root lev 1  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
   localhost storage lev 3  FAILED [can't dump required holdingdisk when no 
holdingdisk space available ]
   localhost backup-minerva lev 0  FAILED [can't dump 'holdingdisk never' dle 
in degraded mode]
   localhost exuvo-desktop-root lev 1  FAILED [can't dump 'holdingdisk never' 
dle in degraded mode]
   localhost backup lev 0  FAILED [can't dump 'holdingdisk never' dle in 
degraded mode]


STATISTICS:
   Total   Full  Incr.   Level:#
             
Estimate Time (hrs:min) 0:15
Run Time (hrs:min)  0:15
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 (%)  -- -- --
DLEs Dumped    0  0  0
Avg Dump Rate (k/s)  -- -- --

Tape Time (hrs:min) 0:00  

Re: DLE RESULTS MISSING after failed backup due to drive not being turned on

[badd...@ingodsfamily.com]

I have frequently done an "ls"  on my holding disk, and manually deleted files 
and directories older than 7 days ago, which clearly amanda is not planning to 
flush to tape.   7 days because I ran amanda nightly.  Your time window is up 
to you.

I'm not sure  'amcleanup -rv backup'  gets everything.  I had an "onboot" job 
to send me email and remind me of that command, but perhaps I didn't reboot 
often, or perhaps amanda didn't register those files any more.

If amanda hasn't flushed them during normal backups (assuming autoflush = ALL, 
i think it is),  then it isn't planning to.  Manual deletions never hurt my 
setup.  If your holding disk isn't empty, but amanda sees nothing she wants to 
backup, then I suggest a manual cleanup.

Deb Baddorf
retired from Fermilab







On Saturday, April 16, 2022, 01:27:15 PM EDT, Exuvo  wrote: 





My backup failed tonight as i forgot to turn on my tape drive before i went to 
bed. Nothing was written to my dump drive as it was too full from a previous 
aborted backup i had done.
When i woke up i turned on the tape drive and ran the backup again as i have 
done before when this has happend, most DLEs ran fine but the one DLE i have 
with 'holdingdisk required' failed as there was too little space left on the 
holding disk.

I cleared out the holding disk and ran just that one failed DLE but it fails 
instantly and i get:
FAILURE DUMP SUMMARY:
  planner: FATAL find_est_for_dp return NULL
  localhost storage RESULTS MISSING

I tried running 'amcleanup -rv backup' but it did not do anything:
# sudo -u amanda amcleanup -rv backup
amcleanup: pid 2972312 is done
amcleanup: pid 2972313 is done
amcleanup: pid 2972311 is done
amcleanup: pid 2972309 is done
amcleanup: pid 2972305 is done
amcleanup: no unprocessed logfile to clean up

I also tested removing 'holdingdisk required' from the affected DLE but same 
result.

Any ideas about what i should try?


The logs don't seem to hold any more information (partial log from a RESULTS 
MISSING run):
SENDING FLUSHES...
Cleaning up holding disk '/dumps/'
driver: adding holding disk 0 dir /dumps/ size 1949288448 chunksize 
9007199254740896
ENDFLUSH

SETTING UP FOR ESTIMATES...
reserving 1949288448 out of 1949288448 for degraded-mode dumps
driver: taper taper0 storage backup-storage tape_size 1499463680
driver: started dumper0 pid 2972312
driver: send-cmd time 0.001 to dumper0: START 20220416185052
planner: time 0.000: setting up estimates for localhost:storage
driver: started dumper1 pid 2972313
driver: send-cmd time 0.001 to dumper1: START 20220416185052
setup_estimate: localhost:storage: command 0, options: none last_level 3 
next_level0 14 level_days 1    getting estimates 0 (-3) 3 (-3) -1 (-3)
planner: time 0.001: setting up estimates took 0.000 secs

GETTING ESTIMATES...
planner: find_est_for_dp return NULL
driver: send-cmd time 0.001 to taper0: START-TAPER taper0 worker0-0 
backup-storage 20220416185052
more about starting dumpers which never get used here until quitting.


-Mail report 03:14 with drive off-

Hostname: minerva
Org : exuvo
Config  : backup
Date    : april 16, 2022

*** A TAPE ERROR OCCURRED: ['/dev/tape/by-id/scsi-DEC8320699' not found].
Some dumps may have been left in the holding disk.

The next 2 tapes Amanda expects to use are: ROT09, ROT07.


FAILURE DUMP SUMMARY:
  localhost efi lev 0  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
  localhost boot lev 0  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
  localhost root lev 1  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
  localhost storage lev 3  FAILED [can't dump required holdingdisk when no 
holdingdisk space available ]
  localhost backup-minerva lev 0  FAILED [can't dump 'holdingdisk never' dle in 
degraded mode]
  localhost exuvo-desktop-root lev 1  FAILED [can't dump 'holdingdisk never' 
dle in degraded mode]
  localhost backup lev 0  FAILED [can't dump 'holdingdisk never' dle in 
degraded mode]


STATISTICS:
  Total   Full  Incr.   Level:#
            
Estimate Time (hrs:min) 0:15
Run Time (hrs:min)  0:15
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 (%)  -- -- --
DLEs 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
DLEs Taped 0  0  0
Parts Taped    0  0  0
Avg Tp Write Rate (k/s)  -- -- --


NOTES:
  planner: Last full dump of localhost:efi on tape ROT05 overwritten in 4 runs.
  planner: Last full dump of localhos

DLE RESULTS MISSING after failed backup due to drive not being turned on

[Exuvo]

My backup failed tonight as i forgot to turn on my tape drive before i went to 
bed. Nothing was written to my dump drive as it was too full from a previous 
aborted backup i had done.
When i woke up i turned on the tape drive and ran the backup again as i have 
done before when this has happend, most DLEs ran fine but the one DLE i have 
with 'holdingdisk required' failed as there was too little space left on the 
holding disk.

I cleared out the holding disk and ran just that one failed DLE but it fails 
instantly and i get:
FAILURE DUMP SUMMARY:
  planner: FATAL find_est_for_dp return NULL
  localhost storage RESULTS MISSING

I tried running 'amcleanup -rv backup' but it did not do anything:
# sudo -u amanda amcleanup -rv backup
amcleanup: pid 2972312 is done
amcleanup: pid 2972313 is done
amcleanup: pid 2972311 is done
amcleanup: pid 2972309 is done
amcleanup: pid 2972305 is done
amcleanup: no unprocessed logfile to clean up

I also tested removing 'holdingdisk required' from the affected DLE but same 
result.

Any ideas about what i should try?


The logs don't seem to hold any more information (partial log from a RESULTS 
MISSING run):
SENDING FLUSHES...
Cleaning up holding disk '/dumps/'
driver: adding holding disk 0 dir /dumps/ size 1949288448 chunksize 
9007199254740896
ENDFLUSH

SETTING UP FOR ESTIMATES...
reserving 1949288448 out of 1949288448 for degraded-mode dumps
driver: taper taper0 storage backup-storage tape_size 1499463680
driver: started dumper0 pid 2972312
driver: send-cmd time 0.001 to dumper0: START 20220416185052
planner: time 0.000: setting up estimates for localhost:storage
driver: started dumper1 pid 2972313
driver: send-cmd time 0.001 to dumper1: START 20220416185052
setup_estimate: localhost:storage: command 0, options: none last_level 3 
next_level0 14 level_days 1    getting estimates 0 (-3) 3 (-3) -1 (-3)
planner: time 0.001: setting up estimates took 0.000 secs

GETTING ESTIMATES...
planner: find_est_for_dp return NULL
driver: send-cmd time 0.001 to taper0: START-TAPER taper0 worker0-0 
backup-storage 20220416185052
more about starting dumpers which never get used here until quitting.


-Mail report 03:14 with drive off-

Hostname: minerva
Org : exuvo
Config  : backup
Date    : april 16, 2022

*** A TAPE ERROR OCCURRED: ['/dev/tape/by-id/scsi-DEC8320699' not found].
Some dumps may have been left in the holding disk.

The next 2 tapes Amanda expects to use are: ROT09, ROT07.


FAILURE DUMP SUMMARY:
  localhost efi lev 0  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
  localhost boot lev 0  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
  localhost root lev 1  FAILED [can't dump 'holdingdisk never' dle in degraded 
mode]
  localhost storage lev 3  FAILED [can't dump required holdingdisk when no 
holdingdisk space available ]
  localhost backup-minerva lev 0  FAILED [can't dump 'holdingdisk never' dle in 
degraded mode]
  localhost exuvo-desktop-root lev 1  FAILED [can't dump 'holdingdisk never' 
dle in degraded mode]
  localhost backup lev 0  FAILED [can't dump 'holdingdisk never' dle in 
degraded mode]


STATISTICS:
  Total   Full  Incr.   Level:#
            
Estimate Time (hrs:min) 0:15
Run Time (hrs:min)  0:15
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 (%)  -- -- --
DLEs 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
DLEs Taped 0  0  0
Parts Taped    0  0  0
Avg Tp Write Rate (k/s)  -- -- --


NOTES:
  planner: Last full dump of localhost:efi on tape ROT05 overwritten in 4 runs.
  planner: Last full dump of localhost:boot on tape ROT05 overwritten in 4 runs.
  planner: Last full dump of localhost:root on tape ROT05 overwritten in 4 runs.
  planner: Last full dump of localhost:storage on tape ROT04 overwritten in 3 
runs.
  planner: Last full dump of localhost:backup-minerva on tape ROT03 overwritten 
in 3 runs.
  planner: Last full dump of localhost:exuvo-desktop-root on tape ROT08 
overwritten in 2 runs.
  planner: Last full dump of localhost:backup on tape ROT03 overwritten in 3 
runs.
  planner: Full dump of localhost:backup-minerva promoted from 14 days ahead.
  planner: Full dump of localhost:boot promoted from 22 days ahead.
  planner: Full dump of localhost:efi promoted from 22 days ahead.
  planner: Full dump of localhost:backup promoted from 56 days ahead.


DUMP SUMMARY:
  DUMPER STATS   TAPER 
STATS
HOSTNAME

Re: new debian buster install, missing /etc/amanda-security.conf file

[Gene Heskett]

On Friday 05 February 2021 00:02:15 Gene Heskett wrote:

> On Thursday 04 February 2021 21:43:38 Charles Curley wrote:
> > On Thu, 4 Feb 2021 15:36:21 -0500
> >
> > Gene Heskett  wrote:
> > > Updating both to newer hardware for machines and installing debian
> > > buster, but amcheck says that the /etc/amanda-security.conf file
> > > won't let me run tar as root, but the real problem is that
> > > the /etc/amanda-security.conf file does not exist.
> >
> > If you used the packages that come with buster, you should have
> > gotten /etc/amanda-security.conf from the amanda-client package. Did
> > you install from the debian packages, or did you only install the
> > server on that machine?
>
> Both Charles. And I am about 2.5 hours from finding out if a normal
> backup works.
>
And it worked normally. Whoopee.

Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: new debian buster install, missing /etc/amanda-security.conf file

[Gene Heskett]

On Thursday 04 February 2021 21:43:38 Charles Curley wrote:

> On Thu, 4 Feb 2021 15:36:21 -0500
>
> Gene Heskett  wrote:
> > Updating both to newer hardware for machines and installing debian
> > buster, but amcheck says that the /etc/amanda-security.conf file
> > won't let me run tar as root, but the real problem is that
> > the /etc/amanda-security.conf file does not exist.
>
> If you used the packages that come with buster, you should have
> gotten /etc/amanda-security.conf from the amanda-client package. Did
> you install from the debian packages, or did you only install the
> server on that machine?

Both Charles. And I am about 2.5 hours from finding out if a normal 
backup works.


Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: new debian buster install, missing /etc/amanda-security.conf file

[Charles Curley]

On Thu, 4 Feb 2021 15:36:21 -0500
Gene Heskett  wrote:

> Updating both to newer hardware for machines and installing debian 
> buster, but amcheck says that the /etc/amanda-security.conf file
> won't let me run tar as root, but the real problem is that 
> the /etc/amanda-security.conf file does not exist.

If you used the packages that come with buster, you should have
gotten /etc/amanda-security.conf from the amanda-client package. Did
you install from the debian packages, or did you only install the
server on that machine?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: new debian buster install, missing /etc/amanda-security.conf file

[Gene Heskett]

On Thursday 04 February 2021 16:28:14 Debra S Baddorf wrote:

> > On Feb 4, 2021, at 2:49 PM, Alan Hodgson 
> > wrote:
> >
> > On Thu, 2021-02-04 at 15:36 -0500, Gene Heskett wrote:
> >> Greetings all;
> >>
> >> Updating both to newer hardware for machines and installing debian
> >> buster, but amcheck says that the /etc/amanda-security.conf file
> >> won't let me run tar as root, but the real problem is that
> >> the /etc/amanda-security.conf file does not exist.
> >>
> >> Who owns it, I assume its 0600 for perms, and whats it supposed to
> >> say?
> >>
> >> Thanks everybody.
> >>
> >> Cheers, Gene Heskett
> >
> > Not a Debian system, but:
> >
> > hades ~ # ls -l /etc/amanda-security.conf
> > -rw-r--r-- 1 root amanda 56 Sep 20  2016 /etc/amanda-security.conf
> >
> > hades ~ # cat /etc/amanda-security.conf
> > amgtar:gnutar_path:/bin/tar
> > runtar:gnutar_path:/bin/tar
> >
> > There's also a manpage for it on my systems.
>
> Contents on my machines:  (can be entirely commented out; that’s how
> it starts)

edited for buster below.

>   amanda-security.conf  
> 
> # /etc/amanda-security.conf#
> #  #
> # See: man amanda-security.conf#
> #  #
> # This file must be installed at /etc/amanda-security.conf #
> #  #
> # It list all executables amanda can execute as root.  #
> # This file must contains realpath to executable, with #
> # all symbolic links resolved. #
> # You can use the 'realpath' command to find them. #
> #  #
> # It list program and a symbolic name for the program  #
> # Followed by the realpath of the binary   #
> #  #
> # Uncomment and edit the following lines to let Amanda to  #
> # use customized system commands.  If multiple PATH is #
> # necessary, please put them in different lines.   #
> # e.g.:#
> # amgtar:GNUTAR_PATH=/usr/bin/tar  #
> # amgtar:GNUTAR_PATH=/usr/bin/tar-1.28 #
> #  #
> # If a program and symbolic name is not listed, then the   #
> # configured binary is allowed to be run as root.  #
> # You can find the configured binary with amgetconf#
> # amgetconf build.gnutar_path  #
> # amgetconf build.star_path#
> # amgetconf build.bsdtar_path  #
> #  #
> 
> #runtar:gnutar_path=/bin/tar
amgtar:gnutar_path=/usr/bin/tar
> #amstar:star_path=/usr/bin/star
> #ambsdtar:bsdtar_path=/usr/bin/bsdtar
>
> #restore_by_amanda_user=no

Thanks Deb.

I copied it from another install, then had to edit the amgtar path cuz 
buster moved tar from /bin, to /usr/bin.  So that basket of rattlesnakes 
is sorted.  We'll see what happens tonight.

Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: new debian buster install, missing /etc/amanda-security.conf file

[Debra S Baddorf]

> On Feb 4, 2021, at 2:49 PM, Alan Hodgson  wrote:
> 
> On Thu, 2021-02-04 at 15:36 -0500, Gene Heskett wrote:
>> Greetings all;
>> 
>> Updating both to newer hardware for machines and installing debian 
>> buster, but amcheck says that the /etc/amanda-security.conf file won't 
>> let me run tar as root, but the real problem is that 
>> the /etc/amanda-security.conf file does not exist.
>> 
>> Who owns it, I assume its 0600 for perms, and whats it supposed to say?
>> 
>> Thanks everybody.
>> 
>> Cheers, Gene Heskett
> 
> Not a Debian system, but:
> 
> hades ~ # ls -l /etc/amanda-security.conf  
> -rw-r--r-- 1 root amanda 56 Sep 20  2016 /etc/amanda-security.conf
> 
> hades ~ # cat /etc/amanda-security.conf  
> amgtar:gnutar_path:/bin/tar 
> runtar:gnutar_path:/bin/tar
> 
> There's also a manpage for it on my systems.


Contents on my machines:  (can be entirely commented out; that’s how it starts)

  amanda-security.conf  

# /etc/amanda-security.conf#
#  #
# See: man amanda-security.conf#
#  #
# This file must be installed at /etc/amanda-security.conf #
#  #
# It list all executables amanda can execute as root.  #
# This file must contains realpath to executable, with #
# all symbolic links resolved. #
# You can use the 'realpath' command to find them. #
#  #
# It list program and a symbolic name for the program  #
# Followed by the realpath of the binary   #
#  #
# Uncomment and edit the following lines to let Amanda to  #
# use customized system commands.  If multiple PATH is #
# necessary, please put them in different lines.   #
# e.g.:#
# amgtar:GNUTAR_PATH=/usr/bin/tar  #
# amgtar:GNUTAR_PATH=/usr/bin/tar-1.28 #
#  #
# If a program and symbolic name is not listed, then the   #
# configured binary is allowed to be run as root.  #
# You can find the configured binary with amgetconf#
# amgetconf build.gnutar_path  #
# amgetconf build.star_path#
# amgetconf build.bsdtar_path  #
#  #

#runtar:gnutar_path=/bin/tar
#amgtar:gnutar_path=/bin/tar
#amstar:star_path=/usr/bin/star
#ambsdtar:bsdtar_path=/usr/bin/bsdtar

#restore_by_amanda_user=no

Re: new debian buster install, missing /etc/amanda-security.conf file

[Gene Heskett]

On Thursday 04 February 2021 15:49:21 Alan Hodgson wrote:

> On Thu, 2021-02-04 at 15:36 -0500, Gene Heskett wrote:
> > Greetings all;
> > Updating both to newer hardware for machines and installing debian
> > buster, but amcheck says that the /etc/amanda-security.conf file
> > won't let me run tar as root, but the real problem is that the
> > /etc/amanda-security.conf file does not exist.
> > Who owns it, I assume its 0600 for perms, and whats it supposed to
> > say? Thanks everybody.
> > Cheers, Gene Heskett
>
> Not a Debian system, but:
>
> hades ~ # ls -l /etc/amanda-security.conf
> -rw-r--r-- 1 root amanda 56 Sep 20  2016 /etc/amanda-security.conf
>
>
>
> hades ~ # cat /etc/amanda-security.conf
> amgtar:gnutar_path:/bin/tar
>
> runtar:gnutar_path:/bin/tar

 Never uncommented this one in years, don't use anything but amgtar.
>
> There's also a manpage for it on my systems.
I got it, copied it from another buster install, then had to edit it cuz 
buster moved tar to /usr/bin. But I just this instant got it down to 
zero errors.

Thanks Alan.

Copyright 2019 by Maurice E. Heskett
Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: new debian buster install, missing /etc/amanda-security.conf file

[Alan Hodgson]

On Thu, 2021-02-04 at 15:36 -0500, Gene Heskett wrote:
> Greetings all;
> Updating both to newer hardware for machines and installing debian buster,
> but amcheck says that the /etc/amanda-security.conf file won't let me run
> tar as root, but the real problem is that the /etc/amanda-security.conf file
> does not exist.
> Who owns it, I assume its 0600 for perms, and whats it supposed to say?
> Thanks everybody.
> Cheers, Gene Heskett

Not a Debian system, but:

hades ~ # ls -l /etc/amanda-security.conf  
-rw-r--r-- 1 root amanda 56 Sep 20  2016 /etc/amanda-security.conf



hades ~ # cat /etc/amanda-security.conf  
amgtar:gnutar_path:/bin/tar

runtar:gnutar_path:/bin/tar


There's also a manpage for it on my systems.

new debian buster install, missing /etc/amanda-security.conf file

[Gene Heskett]

Greetings all;

Updating both to newer hardware for machines and installing debian 
buster, but amcheck says that the /etc/amanda-security.conf file won't 
let me run tar as root, but the real problem is that 
the /etc/amanda-security.conf file does not exist.

Who owns it, I assume its 0600 for perms, and whats it supposed to say?

Thanks everybody.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: "vaulting run" amdump email report issues -- "amdump --no-dump --no-flush" has MISSING in subject line

[Nathan Stratton Treadway]

On Wed, Nov 22, 2017 at 11:58:12 -0500, Jean-Louis Martineau wrote:
> On 22/11/17 12:56 AM, Nathan Stratton Treadway wrote:
> >> I applied this patch and ran the test again, and "amdump --no-dump 
> >> 
> > --no-flush" worked just as well as with the previous patch, but showed  
> >
> > no "dumper lines" in the log.*.0 file.  
> >
> > (Of course the email report did still have the unexpected RESULTS
> > MISSING line for each DLE.)
> I already committed a fix for that, use SVN or GIT.
> 

Sorry to revive this old thread, but I'm finally getting a chance to
look at this carefully under v3.5.1.


The context of this discussion is a configuration where "vault-storage"
is set, and the main storage had a "vault" line pointing to that vault
storage.  If I then run a "normal" amdump without any vault vtapes being
available, this leaves a situation where there is a pending "vault"
operation for each affected DLE..


When I mounted a suitable vault vtape and ran the v3.5.1 "amdump
-no-dump --noflush" command to perform the vaulting, the copy proceeded
as expected... and the Amanda mail report message did not have the
RESULTS MISSING line for each DLE that used to appear, and generally
looked correct.

However, the one thing that did not quite seem correct is that the
Subject line of the email message _did_ have the word "MISSING" in it...

Included below is a (shorted) version of the email, in case that's
helpful in tracking down what is causing that "MISSING".

Nathan

=
To: natha...@ontko.com
Subject: TestBackup MISSING: AMANDA MAIL REPORT FOR February 21, 2018
Date: Wed, 21 Feb 2018 11:00:40 -0500

Hostname: tumhalad
Org : TestBackup
Config  : TestBackup
Date: February 21, 2018

These dumps to storage 'TestOffsite' were to tape TESTBACKUP-108.
The next tape Amanda expects to use for storage 'TestBackup' is: TESTBACKUP-06.
The next tape Amanda expects to use for storage 'TestOffsite' is: 
TESTBACKUP-109.


STATISTICS:
  Total   Full  Incr.   Level:#
        
Estimate Time (hrs:min) 0:00
Run Time (hrs:min)  0:01
Dump Time (hrs:min) 0:00   0:00   0:00
Output Size (meg)0.00.00.0
Original Size (meg)  0.00.00.0
Avg Compressed Size (%)  -- -- --
DLEs Dumped0  0  0
Avg Dump Rate (k/s)  -- -- --

Tape Time (hrs:min) 0:01   0:01   0:00
Tape Size (meg)   7106.0 6813.9  292.1
Tape Used (%)3.53.30.1
DLEs Taped 9  3  6  1:6
Parts Taped9  3  6  1:6
Avg Tp Write Rate (k/s)  92812.991808.4 124623


USAGE BY TAPE:
  Label Time Size  %  DLEs Parts
  TESTBACKUP-1080:017106M3.5 9 9


NOTES:
  taper: Slot 3 with label TESTBACKUP-03 is usable
  taper: Slot 8 with label TESTBACKUP-108 is usable
  taper: tape TESTBACKUP-108 kb 7276536 fm 9 [OK]


DUMP SUMMARY:
 DUMPER STATS   TAPER STATS
HOSTNAME   DISK   L  ORIG-MB   OUT-MB COMP% MMM:SSKB/s MMM:SSKB/s
--- --- -- --
client1/  0  2093   --  VAULT0:22 97401.6
client2/  1 4   --  VAULT0:00 41540.0
[... similar lines for each DLE ...]
=




Nathan Stratton Treadway  -  natha...@ontko.com  -  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

Re: ambackupd reports missing data

[Jon LaBadie]

On Tue, Sep 26, 2017 at 02:46:10PM -0400, Jon LaBadie wrote:
> Thanks, I'll try it.
> 
> As a minor additional query, must each DLE generate a separarate
> report unlike the normal combined report of amdump?
> 
> Jon
> On Tue, Sep 26, 2017 at 08:38:51AM -0400, Jean-Louis Martineau wrote:
> > Jon,
> > 
> > I committed the attached patch to fix the issue.
> > 
> > ambackup should not print the server-src on the 'SUCCESS dumper' line.
> > Fix the report to parse it so that it can parse log file with the bogus 
> > server-src
> > 
> > Jean-Louis
> > 

That seems to do the trick, thank you.

jl
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: ambackupd reports missing data

[Jon LaBadie]

Thanks, I'll try it.

As a minor additional query, must each DLE generate a separarate
report unlike the normal combined report of amdump?

Jon
On Tue, Sep 26, 2017 at 08:38:51AM -0400, Jean-Louis Martineau wrote:
> Jon,
> 
> I committed the attached patch to fix the issue.
> 
> ambackup should not print the server-src on the 'SUCCESS dumper' line.
> Fix the report to parse it so that it can parse log file with the bogus 
> server-src
> 
> Jean-Louis
> 
> On 25/09/17 05:28 PM, Jon LaBadie wrote:
> > On Mon, Sep 25, 2017 at 08:57:31AM -0400, Jean-Louis Martineau wrote:
> > > Jon,
> > >
> > > Can you post the log..0 file?
> > >
> > > Jean-Louis
> > >
> > > On 24/09/17 05:59 PM, Jon LaBadie wrote:
> > > > When I request a backup of a client using ambackupd, the subsequent
> > > > report does not include most of the dump statistics (first line of
> > > > data). Some of them print out on the next regular amdump run when
> > > > the client backup is flushed from the holding disk to the storage
> > > > (second line of data) medium. The dump time and rate are nor
> > > > reported in either report.
> > > >
> > > > Is this an oversight or is there a reason they can not be reported?
> >
> > Those log files were no longer available so I just ran a new set.
> >
> > Here is a log, the email report follows.
> >
> > INFO ambackupd ambackupd pid 20275
> > START ambackupd date 20170925164612
> > STATS ambackupd hostname mums.jgcomp.com 
> > 
> > DISK ambackupd vost.jgcomp.com 
> >  
> > Root
> > SUCCESS dumper vost.jgcomp.com 
> >  
> > Root 20170925164612 1 \
> > a0311982:661278720 a7e75a37:188633372 a7e75a37:188633372 \
> > [sec 297.261288 kb 184212 kps 619.697240900066 orig-kb 645780]
> > SUCCESS chunker vost.jgcomp.com 
> >  
> > Root 20170925164612 1 \
> > a7e75a37:188633372 \
> > [sec 297.261288 kb 184212 kps 619.697240900066]
> > FINISH ambackupd date 20170925164612 time 297.261288
> > INFO ambackupd pid-done 20275
> >
> >
> > STATISTICS:
> > Total Full Incr. Level:#
> >    
> > Estimate Time (hrs:min) 0:00
> > Run Time (hrs:min) 0:00
> > Dump Time (hrs:min) 0:00 0:00 0:00
> > Output Size (meg) 179.9 0.0 179.9
> > Original Size (meg) 0.0 0.0 0.0
> > Avg Compressed Size (%) -- -- --
> > DLEs Dumped 1 0 1 1:1
> > 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
> > DLEs Taped 0 0 0
> > Parts Taped 0 0 0
> > Avg Tp Write Rate (k/s) -- -- --
> >
> > DUMP SUMMARY:
> > DUMPER STATS TAPER STATS
> > HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
> > - -- -- 
> > -
> > vost.jgcomp.com 
> >  
> > Root 1 0 180 -- 0:00 0.0
> >
> > (brought to you by Amanda version 3.4.1)
> >
> > -- 
> > Jon H. LaBadie j...@jgcomp.com
> > 11226 South Shore Rd. (703) 787-0688 (H)
> > Reston, VA 20190 (703) 935-6720 (C)
> This message is the property of CARBONITE, INC. and may contain confidential 
> or privileged information.
> If this message has been delivered to you by mistake, then do not copy or 
> deliver this message to anyone.  Instead, destroy it and notify me by reply 
> e-mail

> diff --git a/perl/Amanda/Report.pm b/perl/Amanda/Report.pm
> index 2f9653f..b2a7088 100644
> --- a/perl/Amanda/Report.pm
> +++ b/perl/Amanda/Report.pm
> @@ -976,8 +976,10 @@ sub _handle_dumper_line
>   my $x;
>   if ($info[4] eq '[sec') {
>   $x = 5;
> - } else {
> + } elsif ($info[6] eq '[sec') {
>   $x = 7; #native and client crc
> + } else {
> + $x = 8; #native, client crc and server crc
>   }
>  my ( $sec, $kb, $kps, $orig_kb ) = @info[ $x, $x+2, $x+4, $x+6 ];
>   $kb = int($kb/1024) if $info[$x+1] eq 'bytes';
> diff --git a/server-src/ambackupd.pl b/server-src/ambackupd.pl
> index af8bc8b..ead2889 100644
> --- a/server-src/ambackupd.pl
> +++ b/server-src/ambackupd.pl
> @@ -918,7 +918,7 @@ sub do_backup {
>   log_end_multiline();
>   } else {
>   print {$self->{'mesg_fh'}} "backup done: " . 
> Amanda::Util::quote_string($self->{'diskname'}) . "\n";
> - log_add_full($L_SUCCESS, "dumper", "$self->{'hostname'} 
> $self->{'qdiskname'} $self->{'timestamp'} $self->{'hdr'}->{'dumplevel'} 
> $self->{'native_crc'} $self->{'client_crc'} $self->{'server_crc'} [sec 
> $self->{'dump_time'} kb $kb kps $kps orig-kb $self->{'orig_size'}]");
> + log_add_full($L_SUCCESS, "dumper", "$self->{'hostname'} 
> $self->{'qdiskname'} $self->{'timestamp'} $self->{'hdr'}->{'dumplevel'} 
> $self->{'native_crc'} $self->{'client_crc'} [sec $self->{'dump_time'} kb $kb 
> kps $kps orig-kb $self->{'orig_size'}]");
>   }
>   log_add_full($L_SUCCESS, "chunker", "$self->{'hostname'} 
> $self->{'qdiskname'} $self->{'timestamp'} $self->{'hdr'}->{'dumplevel'} 
> 

Re: ambackupd reports missing data

[Jean-Louis Martineau]

Jon,

I committed the attached patch to fix the issue.

ambackup should not print the server-src on the 'SUCCESS dumper' line.
Fix the report to parse it so that it can parse log file with the bogus 
server-src

Jean-Louis

On 25/09/17 05:28 PM, Jon LaBadie wrote:
> On Mon, Sep 25, 2017 at 08:57:31AM -0400, Jean-Louis Martineau wrote:
> > Jon,
> >
> > Can you post the log..0 file?
> >
> > Jean-Louis
> >
> > On 24/09/17 05:59 PM, Jon LaBadie wrote:
> > > When I request a backup of a client using ambackupd, the subsequent
> > > report does not include most of the dump statistics (first line of
> > > data). Some of them print out on the next regular amdump run when
> > > the client backup is flushed from the holding disk to the storage
> > > (second line of data) medium. The dump time and rate are nor
> > > reported in either report.
> > >
> > > Is this an oversight or is there a reason they can not be reported?
>
> Those log files were no longer available so I just ran a new set.
>
> Here is a log, the email report follows.
>
> INFO ambackupd ambackupd pid 20275
> START ambackupd date 20170925164612
> STATS ambackupd hostname mums.jgcomp.com 
> 
> DISK ambackupd vost.jgcomp.com 
>  
> Root
> SUCCESS dumper vost.jgcomp.com 
>  
> Root 20170925164612 1 \
> a0311982:661278720 a7e75a37:188633372 a7e75a37:188633372 \
> [sec 297.261288 kb 184212 kps 619.697240900066 orig-kb 645780]
> SUCCESS chunker vost.jgcomp.com 
>  
> Root 20170925164612 1 \
> a7e75a37:188633372 \
> [sec 297.261288 kb 184212 kps 619.697240900066]
> FINISH ambackupd date 20170925164612 time 297.261288
> INFO ambackupd pid-done 20275
>
>
> STATISTICS:
> Total Full Incr. Level:#
>    
> Estimate Time (hrs:min) 0:00
> Run Time (hrs:min) 0:00
> Dump Time (hrs:min) 0:00 0:00 0:00
> Output Size (meg) 179.9 0.0 179.9
> Original Size (meg) 0.0 0.0 0.0
> Avg Compressed Size (%) -- -- --
> DLEs Dumped 1 0 1 1:1
> 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
> DLEs Taped 0 0 0
> Parts Taped 0 0 0
> Avg Tp Write Rate (k/s) -- -- --
>
> DUMP SUMMARY:
> DUMPER STATS TAPER STATS
> HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
> - -- -- 
> -
> vost.jgcomp.com 
>  
> Root 1 0 180 -- 0:00 0.0
>
> (brought to you by Amanda version 3.4.1)
>
> -- 
> Jon H. LaBadie j...@jgcomp.com
> 11226 South Shore Rd. (703) 787-0688 (H)
> Reston, VA 20190 (703) 935-6720 (C)
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail
diff --git a/perl/Amanda/Report.pm b/perl/Amanda/Report.pm
index 2f9653f..b2a7088 100644
--- a/perl/Amanda/Report.pm
+++ b/perl/Amanda/Report.pm
@@ -976,8 +976,10 @@ sub _handle_dumper_line
 	my $x;
 	if ($info[4] eq '[sec') {
 	$x = 5;
-	} else {
+	} elsif ($info[6] eq '[sec') {
 	$x = 7; #native and client crc
+	} else {
+	$x = 8; #native, client crc and server crc
 	}
 my ( $sec, $kb, $kps, $orig_kb ) = @info[ $x, $x+2, $x+4, $x+6 ];
 	$kb = int($kb/1024) if $info[$x+1] eq 'bytes';
diff --git a/server-src/ambackupd.pl b/server-src/ambackupd.pl
index af8bc8b..ead2889 100644
--- a/server-src/ambackupd.pl
+++ b/server-src/ambackupd.pl
@@ -918,7 +918,7 @@ sub do_backup {
 	log_end_multiline();
 	} else {
 	print {$self->{'mesg_fh'}} "backup done: " . Amanda::Util::quote_string($self->{'diskname'}) . "\n";
-	log_add_full($L_SUCCESS, "dumper", "$self->{'hostname'} $self->{'qdiskname'} $self->{'timestamp'} $self->{'hdr'}->{'dumplevel'} $self->{'native_crc'} $self->{'client_crc'} $self->{'server_crc'} [sec $self->{'dump_time'} kb $kb kps $kps orig-kb $self->{'orig_size'}]");
+	log_add_full($L_SUCCESS, "dumper", "$self->{'hostname'} $self->{'qdiskname'} $self->{'timestamp'} $self->{'hdr'}->{'dumplevel'} $self->{'native_crc'} $self->{'client_crc'} [sec $self->{'dump_time'} kb $kb kps $kps orig-kb $self->{'orig_size'}]");
 	}
 	log_add_full($L_SUCCESS, "chunker", "$self->{'hostname'} $self->{'qdiskname'} $self->{'timestamp'} $self->{'hdr'}->{'dumplevel'} $self->{'server_crc'} [sec $self->{'dump_time'} kb $kb kps $kps]");
 	$steps->{'quit'}->();

Re: ambackupd reports missing data

[Jon LaBadie]

On Mon, Sep 25, 2017 at 08:57:31AM -0400, Jean-Louis Martineau wrote:
> Jon,
> 
> Can you post the log..0 file?
> 
> Jean-Louis
> 
> On 24/09/17 05:59 PM, Jon LaBadie wrote:
> > When I request a backup of a client using ambackupd, the subsequent
> > report does not include most of the dump statistics (first line of
> > data).  Some of them print out on the next regular amdump run when
> > the client backup is flushed from the holding disk to the storage
> > (second line of data) medium.  The dump time and rate are nor
> > reported in either report.
> >
> > Is this an oversight or is there a reason they can not be reported?

Those log files were no longer available so I just ran a new set.

Here is a log, the email report follows.

INFO ambackupd ambackupd pid 20275
START ambackupd date 20170925164612
STATS ambackupd hostname mums.jgcomp.com
DISK ambackupd vost.jgcomp.com Root
SUCCESS dumper vost.jgcomp.com Root 20170925164612 1 \
a0311982:661278720 a7e75a37:188633372 a7e75a37:188633372 \
[sec 297.261288 kb 184212 kps 619.697240900066 orig-kb 645780]
SUCCESS chunker vost.jgcomp.com Root 20170925164612 1 \
a7e75a37:188633372 \
[sec 297.261288 kb 184212 kps 619.697240900066]
FINISH ambackupd date 20170925164612 time 297.261288
INFO ambackupd pid-done 20275


STATISTICS:
  Total   Full  Incr.   Level:#
        
Estimate Time (hrs:min) 0:00
Run Time (hrs:min)  0:00
Dump Time (hrs:min) 0:00   0:00   0:00
Output Size (meg)  179.90.0  179.9
Original Size (meg)  0.00.00.0
Avg Compressed Size (%)  -- -- --
DLEs Dumped1  0  1  1:1
Avg Dump Rate (k/s)  -- -- --

Tape Time (hrs:min) 0:00   0:00   0:00
Tape Size (meg)  0.00.00.0
Tape Used (%)0.00.00.0
DLEs Taped 0  0  0
Parts Taped0  0  0
Avg Tp Write Rate (k/s)  -- -- --

DUMP SUMMARY:
  DUMPER STATS   TAPER STATS
HOSTNAMEDISKL ORIG-MB  OUT-MB  COMP%  MMM:SS   KB/s MMM:SS   
KB/s
- -- -- 
-
vost.jgcomp.com Root1   0 180-- 0:000.0

(brought to you by Amanda version 3.4.1)

-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

Re: ambackupd reports missing data

[Jean-Louis Martineau]

Jon,

Can you post the log..0 file?

Jean-Louis

On 24/09/17 05:59 PM, Jon LaBadie wrote:
> When I request a backup of a client using ambackupd, the subsequent
> report does not include most of the dump statistics (first line of
> data).  Some of them print out on the next regular amdump run when
> the client backup is flushed from the holding disk to the storage
> (second line of data) medium.  The dump time and rate are nor
> reported in either report.
>
> Is this an oversight or is there a reason they can not be reported?
>
>
> DUMP SUMMARY:
>  DUMPER STATSTAPER STATS
> HOSTNAMEDISK   L  ORIG-MB  OUT-MB  COMP%   MMM:SS   KB/s   MMM:SS   KB/s
> 
> vost. ...   Root   005017--  0:000.0
>
> vost. ...   Root   0128145017   39.2FLUSH 2:45   31137.7
>
>
> Thanks,
> Jon
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail

ambackupd reports missing data

[Jon LaBadie]

When I request a backup of a client using ambackupd, the subsequent
report does not include most of the dump statistics (first line of
data).  Some of them print out on the next regular amdump run when
the client backup is flushed from the holding disk to the storage
(second line of data) medium.  The dump time and rate are nor
reported in either report.

Is this an oversight or is there a reason they can not be reported?


DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAMEDISK   L  ORIG-MB  OUT-MB  COMP%   MMM:SS   KB/s   MMM:SS   KB/s

vost. ...   Root   005017--  0:000.0

vost. ...   Root   0128145017   39.2FLUSH 2:45   31137.7


Thanks,
Jon
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)

RESULTS MISSING on all DLE when only one estimate fails?

[Matthias Teege]

Hallo!

I've installed Amanda 3.3.3 on a Centos server. Sometimes backups are
failing with "RESULTS MISSING" and "driver: WARNING: got empty
schedule from planner". I think this is mostly because of estimate
timeouts. I see "planner: ERROR Some estimate timeout on
a.example.com, using server estimate if possible". Thats something I
can handle.

But why do I get "RESULTS MISSING" for all hosts/DLE and "... empty
schedule ..." when only one estimate fails? There are planner/estimate
results from all my DLE, except one, in the logs. Shouldn't the amanda
planner return a schedule without the failing DLE?

Thanks!
Matthias

Re: labelstr check missing in amlabel (v3.4.3)?

[Nathan Stratton Treadway]

On Thu, Mar 16, 2017 at 11:46:10 -0400, Jean-Louis Martineau wrote:
> Thanks for reporting the issue.
> I committed the attached patch.

I noticed if I have an already-labeled volume in a slot at then try to
put an invalid label on it, the error message printed is misleading:


# su backup -c "amtape TestBackup slot 2"
slot   2: time X  label TESTBACKUP-02
changed to slot 2
# su backup -c "amlabel TestBackup BLAH-03 slot 2"
Reading label...
Found label 'TESTBACKUP-02' but it doesn't match the labelstr 
'^TESTBACKUP-[0-9][0-9]*$'.
Not writing label.
Not writing label.


I guess this situation is really a combination of two error conditions:
1) the specified new label doesn't match labelstr, and 2) the current
tape is already labeled  


Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  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

Re: labelstr check missing in amlabel (v3.4.3)?

[Nathan Stratton Treadway]

On Thu, Mar 16, 2017 at 11:46:10 -0400, Jean-Louis Martineau wrote:
> Thanks for reporting the issue.
> I committed the attached patch.

Great, thanks.

I applied to the patch to Label.pm and can confirm it works as expected
now: 


# su backup -c "amlabel TestBackup BLAH-02 slot 2"
Reading label...
Found an empty tape.
Label 'BLAH-02' doesn't match the labelstr '^TESTBACKUP-[0-9][0-9]*$'.
Label 'BLAH-02' doesn't match the labelstr '^TESTBACKUP-[0-9][0-9]*$'.


However, as you can see, the error message is repeated twice, and
there's no explicit message telling me that the label attempt failed.

I tried some other failure-to-write-label situations and found the
warning/failure messages were inconsistent:


# su backup -c "amlabel TestBackup TESTBACKUP-03 slot 2"
Reading label...
Volume with label 'TESTBACKUP-02' is active and contains data from this 
configuration.
Not writing label.
Not writing label.
# su backup -c "amlabel TestBackup TESTBACKUP-02 slot 3"
Label 'TESTBACKUP-02' already on a volume
# su backup -c "amlabel TestBackup slot 3"
Reading label...
Found an empty tape.
template is not set, you must set autolabel
template is not set, you must set autolabel


How difficult would be it be to fix the program to consistently A) print
the error message just one time and B) print "Not writing label." (or
something similar) in all situation where the label is not successfully
written?

Nathan




Nathan Stratton Treadway  -  natha...@ontko.com  -  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

Re: labelstr check missing in amlabel (v3.4.3)?

[Jean-Louis Martineau]

Nathan,

Thanks for reporting the issue.
I committed the attached patch.

Jean-Louis

On 15/03/17 05:45 PM, Nathan Stratton Treadway wrote:
> I'm running Amanda 3.4.3 (built under Ubuntu from Jose's Debian
> "experimental" source package, v3.4.3-1).
>
> The man page for "amlabel" includes the following paragraph:
> Label 'label' doesn't match labelstr 'labelstr'
> The given label does not match the configured labelstr. Even with
> -f, this is an error.
> ... but in practice it lets me create labels that don't match without
> any warning:
>
> ==
> # amgetconf TestBackup labelstr
> "^TESTBACKUP-[0-9][0-9]*$"
>
> # su backup -c "amlabel TestBackup BLAH-05 slot 5"
> Reading label...
> Found an empty tape.
> Writing label 'BLAH-05'...
> Checking label...
> Success!
>
> # grep BLAH tapelist
> 0 BLAH-05 reuse BLOCKSIZE:32 POOL:TestBackup STORAGE:TestBackup 
> CONFIG:TestBackup
> ==
>
>
> Other commands do show that the label doesn't match the labelstr, though:
> ==
> # su backup -c "amtape TestBackup show 1,5"
> slot   1: date X  label TESTBACKUP-01
> slot   5: date X  label BLAH-05 (label do not match labelstr)
> ==
>
>
> Am I correct that amlabel should be refusing to create this non-matching
> label?
>
> Thanks.
>
>   Nathan
>
> 
> Nathan Stratton Treadway  -  natha...@ontko.com  -  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
>
This message is the property of CARBONITE, INC. and may contain confidential or 
privileged information.
If this message has been delivered to you by mistake, then do not copy or 
deliver this message to anyone.  Instead, destroy it and notify me by reply 
e-mail
diff --git a/installcheck/amlabel.pl b/installcheck/amlabel.pl
index 165f455..86619d9 100644
--- a/installcheck/amlabel.pl
+++ b/installcheck/amlabel.pl
@@ -138,7 +138,7 @@ like($Installcheck::Run::stdout,
 ok(!run('amlabel', 'TESTCONF', 'SomeTape'),
 "amlabel refuses to write on a  tape already labeled");
 like($Installcheck::Run::stdout,
-qr/Reading label...\nLabel 'TESTCONF92' doesn't match the labelstr 'TESTCONF\[0-9\]\[0-9\]'/,
+qr/Reading label...\nFound label 'TESTCONF92' but it doesn't match the labelstr 'TESTCONF\[0-9\]\[0-9\]'/,
 "with correct message on stdout");
 like($Installcheck::Run::stderr,
 qr/Not writing label./,
diff --git a/perl/Amanda/Label.pm b/perl/Amanda/Label.pm
index 6d3cb3e..ad16ece 100644
--- a/perl/Amanda/Label.pm
+++ b/perl/Amanda/Label.pm
@@ -669,7 +669,7 @@ sub label {
 		$self->user_msg(Amanda::Label::Message->new(
 	source_filename => __FILE__,
 	source_line => __LINE__,
-	code  => 113,
+	code  => 116,
 	severity  => $Amanda::Message::ERROR,
 	label => $label,
 	labelstr  => $labelstr));
@@ -768,7 +768,21 @@ sub label {
 	}
 	}
 
-	if ($dev_ok) {
+	if ($params{'label'} && $dev_ok) {
+	my $barcode = $res->{'barcode'};
+	my $meta = $meta;
+
+	if (!match_labelstr($labelstr, $autolabel, $params{'label'}, $barcode, $meta, $storage_name)) {
+		return $steps->{'releasing'}->(Amanda::Label::Message->new(
+	source_filename => __FILE__,
+	source_line => __LINE__,
+	code  => 113,
+	severity  => $Amanda::Message::ERROR,
+	label => $label,
+	labelstr  => $labelstr));
+	}
+	}
+	if ($dev_ok){
 	$self->user_msg(Amanda::Label::Message->new(
 source_filename => __FILE__,
 source_line => __LINE__,

labelstr check missing in amlabel (v3.4.3)?

[Nathan Stratton Treadway]

I'm running Amanda 3.4.3 (built under Ubuntu from Jose's Debian
"experimental" source package, v3.4.3-1).

The man page for "amlabel" includes the following paragraph:
   Label 'label' doesn't match labelstr 'labelstr'
   The given label does not match the configured labelstr. Even with
   -f, this is an error.
... but in practice it lets me create labels that don't match without
any warning:

==
# amgetconf TestBackup labelstr
"^TESTBACKUP-[0-9][0-9]*$"

# su backup -c "amlabel TestBackup BLAH-05 slot 5"
Reading label...
Found an empty tape.
Writing label 'BLAH-05'...
Checking label...
Success!

# grep BLAH tapelist
0 BLAH-05 reuse BLOCKSIZE:32 POOL:TestBackup STORAGE:TestBackup 
CONFIG:TestBackup
==


Other commands do show that the label doesn't match the labelstr, though:
==
# su backup -c "amtape TestBackup show 1,5"
slot   1: date X  label TESTBACKUP-01
slot   5: date X  label BLAH-05 (label do not match labelstr)
==


Am I correct that amlabel should be refusing to create this non-matching
label?

Thanks.

Nathan


Nathan Stratton Treadway  -  natha...@ontko.com  -  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

Rv: amaddclient missing in amanda-backup_client-3.3.1-1.rhel6.i686.rpm

[contenidos2000-ama...@yahoo.com.ar]

Perhaps the confusion is where the utility should be executed?  
amaddclient runs on the server not the client.


Yes, it was was my confusion, the tutorial Setting Up the Open Source Backup 
Software Amanda Community in About 15 Minutes  seems to execute that command 
from the client. It is unclear that runs from the server.

Thanks a lot for your help.

roberto

Re: amaddclient missing in amanda-backup_client-3.3.1-1.rhel6.i686.rpm

[Dan Locks]

On 03/28/2012 06:04 PM, contenidos2000-ama...@yahoo.com.ar wrote:

Hello

I've installed amanda-backup_client-3.3.1-1.rhel6.i686.rpmin a new system and 
seems that command amaddclient
is missing.

The client works well but this file seems missing.
   


This executable is actually part of the server package, not the client.

$ rpm -qlp amanda-backup_server-3.3.1-1.rhel6.i686.rpm | grep add
/usr/sbin/amaddclient
/usr/share/man/man8/amaddclient.8.gz

Perhaps the confusion is where the utility should be executed?  
amaddclient runs on the server not the client.


Hope this helps,
Dan

amaddclient missing in amanda-backup_client-3.3.1-1.rhel6.i686.rpm

[contenidos2000-ama...@yahoo.com.ar]

Hello

I've installed amanda-backup_client-3.3.1-1.rhel6.i686.rpmin a new system and 
seems that command amaddclient
is missing.

The client works well but this file seems missing.

roberto

How To Tell Amanda a Tape is Missing

[Steven Backus]

I accidentally removed a tape while it was writing and now amanda
doesn't recognize the label.  Is there a way I can tell amanda next
time this tape comes up it has to re-write the label, and that the
data from this tape is missing?

Thanks,
  Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  steven.bac...@utah.edu
Genetic EpidemiologyAlternate:  bac...@math.utah.edu
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus

How To Tell Amanda a Tape is Missing?

[Steven Backus]

I accidentally removed a tape while it was writing and now amanda
doesn't recognize the label.  Is there a way I can tell amanda next
time this tape comes up it has to re-write the label, and that the
data from this tape is missing?

Thanks,
  Steve
-- 
Steven J. BackusComputer Specialist
University of Utah  E-Mail:  steven.bac...@utah.edu
Genetic EpidemiologyAlternate:  bac...@math.utah.edu
391 Chipeta Way -- Suite D  Office:  801.587.9308
Salt Lake City, UT 84108-1266   http://www.math.utah.edu/~backus

Re: How To Tell Amanda a Tape is Missing?

[Chris Hoogendyk]

On 7/15/11 10:40 AM, Steven Backus wrote:

I accidentally removed a tape while it was writing and now amanda
doesn't recognize the label.  Is there a way I can tell amanda next
time this tape comes up it has to re-write the label, and that the
data from this tape is missing?


Check `man amrmtape`.

Then `man amlabel`.

Basically, you'll use the first command to remove references to the tape from Amanda's records. Then 
you'll use the second command to label the tape again. You may have to use mt to erase it first.


--
---

Chris Hoogendyk

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

hoogen...@bio.umass.edu

---

Erdös 4

Status 'OK FAIL Missing part' in amadmin find - Bug is still in 3.2.2

[Marc Muehlfeld]

Hi

Jean-Louis Martineau wrote Mon, 03 Jan 2011 07:15:43 -0800:

your patch fixed it for 3.2.0. But wasn't it applied to the sources of
3.2.1? This version is still having the bug



The patch was committed after the 3.2.1 release.



Are you sure, that the patch was really committed? *3.2.2* is still having 
this issue:



$ amadmin KDD find | grep OK FAIL Missing part| head -3
2011-02-19 21:00:02 ... /home   4 KDD117   103   1/3 OK FAIL Missing part
2011-02-23 21:00:02 ... /home   6 KDD140   101   1/3 OK FAIL Missing part
2011-02-24 21:00:02 ... /home   7 KDD14787   1/2 OK FAIL Missing part
2011-03-01 21:00:01 ... /home   2 KDD172   105   1/3 OK FAIL Missing part
2011-03-08 21:00:01 ... /home   4 KDD03194   1/2 OK FAIL Missing part



Also I saw that the amount of this messages changes on what I query:

$ amadmin KDD find | grep OK FAIL Missing part | wc -l
6

$ amadmin KDD find genome | grep OK FAIL Missing part | wc -l
346



$ amadmin KDD version
build: VERSION=Amanda-3.2.2



Regards,
Marc



--
Marc Muehlfeld (IT-Leiter)
Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost
Lochhamer Str. 29 - D-82152 Martinsried
Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780
http://www.medizinische-genetik.de

Re: Status 'OK FAIL Missing part' in amadmin find - Bug is still in 3.2.2

[Jean-Louis Martineau]

Marc,

It is not the same bug I fixed.
Can you try this path?

Jean-Louis

Marc Muehlfeld wrote:

Hi

Jean-Louis Martineau wrote Mon, 03 Jan 2011 07:15:43 -0800:

your patch fixed it for 3.2.0. But wasn't it applied to the sources of
3.2.1? This version is still having the bug



The patch was committed after the 3.2.1 release.



Are you sure, that the patch was really committed? *3.2.2* is still 
having this issue:



$ amadmin KDD find | grep OK FAIL Missing part| head -3
2011-02-19 21:00:02 ... /home   4 KDD117   103   1/3 OK FAIL Missing part
2011-02-23 21:00:02 ... /home   6 KDD140   101   1/3 OK FAIL Missing part
2011-02-24 21:00:02 ... /home   7 KDD14787   1/2 OK FAIL Missing part
2011-03-01 21:00:01 ... /home   2 KDD172   105   1/3 OK FAIL Missing part
2011-03-08 21:00:01 ... /home   4 KDD03194   1/2 OK FAIL Missing part



Also I saw that the amount of this messages changes on what I query:

$ amadmin KDD find | grep OK FAIL Missing part | wc -l
6

$ amadmin KDD find genome | grep OK FAIL Missing part | wc -l
346



$ amadmin KDD version
build: VERSION=Amanda-3.2.2



Regards,
Marc





diff --git a/server-src/find.c b/server-src/find.c
index b387a9d..cfe33d6 100644
--- a/server-src/find.c
+++ b/server-src/find.c
@@ -1012,6 +1012,17 @@ search_logfile(
 	host, disk, date, level);
 		find_result_t *new_output_find = g_new0(find_result_t, 1);
 		part_find = g_hash_table_lookup(part_by_dle, key);
+		maxparts = partnum;
+		if (maxparts  totalparts)
+			maxparts = totalparts;
+		for (a_part_find = part_find;
+			 a_part_find;
+			 a_part_find = a_part_find-next) {
+			if (maxparts  a_part_find-partnum)
+			maxparts = a_part_find-partnum;
+			if (maxparts  a_part_find-totalparts)
+			maxparts = a_part_find-totalparts;
+		}
 		new_output_find-timestamp = stralloc(date);
 		new_output_find-write_timestamp = stralloc(datestamp);
 		new_output_find-hostname=stralloc(host);

Re: Status 'OK FAIL Missing part' in amadmin find - Bug is still in 3.2.2

[Marc Muehlfeld]

Am 15.03.2011 15:06, schrieb Jean-Louis Martineau:

Can you try this path?


If the find contains a hostname, it seems fixed now (before it were 346):


$ amadmin KDD find genome | grep OK FAIL Missing part | wc -l
0


But without hostname still 6 are found


$ amadmin KDD find | grep OK FAIL Missing part | wc -l
6


$ amadmin KDD find | grep OK FAIL Missing part

2011-02-11 21:00:01 ...  //lysine/backup$ 1 KDD075  1 35/40 OK FAIL 
Missing part
2011-02-11 21:00:01 ...  //lysine/backup$ 1 KDD075  2 36/40 OK FAIL 
Missing part
2011-02-11 21:00:01 ...  //lysine/backup$ 1 KDD075  3 37/40 OK FAIL 
Missing part
2011-02-11 21:00:01 ...  //lysine/backup$ 1 KDD075  4 38/40 OK FAIL 
Missing part
2011-02-11 21:00:01 ...  //lysine/backup$ 1 KDD075  5 39/40 OK FAIL 
Missing part
2011-02-11 21:00:01 ...  //lysine/backup$ 1 KDD075  6 40/40 OK FAIL 
Missing part






--
Marc Muehlfeld (IT-Leiter)
Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost
Lochhamer Str. 29 - D-82152 Martinsried
Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780
http://www.medizinische-genetik.de

Re: Status 'OK FAIL Missing part' in amadmin find - Bug is still in 3.2.2

[Marc Muehlfeld]

Am 15.03.2011 16:11, schrieb Jean-Louis Martineau:

Do that dle is on the genome host?


No. It's a windows host with name lysine that is backuped via the 
linux host nucleus.


 2011-02-11 21:00:01 ... //lysine/backup$ 1 KDD075 1 35/40 OK FAIL
 Missing part




Do the part 1 to 34 are still available? The volume might already been
overwritten by new dump.


You are right. The first 34 parts are already overwritten. Then your 
patch fixes the whole issue.



Thanks.


Regards,
Marc


--
Marc Muehlfeld (Leitung Systemadministration)
Zentrum fuer Humangenetik und Labormedizin Dr. Klein und Dr. Rost
Lochhamer Str. 29 - D-82152 Martinsried
Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780
http://www.medizinische-genetik.de

Re: Status 'OK FAIL Missing part' in amadmin find - bug is back in 3.2.1

[Jean-Louis Martineau]

The patch was committed after the 3.2.1 release.

Jean-Louis

Marc Muehlfeld wrote:

Hi,

your patch fixed it for 3.2.0. But wasn't it applied to the sources of
3.2.1? This version is still having the bug:



$ amadmin KDD find nucleus /
Warning: no log files found for tape KDD173 written 2010-12-27 21:00:01

datehost   disk lv tape or file file part status
2010-12-01 23:27:00 nucleus.mr.lfmg.de / 1 KDD176 11 1/30 OK
FAIL Missing part
2010-12-02 21:00:02 nucleus.mr.lfmg.de / 1 KDD024 30 1/31 OK
FAIL Missing part
.


Regards,
Marc



  

Re: Status 'OK FAIL Missing part' in amadmin find - bug is back in 3.2.1

[Marc Muehlfeld]

Hi,

your patch fixed it for 3.2.0. But wasn't it applied to the sources of
3.2.1? This version is still having the bug:



$ amadmin KDD find nucleus /
Warning: no log files found for tape KDD173 written 2010-12-27 21:00:01

datehost   disk lv tape or file file part status
2010-12-01 23:27:00 nucleus.mr.lfmg.de / 1 KDD176 11 1/30 OK
FAIL Missing part
2010-12-02 21:00:02 nucleus.mr.lfmg.de / 1 KDD024 30 1/31 OK
FAIL Missing part
.


Regards,
Marc



-- 
Marc Muehlfeld (IT-Leiter)
Zentrum fuer Humangenetik und Laboratoriumsmedizin Dr. Klein und Dr. Rost
Lochhamer Str. 29 - D-82152 Martinsried
Telefon: +49(0)89/895578-0 - Fax: +49(0)89/895578-780
http://www.medizinische-genetik.de

Status 'OK FAIL Missing part' in amadmin find

[Marc Muehlfeld]

Hi,

what does status OK FAIL Missing part in amadmin find mean?

2010-10-21 21:00:02 nucleus.mr.lfmg.de / 1 KDD136  7 1/28 OK FAIL 
Missing part

2010-10-22 21:00:01 nucleus.mr.lfmg.de / 0 KDD139 54  1/1 OK
2010-10-23 21:00:01 nucleus.mr.lfmg.de / 1 KDD148 13 1/29 OK FAIL 
Missing part
2010-10-25 21:00:01 nucleus.mr.lfmg.de / 2 KDD152 27 1/28 OK FAIL 
Missing part
2010-10-26 21:00:01 nucleus.mr.lfmg.de / 0 KDD161 20 1/29 OK FAIL 
Missing part
2010-10-27 21:00:01 nucleus.mr.lfmg.de / 1 KDD167 21 1/16 OK FAIL 
Missing part
2010-10-28 21:00:02 nucleus.mr.lfmg.de / 2 KDD174  8 1/29 OK FAIL 
Missing part
2010-10-29 21:00:02 nucleus.mr.lfmg.de / 3 KDD178 16 1/28 OK FAIL 
Missing part
2010-10-30 21:00:01 nucleus.mr.lfmg.de / 3 KDD020 18 1/29 OK FAIL 
Missing part
2010-11-01 21:00:01 nucleus.mr.lfmg.de / 3 KDD024 27 1/28 OK FAIL 
Missing part



Most of my DLEs are in that status. But the report mails never showed problems.

Regards,
Marc

Re: Status 'OK FAIL Missing part' in amadmin find

[Jean-Louis Martineau]

Always report which amanda version you are using.

Send me the log.datestamp.? for the KDD152 volume.

Marc Muehlfeld wrote:

Hi,

what does status OK FAIL Missing part in amadmin find mean?

2010-10-21 21:00:02 nucleus.mr.lfmg.de / 1 KDD136  7 1/28 
OK FAIL Missing part

2010-10-22 21:00:01 nucleus.mr.lfmg.de / 0 KDD139 54  1/1 OK
2010-10-23 21:00:01 nucleus.mr.lfmg.de / 1 KDD148 13 1/29 
OK FAIL Missing part
2010-10-25 21:00:01 nucleus.mr.lfmg.de / 2 KDD152 27 1/28 
OK FAIL Missing part
2010-10-26 21:00:01 nucleus.mr.lfmg.de / 0 KDD161 20 1/29 
OK FAIL Missing part
2010-10-27 21:00:01 nucleus.mr.lfmg.de / 1 KDD167 21 1/16 
OK FAIL Missing part
2010-10-28 21:00:02 nucleus.mr.lfmg.de / 2 KDD174  8 1/29 
OK FAIL Missing part
2010-10-29 21:00:02 nucleus.mr.lfmg.de / 3 KDD178 16 1/28 
OK FAIL Missing part
2010-10-30 21:00:01 nucleus.mr.lfmg.de / 3 KDD020 18 1/29 
OK FAIL Missing part
2010-11-01 21:00:01 nucleus.mr.lfmg.de / 3 KDD024 27 1/28 
OK FAIL Missing part



Most of my DLEs are in that status. But the report mails never showed 
problems.


Regards,
Marc

Re: Status 'OK FAIL Missing part' in amadmin find

[Jean-Louis Martineau]

Marc Muehlfeld wrote:

Send me the log.datestamp.? for the KDD152 volume.


There's no log.* logfile. I attached the only one that contains KDD152 
from that day. If you need a different one, just tell me which.

log.* files are in `amgetconf CONF logdir`

Jean-Louis

Tape headers mysteriously missing

[Onotsky, Steve x55328]

Hi all,

 

We're running Amanda 2.6.0p2 on a 64-bit RHEL 5 machine (code compiled
on the same host) against a Dell PowerVault ML6020 library (LTO4 drives)
and have been for well over a year.

 

Every once in a while, we'll get a backup report where A TAPE ERROR
OCCURRED: [Could not find a tape to use], even though the next expected
tape is in the library, and other tapes further down in the tapelist are
also available.  But that's not the part that really concerns me.

 

When I load the expected tape and attempt to read the tape header, there
*is* no header on the tape.  In today's instance of the problem, I know
that I've backed up to the tape at least twice before (I have the backup
reports to prove it).  To the best of my knowledge, the tape in question
has never been dropped, and can be written to after force-writing the
header back to the tape.

 

The reason I'm so concerned is, I can't get amrestore to list the tape's
contents after re-writing the header, so I won't be able to restore any
data from the tape (unless there's a trick to it that I'm not aware of).

 

Any thoughts on this or suggestions of things I should check/change?

 

Thanks in advance!

 

 

Steve Onotsky

Team Lead, Server Support

Broadridge

Investor Communication Solutions, Canada

5970 Chedworth Way

Mississauga  ON  L5R 4G5

Tel: (905) 507-5328

Fax: (905) 507-5312

 


This message and any attachments are intended only for the use of the addressee 
and
may contain information that is privileged and confidential. If the reader of 
the 
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

New machine fails, all e stimates missing.

[Gene Heskett]

Greetings;

I am trying to add a kubuntu-6.06 machine, on which I have installed via apt-
get, the amanda-client and related debs.  One dependency that apt-get didn't 
pull in was xinetd, but that's now installed and an amanda file added to 
/etc/xinetd.d.

Amcheck, done from this machine is happy, but when the backup runs, the 
runtar log file on that machine reports this:

---
runtar: debug 1 pid 12192 ruid 1001 euid 0: start at Wed Sep 30 10:17:57 2009
/bin/tar: version 2.4.5p1
runtar: error [must be invoked by amanda]

runtar: pid 12192 finish time Wed Sep 30 10:17:57 2009
--

Now, probably an attack of dumbass on my part, I couldn't figure out how 
amanda stuff was to be executed as having a backup:backup ownership, so I 
made it all, except for runtar, owned by amanda:disk, runtar is root:disk, 
has the suid things set, and the binary edited to replace the string 'backup' 
in it with the string 'amanda', same number of chars so I did it with vim.

I _think_ it is being run by amanda, here is that amanda file from the 
xinetd.d directory:
--
# default on
# description:  The amanda service
service amanda
{
only_from   = coyote.coyote.den
socket  = dgram
protocol= udp
wait= yes
user= amanda
group   = disk
groups  = yes
server  = /usr/lib/amanda/amandad
server_args =-auth=bsd amdump amindexd amidxtaped
disable = no
}

The amanda user has been added, and /etc/group made to match what has worked 
for many years on this machine, so it all should be running as amanda, who is 
a member of group disk.  And xinetd has been restarted several times.

What might I have missed?  Or should I edit the above file to put the 
user:group back to 'backup' and reinstall the amanda-client?

Or nuke the debs and build from a recent tarball?

FWIW, packaging system constraints are a PIMA. :)

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

If bankers can count, how come they have eight windows and only four tellers?

Missing file in 2.6.2alpha-20090711?

[Gene Heskett]

Greetings;

I just grabbed the last snapshot, and the build fails:

chown amanda:disk /DLT.ps
chown: cannot access `/DLT.ps': No such file or directory
make[5]: *** [installperms-data] Error 1
make[5]: Leaving directory `/home/amanda/amanda-2.6.2alpha-20090711/example'
make[4]: *** [install-data-am] Error 2
make[4]: Leaving directory `/home/amanda/amanda-2.6.2alpha-20090711/example'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory `/home/amanda/amanda-2.6.2alpha-20090711/example'
make[2]: *** [install] Error 2
make[2]: Leaving directory `/home/amanda/amanda-2.6.2alpha-20090711/example'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/amanda/amanda-2.6.2alpha-20090711'
make: *** [install] Error 2

However:

[r...@coyote amanda]# ls -lR *|grep DLT
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
-rw-r--r-- 1 amanda disk  5768 2008-03-10 13:07 DLT-A4.ps
-rw-r--r-- 1 amanda disk  5268 2008-03-10 13:07 DLT.ps
==

It seems we have plenty of those available. ???

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

I feel sorry for your brain... all alone in that great big head...

Re: Missing file in 2.6.2alpha-20090711?

[Dustin J. Mitchell]

On Sat, Jul 11, 2009 at 9:01 PM, Gene Heskettgene.hesk...@verizon.net wrote:
 I just grabbed the last snapshot, and the build fails:

Thanks!  Dumb typo on my part, a fix for which I just committed.

Dustin

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

Re: Missing file in 2.6.2alpha-20090711?

[Gene Heskett]

On Saturday 11 July 2009, Dustin J. Mitchell wrote:
On Sat, Jul 11, 2009 at 9:01 PM, Gene Heskettgene.hesk...@verizon.net 
wrote:
 I just grabbed the last snapshot, and the build fails:

Thanks!  Dumb typo on my part, a fix for which I just committed.

Dustin

I figured that, needs a . I bet. :)

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

Never reveal your best argument.

missing index

[A.M.A.N.D.A. Materials]

Hi,
need to recover a storage volume and the amanda index is missing.  
There seems to be lots of data on the tape for the volume.


Is it possible to build an amanda index from the tape? I used tar for  
the backup.


I've got a file listing of whats on the tape by doing:

amrestore -f12 -p /dev/st0 brokenserver /media/disk |  tar tvf -
list.tar


Can I use the listing as the index or is there a neat amanda command  
to build the index properly?


Thanks

Happy Amanda User

Re: missing index

[Dustin J. Mitchell]

On Tue, May 20, 2008 at 9:42 AM, A.M.A.N.D.A. Materials
[EMAIL PROTECTED] wrote:
 amrestore -f12 -p /dev/st0 brokenserver /media/disk |  tar tvf -   list.tar

 Can I use the listing as the index or is there a neat amanda command to
 build the index properly?

You can use that file listing as an index, as thats exactly how Amanda
builds the index.

There's currently no neat amanda command to do this, although it is
planned as part of the Application API (the reindex operation).

Dustin

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

Re: missing index

[A.M.A.N.D.A. Materials]

Ah!  thanks yes pulling 600Gb off the tape now :) I love amanda!  
Fantastic system built like a proper unix bit of kit. Text to the  
last :)


thanks. I'll write a little script to rebuild indexes. I thought the  
relative path wasn't good enough and date/time stamps were required  
but not so.


thanks asked question too soon before playing with the other amanda  
indexes :)



On 20 May 2008, at 17:06, Dustin J. Mitchell wrote:


On Tue, May 20, 2008 at 9:42 AM, A.M.A.N.D.A. Materials
[EMAIL PROTECTED] wrote:
amrestore -f12 -p /dev/st0 brokenserver /media/disk |  tar tvf -
list.tar


Can I use the listing as the index or is there a neat amanda  
command to

build the index properly?


You can use that file listing as an index, as thats exactly how Amanda
builds the index.

There's currently no neat amanda command to do this, although it is
planned as part of the Application API (the reindex operation).

Dustin

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

Re: more of the dreaded 'missing size line from sendbackup'

[Jean-Francois Malouin]

* O'Brien MJ [EMAIL PROTECTED] [20080118 11:01]:
 Hi Jean
 
 As I mentioned in a previous mail this week, my problems miraculously
 disappeared when I upgrade the client to 2.5.2p1, still touching wood
 about that...

Both server and client are at 2.5.2p1

Now that I investigated a little more I found out that the client
issued a few warnings in its syslog right at the time sendbackup

Jan 17 12:15:42 6A:yorick unix: NFS server: reply error 11
Jan 17 12:15:46 4A:yorick unix: WARNING: NFSTCP: service send error 11 on socket

error 11 in sys/errno.h is 

#define EAGAIN  11  /* Resource temporarily unavailable */

Dunno which one is the chicken or the egg though or maybe
both (amanda and syslog warnings) are just the effects of
a deeper problem. 

Thanks
jf

 
 I'd believed the problem was relate to 
 
 From the sendsize debug log:
 
 sendsize[1907]: time 24.758: child 1911 terminated with signal 4
 
 Which I'd seen mentioned somewhere as a linux kernel process signal
 handling change, hacked all binary outcome checks to include and convert
 the signal '4' to something sensible in sendmail and sendbackup source
 code. recompiled but to no avail. Then the upgrade cornered the goose :)
 
 I still think that signal 4 is/was guilty.
 
 Cheers
 
 Marc O'Brien
 
 - Original Message -
 From: Jean-Francois Malouin [EMAIL PROTECTED]
 Date: Thursday, January 17, 2008 7:41 pm
 Subject: more of the dreaded 'missing size line from sendbackup'
 To: AMANDA users amanda-users@amanda.org
 
  Hello again,
  
  Yet another case of the driver reporting 'missing size line from
  sendbackup' just before the DLE (~1TB) was entirely in the holddisk...
  
  Here's what the server (2.5.2p1) logs show: 
  
  log:
  
  FAIL dumper yorick /data/nih/nih1 20080116 0 [missing size line 
  from sendbackup]
   sendbackup: start [yorick:/data/nih/nih1 level 0]
   sendbackup: info BACKUP=/usr/freeware/bin/tar
   sendbackup: info RECOVER_CMD=/usr/freeware/bin/tar -xpGf - ...
   sendbackup: info end
   ? dumper: strange [missing size line from sendbackup]
  PARTIAL chunker yorick /data/nih/nih1 20080116 0 [sec 49050.184 kb 
  933151530 kps 19024.4]
  
  amdump:
  
  driver: state time 50745.505 free kps: 1003626 space: 979020896 
  taper: idle idle-dumpers: 11 qlen tapeq: 0 run q: 0 roomq: 0 
  wakeup: 0 driver-idle: no-dumpers
  driver: interface-state time 50745.505 if default: free 1002226 if 
  local: free 1000 if le0: free 400
  driver: hdisk-state time 50745.505 hdisk 0: free 979020896 dumpers 1
  driver: result time 50745.522 from dumper1: FAILED 01-2 
  [missing size line from sendbackup]
  driver: send-cmd time 50745.522 to chunker1: FAILED 01-2
  driver: state time 50745.522 free kps: 1003626 space: 979020896 
  taper: idle idle-dumpers: 11 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 
  0 driver-idle: no-dumpers
  driver: interface-state time 50745.522 if default: free 1002226 if 
  local: free 1000 if le0: free 400
  driver: hdisk-state time 50745.522 hdisk 0: free 979020896 dumpers 1
  driver: result time 50745.522 from chunker1: PARTIAL 01-2 
  933151530 [sec 49050.184 kb 933151530 kps 19024.4]
  driver: finished-cmd time 50745.522 chunker1 chunked 
  yorick:/data/nih/nih1
  On the client (2.5.2p1), the amandad/sendbackup/runtar debug files:
  
  amandad.20080116223817.debug:
  
  amandad: time 49049.651: security_stream_seterr(1003ca70, write 
  error to :
  Resource temporarily unavailable)
  amandad: time 49049.663: sending NAK pkt:
  
  ERROR write error on stream 49: write error to : Resource 
  temporarilyunavailable
  
  
  sendbackup.20080116223817.debug:
  
  sendbackup-gnutar: time 724.655: /opt/amanda/av24-2/libexec/runtar: 
  pid 7955181
  sendbackup: time 724.656: started backup
  sendbackup: time 49049.606: index tee cannot write [Broken pipe]
  sendbackup: time 49049.616: pid 7963340 finish time Thu Jan 17 
  12:15:46 2008
  
  
  runtar.20080116225021.debug:
  
  runtar: debug 1 pid 7955181 ruid 666 euid 0: start at Wed Jan 16 
  22:50:21 2008
  runtar: time 0.001: version 2.5.2p1
  /usr/freeware/bin/tar version: tar (GNU tar) 1.13.25
  
  config: left2
  runtar: debug 1 pid 7955181 ruid 0 euid 0: rename at Wed Jan 16 
  22:50:21 2008
  running: /usr/freeware/bin/tar: 'gtar' '--create' '--file' '-' '--
  directory''/data/nih/nih1' '--one-file-system' '--listed-incremental'
  '/opt/amanda-av24-2/var/amanda/left2/gnutar-
  lists/yorick_data_nih_nih1_0.new''--sparse' '--ignore-failed-read' 
  '--totals' '.' 
  runtar: time 0.017: pid 7955181 finish time Wed Jan 16 22:50:21 2008
  
  
  Looks like another goose chase to me...
  Any ideas on how to debug and track this issue?
  
  regards,
  jf
  -- 
  ° 
  

-- 
° 

Re: more of the dreaded 'missing size line from sendbackup'

[O'Brien MJ]

Hi Jean

As I mentioned in a previous mail this week, my problems miraculously
disappeared when I upgrade the client to 2.5.2p1, still touching wood
about that...

I'd believed the problem was relate to 

From the sendsize debug log:

sendsize[1907]: time 24.758: child 1911 terminated with signal 4

Which I'd seen mentioned somewhere as a linux kernel process signal
handling change, hacked all binary outcome checks to include and convert
the signal '4' to something sensible in sendmail and sendbackup source
code. recompiled but to no avail. Then the upgrade cornered the goose :)

I still think that signal 4 is/was guilty.

Cheers

Marc O'Brien

- Original Message -
From: Jean-Francois Malouin [EMAIL PROTECTED]
Date: Thursday, January 17, 2008 7:41 pm
Subject: more of the dreaded 'missing size line from sendbackup'
To: AMANDA users amanda-users@amanda.org

 Hello again,
 
 Yet another case of the driver reporting 'missing size line from
 sendbackup' just before the DLE (~1TB) was entirely in the holddisk...
 
 Here's what the server (2.5.2p1) logs show: 
 
 log:
 
 FAIL dumper yorick /data/nih/nih1 20080116 0 [missing size line 
 from sendbackup]
  sendbackup: start [yorick:/data/nih/nih1 level 0]
  sendbackup: info BACKUP=/usr/freeware/bin/tar
  sendbackup: info RECOVER_CMD=/usr/freeware/bin/tar -xpGf - ...
  sendbackup: info end
  ? dumper: strange [missing size line from sendbackup]
 PARTIAL chunker yorick /data/nih/nih1 20080116 0 [sec 49050.184 kb 
 933151530 kps 19024.4]
 
 amdump:
 
 driver: state time 50745.505 free kps: 1003626 space: 979020896 
 taper: idle idle-dumpers: 11 qlen tapeq: 0 run q: 0 roomq: 0 
 wakeup: 0 driver-idle: no-dumpers
 driver: interface-state time 50745.505 if default: free 1002226 if 
 local: free 1000 if le0: free 400
 driver: hdisk-state time 50745.505 hdisk 0: free 979020896 dumpers 1
 driver: result time 50745.522 from dumper1: FAILED 01-2 
 [missing size line from sendbackup]
 driver: send-cmd time 50745.522 to chunker1: FAILED 01-2
 driver: state time 50745.522 free kps: 1003626 space: 979020896 
 taper: idle idle-dumpers: 11 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 
 0 driver-idle: no-dumpers
 driver: interface-state time 50745.522 if default: free 1002226 if 
 local: free 1000 if le0: free 400
 driver: hdisk-state time 50745.522 hdisk 0: free 979020896 dumpers 1
 driver: result time 50745.522 from chunker1: PARTIAL 01-2 
 933151530 [sec 49050.184 kb 933151530 kps 19024.4]
 driver: finished-cmd time 50745.522 chunker1 chunked 
 yorick:/data/nih/nih1
 On the client (2.5.2p1), the amandad/sendbackup/runtar debug files:
 
 amandad.20080116223817.debug:
 
 amandad: time 49049.651: security_stream_seterr(1003ca70, write 
 error to :
 Resource temporarily unavailable)
 amandad: time 49049.663: sending NAK pkt:
 
 ERROR write error on stream 49: write error to : Resource 
 temporarilyunavailable
 
 
 sendbackup.20080116223817.debug:
 
 sendbackup-gnutar: time 724.655: /opt/amanda/av24-2/libexec/runtar: 
 pid 7955181
 sendbackup: time 724.656: started backup
 sendbackup: time 49049.606: index tee cannot write [Broken pipe]
 sendbackup: time 49049.616: pid 7963340 finish time Thu Jan 17 
 12:15:46 2008
 
 
 runtar.20080116225021.debug:
 
 runtar: debug 1 pid 7955181 ruid 666 euid 0: start at Wed Jan 16 
 22:50:21 2008
 runtar: time 0.001: version 2.5.2p1
 /usr/freeware/bin/tar version: tar (GNU tar) 1.13.25
 
 config: left2
 runtar: debug 1 pid 7955181 ruid 0 euid 0: rename at Wed Jan 16 
 22:50:21 2008
 running: /usr/freeware/bin/tar: 'gtar' '--create' '--file' '-' '--
 directory''/data/nih/nih1' '--one-file-system' '--listed-incremental'
 '/opt/amanda-av24-2/var/amanda/left2/gnutar-
 lists/yorick_data_nih_nih1_0.new''--sparse' '--ignore-failed-read' 
 '--totals' '.' 
 runtar: time 0.017: pid 7955181 finish time Wed Jan 16 22:50:21 2008
 
 
 Looks like another goose chase to me...
 Any ideas on how to debug and track this issue?
 
 regards,
 jf
 -- 
 ° 
 

more of the dreaded 'missing size line from sendbackup'

[Jean-Francois Malouin]

Hello again,

Yet another case of the driver reporting 'missing size line from
sendbackup' just before the DLE (~1TB) was entirely in the holddisk...

Here's what the server (2.5.2p1) logs show: 

log:

FAIL dumper yorick /data/nih/nih1 20080116 0 [missing size line from sendbackup]
  sendbackup: start [yorick:/data/nih/nih1 level 0]
  sendbackup: info BACKUP=/usr/freeware/bin/tar
  sendbackup: info RECOVER_CMD=/usr/freeware/bin/tar -xpGf - ...
  sendbackup: info end
  ? dumper: strange [missing size line from sendbackup]
PARTIAL chunker yorick /data/nih/nih1 20080116 0 [sec 49050.184 kb 933151530 
kps 19024.4]

amdump:

driver: state time 50745.505 free kps: 1003626 space: 979020896 taper: idle 
idle-dumpers: 11 qlen tapeq: 0 run q: 0 roomq: 0 wakeup: 0 driver-idle: 
no-dumpers
driver: interface-state time 50745.505 if default: free 1002226 if local: free 
1000 if le0: free 400
driver: hdisk-state time 50745.505 hdisk 0: free 979020896 dumpers 1
driver: result time 50745.522 from dumper1: FAILED 01-2 [missing size line 
from sendbackup]
driver: send-cmd time 50745.522 to chunker1: FAILED 01-2
driver: state time 50745.522 free kps: 1003626 space: 979020896 
taper: idle idle-dumpers: 11 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 0 
driver-idle: no-dumpers
driver: interface-state time 50745.522 if default: free 1002226 if local: free 
1000 if le0: free 400
driver: hdisk-state time 50745.522 hdisk 0: free 979020896 dumpers 1
driver: result time 50745.522 from chunker1: PARTIAL 01-2 933151530 [sec 
49050.184 kb 933151530 kps 19024.4]
driver: finished-cmd time 50745.522 chunker1 chunked yorick:/data/nih/nih1

On the client (2.5.2p1), the amandad/sendbackup/runtar debug files:

amandad.20080116223817.debug:

amandad: time 49049.651: security_stream_seterr(1003ca70, write error to :
Resource temporarily unavailable)
amandad: time 49049.663: sending NAK pkt:

ERROR write error on stream 49: write error to : Resource temporarily
unavailable


sendbackup.20080116223817.debug:

sendbackup-gnutar: time 724.655: /opt/amanda/av24-2/libexec/runtar: pid 7955181
sendbackup: time 724.656: started backup
sendbackup: time 49049.606: index tee cannot write [Broken pipe]
sendbackup: time 49049.616: pid 7963340 finish time Thu Jan 17 12:15:46 2008


runtar.20080116225021.debug:

runtar: debug 1 pid 7955181 ruid 666 euid 0: start at Wed Jan 16 22:50:21 2008
runtar: time 0.001: version 2.5.2p1
/usr/freeware/bin/tar version: tar (GNU tar) 1.13.25

config: left2
runtar: debug 1 pid 7955181 ruid 0 euid 0: rename at Wed Jan 16 22:50:21 2008
running: /usr/freeware/bin/tar: 'gtar' '--create' '--file' '-' '--directory'
'/data/nih/nih1' '--one-file-system' '--listed-incremental'
'/opt/amanda-av24-2/var/amanda/left2/gnutar-lists/yorick_data_nih_nih1_0.new'
'--sparse' '--ignore-failed-read' '--totals' '.' 
runtar: time 0.017: pid 7955181 finish time Wed Jan 16 22:50:21 2008


Looks like another goose chase to me...
Any ideas on how to debug and track this issue?

regards,
jf
-- 
° 

Re: missing size line from sendbackup and PARTIAL

[Paul Bijnens]

Sorry, for replying late -- very very busy here...
See below

On 2008-01-10 16:54, Jean-Francois Malouin wrote:

* Paul Bijnens [EMAIL PROTECTED] [20080110 04:40]:

On 2008-01-09 22:55, Jean-Francois Malouin wrote:

Hi,

Amanda-2.5.2p1 on both the server (Debian/Etch) and client (irix-6.5.x).

In a amreport this morning I got a DLE with:

FAILURE AND STRANGE DUMP SUMMARY:
 yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]
 yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]


The backup program (gnutar for this DLE) normally should have ended with
a last line indicating the total size of the backup.  However, Amanda did
not find that line.

But because that does not mean that you want be able to do at least 
something

with the partial backup, Amanda did not discard the whole backup image.
(Also because, when e.g. dumping to tape, Amanda will not rewind and 
overwrite

an invalid backup image -- too difficult and maybe some intelligent human
can still do something with the partial backup.)

But Amanda still marks it FAILED, and will try next time to make a decent
backup.

[...]

Need to find out why it broke off.
Look on the client in the sendbackup.DATETIME.debug file


Here they come, attached, for the initial run and the retry.
What is puzzling me is that the entire image must have first
been dumped on the holding disk on the server, then taped.
Is it possible that I have hit some timeout. 
amanda.conf on the server has the following timeouts:

ctimeout 360
dtimeout 12960
etimeout 12960

Notice that the first sendbackup on the client failed after 37676s
while the retry did only after 5397s...


The log files show:


sendbackup: time 223.775: started backup
sendbackup: time 37676.088: index tee cannot write [Broken pipe]

...

sendbackup: time 86.306: started backup
sendbackup: time 5397.634: index tee cannot write [Broken pipe]


Maybe this is the same problem as described here:

http://wiki.zmanda.com/index.php/Mesg_read:_Connection_reset_by_peer

ALso have a look in the accompanying runtar.DATETIME.debug files
or see if you find any core files from around that time in the same
debug directory.

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

Re: missing size line from sendbackup and PARTIAL

[O'Brien MJ]

Hi Paul

I fought with a similar problem for months when trying to get an amanda
client running on an unslung NSLU2 box (I already had one box up and
running). The infuriating thing was the dump appearing on the server
spool area then being deleted when the size line wasn't found.

Server and client were 2.5.0p2 (settled on after the struggle to setup
the first NSLU2 box).

Finally in desperation altered the client to 2.5.2pl which then worked
with client using it's native dump but not gnu tar!

Still no idea why it didn't or why it now appears to (trying not to
tempt fate here).

Good luck

Marc O'Brien

- Original Message -
From: Paul Bijnens [EMAIL PROTECTED]
Date: Monday, January 14, 2008 3:22 pm
Subject: Re: missing size line from sendbackup and PARTIAL
To: Jean-Francois Malouin [EMAIL PROTECTED]
Cc: Amanda List amanda-users@amanda.org

 
 Sorry, for replying late -- very very busy here...
 See below
 
 On 2008-01-10 16:54, Jean-Francois Malouin wrote:
  * Paul Bijnens [EMAIL PROTECTED] [20080110 04:40]:
  On 2008-01-09 22:55, Jean-Francois Malouin wrote:
  Hi,
 
  Amanda-2.5.2p1 on both the server (Debian/Etch) and client 
 (irix-6.5.x).
 
  In a amreport this morning I got a DLE with:
 
  FAILURE AND STRANGE DUMP SUMMARY:
   yorick  /data/nih/nih1  lev 0  FAILED [missing size line from 
 sendbackup]  yorick  /data/nih/nih1  lev 0  FAILED [missing size 
 line from sendbackup]
 
  The backup program (gnutar for this DLE) normally should have 
 ended with
  a last line indicating the total size of the backup.  However, 
 Amanda did
  not find that line.
 
  But because that does not mean that you want be able to do at 
 least 
  something
  with the partial backup, Amanda did not discard the whole backup 
 image. (Also because, when e.g. dumping to tape, Amanda will not 
 rewind and 
  overwrite
  an invalid backup image -- too difficult and maybe some 
 intelligent human
  can still do something with the partial backup.)
 
  But Amanda still marks it FAILED, and will try next time to 
 make a decent
  backup.
 [...]
  Need to find out why it broke off.
  Look on the client in the sendbackup.DATETIME.debug file
  
  Here they come, attached, for the initial run and the retry.
  What is puzzling me is that the entire image must have first
  been dumped on the holding disk on the server, then taped.
  Is it possible that I have hit some timeout. 
  amanda.conf on the server has the following timeouts:
  ctimeout 360
  dtimeout 12960
  etimeout 12960
  
  Notice that the first sendbackup on the client failed after 37676s
  while the retry did only after 5397s...
 
 The log files show:
 
  sendbackup: time 223.775: started backup
  sendbackup: time 37676.088: index tee cannot write [Broken pipe]
 ...
  sendbackup: time 86.306: started backup
  sendbackup: time 5397.634: index tee cannot write [Broken pipe]
 
 Maybe this is the same problem as described here:
 
 http://wiki.zmanda.com/index.php/Mesg_read:_Connection_reset_by_peer
 
 ALso have a look in the accompanying runtar.DATETIME.debug files
 or see if you find any core files from around that time in the same
 debug directory.
 
 -- 
 Paul Bijnens, xplanation Technology ServicesTel  +32 16 
 397.511Technologielaan 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
  *
 ***
 

Re: missing size line from sendbackup and PARTIAL

[Jean-Francois Malouin]

* Paul Bijnens [EMAIL PROTECTED] [20080114 10:17]:
 
 Sorry, for replying late -- very very busy here...

Same here!

 See below
 
 On 2008-01-10 16:54, Jean-Francois Malouin wrote:
 * Paul Bijnens [EMAIL PROTECTED] [20080110 04:40]:
 On 2008-01-09 22:55, Jean-Francois Malouin wrote:
 Hi,
 
 Amanda-2.5.2p1 on both the server (Debian/Etch) and client (irix-6.5.x).
 
 In a amreport this morning I got a DLE with:
 
 FAILURE AND STRANGE DUMP SUMMARY:
  yorick  /data/nih/nih1  lev 0  FAILED [missing size line from 
  sendbackup]
  yorick  /data/nih/nih1  lev 0  FAILED [missing size line from 
  sendbackup]
 

[...%...]

 
 The log files show:
 
 sendbackup: time 223.775: started backup
 sendbackup: time 37676.088: index tee cannot write [Broken pipe]
 ...
 sendbackup: time 86.306: started backup
 sendbackup: time 5397.634: index tee cannot write [Broken pipe]
 
 Maybe this is the same problem as described here:
 
 http://wiki.zmanda.com/index.php/Mesg_read:_Connection_reset_by_peer

Hmmm, there is no firewall involved between the server and client.

 
 ALso have a look in the accompanying runtar.DATETIME.debug files
 or see if you find any core files from around that time in the same
 debug directory.

sadly they have been reaped (they live in /tmp) but I remember
checking the debug runtar files...

The day after amanda did a full dump of this DLE
and I verified it and it looks good.

I'll keep a eye on it though!

Thanks for you time,
jf

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

-- 
° 

Re: missing size line from sendbackup and PARTIAL

[Paul Bijnens]

On 2008-01-09 22:55, Jean-Francois Malouin wrote:

Hi,

Amanda-2.5.2p1 on both the server (Debian/Etch) and client (irix-6.5.x).

In a amreport this morning I got a DLE with:

FAILURE AND STRANGE DUMP SUMMARY:
  yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]
  yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]



The backup program (gnutar for this DLE) normally should have ended with
a last line indicating the total size of the backup.  However, Amanda did
not find that line.

But because that does not mean that you want be able to do at least something
with the partial backup, Amanda did not discard the whole backup image.
(Also because, when e.g. dumping to tape, Amanda will not rewind and overwrite
an invalid backup image -- too difficult and maybe some intelligent human
can still do something with the partial backup.)

But Amanda still marks it FAILED, and will try next time to make a decent
backup.





DUMP SUMMARY: 
  DUMPER STATS TAPER STATS

HOSTNAME DISK   L ORIG-MB  OUT-MB  COMP%  MMM:SSKB/s MMM:SS KB/s
- 
yorick   /data/nih/nih1 0 N/A   84080-- N/A N/A 22:33 63615.7
+PARTIAL

Checking what 'adadmin info' tells me for it:

amadmin left2 info yorick /data/nih/nih1

Current info for yorick /data/nih/nih1:
  Stats: dump rates (kps), Full:  21651.2, 23245.9, 22401.7
Incremental:   80.9,  97.4, 157.8
  compressed size, Full: -100.0%,-100.0%,-100.0%
Incremental: -100.0%,-100.0%,-100.0%
  Dumps: lev datestmp  tape file   origK   compK secs
  0  20080102  av24-2_left2_U00041L3  34 973979040 973979040 44985
  1  20080107  av24-2_left2_U00040L3  6 97850 97850 1209


Note the date of the level 0!  That is not the date of this morning.
The level 0 from this morning is not considered a valid level 0 by Amanda.




Seems good but trying to restore the image to disk with amfetchdump
fails with:

amfetchdump -p left2 yorick /data/nih/nih1 20080108 | tar -xpGf -


So you try to restore the one from this morning...


...
amfetchdump: 34: restoring split dumpfile: date 20080108 host yorick
disk /data/nih/nih1 part 17/17 lev 0 comp N program /usr/freeware/bin/tar 
amfetchdump: Search of av24-2_left2_U00041L3 complete


tar: Unexpected EOF in archive
tar: Unexpected EOF in archive


And, indeed, the backup image on this tape is a partial backup, that is
prematurely broken off.



tar: Error is not recoverable: exiting now


Any ideas?



Need to find out why it broke off.
Look on the client in the sendbackup.DATETIME.debug file


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

Re: missing size line from sendbackup and PARTIAL

[Jean-Francois Malouin]

* Paul Bijnens [EMAIL PROTECTED] [20080110 04:40]:
 On 2008-01-09 22:55, Jean-Francois Malouin wrote:
 Hi,
 
 Amanda-2.5.2p1 on both the server (Debian/Etch) and client (irix-6.5.x).
 
 In a amreport this morning I got a DLE with:
 
 FAILURE AND STRANGE DUMP SUMMARY:
   yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]
   yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]
 
 
 The backup program (gnutar for this DLE) normally should have ended with
 a last line indicating the total size of the backup.  However, Amanda did
 not find that line.
 
 But because that does not mean that you want be able to do at least 
 something
 with the partial backup, Amanda did not discard the whole backup image.
 (Also because, when e.g. dumping to tape, Amanda will not rewind and 
 overwrite
 an invalid backup image -- too difficult and maybe some intelligent human
 can still do something with the partial backup.)
 
 But Amanda still marks it FAILED, and will try next time to make a decent
 backup.

indeed, amstatus shows that a full is being done. 

 
 DUMP SUMMARY: 
   DUMPER STATS TAPER STATS
 HOSTNAME DISK   L ORIG-MB  OUT-MB  COMP%  MMM:SSKB/s MMM:SS 
 KB/s
 - 
 
 yorick   /data/nih/nih1 0 N/A   84080-- N/A N/A 22:33 
 63615.7
 +PARTIAL
 
 Checking what 'adadmin info' tells me for it:
 
 amadmin left2 info yorick /data/nih/nih1
 
 Current info for yorick /data/nih/nih1:
   Stats: dump rates (kps), Full:  21651.2, 23245.9, 22401.7
 Incremental:   80.9,  97.4, 157.8
   compressed size, Full: -100.0%,-100.0%,-100.0%
 Incremental: -100.0%,-100.0%,-100.0%
   Dumps: lev datestmp  tape file   origK   compK secs
   0  20080102  av24-2_left2_U00041L3  34 973979040 973979040 44985
   1  20080107  av24-2_left2_U00040L3  6 97850 97850 1209
 
 Note the date of the level 0!  That is not the date of this morning.
 The level 0 from this morning is not considered a valid level 0 by Amanda.

Ah! Good eye! I missed the date and also the fact that there was a
level 1 so indeed the last tried ('partial') full backup was not
considered valid.

 
 Seems good but trying to restore the image to disk with amfetchdump
 fails with:
 
 amfetchdump -p left2 yorick /data/nih/nih1 20080108 | tar -xpGf -
 
 So you try to restore the one from this morning...
 
 
 Need to find out why it broke off.
 Look on the client in the sendbackup.DATETIME.debug file

Here they come, attached, for the initial run and the retry.
What is puzzling me is that the entire image must have first
been dumped on the holding disk on the server, then taped.
Is it possible that I have hit some timeout. 
amanda.conf on the server has the following timeouts:
ctimeout 360
dtimeout 12960
etimeout 12960

Notice that the first sendbackup on the client failed after 37676s
while the retry did only after 5397s...

thanks for the time,
jf

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

-- 
° 
sendbackup: debug 1 pid 3694238 ruid 666 euid 666: start at Tue Jan  8 23:11:36 
2008
sendbackup: version 2.5.2p1
Could not open conf file /opt/amanda/av24-2/etc/amanda/amanda-client.conf: No 
such file or directory
Reading conf file /opt/amanda/av24-2/etc/amanda/left2/amanda-client.conf.
sendbackup: debug 1 pid 3694238 ruid 666 euid 666: rename at Tue Jan  8 
23:11:36 2008
  sendbackup req: GNUTAR /data/nih/nih1  0 1970:1:1:0:0:0 OPTIONS 
|;auth=bsdtcp;index;
  parsed request as: program `GNUTAR'
 disk `/data/nih/nih1'
 device `/data/nih/nih1'
 level 0
 since 1970:1:1:0:0:0
 options `|;auth=bsdtcp;index;'
sendbackup: start: yorick:/data/nih/nih1 lev 0
sendbackup-gnutar: time 0.058: doing level 0 dump as listed-incremental to 
'/opt/amanda-av24-2/var/amanda/left2/gnutar-lists/yorick_data_nih_nih1_0.new'
sendbackup-gnutar: time 223.333: doing level 0 dump from date: 1970-01-01  
0:00:00 GMT
sendbackup: time 223.769: spawning /opt/amanda/av24-2/libexec/runtar in pipeline

missing size line from sendbackup and PARTIAL

[Jean-Francois Malouin]

Hi,

Amanda-2.5.2p1 on both the server (Debian/Etch) and client (irix-6.5.x).

In a amreport this morning I got a DLE with:

FAILURE AND STRANGE DUMP SUMMARY:
  yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]
  yorick  /data/nih/nih1  lev 0  FAILED [missing size line from sendbackup]

DUMP SUMMARY: 
  DUMPER STATS TAPER STATS
HOSTNAME DISK   L ORIG-MB  OUT-MB  COMP%  MMM:SSKB/s MMM:SS KB/s
- 
yorick   /data/nih/nih1 0 N/A   84080-- N/A N/A 22:33 63615.7
+PARTIAL

Checking what 'adadmin info' tells me for it:

amadmin left2 info yorick /data/nih/nih1

Current info for yorick /data/nih/nih1:
  Stats: dump rates (kps), Full:  21651.2, 23245.9, 22401.7
Incremental:   80.9,  97.4, 157.8
  compressed size, Full: -100.0%,-100.0%,-100.0%
Incremental: -100.0%,-100.0%,-100.0%
  Dumps: lev datestmp  tape file   origK   compK secs
  0  20080102  av24-2_left2_U00041L3  34 973979040 973979040 44985
  1  20080107  av24-2_left2_U00040L3  6 97850 97850 1209

Seems good but trying to restore the image to disk with amfetchdump
fails with:

amfetchdump -p left2 yorick /data/nih/nih1 20080108 | tar -xpGf -
...
amfetchdump: 34: restoring split dumpfile: date 20080108 host yorick
disk /data/nih/nih1 part 17/17 lev 0 comp N program /usr/freeware/bin/tar 
amfetchdump: Search of av24-2_left2_U00041L3 complete

tar: Unexpected EOF in archive
tar: Unexpected EOF in archive

tar: Error is not recoverable: exiting now


Any ideas?
regards,
jf
-- 
° 

Re: A bit of a bug - or I'm missing something?

[Dustin J. Mitchell]

On 10/25/07, Lindsay Haisley [EMAIL PROTECTED] wrote:
 Well fstab is the only data structure on the box that relates /dev/sda1
 to /boot, which is what gets backed up willy-nilly.  It has to be
 referenced _somewhere_ in the process!

You're right -- Amanda does use fstab for that.  Sorry!

Dustin

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

Re: A bit of a bug - or I'm missing something?

[Lindsay Haisley]

On Wed, 2007-10-24 at 22:43 -0500, Dustin J. Mitchell wrote:
 On 10/24/07, Lindsay Haisley [EMAIL PROTECTED] wrote:
  I have a DLE in my disklist which specifies a dump of /dev/sda1 on a
  client box.  /dev/sda1 is the /boot partition and is generally not
  mounted unless I'm doing something such as installing a new kernel.
  What amandad on the client system is apparently doing is looking
  at /etc/fstab, which contains a noauto entry for /dev/sda1 so that it
  can be mounted easily, and then backing up /boot which is the mountpoint
  for /dev/sda1.  /boot contains only a couple of placeholder files of no
  consequence.
 
 amandad's not looking at fstab, AFAIK,

Well fstab is the only data structure on the box that relates /dev/sda1
to /boot, which is what gets backed up willy-nilly.  It has to be
referenced _somewhere_ in the process!

  and certainly isn't going to
 mount anything.  If you want to do this, you should either use DUMP
 for that partition, or just mount it (read-only, if you'd like) so
 Amanda can back it up.

Pre-mounting is probably the way to go here.

   If you're feeling really excited to spend some
 time, you could write a gtar wrapper that mounts the fs for the
 duration of the backup, then unmounts it..

Been there, done that (for other problems).  I think I'll let this one
pass grin.

Thanks.

-- 
Lindsay Haisley   | In an open world,| PGP public key
FMP Computer Services |who needs Windows  |  available at
512-259-1190  |  or Gates| http://pubkeys.fmp.com
http://www.fmp.com|   |

A bit of a bug - or I'm missing something?

[Lindsay Haisley]

I have a DLE in my disklist which specifies a dump of /dev/sda1 on a
client box.  /dev/sda1 is the /boot partition and is generally not
mounted unless I'm doing something such as installing a new kernel.
What amandad on the client system is apparently doing is looking
at /etc/fstab, which contains a noauto entry for /dev/sda1 so that it
can be mounted easily, and then backing up /boot which is the mountpoint
for /dev/sda1.  /boot contains only a couple of placeholder files of no
consequence.

I thought that perhaps amandad on the client system was trying to
mount /dev/sda1 and failing, so I added the amanda user on the client
system to the disk group and added groups to the mounting options on
the client, and now the amanda user can mount /dev/sda1, but amdump
still backs up the bare directory if /dev/sda1 wasn't previously
mounted.

Maybe there's a setting I'm missing somewhere.  At least I can do a
backup of the system now, having switched to ssh authentication rather
than bsd.

-- 
Lindsay Haisley   | Everything works| PGP public key
FMP Computer Services |   if you let it |  available at
512-259-1190  |(The Roadie)  | http://pubkeys.fmp.com
http://www.fmp.com|  |

Re: A bit of a bug - or I'm missing something?

[Dustin J. Mitchell]

On 10/24/07, Lindsay Haisley [EMAIL PROTECTED] wrote:
 I have a DLE in my disklist which specifies a dump of /dev/sda1 on a
 client box.  /dev/sda1 is the /boot partition and is generally not
 mounted unless I'm doing something such as installing a new kernel.
 What amandad on the client system is apparently doing is looking
 at /etc/fstab, which contains a noauto entry for /dev/sda1 so that it
 can be mounted easily, and then backing up /boot which is the mountpoint
 for /dev/sda1.  /boot contains only a couple of placeholder files of no
 consequence.

amandad's not looking at fstab, AFAIK, and certainly isn't going to
mount anything.  If you want to do this, you should either use DUMP
for that partition, or just mount it (read-only, if you'd like) so
Amanda can back it up.  If you're feeling really excited to spend some
time, you could write a gtar wrapper that mounts the fs for the
duration of the backup, then unmounts it..

Dustin

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

amrecover complains about missing index

[Ingo Freund]

Hi,

when I try to run amrecover and call it like:

[EMAIL PROTECTED] $ amrecover -C DAILYSET -s tapehost -t tapehost -d /dev/nst0
the answer is:
501 Index directory /var/lib/amanda/DAILYSET/index does not exist
and then:
amrecover sethost HOST.LAN
it shows me:
501 Must set config before setting host.
Trying host HOST.LAN ...
501 Must set config before setting host.


1. Question
- where and how do I get the index-directory

2. Question
- how can I set the config which I thought I gave in the command
  line already.

Thx
-Ingo.

Re: amrecover complains about missing index

[Jean-Louis Martineau]

Why /var/lib/amanda/DAILYSET/index does not exist?

Do you generate index? What's the index setting on your dumptype?
What's the output of: amadmin DAILYSET disklist
Did it list 'index yes' for all DLE?

Jean-Louis

Ingo Freund wrote:

Hi,

when I try to run amrecover and call it like:

[EMAIL PROTECTED] $ amrecover -C DAILYSET -s tapehost -t tapehost -d /dev/nst0
the answer is:
501 Index directory /var/lib/amanda/DAILYSET/index does not exist
and then:
amrecover sethost HOST.LAN
it shows me:
501 Must set config before setting host.
Trying host HOST.LAN ...
501 Must set config before setting host.


1. Question
- where and how do I get the index-directory

2. Question
- how can I set the config which I thought I gave in the command
  line already.

Thx
-Ingo.
  

Re: amrecover complains about missing index

[Ingo Freund]

On 22.10.2007 17:17, Jean-Louis Martineau wrote (please find the answer below 
the original text):
 Why /var/lib/amanda/DAILYSET/index does not exist?
 
 Do you generate index? What's the index setting on your dumptype?
 What's the output of: amadmin DAILYSET disklist
 Did it list 'index yes' for all DLE?
 
 Jean-Louis
 
 Ingo Freund wrote:
 Hi,

 when I try to run amrecover and call it like:

 [EMAIL PROTECTED] $ amrecover -C DAILYSET -s tapehost -t tapehost -d 
 /dev/nst0
 the answer is:
 501 Index directory /var/lib/amanda/DAILYSET/index does not exist
 and then:
 amrecover sethost HOST.LAN
 it shows me:
 501 Must set config before setting host.
 Trying host HOST.LAN ...
 501 Must set config before setting host.


 1. Question
 - where and how do I get the index-directory

 2. Question
 - how can I set the config which I thought I gave in the command
   line already.


Well I have no idea, why the directory is not there. Doesn't amanda
create it by itself?
Every line of amadmin DAILYSET disklist shows index NO.
...and the included dumptype shows index no.

Bye - Ingo.

Re: amrecover complains about missing index

[Jean-Louis Martineau]

Index are needed for amrecover, you must enabled them.
Add 'index yes' to your dumptype.

amrecover will only works your newer dump.

Ingo Freund wrote:

On 22.10.2007 17:17, Jean-Louis Martineau wrote (please find the answer below 
the original text):
  

Why /var/lib/amanda/DAILYSET/index does not exist?

Do you generate index? What's the index setting on your dumptype?
What's the output of: amadmin DAILYSET disklist
Did it list 'index yes' for all DLE?

Jean-Louis

Ingo Freund wrote:


Hi,

when I try to run amrecover and call it like:

[EMAIL PROTECTED] $ amrecover -C DAILYSET -s tapehost -t tapehost -d /dev/nst0
the answer is:
501 Index directory /var/lib/amanda/DAILYSET/index does not exist
and then:
amrecover sethost HOST.LAN
it shows me:
501 Must set config before setting host.
Trying host HOST.LAN ...
501 Must set config before setting host.


1. Question
- where and how do I get the index-directory

2. Question
- how can I set the config which I thought I gave in the command
  line already.

  


Well I have no idea, why the directory is not there. Doesn't amanda
create it by itself?
Every line of amadmin DAILYSET disklist shows index NO.
...and the included dumptype shows index no.

Bye - Ingo.
  

Re: [amanda-2.5.2p1] Bug in chg-zd-mtx: prefix Missing

[Dustin J. Mitchell]

Thanks for reporting that!

There were actually two more changers with this bug -- I've attached
an updated patch, and will commit it shortly.

Dustin

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


chg-prefix.patch
Description: Binary data

[amanda-2.5.2p1] Bug in chg-zd-mtx: prefix Missing

[Svend Sorensen]

chg-zd-mtx is missing a line for the configured prefix.  It has a line
for @exec_prefix@, but if that wasn't specified during configure, it
defaults to @[EMAIL PROTECTED]  This results in the following block after
`make`.

   # source utility functions and values from configure
   exec_prefix=${prefix}
   libexecdir=${exec_prefix}/libexec
   . ${libexecdir}/chg-lib.sh

In this case, the script would look for chg-lib.sh in
/libexec/chg-lib.sh, which is incorrect.

Patch is attached.


amanda-2.5.2p1-chg-zd-mtx_prefix.diff
Description: Binary data

Re: [amanda-2.5.2p1] Bug in chg-zd-mtx: prefix Missing

[Paul Lussier]

Svend Sorensen [EMAIL PROTECTED] writes:

 chg-zd-mtx is missing a line for the configured prefix.  It has a line
 for @exec_prefix@, but if that wasn't specified during configure, it
 defaults to @[EMAIL PROTECTED]  This results in the following block after
 `make`.

Heh, I just ran across that this afternoon as well and was going to
submit the same patch :)

-- 
Thanks,
Paul

driver says [missing size line from sendbackup]

[Jean-Francois Malouin]

Hi,

Got a strange one: client is irix-6.5, server a Debian/Linux running a
64bit kernel both running amanda-2.5.2p1. I was testing my setup by
forcing a full with norecord and noindex from a big DLE on the client
(~1.7TB) and amdump failed with the subject line.

amdump log say:

taper: reader-side: got label av24-2_left2_U00012L3 filenum 104
driver: result time 66020.266 from dumper0: FAILED 00-1 [missing
size line from sendbackup]

Looking on the client debug files shows nothing except that sendbackup
was started yesterday evening. I was surprised that this actually
didn't timeout before as the server's amanda.conf has dtimeout=43200s
ie 12hrs and the failure occured after 66020sec...

any ideas?
jf

Re: missing result

[Gene Heskett]

On Saturday 24 March 2007, Joe Konecny wrote:
Gene Heskett wrote:
 snip
 I believe, and somebody correct me if I'm wrong, but ISTR that file
 needs to be touched by root, 'chown'ed to 'amanda:disk' or whatever
 your amanda user is named: and a member of that :group, then chmod'ed
 to 0600, so that 'amanda' is the only normal user with rights to that
 file.  I use amanda:disk here cause then I don't have to remember who
 the operator for amanda is.

I left it 644 and it seems ok.  Strange the whole amandates thing isn't
in the docs (except for the cygwin
part so you'd think it wouldn't apply) and it's not in the faq either.
Seems like it should be part of the
installation instructions.

If it was going to be mentioned, I'd think it would be in the manpage for 
amdump, but you are correct, its not in there.

In the src tree's docs dir, a grep shows it in 'amanda.client.conf.5.txt':
amanda-client.conf.5.txt:  amandates string
amanda-client.conf.5.txt:  Default: /etc/amandates. The file where 
amanda keep the last date of each
amanda-client.conf.5.txt-  dumplevel.

And in 'whatwasnew.txt':
-
Since Gnu TAR does not maintain a dumpdates file itself, nor give an 
estimate
of backup size, those need to be done within Amanda. Amanda maintains 
an /etc/
amandates file to track the backup dates analogously to how dump does it.
NOTE: if your /etc directory is not writable by your dumpuser, you'll have 
to
create the empty file initially by hand, and make it writable by your 
dumpuser
ala /etc/dumpdates.
NOTE: Since tar traverses the directory hierarchy and reads files as a 
regular
user would, it must run as root. The two new Amanda programs calcsize and
runtar therefore must be installed setuid root. I've made them as simple 
as
possible to to avoid potential security holes.
---
But that, it appears, does not make it into the manpages.

-- 
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)
Yevtushenko has... an ego that can crack crystal at a distance of twenty 
feet.
-- John Cheever

Re: missing result

[Jon LaBadie]

On Sat, Mar 24, 2007 at 12:01:16AM -0400, Joe Konecny wrote:
 
 I left it 644 and it seems ok.  Strange the whole amandates thing isn't 
 in the docs (except for the cygwin
 part so you'd think it wouldn't apply) and it's not in the faq either.  
 Seems like it should be part of the
 installation instructions.
 

There are two separate attempts to create the /etc/amandates file in
the source code client-src/amandates.c when access to the file is
first attempted.  So it typically would not be an installation item.
Perhaps cygwin is a special case where those creation attemps fail.

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

Re: missing result

[Gene Heskett]

On Saturday 24 March 2007, Jon LaBadie wrote:
On Sat, Mar 24, 2007 at 12:01:16AM -0400, Joe Konecny wrote:
 I left it 644 and it seems ok.  Strange the whole amandates thing
 isn't in the docs (except for the cygwin
 part so you'd think it wouldn't apply) and it's not in the faq either.
 Seems like it should be part of the
 installation instructions.

There are two separate attempts to create the /etc/amandates file in
the source code client-src/amandates.c when access to the file is
first attempted.  So it typically would not be an installation item.
Perhaps cygwin is a special case where those creation attemps fail.

ISTR it also failed here on this FC6 box and I had to touch it after 
installing amanda from the old installs /home/amanda tree, back in the 
middle of November 2006.  ISTR amanda didn't have perms to touch (create) 
a file in the /etc dir, so I had to do it as root, then chown and chmod 
it.  Then everybody was happy.  Which at the time may have been an 
selinux problem.  That's such a PITA its been disabled after the first 
week of its screwups like that.

-- 
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)
There are more old drunkards than old doctors.

Re: missing result

[Joe Konecny]

Gene Heskett wrote:
snip
Yes, start with howto-auth.txt in the tarballs doc directory to do it how 
I am, which probably isn't the ultimate model, but it works for me.


This looks like it was because the file /etc/amandates was missing.  Apparently
the install does not create it.  I found an error in the auth.log...

Mar 22 00:00:01 r4p17 sendsize[90503]: error [opening /etc/amandates: No such 
file or directory]

I don't know what /etc/amandates is for but my backups seem much happier with 
it.

Thanks for your help!

Re: missing result

[Gene Heskett]

On Friday 23 March 2007, Joe Konecny wrote:
Gene Heskett wrote:
snip

 Yes, start with howto-auth.txt in the tarballs doc directory to do it
 how I am, which probably isn't the ultimate model, but it works for
 me.

This looks like it was because the file /etc/amandates was missing. 
 Apparently the install does not create it.  I found an error in the
 auth.log...

Mar 22 00:00:01 r4p17 sendsize[90503]: error [opening /etc/amandates: No
 such file or directory]

I don't know what /etc/amandates is for but my backups seem much happier
 with it.

Thanks for your help!

I believe, and somebody correct me if I'm wrong, but ISTR that file needs 
to be touched by root, 'chown'ed to 'amanda:disk' or whatever your amanda 
user is named: and a member of that :group, then chmod'ed to 0600, so 
that 'amanda' is the only normal user with rights to that file.  I use 
amanda:disk here cause then I don't have to remember who the operator for 
amanda is.

It will then be maintained in an uptodate status from then on by the 
amdump supervisory utils.  Its general format will resemble this:
===
/GenesAmandaHelper-0.6 0 1174288560
/GenesAmandaHelper-0.6 1 1174453248
/GenesAmandaHelper-0.6 2 1174541095
/GenesAmandaHelper-0.6 3 1174625228
[snip another 100k of different pathlistings]
===
The number after the path is the level, and I'm not sure what the last 
number is, possibly a timestamp, but I've NDI what notation format that 
represents.  Swahili to this old fart.

-- 
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 bureaucracy is expanding to meet the needs of an expanding 
bureaucracy.

Re: missing result

[Frank Smith]

Gene Heskett wrote:
 snippage re /etc/amandates 
 ===
 /GenesAmandaHelper-0.6 0 1174288560
 /GenesAmandaHelper-0.6 1 1174453248
 /GenesAmandaHelper-0.6 2 1174541095
 /GenesAmandaHelper-0.6 3 1174625228
 [snip another 100k of different pathlistings]
 ===
 The number after the path is the level, and I'm not sure what the last 
 number is, possibly a timestamp, but I've NDI what notation format that 
 represents.  Swahili to this old fart.

The number is a timestamp in UNIX epoch time (seconds since 1-1-1970).
Your first number, 1174288560, is Mon Mar 19 07:16:00 2007 UTC

You can do the conversion with the Perl function localtime, , or a
C program using the system ctime function, or use one of the online
javascript converters like http://dan.drydog.com/unixdatetime.html

Frank

-- 
Frank Smith  [EMAIL PROTECTED]
Sr. Systems Administrator   Voice: 512-374-4673
Hoover's Online   Fax: 512-374-4501

Re: missing result

[Gene Heskett]

On Friday 23 March 2007, Frank Smith wrote:
Gene Heskett wrote:
 snippage re /etc/amandates 

 ===
 /GenesAmandaHelper-0.6 0 1174288560
 /GenesAmandaHelper-0.6 1 1174453248
 /GenesAmandaHelper-0.6 2 1174541095
 /GenesAmandaHelper-0.6 3 1174625228
 [snip another 100k of different pathlistings]
 ===
 The number after the path is the level, and I'm not sure what the last
 number is, possibly a timestamp, but I've NDI what notation format
 that represents.  Swahili to this old fart.

The number is a timestamp in UNIX epoch time (seconds since 1-1-1970).
Your first number, 1174288560, is Mon Mar 19 07:16:00 2007 UTC

You can do the conversion with the Perl function localtime, , or a
C program using the system ctime function, or use one of the online
javascript converters like http://dan.drydog.com/unixdatetime.html

Frank

Thanks, Frank.  I figured maybe it was Julian, but those numbers look way 
too old to be current.  Unix epoch time format never occurred to me.  But 
it makes perfect sense now.

-- 
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)
HAL 9000: Dave. Put down those Windows disks, Dave. DAVE! 

Re: missing result

[Joe Konecny]

Gene Heskett wrote:

snip
I believe, and somebody correct me if I'm wrong, but ISTR that file needs 
to be touched by root, 'chown'ed to 'amanda:disk' or whatever your amanda 
user is named: and a member of that :group, then chmod'ed to 0600, so 
that 'amanda' is the only normal user with rights to that file.  I use 
amanda:disk here cause then I don't have to remember who the operator for 
amanda is.


  


I left it 644 and it seems ok.  Strange the whole amandates thing isn't 
in the docs (except for the cygwin
part so you'd think it wouldn't apply) and it's not in the faq either.  
Seems like it should be part of the

installation instructions.

missing result

[Joe Konecny]

I upgraded from 2.4.5? to 2.5.1p3 and now have the following problem...
Can anyone provide any insight?

These dumps were to tape daily set1006.
The next tape Amanda expects to use is: DailySet1002.

FAILURE AND STRANGE DUMP SUMMARY:
  R4P17.rmtohio.com  amrd0s1f  lev 0  FAILED [missing result for amrd0s1f in 
R4P17.rmtohio.com response]


STATISTICS:
  Total   Full  Incr.
      
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00   0:00   0:00
Output Size (meg)   0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0  0  0
Avg Dump Rate (k/s) -- -- --

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

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

USAGE BY TAPE:
  Label  Time  Size  %NbNc
  DailySet1006   0:000k0.0 0 0

Re: missing result

[Gene Heskett]

On Thursday 22 March 2007, Joe Konecny wrote:
I upgraded from 2.4.5? to 2.5.1p3 and now have the following problem...
Can anyone provide any insight?

The security model was changed in the middle of that transition.  Did you 
do the appropriate changes, which I believe are explained in the FAQ?

These dumps were to tape daily set1006.
The next tape Amanda expects to use is: DailySet1002.

FAILURE AND STRANGE DUMP SUMMARY:
   R4P17.rmtohio.com  amrd0s1f  lev 0  FAILED [missing result for
 amrd0s1f in R4P17.rmtohio.com response]


STATISTICS:
   Total   Full  Incr.
       
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00   0:00   0:00
Output Size (meg)   0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0  0  0
Avg Dump Rate (k/s) -- -- --

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

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

USAGE BY TAPE:
   Label  Time  Size  %NbNc
   DailySet1006   0:000k0.0 0 0



-- 
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)
Success is relative: It is what we can make of the mess we have made of 
things.
-- T.S. Eliot, The Family Reunion

Re: missing result

[Joe Konecny]

Gene Heskett wrote:

On Thursday 22 March 2007, Joe Konecny wrote:
  

I upgraded from 2.4.5? to 2.5.1p3 and now have the following problem...
Can anyone provide any insight?


The security model was changed in the middle of that transition.  Did you 
do the appropriate changes, which I believe are explained in the FAQ?


  


I've searched the faq but have turned up nothing.  Is there a chance you 
could point me in the

right direction to find the info I need to make this work?

Re: missing result

[Gene Heskett]

On Thursday 22 March 2007, Joe Konecny wrote:
Gene Heskett wrote:
 On Thursday 22 March 2007, Joe Konecny wrote:
 I upgraded from 2.4.5? to 2.5.1p3 and now have the following
 problem... Can anyone provide any insight?

 The security model was changed in the middle of that transition.  Did
 you do the appropriate changes, which I believe are explained in the
 FAQ?

I've searched the faq but have turned up nothing.  Is there a chance you
could point me in the
right direction to find the info I need to make this work?

Not right at the moment but I expect a google search for amanda + 
bsdtcp-security might turn up something.  I had to add a line to my 
configuration driver script which I posted in another thread on this list 
just this evening, and I had to create a couple of files, the exact 
details of which elude me as I've reached that age (72) where short term 
memory isn't so quick.

I do see that the /home/amanda/.amandahosts file has some additions also.  
More aliases mainly.

This line in my gh.cf file which drives the configure stage here was 
added:
--with-bsdtcp-security \

There might be something in the docs directory of the tarball.

Yes, start with howto-auth.txt in the tarballs doc directory to do it how 
I am, which probably isn't the ultimate model, but it works for me.

-- 
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)
You want brutality and heuristics?  I'll give you brutality and 
heuristics...

- Eric S. Raymond on linux-kernel

Re: missing function in amanda?

[Jean-Louis Martineau]

Gene Heskett wrote:

Greetings;

In my troubleshooting of the 2.6.21-rc* vs tar thinking the whole system 
is new, where it works normally for any kernel up to 2.6.20.3. I find I'm 
in need of an amestimate command, to have amdump survey the system and 
report how much data (before compression obviously) that a dump would 
generate, but without doing anything to the install other than what it 
would normally do if it went all the way through the estimate phase plus 
its scheduling calculations, reporting the results and then exiting 
without actually doing anything.
  


Run the 'planner', don't forget to run 'amcleanup' once the planner finish.

Jean-Louis

Re: missing function in amanda?

[Gene Heskett]

On Tuesday 20 March 2007, Jean-Louis Martineau wrote:
Gene Heskett wrote:
 Greetings;

 In my troubleshooting of the 2.6.21-rc* vs tar thinking the whole
 system is new, where it works normally for any kernel up to 2.6.20.3.
 I find I'm in need of an amestimate command, to have amdump survey the
 system and report how much data (before compression obviously) that a
 dump would generate, but without doing anything to the install other
 than what it would normally do if it went all the way through the
 estimate phase plus its scheduling calculations, reporting the results
 and then exiting without actually doing anything.

Run the 'planner', don't forget to run 'amcleanup' once the planner
 finish.

Jean-Louis

Thanks, Jean-Louis.

It blew up again last night while running a 2.6.20.4-rc1 kernel, so that 
narrows it down to the 31 patches between a kernel-2.6.20.3 and 
kernel-2.6.20.4-rc1, a much easier bisect than the several hundred 
accumulated patches that separate 2.6.20 final from 2.6.21-rc1 where it 
blows up full time.  This will be VERY VERY helpfull.  I'm off to copy 
backup.sh to estimate.sh and modify it to do exactly that right now.

-- 
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)
Politics, like religion, hold up the torches of matrydom to the
reformers of error.
-- Thomas Jefferson

Re: missing function in amanda?

[Gene Heskett]

On Tuesday 20 March 2007, Jean-Louis Martineau wrote:
Gene Heskett wrote:
 Greetings;

 In my troubleshooting of the 2.6.21-rc* vs tar thinking the whole
 system is new, where it works normally for any kernel up to 2.6.20.3.
 I find I'm in need of an amestimate command, to have amdump survey the
 system and report how much data (before compression obviously) that a
 dump would generate, but without doing anything to the install other
 than what it would normally do if it went all the way through the
 estimate phase plus its scheduling calculations, reporting the results
 and then exiting without actually doing anything.

Run the 'planner', don't forget to run 'amcleanup' once the planner
 finish.

Jean-Louis

I have a problem jean-Louis, planner needs a screen, and the X server here 
is owned by root, even if I am su'd to amanda.  So...

[EMAIL PROTECTED] GenesAmandaHelper-0.6]$ /usr/bin/planner Daily
Xlib: connection to :0.0 refused by server
Xlib: No protocol specified

Xlib: connection to :0.0 refused by server
Xlib: No protocol specified


(planner:8633): Gtk-WARNING **: cannot open display:

What would be the std workaround for this line in my script:
   ${AM_BIN_DIR}/planner $CONFIGNAME $HOST $DLE  $LOG

Running it as root, and giving it the full pathlist to Daily the gtk gui 
it opens squawks because Daily is a directory.
Ahh, I see, there are two 'planner's on the system, one is a gtk tool of 
some sort, and one that is part of amanda is in /usr/local/libexec.  
Running this as root gives a way too verbose output, can I strip it down 
to just the final results?

What I need is the line getting estimates took and everything after it 
in the log.  The nitty-gritty traffic can go to /dev/null AFAIC.  Or is 
that possible.  I could write a script to edit it I suppose...  Or even 
grep -A200 'getting estimates took' would get me what I want to know.

-- 
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)
If you have to hate, hate gently.

Re: missing function in amanda?

[Jean-Louis Martineau]

Gene Heskett wrote:
Ahh, I see, there are two 'planner's on the system, one is a gtk tool of 
some sort, and one that is part of amanda is in /usr/local/libexec.  
Running this as root gives a way too verbose output, can I strip it down 
to just the final results?
  

No
What I need is the line getting estimates took and everything after it 
in the log.  The nitty-gritty traffic can go to /dev/null AFAIC.  Or is 
that possible.  I could write a script to edit it I suppose...  Or even 
grep -A200 'getting estimates took' would get me what I want to know.
  

Maybe you only need stdout, you can try to put stderr to /dev/null.

Re: missing function in amanda?

[Gene Heskett]

On Tuesday 20 March 2007, Jean-Louis Martineau wrote:
Gene Heskett wrote:
 Ahh, I see, there are two 'planner's on the system, one is a gtk tool
 of some sort, and one that is part of amanda is in /usr/local/libexec.
 Running this as root gives a way too verbose output, can I strip it
 down to just the final results?

No

 What I need is the line getting estimates took and everything after
 it in the log.  The nitty-gritty traffic can go to /dev/null AFAIC. 
 Or is that possible.  I could write a script to edit it I suppose... 
 Or even grep -A200 'getting estimates took' would get me what I want
 to know.

Maybe you only need stdout, you can try to put stderr to /dev/null.

I'll give that a shot, mm, I think I'm only sending stdout to the log, and 
its a bit terse, too terse for good troubleshooting.  So apparently I'm 
seeing stderr on the screen only.  Humm...

-- 
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)
Never put off till tomorrow what you can avoid all together.

Re: missing function in amanda?

[Michael Loftis]

--On March 18, 2007 11:16:49 PM -0400 Gene Heskett 
[EMAIL PROTECTED] wrote:



On Sunday 18 March 2007, [EMAIL PROTECTED] wrote:

On Sun, Mar 18, 2007 at 08:15:30PM -0400, Gene Heskett wrote:

If we had such a tool, I could run an estimate phase in advance of the
regular run and be in a position to reboot to the older kernel ahead
of time instead of totally screwing with the amanda database.


I'm not sure that is the most compelling use-case! ;)


Well, given enough time I expect I could come up with more excuses. :)


That said, it's always useful to be able to decompose operations for
debugging purposes.  At this point, the system is not factored in such a
way as to make that break a clean one.  I can think of ways to
accomplish something *like* what you're asking, but they're all hacks
that would be harder than

 if [ $(ssh mybox uname -r) == 2.6.foo.bar ]
 then
   echo Please reboot mybox | page_gene
 fi


Well, I know that 2.6.21-rc1-rc2-rc3 are making tar look broken.  So if
it  screws up tonight, I go get the identically versioned but hand built
tar-1.15-1 from my old FC2 install, nearly a megabyte in size, and move
the tar-1.15-1 from the FC6 rpm install out of the way.  That one is only
about 240k.  Mine is obviously staticly linked as its some over 830k in
size.  If that won't work, and all the other file inspection tools all
report sane dates and such, but tar still insists on backing up most of
the 45GB I have here in one fell swoop when told to do a level 3 or 4,
then tar is indeed broken and the bugzilla entry I made against it 3 days
ago will get re-inforced with more data.  Considering that a vtape here
is sized at about 11GB, there is no reason for amanda to tell it to
backup 3x the data the tape will hold.

In this case, an amestimate utility would be handier than that famous
button on the equally famous door.  I could time a run and see what it
says, change something and repeat, and do it several times a day without
screwing up amanda's database all that badly.


You can make a run with no-record set on the DLEs



Thanks Dustin.

--
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)
What hath Bob wrought?





--
Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler

Re: missing function in amanda?

[Gene Heskett]

On Monday 19 March 2007, Michael Loftis wrote:
--On March 18, 2007 11:16:49 PM -0400 Gene Heskett

[EMAIL PROTECTED] wrote:
 On Sunday 18 March 2007, [EMAIL PROTECTED] wrote:
 On Sun, Mar 18, 2007 at 08:15:30PM -0400, Gene Heskett wrote:
 If we had such a tool, I could run an estimate phase in advance of
 the regular run and be in a position to reboot to the older kernel
 ahead of time instead of totally screwing with the amanda database.

 I'm not sure that is the most compelling use-case! ;)

 Well, given enough time I expect I could come up with more excuses. :)

 That said, it's always useful to be able to decompose operations for
 debugging purposes.  At this point, the system is not factored in
 such a way as to make that break a clean one.  I can think of ways to
 accomplish something *like* what you're asking, but they're all hacks
 that would be harder than

  if [ $(ssh mybox uname -r) == 2.6.foo.bar ]
  then
echo Please reboot mybox | page_gene
  fi

 Well, I know that 2.6.21-rc1-rc2-rc3 are making tar look broken.  So
 if it  screws up tonight, I go get the identically versioned but hand
 built tar-1.15-1 from my old FC2 install, nearly a megabyte in size,
 and move the tar-1.15-1 from the FC6 rpm install out of the way.  That
 one is only about 240k.  Mine is obviously staticly linked as its some
 over 830k in size.  If that won't work, and all the other file
 inspection tools all report sane dates and such, but tar still insists
 on backing up most of the 45GB I have here in one fell swoop when told
 to do a level 3 or 4, then tar is indeed broken and the bugzilla entry
 I made against it 3 days ago will get re-inforced with more data. 
 Considering that a vtape here is sized at about 11GB, there is no
 reason for amanda to tell it to backup 3x the data the tape will hold.

 In this case, an amestimate utility would be handier than that famous
 button on the equally famous door.  I could time a run and see what it
 says, change something and repeat, and do it several times a day
 without screwing up amanda's database all that badly.

You can make a run with no-record set on the DLEs

Which still takes as much time, and if I have to bisect all of the patches 
between 2.6.20 final and 2.6.21-rc1 to find it, that time wasted will 
make me sit here till the middle of June!

And that ain't gonna happen.

Thanks guys.

-- 
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)
f u cn rd ths, u r prbbly a lsy spllr.

missing function in amanda?

[Gene Heskett]

Greetings;

In my troubleshooting of the 2.6.21-rc* vs tar thinking the whole system 
is new, where it works normally for any kernel up to 2.6.20.3. I find I'm 
in need of an amestimate command, to have amdump survey the system and 
report how much data (before compression obviously) that a dump would 
generate, but without doing anything to the install other than what it 
would normally do if it went all the way through the estimate phase plus 
its scheduling calculations, reporting the results and then exiting 
without actually doing anything.

The man pages don't seem to indicate we have such a utility.  It there  a 
way to do this that is not obvious from the manpages?

If we had such a tool, I could run an estimate phase in advance of the 
regular run and be in a position to reboot to the older kernel ahead of 
time instead of totally screwing with the amanda database.

Thanks all.

-- 
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)
Too much of anything, even love, isn't necessarily a good thing.
-- Kirk, The Trouble with Tribbles, stardate 4525.6

Re: missing function in amanda?

[dustin]

On Sun, Mar 18, 2007 at 08:15:30PM -0400, Gene Heskett wrote:
 If we had such a tool, I could run an estimate phase in advance of the 
 regular run and be in a position to reboot to the older kernel ahead of 
 time instead of totally screwing with the amanda database.

I'm not sure that is the most compelling use-case! ;)

That said, it's always useful to be able to decompose operations for
debugging purposes.  At this point, the system is not factored in such a
way as to make that break a clean one.  I can think of ways to
accomplish something *like* what you're asking, but they're all hacks
that would be harder than 

  if [ $(ssh mybox uname -r) == 2.6.foo.bar ]
  then
echo Please reboot mybox | page_gene
  fi

Dustin

-- 
Dustin J. Mitchell
Storage Software Engineer, Zmanda, Inc.
http://www.zmanda.com/

Re: missing function in amanda?

[Gene Heskett]

On Sunday 18 March 2007, [EMAIL PROTECTED] wrote:
On Sun, Mar 18, 2007 at 08:15:30PM -0400, Gene Heskett wrote:
 If we had such a tool, I could run an estimate phase in advance of the
 regular run and be in a position to reboot to the older kernel ahead
 of time instead of totally screwing with the amanda database.

I'm not sure that is the most compelling use-case! ;)

Well, given enough time I expect I could come up with more excuses. :)

That said, it's always useful to be able to decompose operations for
debugging purposes.  At this point, the system is not factored in such a
way as to make that break a clean one.  I can think of ways to
accomplish something *like* what you're asking, but they're all hacks
that would be harder than

  if [ $(ssh mybox uname -r) == 2.6.foo.bar ]
  then
echo Please reboot mybox | page_gene
  fi

Well, I know that 2.6.21-rc1-rc2-rc3 are making tar look broken.  So if it 
screws up tonight, I go get the identically versioned but hand built 
tar-1.15-1 from my old FC2 install, nearly a megabyte in size, and move 
the tar-1.15-1 from the FC6 rpm install out of the way.  That one is only 
about 240k.  Mine is obviously staticly linked as its some over 830k in 
size.  If that won't work, and all the other file inspection tools all 
report sane dates and such, but tar still insists on backing up most of 
the 45GB I have here in one fell swoop when told to do a level 3 or 4,  
then tar is indeed broken and the bugzilla entry I made against it 3 days 
ago will get re-inforced with more data.  Considering that a vtape here 
is sized at about 11GB, there is no reason for amanda to tell it to 
backup 3x the data the tape will hold.

In this case, an amestimate utility would be handier than that famous 
button on the equally famous door.  I could time a run and see what it 
says, change something and repeat, and do it several times a day without 
screwing up amanda's database all that badly.

Thanks Dustin.

-- 
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)
What hath Bob wrought?

results missing

[Steven Settlemyre]

I finally got past the gnutar problem I was having. I ran amcheck and 
everything looked good, but amdump gives me a bunch of results missing 
errors (even for hosts that worked fine before). Attached is the output 
from amdump.


Thanks,
Steve


*** THE DUMPS DID NOT FINISH PROPERLY!

These dumps were to tape VOL24.
The next tape Amanda expects to use is: VOL01.

FAILURE AND STRANGE DUMP SUMMARY:
 helios.medsci.domain  /var lev 2  STRANGE
 snapserver.medsci.domain  /hd/vol_mnt0/shares/biochem  lev 1  FAILED 
[data write: Broken pipe]
 wagstaff.asel.domain  /usr/local   lev 1  FAILED 
[data write: Connection reset by peer]

 helios.medsci.domain  /usr/local   RESULTS MISSING
 lollipop.asel.domain  /files1  RESULTS MISSING
 wagstaff.asel.domain  /RESULTS MISSING
 wagstaff.asel.domain  /files1  RESULTS MISSING
 wagstaff.asel.domain  /files3  RESULTS MISSING
 wagstaff.asel.domain  /files4  RESULTS MISSING
 wagstaff.asel.domain  /files5  RESULTS MISSING
 wagstaff.asel.domain  /files6/vol/SynthRESULTS MISSING
 wagstaff.asel.domain  /files6/vol/VoicewareRESULTS MISSING
 wagstaff.asel.domain  /files6/vol/bvd  RESULTS MISSING
 wagstaff.asel.domain  /files6/vol/spdata1  RESULTS MISSING
 wagstaff.asel.domain  /files6/vol/spdata2  RESULTS MISSING
 wagstaff.asel.domain  /files6/vol/speech7  RESULTS MISSING
 wagstaff.asel.domain  /usr RESULTS MISSING
 wizard.asel.domain/var/mailRESULTS MISSING
 wizard.asel.domain/files2  RESULTS MISSING
 snapserver.medsci.domain  /hd/vol_mnt0/shares/bcl  RESULTS MISSING
 driver: FATAL Don't know how to send ABORT command to chunker
 chunker: FATAL error [bad command after RQ-MORE-DISK: QUIT]
 chunker: FATAL error [bad command after RQ-MORE-DISK: QUIT]


STATISTICS:
 Total   Full  Incr.
         
Estimate Time (hrs:min)0:10
Run Time (hrs:min) 0:14
Dump Time (hrs:min)0:14   0:00   0:14
Output Size (meg) 765.70.0  765.7
Original Size (meg)  1948.10.0 1948.1
Avg Compressed Size (%)39.3--39.3   (level:#disks ...)
Filesystems Dumped   36  0 36   (1:35 2:1)
Avg Dump Rate (k/s)   966.6--   966.6

Tape Time (hrs:min)0:04   0:00   0:04
Tape Size (meg)   767.70.0  767.7
Tape Used (%)   2.10.02.1   (level:#disks ...)
Filesystems Taped36  0 36   (1:35 2:1)
  (level:#chunks ...)
Chunks Taped 36  0 36   (1:35 2:1)
Avg Tp Write Rate (k/s)  3038.4--  3038.4

USAGE BY TAPE:
 Label   Time  Size  %NbNc
 VOL24   0:04   786080k2.13636


FAILED AND STRANGE DUMP DETAILS:

/--  helios.medsci.domain /var lev 2 STRANGE
sendbackup: start [helios.medsci.domain:/var level 2]
sendbackup: info BACKUP=/bin/tar
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? gtar: 
./lib/amanda/asel/index/professor.asel.domain/_usr_local/20061026_1.gz.tmp: 
Warning: Cannot stat: No such file or directory
? gtar: 
./lib/amanda/asel/index/snapserver.medsci.domain/_hd_vol__mnt0_shares_NeuroGen/20061026_1.gz.tmp: 
Warning: Cannot stat: No such file or directory

| gtar: ./run/postgresql/.s.PGSQL.5432: socket ignored
| Total bytes written: 1115033600 (1.1GiB, 6.5MiB/s)
sendbackup: size 1088900
sendbackup: end
\

/--  snapserver.medsci.domain /hd/vol_mnt0/shares/biochem lev 1 FAILED 
[data write: Broken pipe]
sendbackup: start [snapserver.medsci.domain:/hd/vol_mnt0/shares/biochem 
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
\

/--  wagstaff.asel.domain /usr/local lev 1 FAILED [data write: 
Connection reset by peer]

sendbackup: start [wagstaff.asel.domain:/usr/local level 1]
sendbackup: info BACKUP=/usr/sbin/ufsdump
sendbackup: info RECOVER_CMD=/usr/local/bin/gzip -dc 
|/usr/sbin/ufsrestore -f... -

sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
|   DUMP: Writing 32 Kilobyte records
|   DUMP: Date of this level 1 dump: Thu Oct 26 23:55:10 2006
|   DUMP: Date of last level 0 dump: Mon Oct 23 23:55:43 2006
|   DUMP: Dumping /dev/rdsk/c0t0d0s7 (wagstaff:/usr/local) to standard 
output.

|   DUMP: Mapping (Pass I) [regular files]
|   DUMP: Mapping (Pass II) [directories]
|   DUMP: Mapping (Pass II) [directories]
|   DUMP: Mapping (Pass II) [directories]
|   DUMP: Estimated 11706368

lev 0 FAILED [missing result for /usr in hvbackup response] message

[Christopher Davis]

I know I've seen discussion on this before - but after adding a couple of new
clients I have started getting the following messages

/usr  lev 0  FAILED [missing result for /usr in hvbackup
response]


about 3 or 4 a dump - is it the estimate timeout value I've seen mentioned as
a possible solution to this?

None of these errors are on the new servers - they are actually all on
filesystems local to the amanda server. 


Thanks,

Chris

Re: Missing Results

[Luis Rodrigues]

  Luis
 
 I had just this behavior when I first upgraded my server to amanda 2.5.0.  We 
 had a bried discussion of it here on this list, and a patch was included in 
 2.5.0p2 (maybe 2.5.0p1) that fixed the problem.
 
 What version of amanda are you running?
 
 As I recall it was a bug in amreport that was triggered when a dump started 
 on 
 one date and finished on another (like early AM the next day).

Ahh,

I saw that discussion some time ago but didn't thought that might be it.
I'm using 2.5.0.

Thanks

Missing Results

[Luis Rodrigues]

Hello,

I'm getting this on my backup report.

DUMP SUMMARY:
   DUMPER STATS   TAPER STATS 
HOSTNAME DISKL ORIG-MB  OUT-MB  COMP%  MMM:SS   KB/s MMM:SS   KB/s
-- - -
aca2g.ess.co /var/www01752 485   27.79:14  896.6   4:51 1707.1
acag.ess.co. /gis0   372338964   24.1  231:21  661.3  27:56 5476.0
acag.ess.co. /var/www034382123   61.8   18:25 1968.6   6:36 5487.8
acag.ess.co. /var/www  MISSING ---
cyprus_demo. /var/www0  63  22   35.50:09 2536.8   0:09 2551.2
essg.ess.co. /etc/mail   0  12   3   24.10:02 1196.2   0:04  703.6
essg.ess.co. /home/ftp   0  32  22   69.70:11 2129.0   0:11 2107.3
essg.ess.co. /var/mail   01402 854   60.98:41 1678.3   8:37 1691.9
essg.ess.co. /var/named  0   0   0  160.00:00   45.6   0:03   18.6
essg.ess.co. /var/www037062717   73.3   28:39 1618.1  23:15 1994.3
essg.ess.co. /var/www  MISSING ---

As you can see just some are missing, and it varies depending on the days.
What is this?

Thanks in advance.

Luis

Re: Missing Results

[Paul Bijnens]

On 2006-07-03 09:55, Luis Rodrigues wrote:

Hello,

I'm getting this on my backup report.

DUMP SUMMARY:
   DUMPER STATS   TAPER STATS 
HOSTNAME DISKL ORIG-MB  OUT-MB  COMP%  MMM:SS   KB/s MMM:SS   KB/s

-- - -
aca2g.ess.co /var/www01752 485   27.79:14  896.6   4:51 1707.1
acag.ess.co. /gis0   372338964   24.1  231:21  661.3  27:56 5476.0
acag.ess.co. /var/www034382123   61.8   18:25 1968.6   6:36 5487.8
acag.ess.co. /var/www  MISSING ---
cyprus_demo. /var/www0  63  22   35.50:09 2536.8   0:09 2551.2
essg.ess.co. /etc/mail   0  12   3   24.10:02 1196.2   0:04  703.6
essg.ess.co. /home/ftp   0  32  22   69.70:11 2129.0   0:11 2107.3
essg.ess.co. /var/mail   01402 854   60.98:41 1678.3   8:37 1691.9
essg.ess.co. /var/named  0   0   0  160.00:00   45.6   0:03   18.6
essg.ess.co. /var/www037062717   73.3   28:39 1618.1  23:15 1994.3
essg.ess.co. /var/www  MISSING ---

As you can see just some are missing, and it varies depending on the days.
What is this?


There must be some other messages in the beginning too, indicating
what exactly went wrong.
Also have a look in de debug files on those clients.

Is the problem one of those described in:

http://wiki.zmanda.com/index.php/Amdump:_results_missing


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

Re: Missing Results

[Paul Bijnens]

On 2006-07-03 09:55, Luis Rodrigues wrote:

Hello,

I'm getting this on my backup report.

DUMP SUMMARY:
   DUMPER STATS   TAPER STATS 
HOSTNAME DISKL ORIG-MB  OUT-MB  COMP%  MMM:SS   KB/s MMM:SS   KB/s

-- - -
aca2g.ess.co /var/www01752 485   27.79:14  896.6   4:51 1707.1
acag.ess.co. /gis0   372338964   24.1  231:21  661.3  27:56 5476.0
acag.ess.co. /var/www034382123   61.8   18:25 1968.6   6:36 5487.8
acag.ess.co. /var/www  MISSING ---
cyprus_demo. /var/www0  63  22   35.50:09 2536.8   0:09 2551.2
essg.ess.co. /etc/mail   0  12   3   24.10:02 1196.2   0:04  703.6
essg.ess.co. /home/ftp   0  32  22   69.70:11 2129.0   0:11 2107.3
essg.ess.co. /var/mail   01402 854   60.98:41 1678.3   8:37 1691.9
essg.ess.co. /var/named  0   0   0  160.00:00   45.6   0:03   18.6
essg.ess.co. /var/www037062717   73.3   28:39 1618.1  23:15 1994.3
essg.ess.co. /var/www  MISSING ---

As you can see just some are missing, and it varies depending on the days.
What is this?


One something more weird:
You seem to have 2 entries for those DLE's: one succeeded, one missing.
How did you get 2 lines for one DLE???


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

Re: Missing Results

[Luis Rodrigues]

  
  As you can see just some are missing, and it varies depending on the days.
  What is this?
 
 One something more weird:
 You seem to have 2 entries for those DLE's: one succeeded, one missing.
 How did you get 2 lines for one DLE???

Thats what I would like to know.

I have no other error messages on the report.

I also have on amstatus:

acag.ess.co:/var/www0 2123m finished (5:52:13)
essg.ess.co:/var/www0 2716m finished (1:04:33)

So the dump worked fine...

Any ideias?

Luis

Re: Missing Results

[Alexander Jolk]

Luis Rodrigues wrote:

One something more weird:
You seem to have 2 entries for those DLE's: one succeeded, one missing.
How did you get 2 lines for one DLE???



Thats what I would like to know.


autoflush, by any chance?

Alex


--
Alexander Jolk / BUF Compagnie
tel +33-1 42 68 18 28 /  fax +33-1 42 68 18 29