Re: NT_STATUS_ACCESS_DENIED

[Rodrigo Ventura]

I have the same problem over here. I'm well aware that I could never
restore, at least easly, a windows system partition using backups
based on samba, but at least better than having no backup at all.

By the way, are there off-the-shelf howto to guide setting up a
reliable backup of a NT server using amanda? I tought about something
like using a scheduled backup, using the software that comes with the
system, for microsoft backup images, and then backing up those images
(maybe in full-only mode) using samba and amanda.

Does anyone has any experience on this?

Cheers,

Rodrigo

-- 

*** Rodrigo Martins de Matos Ventura <[EMAIL PROTECTED]>
***  Web page: http://www.isr.ist.utl.pt/~yoda
***   Teaching Assistant and PhD Student at ISR:
***Instituto de Sistemas e Robotica, Polo de Lisboa
*** Instituto Superior Tecnico, Lisboa, PORTUGAL
*** PGP fingerprint = 0119 AD13 9EEE 264A 3F10  31D3 89B3 C6C4 60C6 4585

Re: NT_STATUS_ACCESS_DENIED

[Paul Bijnens]

Nicholas Conrad wrote:
Just wondering if anyone might be able to help me figure out what is 
causing the following:


FAILED AND STRANGE DUMP DETAILS:

/-- localhost  //LYNNIE/backup lev 0 STRANGE
sendbackup: start [localhost://LYNNIE/backup 
 
level 0]


That is new to me!! Where is that coming from?  http://   ???



sendbackup: info BACKUP=/usr/bin/smbclient
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/bin/smbclient -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
? Unknown parameter encountered: "smb password file"
? Ignoring unknown parameter "smb password file"


That should have been "smb passwd file" in your smb.conf.


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\adp new 
employees.wpd (\Word Perfect\)
? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\Lun Mun Inv 
montly.wpd (\Word Perfect\)
? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\MAIL 
SHEET.wpd (\Word Perfect\)
? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\new board 
package -title.wpd (\Word Perfect\)


Could be several things:

File in use?  (but  I believe the message would be "sharing violation" 
or something like that)


Is the smb backup user actually part of the local administrators? 
otherwise it could not access file with stricter permissions, and cannot 
reset the archive bit either.


Specific permissions on those four files?  (Administrators, if not 
listed explictly by the permissions can be lock out to some files by MS 
Windows access lists, contrary to "root" on Unix -- however, selinux

can do that too).

Have tried rebooting LYNNIE already?  (i.e. The most successful solution
for many MS-Windows problems, by lack of public documentation of the 
underlying architecture...)



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

Re: NT_STATUS_ACCESS_DENIED

[Guy Dallaire]

2005/12/14, Nicholas Conrad <[EMAIL PROTECTED]>:
Just wondering if anyone might be able to help me figure out what is causing the following:



FAILED AND STRANGE DUMP DETAILS:





/-- localhost  //LYNNIE/backup lev 0 STRANGE


sendbackup: start [localhost://LYNNIE/backup level 0]



sendbackup: info BACKUP=/usr/bin/smbclient


sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/bin/smbclient -f... -


sendbackup: info COMPRESS_SUFFIX=.gz


sendbackup: info end


? Unknown parameter encountered: "smb password file"


? Ignoring unknown parameter "smb password file"


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\adp new employees.wpd (\Word Perfect\)


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\Lun Mun Inv montly.wpd (\Word Perfect\)


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\MAIL SHEET.wpd (\Word Perfect\)


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\new board package -title.wpd (\Word Perfect\)


| tar: dumped 889 files and directories


| Total bytes written: 312758272


sendbackup: size 305428


sendbackup: end


\



The 4 files that are failing have been modified since the last time
they were successfully backed up.  None of the other .wpd files
have been modified and they are all backing up fine.  Other files
have been modified(.xls, .doc etc) and they are still backing up
fine.  There are 2 accounts on the windows box, both are
admin.  Any ideas/suggestions,  it's getting a little
frustrating.  Thanks in advance

Might the files be LOCKED (In use) by any chance at the time they are
backed up ? Sometimes, MS-Office crashes and leave "invisible"
processes around with open files...

NT_STATUS_ACCESS_DENIED

[Nicholas Conrad]

Just wondering if anyone might be able to help me figure out what is causing the following:



FAILED AND STRANGE DUMP DETAILS:





/-- localhost  //LYNNIE/backup lev 0 STRANGE


sendbackup: start [localhost://LYNNIE/backup level 0]



sendbackup: info BACKUP=/usr/bin/smbclient


sendbackup: info RECOVER_CMD=/bin/gzip -dc |/usr/bin/smbclient -f... -


sendbackup: info COMPRESS_SUFFIX=.gz


sendbackup: info end


? Unknown parameter encountered: "smb password file"


? Ignoring unknown parameter "smb password file"


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\adp new employees.wpd (\Word Perfect\)


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\Lun Mun Inv montly.wpd (\Word Perfect\)


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\MAIL SHEET.wpd (\Word Perfect\)


? NT_STATUS_ACCESS_DENIED opening remote file \Word Perfect\new board package -title.wpd (\Word Perfect\)


| tar: dumped 889 files and directories


| Total bytes written: 312758272


sendbackup: size 305428


sendbackup: end


\



The 4 files that are failing have been modified since the last time
they were successfully backed up.  None of the other .wpd files
have been modified and they are all backing up fine.  Other files
have been modified(.xls, .doc etc) and they are still backing up
fine.  There are 2 accounts on the windows box, both are
admin.  Any ideas/suggestions,  it's getting a little
frustrating.  Thanks in advance

Re: Odd permissions problem

[Dave Ewart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday, 14.12.2005 at 16:17 +0100, Paul Bijnens wrote:

> Dave Ewart wrote:
> >I've just added a few entries to my disklist and am getting errors like
> >the following, during amcheck:
> >
> >ERROR: athena: [could not access /srv/samba/netlogon
> >(/srv/samba/netlogon): Permission denied]
> 
> 
> >Why is this directory not visible to the AMANDA process, given that the
> >AMANDA user is part of group 'disk' and that should give it access to
> >those partitions?  The '/root/' partition is only (technically) visible
> >to the root user, yet AMANDA is able to correctly back this up.
> 
> http://wiki.zmanda.com/index.php/Why_does_amcheck_fail_while_amdump_succeeds_%3F
> 
> The good news is that amdump will probably work fine.
> 
> The fact that amanda is part of group disk has no effect here:
> you're doing backups of subdirectories, and thus cannot use dump, but
> must use gnutar (Dump can only work on whole partitions, not on 
> subdirectories, at least when doing incrementals.)
> 
> For running dumpa and accessing the device-partitions, amanda needs to
> be member of the disk-group, but for running gnutar, amanda actually
> needs root priviledges, which she gets by invoking gnutar with a suid
> root program, which is not used by amcheck. (Note amcheck just sends a
> message to amandad on the client, and it's amandad on the client that
> does the check; hence making amcheck suid-root does not help either.)

Ah, understood, very helpful Paul.  That explains the situation
sufficiently for me to be able to work around it.

Thanks,

Dave.
- -- 
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Cancer Epidemiology Unit
Cancer Research UK / Oxford University
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc
N 51.7518, W 1.2016
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDoEHCbpQs/WlN43ARAnN9AJ92UXOBw630FlSImG9C3fJpHhv2+ACgy4mi
yACzRR4yhXZxUooRO9dOk98=
=cho+
-END PGP SIGNATURE-

Re: Odd permissions problem

[Paul Bijnens]

Dave Ewart wrote:

I've just added a few entries to my disklist and am getting errors like
the following, during amcheck:

ERROR: athena: [could not access /srv/samba/netlogon
(/srv/samba/netlogon): Permission denied]




Why is this directory not visible to the AMANDA process, given that the
AMANDA user is part of group 'disk' and that should give it access to
those partitions?  The '/root/' partition is only (technically) visible
to the root user, yet AMANDA is able to correctly back this up.


http://wiki.zmanda.com/index.php/Why_does_amcheck_fail_while_amdump_succeeds_%3F

The good news is that amdump will probably work fine.

The fact that amanda is part of group disk has no effect here:
you're doing backups of subdirectories, and thus cannot use dump, but
must use gnutar (Dump can only work on whole partitions, not on 
subdirectories, at least when doing incrementals.)


For running dumpa and accessing the device-partitions, amanda needs to
be member of the disk-group, but for running gnutar, amanda actually
needs root priviledges, which she gets by invoking gnutar with a suid
root program, which is not used by amcheck. (Note amcheck just sends a
message to amandad on the client, and it's amandad on the client that
does the check; hence making amcheck suid-root does not help either.)


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

Odd permissions problem

[Dave Ewart]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've just added a few entries to my disklist and am getting errors like
the following, during amcheck:

ERROR: athena: [could not access /srv/samba/netlogon
(/srv/samba/netlogon): Permission denied]

ERROR: athena: [could not access /srv/samba/install
(/srv/samba/install): Permission denied]

This is strange, because other entries, such as /root and /etc have been
backed-up correctly for many months.  This is a Debian system where
AMANDA uses user 'backup', which is a member of user 'disk' - this
should allow it to backup all local disks without further privileges.

/srv/samba, /root and /etc are all on the same partition, /dev/sda1:

# ls -l /dev/sda1
brw-rw  1 root disk 8, 1 Jun 15 18:26 /dev/sda1

Various permissions:

(For working entries in disklist)

# ls -ld /root
drwxr-x---  15 root root 4096 Dec 14 14:31 /root

# ls -ld /etc 
drwxr-xr-x  85 root root 4096 Dec 14 14:38 /etc

(For non-working entries in disklist)

# ls -ld /srv
drwxr-xr-x  3 root root  4096 Nov 28 10:39 /srv

# ls -ld /srv/samba
drwxr-s---  10 root everyone 4096 Nov 21 10:38 /srv/samba

# ls -ld /srv/samba/install/
drwxr-s---  5 root everyone  4096 Nov 15 10:01 /srv/samba/install/

# ls -ld /srv/samba/netlogon/
drwxr-s---  3 root everyone  4096 Dec 14 09:08 /srv/samba/netlogon/

If I make '/srv/samba' chmod-ed to 755, then the permissions errors go
away.  HOWEVER, I don't want to do that, since there are good reasons
for that directory having the permissions it does.

Why is this directory not visible to the AMANDA process, given that the
AMANDA user is part of group 'disk' and that should give it access to
those partitions?  The '/root/' partition is only (technically) visible
to the root user, yet AMANDA is able to correctly back this up.

Ideas/hints?

Dave.
- -- 
Dave Ewart
[EMAIL PROTECTED]
Computing Manager, Cancer Epidemiology Unit
Cancer Research UK / Oxford University
PGP: CC70 1883 BD92 E665 B840 118B 6E94 2CFD 694D E370
Get key from http://www.ceu.ox.ac.uk/~davee/davee-ceu-ox-ac-uk.asc
N 51.7518, W 1.2016
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDoDHtbpQs/WlN43ARArqiAKDlnbEHeiERhCJ4RZ1K6pfA+T61/QCgmo4e
EeFlnVElcIw6MEjUNkrMVI0=
=gTQG
-END PGP SIGNATURE-

Re: Migrating amanda

[Paul Bijnens]

Inaki Sanchez wrote:

Hello:

I have amanda 2.4.4p3 in a RHEL3 box, built from sources (not the 
rpm's by redhat). Now I want to upgrade that server to RHEL 4. What 
would be the best upgrade path to migrate the entire amanda database to 
the new OS? Should an amadmin export/import be enough?


Export/import only does handles the "info" database.
You need more.

But simply copying these directory trees should be fine:

-  configdir
-  logdir/index/info :  probably shared under the same parent dir
-  amanda home directory (maybe same as previous dir)

To find the values of these places do:
  $ amadmin x version

and look in amanda.conf for logdir/index/info etc.


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

RE: VXA-V23 tape difficulties

[Hommersom, Gerrit (G)]

Thanks very much for the clear explanation of the potential other causes but
tape-error. 

Though I will run a cleaning tape, I have a suspicion that this is not the
case. Tapes themselves are also quite new: 6-7th cycle.

The 'end-of-tape' error occurred on 5 different tapes on 5 consecutive days
for one DLE until I force-bumped all due DLE's except the one failing all
the time.
This one was followed by 2 failures on the next large DLE. I have forced
this DLE and force-bumped all other big DLE's and await tomorrow.

That was the motivation for the minimum tape length of a backed-up DLE.

Kind regards
==
Gerrit HommersomDow Benelux BV
tel:-31-115-674102   E&PS/439 Bldg
fax:-31-115-673315   PO Box 48
E-mail: [EMAIL PROTECTED]   4530 AA Terneuzen




-Original Message-
From: Paul Bijnens [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 14, 2005 12:23 PM
To: Hommersom, Gerrit (G)
Cc: 'amanda-users@amanda.org'
Subject: Re: VXA-V23 taoe difficulties


Hommersom, Gerrit (G) wrote:
> I am using Amanda for year as primary backup tool for my Linux/Unix 
> pool.
> 
> Some months I introduced an Exabyte VXA drive and VXA-V23 (80GB
> uncompressed) tapes to cope with the ever expanding storage. I backup 
> 25 DLE's of varying size 18 MB to 55 GB. Amanda nor the hardware 
> compress the data. TapeType definition sets the Tapesize to 75 GB to 
> add some slack in the system.
> Backup program is gtar.
> 
> Recently I get the following error when the large DLE's are backup up
> 
> *** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
> Some dumps may have been left in the holding disk. Run amflush to flush
them to tape. 
> The next tape Amanda expects to use is:
> 
> The mail message indicates that only 65 GB has actually been written 
> at the time the tape ran out.
>  taper: tape xx kb 65110688 fm 25 writing file: No space left on
device

The tape really bumped into -- what it diagnosed as -- end of tape at this
point.

The problem is that "bumping into end of tape" is implemented as a "hard
write error" on the same spot.

For this you have to understand that most tapedrives (disclaimer: I do 
not know a VXA drive, this could be different here) have a read head that
verifies what they write.  During writing, error correcting and error
detecting bits are added, and many of the write errors can be corrected by
those additional error correcting bits.  When writing a block, and the read
head diagnoses this as a bad block, the tape does not rewind, but the
firmware rewrites the same block again, in the hope it does write correctly
this time.  If after a certain number of these 
"soft" errors, the error persists, this becomes a "hard" error.

Bumping into end of tape is the same: the tape drive tries to write a block,
but it does not succeed, resulting in a "hard error".

The result of all this guessing is that most drives report a "hard write
error" as "end of tape".

Only in some circumstances, a drive can really know that it did not bump
into the "real" end of tape, but had a real I/O error.

Cleaning the tape drive helps sometimes.

> 
> Some incremental backups (9 in total) are very small 60 KB to 5 MB.
> Can this be the cause of the gross miscalculation of the tapelength?? 
> What is the minimum tape length for a DLE backup ??

I guess this has nothing to do with it.


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

Migrating amanda

[Inaki Sanchez]

Hello:

I have amanda 2.4.4p3 in a RHEL3 box, built from sources (not the rpm's 
by redhat). Now I want to upgrade that server to RHEL 4. What would be the best 
upgrade path to migrate the entire amanda database to the new OS? Should an 
amadmin export/import be enough?

Thanks,

--
Inaki Sanchez
Servicios Informáticos
Área de desarrollo
Universidad de Navarra

mailto:[EMAIL PROTECTED]
http://www.unav.es/SI

Re: HowToDo:

[Paul Bijnens]

Iqbal wrote:
I have two Linux boxs and there is no tape drives 
available and Amanda clinet/server is installed by 
default via rpms. I want to take my two boxes backup

using Amanda I did try via amanda docs but unable to
complete the backup task using amanda.

Please advise me how can I do this using amanda.
Waiting for the positive reply, thanks in advance.


We could help more if you explained what you tried, and
what did not succeed.

Did you have a look at this documentation:

http://wiki.zmanda.com/index.php/Quick_start
http://wiki.zmanda.com/index.php/Test_environment_with_virtual_tapes
http://wiki.zmanda.com/index.php/Backup_server#File_driver.2FDisk_backups

What have you done so far, and where is it going wrong?

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

Re: VXA-V23 taoe difficulties

[Paul Bijnens]

Hommersom, Gerrit (G) wrote:

I am using Amanda for year as primary backup tool for my Linux/Unix pool.

Some months I introduced an Exabyte VXA drive and VXA-V23 (80GB
uncompressed) tapes to cope with the ever expanding storage.
I backup 25 DLE's of varying size 18 MB to 55 GB. Amanda nor the
hardware compress the data.
TapeType definition sets the Tapesize to 75 GB to add some slack in
the system.
Backup program is gtar.

Recently I get the following error when the large DLE's are backup up

*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. 
Some dumps may have been left in the holding disk. Run amflush to flush them to tape. 
The next tape Amanda expects to use is:


The mail message indicates that only 65 GB has actually been written at the 
time the tape ran out.
 taper: tape xx kb 65110688 fm 25 writing file: No space left on device


The tape really bumped into -- what it diagnosed as -- end of tape
at this point.

The problem is that "bumping into end of tape" is implemented as a
"hard write error" on the same spot.

For this you have to understand that most tapedrives (disclaimer: I do 
not know a VXA drive, this could be different here) have a read head

that verifies what they write.  During writing, error correcting and
error detecting bits are added, and many of the write errors can be
corrected by those additional error correcting bits.  When writing
a block, and the read head diagnoses this as a bad block, the tape does
not rewind, but the firmware rewrites the same block again, in the hope
it does write correctly this time.  If after a certain number of these 
"soft" errors, the error persists, this becomes a "hard" error.


Bumping into end of tape is the same: the tape drive tries to write
a block, but it does not succeed, resulting in a "hard error".

The result of all this guessing is that most drives report a "hard
write error" as "end of tape".

Only in some circumstances, a drive can really know that it did not
bump into the "real" end of tape, but had a real I/O error.

Cleaning the tape drive helps sometimes.



Some incremental backups (9 in total) are very small 60 KB to 5 MB. 
Can this be the cause of the gross miscalculation of the tapelength?? 
What is the minimum tape length for a DLE backup ??


I guess this has nothing to do with it.


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

HowToDo:

[Iqbal]

Hello All,
I have two Linux boxs and there is no tape drives 
available and Amanda clinet/server is installed by 
default via rpms. I want to take my two boxes backup
using Amanda I did try via amanda docs but unable to
complete the backup task using amanda.

Please advise me how can I do this using amanda.
Waiting for the positive reply, thanks in advance.

Regards,
Iqbal

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

VXA-V23 taoe difficulties

[Hommersom, Gerrit (G)]

I am using Amanda for year as primary backup tool for my Linux/Unix pool.

Some months I introduced an Exabyte VXA drive and VXA-V23 (80GB uncompressed) 
tapes to cope with the ever expanding storage.
I backup 25 DLE's of varying size 18 MB to 55 GB. Amanda nor the hardware 
compress the data.
TapeType definition sets the Tapesize to 75 GB to add some slack in the system.
Backup program is gtar.

Recently I get the following error when the large DLE's are backup up

*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]]. 
Some dumps may have been left in the holding disk. Run amflush to flush them to 
tape. 
The next tape Amanda expects to use is:

The mail message indicates that only 65 GB has actually been written at the 
time the tape ran out.
 taper: tape xx kb 65110688 fm 25 writing file: No space left on device

Some incremental backups (9 in total) are very small 60 KB to 5 MB. 
Can this be the cause of the gross miscalculation of the tapelength?? 
What is the minimum tape length for a DLE backup ??

Thanks
==
Gerrit HommersomDow Benelux BV
tel:-31-115-674102   E&PS/439 Bldg
fax:-31-115-673315   PO Box 48
E-mail: [EMAIL PROTECTED]   4530 AA Terneuzen