Re: Problems with dumps
On Fri, 30 Jul 2004 23:24:21 -0500, Frank Smith fsmith escreveu:
De: Frank Smith fsmith
Data: Fri, 30 Jul 2004 23:24:21 -0500
Para: Fábio Mendonça Albuquerque Cunha fmacunha,[EMAIL PROTECTED]
Assunto: Re: Problems with dumps
--On Friday, July 30, 2004 18:20:08 -0300 Fábio Mendonça Albuquerque Cunha
fmacunha wrote:
Hello guys,
I am trying to do a full backup of 03 filesystems (127 GB), and my tape is an AIT
50/130 GB tape driver.
My amcheck is OK, no problems found ...
Amdump simply don't work and report me this :
These dumps were to tape fita03.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
Tape is full.
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
You may need to do this.
The next tape Amanda expects to use is: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
servarq.es /projeto2 lev 0 FAILED [dumps too big, 16044295 KB, but
cannot incremental dump new disk]
Not sure why you got this, 16GB should fit on a 50GB tape. Perhaps you
have an incorrect length set in your tapetype?
servarq.es /projeto3 lev 0 STRANGE
Tar encountered some warnings on /projeto3, they are listed below.
STRANGE may or not be a problem, you need to look at it's output below
and decide yourself.
No it's a not a concern at this moment.
servarq.es /projeto1 lev 0 FAILED [out of tape]
The tape filled up while writing this filesystem so it didn't make it
to tape successfully. It may be on your holding disk if you defined one.
If so, run amflush.
But why the tape is filled up? The capacity is 130GB, with hardware compression.
The tape device is an AIT 50/130 GB tape drive.
servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
Possibly you weren't using a holding disk and it was going directly
to tape, so when the tape filled up the pipe closed, terminating the
connection.
servarq.es /projeto1 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:21
Run Time (hrs:min)11:56
Dump Time (hrs:min)5:18 5:18 0:00
Output Size (meg) 17838.917838.90.0
Original Size (meg) 33755.833755.80.0
Avg Compressed Size (%)52.8 52.8--
Filesystems Dumped1 1 0
Avg Dump Rate (k/s) 956.0 956.0--
Tape Time (hrs:min)5:19 5:19 0:00
Tape Size (meg) 17838.917838.90.0
Tape Used (%) 35.7 35.70.0
Filesystems Taped 1 1 0
Avg Tp Write Rate (k/s) 955.5 955.5--
USAGE BY TAPE:
LabelTime Size %Nb
fita03 5:19 17838.9 35.7 1
FAILED AND STRANGE DUMP DETAILS:
/-- servarq.es /projeto3 lev 0 STRANGE
sendbackup: start [servarq.estatica.com.br:/projeto3 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 1.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 2.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
METRO - S\306o Paulo - 03.035.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/e-mail recebido ate/COMGAS/Fw_
Concorr\210ncia Elabora\207\306o Projeto Executivo - Bols\344es Av_
Jabaquara_Lino Coutinho_Winner_Cardoso Almeida_Ant\223nio Ambuda_Costa
Marina_Ida Kolbi_ERS41_Ripasa Pap\202is Limeira.eml: Warning: Cannot stat:
No such file or directory
? gtar: ./projeto3/COMGAS-1463/e-mail recebido ate/COMGAS/Fw_
Concorr\210ncia Elabora\207\306o Projeto Executivo - Bols\344es Av_
Jabaquara_Lino Coutinho_Winner_Cardoso Almeida_Ant\223nio Ambuda_Costa
Marina_Ida Kolbi_ERS41_Ripasa_Pap\202is Limeira.eml: Warning: Cannot stat:
No such file or directory
All these files disappeared between the time tar made its filelist and
the time it tried to read them. The result of backing up a busy
filesystem. May or may not be a concern to you.
| Total bytes written: 35395502080 (33GB, 1.8MB/s)
sendbackup: size 34565920
sendbackup: end
\
/-- servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
sendbackup: start [servarq.estatica.com.br:/projeto1 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
\
NOTES:
planner: tapecycle (5) = runspercycle (7)
planner: Adding new disk
Re: Problems with dumps
Hello guys ...
The next tape Amanda expects to use is: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
servarq.es /projeto2 lev 0 FAILED [dumps too big, 16044295 KB, but
cannot incremental dump new disk]
Not sure why you got this, 16GB should fit on a 50GB tape. Perhaps you
have an incorrect length set in your tapetype?
My length set is : 5
Tar encountered some warnings on /projeto3, they are listed below.
STRANGE may or not be a problem, you need to look at it's output below
and decide yourself.
No it's a not a concern at this moment.
servarq.es /projeto1 lev 0 FAILED [out of tape]
The tape filled up while writing this filesystem so it didn't make it
to tape successfully. It may be on your holding disk if you defined one.
If so, run amflush.
But why the tape is filled up? The capacity is 130GB, with hardware compression.
The tape device is an AIT 50/130 GB tape drive.
Amanda wrote 43GB when it hit the end of tape.
I don't understand this ... How works AIT tape hardware compression ?
Regards,
InfraNet Tecnologia
Fábio M. A. Cunha
(55 11) 5542-0941 ramal 22
(55 11) 9603-6377
www.infranetsp.com.br
On Sun, 1 Aug 2004 21:17:53 -0300, Fábio Mendonça Albuquerque Cunha fmacunha
escreveu:
De: Fábio Mendonça Albuquerque Cunha fmacunha
Data: Sun, 1 Aug 2004 21:17:53 -0300
Para: Frank Smith fsmith, [EMAIL PROTECTED]
Assunto: Re: Problems with dumps
On Fri, 30 Jul 2004 23:24:21 -0500, Frank Smith fsmith escreveu:
De: Frank Smith fsmith
Data: Fri, 30 Jul 2004 23:24:21 -0500
Para: Fábio Mendonça Albuquerque Cunha fmacunha,[EMAIL PROTECTED]
Assunto: Re: Problems with dumps
--On Friday, July 30, 2004 18:20:08 -0300 Fábio Mendonça Albuquerque Cunha
fmacunha wrote:
Hello guys,
I am trying to do a full backup of 03 filesystems (127 GB), and my tape is an
AIT 50/130 GB tape driver.
My amcheck is OK, no problems found ...
Amdump simply don't work and report me this :
These dumps were to tape fita03.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
Tape is full.
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
You may need to do this.
The next tape Amanda expects to use is: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
servarq.es /projeto2 lev 0 FAILED [dumps too big, 16044295 KB, but
cannot incremental dump new disk]
Not sure why you got this, 16GB should fit on a 50GB tape. Perhaps you
have an incorrect length set in your tapetype?
servarq.es /projeto3 lev 0 STRANGE
Tar encountered some warnings on /projeto3, they are listed below.
STRANGE may or not be a problem, you need to look at it's output below
and decide yourself.
No it's a not a concern at this moment.
servarq.es /projeto1 lev 0 FAILED [out of tape]
The tape filled up while writing this filesystem so it didn't make it
to tape successfully. It may be on your holding disk if you defined one.
If so, run amflush.
But why the tape is filled up? The capacity is 130GB, with hardware compression.
The tape device is an AIT 50/130 GB tape drive.
servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
Possibly you weren't using a holding disk and it was going directly
to tape, so when the tape filled up the pipe closed, terminating the
connection.
servarq.es /projeto1 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:21
Run Time (hrs:min)11:56
Dump Time (hrs:min)5:18 5:18 0:00
Output Size (meg) 17838.917838.90.0
Original Size (meg) 33755.833755.80.0
Avg Compressed Size (%)52.8 52.8--
Filesystems Dumped1 1 0
Avg Dump Rate (k/s) 956.0 956.0--
Tape Time (hrs:min)5:19 5:19 0:00
Tape Size (meg) 17838.917838.90.0
Tape Used (%) 35.7 35.70.0
Filesystems Taped 1 1 0
Avg Tp Write Rate (k/s) 955.5 955.5--
USAGE BY TAPE:
LabelTime Size %Nb
fita03 5:19 17838.9 35.7 1
FAILED AND STRANGE DUMP DETAILS:
/-- servarq.es /projeto3 lev 0 STRANGE
sendbackup: start [servarq.estatica.com.br:/projeto3 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 1.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM
Re: Problems with dumps
On Sun, Aug 01, 2004 at 09:17:53PM -0300, Fábio Mendonça Albuquerque Cunha wrote: On Fri, 30 Jul 2004 23:24:21 -0500, Frank Smith fsmith escreveu: De: Frank Smith fsmith Data: Fri, 30 Jul 2004 23:24:21 -0500 Para: Fábio Mendonça Albuquerque Cunha fmacunha,[EMAIL PROTECTED] Assunto: Re: Problems with dumps --On Friday, July 30, 2004 18:20:08 -0300 Fábio Mendonça Albuquerque Cunha fmacunha wrote: Hello guys, I am trying to do a full backup of 03 filesystems (127 GB), and my tape is an AIT 50/130 GB tape driver. You must differentiate between YOUR data size and the amount of actual data that can be written to a tape. Your vendor's claim of 50/130 GB means the tape itself can hold about 50GB worth of actual written data. With compression, that may represent, according to the vendor, 130GB of YOUR data. If your data are HIGHLY compressible, the vendor MAY be right. A lot of my data can not be compressed at all. Others can be compressed as little as 20% of the original size. Your data are not my data so until you try it, you will not know how compressible your data are. The more random your data are (music, video, encrypted, compiled programs, already compressed zip files, ...) the less it will compress. In fact, random data has a habit of expanding when passed through some compression schemes. Thus, your tape could hold less than 50GB of YOUR data if compression expands it. One form of highly randomized data is already compressed data. If you use amanda's gzip compression AND hardware compression both, your tape may seem smaller than it really is. This may be the explanation for the following situation. NOTES: planner: tapecycle (5) = runspercycle (7) planner: Adding new disk servarq.estatica.com.br:/projeto2. planner: Adding new disk servarq.estatica.com.br:/projeto3. planner: Adding new disk servarq.estatica.com.br:/projeto1. taper: tape fita03 kb 43281440 fm 2 writing file: No space left on device Amanda wrote 43GB when it hit the end of tape. I don't understand this ... How works AIT tape hardware compression ? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Problems with dumps
Hello guys,
I am trying to do a full backup of 03 filesystems (127 GB), and my tape is an AIT
50/130 GB tape driver.
My amcheck is OK, no problems found ...
Amdump simply don't work and report me this :
These dumps were to tape fita03.
*** 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: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
servarq.es /projeto2 lev 0 FAILED [dumps too big, 16044295 KB, but
cannot incremental dump new disk]
servarq.es /projeto3 lev 0 STRANGE
servarq.es /projeto1 lev 0 FAILED [out of tape]
servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
servarq.es /projeto1 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:21
Run Time (hrs:min)11:56
Dump Time (hrs:min)5:18 5:18 0:00
Output Size (meg) 17838.917838.90.0
Original Size (meg) 33755.833755.80.0
Avg Compressed Size (%)52.8 52.8--
Filesystems Dumped1 1 0
Avg Dump Rate (k/s) 956.0 956.0--
Tape Time (hrs:min)5:19 5:19 0:00
Tape Size (meg) 17838.917838.90.0
Tape Used (%) 35.7 35.70.0
Filesystems Taped 1 1 0
Avg Tp Write Rate (k/s) 955.5 955.5--
USAGE BY TAPE:
LabelTime Size %Nb
fita03 5:19 17838.9 35.7 1
FAILED AND STRANGE DUMP DETAILS:
/-- servarq.es /projeto3 lev 0 STRANGE
sendbackup: start [servarq.estatica.com.br:/projeto3 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 1.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 2.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
METRO - S\306o Paulo - 03.035.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/e-mail recebido ate/COMGAS/Fw_
Concorr\210ncia Elabora\207\306o Projeto Executivo - Bols\344es Av_
Jabaquara_Lino Coutinho_Winner_Cardoso Almeida_Ant\223nio Ambuda_Costa
Marina_Ida Kolbi_ERS41_Ripasa Pap\202is Limeira.eml: Warning: Cannot stat:
No such file or directory
? gtar: ./projeto3/COMGAS-1463/e-mail recebido ate/COMGAS/Fw_
Concorr\210ncia Elabora\207\306o Projeto Executivo - Bols\344es Av_
Jabaquara_Lino Coutinho_Winner_Cardoso Almeida_Ant\223nio Ambuda_Costa
Marina_Ida Kolbi_ERS41_Ripasa_Pap\202is Limeira.eml: Warning: Cannot stat:
No such file or directory
| Total bytes written: 35395502080 (33GB, 1.8MB/s)
sendbackup: size 34565920
sendbackup: end
\
/-- servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
sendbackup: start [servarq.estatica.com.br:/projeto1 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
\
NOTES:
planner: tapecycle (5) = runspercycle (7)
planner: Adding new disk servarq.estatica.com.br:/projeto2.
planner: Adding new disk servarq.estatica.com.br:/projeto3.
planner: Adding new disk servarq.estatica.com.br:/projeto1.
taper: tape fita03 kb 43281440 fm 2 writing file: No space left on
device
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
servarq.esta /projeto1 0 FAILED ---
servarq.esta /projeto2 0 FAILED ---
servarq.esta /projeto3 0 3456592018267056 52.8 318:28 956.0 318:37
955.5
(brought to you by Amanda version 2.4.4p3)
At my configuration file I use this options :
define dumptype comp-high {
global
comment very important partitions on fast machines
compress client best
priority high
}
Compress: I supose that option I used the best, but the slowest one, right ? What
the comprresion that is used at this option ? bzip2 ?
At my disklist I use :
my_host.my_domain /dir1 comp-high
my_host.my_domain /dir2 comp-high
my_host.my_domain /dir3 comp-high
my_host.my_domain /dir4 comp-high
Someone could help me ???
Am I providing enough information ?
Regards,
InfraNet Tecnologia
Fábio M. A. Cunha
(55 11) 5542-0941 ramal 22
(55 11) 9603-6377
www.infranetsp.com.br
Re: Problems with dumps
--On Friday, July 30, 2004 18:20:08 -0300 Fábio Mendonça Albuquerque Cunha [EMAIL
PROTECTED] wrote:
Hello guys,
I am trying to do a full backup of 03 filesystems (127 GB), and my tape is an AIT
50/130 GB tape driver.
My amcheck is OK, no problems found ...
Amdump simply don't work and report me this :
These dumps were to tape fita03.
*** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
Tape is full.
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
You may need to do this.
The next tape Amanda expects to use is: a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
servarq.es /projeto2 lev 0 FAILED [dumps too big, 16044295 KB, but
cannot incremental dump new disk]
Not sure why you got this, 16GB should fit on a 50GB tape. Perhaps you
have an incorrect length set in your tapetype?
servarq.es /projeto3 lev 0 STRANGE
Tar encountered some warnings on /projeto3, they are listed below.
STRANGE may or not be a problem, you need to look at it's output below
and decide yourself.
servarq.es /projeto1 lev 0 FAILED [out of tape]
The tape filled up while writing this filesystem so it didn't make it
to tape successfully. It may be on your holding disk if you defined one.
If so, run amflush.
servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
Possibly you weren't using a holding disk and it was going directly
to tape, so when the tape filled up the pipe closed, terminating the
connection.
servarq.es /projeto1 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:21
Run Time (hrs:min)11:56
Dump Time (hrs:min)5:18 5:18 0:00
Output Size (meg) 17838.917838.90.0
Original Size (meg) 33755.833755.80.0
Avg Compressed Size (%)52.8 52.8--
Filesystems Dumped1 1 0
Avg Dump Rate (k/s) 956.0 956.0--
Tape Time (hrs:min)5:19 5:19 0:00
Tape Size (meg) 17838.917838.90.0
Tape Used (%) 35.7 35.70.0
Filesystems Taped 1 1 0
Avg Tp Write Rate (k/s) 955.5 955.5--
USAGE BY TAPE:
LabelTime Size %Nb
fita03 5:19 17838.9 35.7 1
FAILED AND STRANGE DUMP DETAILS:
/-- servarq.es /projeto3 lev 0 STRANGE
sendbackup: start [servarq.estatica.com.br:/projeto3 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 1.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
CPTM - S\306o Paulo - 03.035 - 2.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/Enrique/Cartas a Tramitar/oficio 04-08xx -
METRO - S\306o Paulo - 03.035.doc: Warning: Cannot stat: No such file or
directory
? gtar: ./projeto3/COMGAS-1463/e-mail recebido ate/COMGAS/Fw_
Concorr\210ncia Elabora\207\306o Projeto Executivo - Bols\344es Av_
Jabaquara_Lino Coutinho_Winner_Cardoso Almeida_Ant\223nio Ambuda_Costa
Marina_Ida Kolbi_ERS41_Ripasa Pap\202is Limeira.eml: Warning: Cannot stat:
No such file or directory
? gtar: ./projeto3/COMGAS-1463/e-mail recebido ate/COMGAS/Fw_
Concorr\210ncia Elabora\207\306o Projeto Executivo - Bols\344es Av_
Jabaquara_Lino Coutinho_Winner_Cardoso Almeida_Ant\223nio Ambuda_Costa
Marina_Ida Kolbi_ERS41_Ripasa_Pap\202is Limeira.eml: Warning: Cannot stat:
No such file or directory
All these files disappeared between the time tar made its filelist and
the time it tried to read them. The result of backing up a busy
filesystem. May or may not be a concern to you.
| Total bytes written: 35395502080 (33GB, 1.8MB/s)
sendbackup: size 34565920
sendbackup: end
\
/-- servarq.es /projeto1 lev 0 FAILED [data write: Connection reset by
peer]
sendbackup: start [servarq.estatica.com.br:/projeto1 level 0]
sendbackup: info BACKUP=/bin/gtar
sendbackup: info RECOVER_CMD=/bin/gtar -f... -
sendbackup: info end
\
NOTES:
planner: tapecycle (5) = runspercycle (7)
planner: Adding new disk servarq.estatica.com.br:/projeto2.
planner: Adding new disk servarq.estatica.com.br:/projeto3.
planner: Adding new disk servarq.estatica.com.br:/projeto1.
taper: tape fita03 kb 43281440 fm 2 writing file: No space left on
device
Amanda wrote 43GB when it hit the end of tape.
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
Problems with dumps
Hi all, I'm having trouble getting one of my clients backed up. There are 13 file systems on the client which need to be dumped, totalling about 12GB of data. I'm getting error messages like the following for several of the file systems: hacluster1 /dev/sda12 lev 0 FAILED [dumps too big, but cannot\ incremental dump skip-incr disk] I know that amanda seems to think that the dumps are too big, and failing these file systems because I've dis-allowed incremental backups. However, I've also specified the use of 2 tapes for the backups, and amanda doesn't seem to be filling both: Estimate Time (hrs:min)0:10 Run Time (hrs:min) 9:26 Dump Time (hrs:min)7:51 7:49 0:02 Output Size (meg) 54711.454709.12.2 Original Size (meg) 89777.289755.3 22.0 Avg Compressed Size (%)60.9 61.0 10.2 (level:#disks ...) Filesystems Dumped 33 28 5 (1:5) Avg Dump Rate (k/s) 1981.3 1991.6 15.7 Tape Time (hrs:min)6:50 6:50 0:00 Tape Size (meg) 54712.454710.02.4 Tape Used (%) 156.3 156.30.0 (level:#disks ...) Filesystems Taped33 28 5 (1:5) From the 'Tape Used' it appears that amanda is only filling 50% of the second tape. The 'Tape Size' seems to indicate I'm only filling about 55GB worth of tape. I'm using a DLT7000 drive with DLT4 tapes. I should be able to get 70GBs worth of data across 2 tapes, no? So, I should be able to get another 15GBs onto the second tape, by my calculations, which is fine, since there's less than 12GB currently failing. Any ideas? Thanks, -- Seeya, Paul God Bless America! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon
RE: Problems with dumps
Paul, A couple of things might help track down where the problem is coming from. First, if you can add a third tape to a run, that will indicate whether the problem is with AMANDA's tape size estimate or not. Next, do you have enough holding disk space for that backup? You can test this by configuring that entry in disklist to use a backup type that does not go to the holding disk. That should help narrow down where the limitation is. Paul -Original Message- From: Paul Lussier [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 11:35 AM To: [EMAIL PROTECTED] Subject: Problems with dumps Hi all, I'm having trouble getting one of my clients backed up. There are 13 file systems on the client which need to be dumped, totalling about 12GB of data. I'm getting error messages like the following for several of the file systems: hacluster1 /dev/sda12 lev 0 FAILED [dumps too big, but cannot\ incremental dump skip-incr disk] I know that amanda seems to think that the dumps are too big, and failing these file systems because I've dis-allowed incremental backups. However, I've also specified the use of 2 tapes for the backups, and amanda doesn't seem to be filling both: Estimate Time (hrs:min)0:10 Run Time (hrs:min) 9:26 Dump Time (hrs:min)7:51 7:49 0:02 Output Size (meg) 54711.454709.12.2 Original Size (meg) 89777.289755.3 22.0 Avg Compressed Size (%)60.9 61.0 10.2 (level:#disks ...) Filesystems Dumped 33 28 5 (1:5) Avg Dump Rate (k/s) 1981.3 1991.6 15.7 Tape Time (hrs:min)6:50 6:50 0:00 Tape Size (meg) 54712.454710.02.4 Tape Used (%) 156.3 156.30.0 (level:#disks ...) Filesystems Taped33 28 5 (1:5) From the 'Tape Used' it appears that amanda is only filling 50% of the second tape. The 'Tape Size' seems to indicate I'm only filling about 55GB worth of tape. I'm using a DLT7000 drive with DLT4 tapes. I should be able to get 70GBs worth of data across 2 tapes, no? So, I should be able to get another 15GBs onto the second tape, by my calculations, which is fine, since there's less than 12GB currently failing. Any ideas? Thanks, -- Seeya, Paul God Bless America! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon
Problems with dumps
Hi all, I'm having trouble getting one of my clients backed up. There are 13 file systems on the client which need to be dumped, totalling about 12GB of data. I'm getting error messages like the following for several of the file systems: hacluster1 /dev/sda12 lev 0 FAILED [dumps too big, but cannot\ incremental dump skip-incr disk] I know that amanda seems to think that the dumps are too big, and failing these file systems because I've dis-allowed incremental backups. However, I've also specified the use of 2 tapes for the backups, and amanda doesn't seem to be filling both: Estimate Time (hrs:min)0:10 Run Time (hrs:min) 9:26 Dump Time (hrs:min)7:51 7:49 0:02 Output Size (meg) 54711.454709.12.2 Original Size (meg) 89777.289755.3 22.0 Avg Compressed Size (%)60.9 61.0 10.2 (level:#disks ...) Filesystems Dumped 33 28 5 (1:5) Avg Dump Rate (k/s) 1981.3 1991.6 15.7 Tape Time (hrs:min)6:50 6:50 0:00 Tape Size (meg) 54712.454710.02.4 Tape Used (%) 156.3 156.30.0 (level:#disks ...) Filesystems Taped33 28 5 (1:5) From the 'Tape Used' it appears that amanda is only filling 50% of the second tape. The 'Tape Size' seems to indicate I'm only filling about 55GB worth of tape. I'm using a DLT7000 drive with DLT4 tapes. I should be able to get 70GBs worth of data across 2 tapes, no? So, I should be able to get another 15GBs onto the second tape, by my calculations, which is fine, since there's less than 12GB currently failing. Any ideas? Thanks, -- Seeya, Paul God Bless America! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon
RE: Problems with dumps
Paul, A couple of things might help track down where the problem is coming from. First, if you can add a third tape to a run, that will indicate whether the problem is with AMANDA's tape size estimate or not. Next, do you have enough holding disk space for that backup? You can test this by configuring that entry in disklist to use a backup type that does not go to the holding disk. That should help narrow down where the limitation is. Paul -Original Message- From: Paul Lussier [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 03, 2002 11:35 AM To: [EMAIL PROTECTED] Subject: Problems with dumps Hi all, I'm having trouble getting one of my clients backed up. There are 13 file systems on the client which need to be dumped, totalling about 12GB of data. I'm getting error messages like the following for several of the file systems: hacluster1 /dev/sda12 lev 0 FAILED [dumps too big, but cannot\ incremental dump skip-incr disk] I know that amanda seems to think that the dumps are too big, and failing these file systems because I've dis-allowed incremental backups. However, I've also specified the use of 2 tapes for the backups, and amanda doesn't seem to be filling both: Estimate Time (hrs:min)0:10 Run Time (hrs:min) 9:26 Dump Time (hrs:min)7:51 7:49 0:02 Output Size (meg) 54711.454709.12.2 Original Size (meg) 89777.289755.3 22.0 Avg Compressed Size (%)60.9 61.0 10.2 (level:#disks ...) Filesystems Dumped 33 28 5 (1:5) Avg Dump Rate (k/s) 1981.3 1991.6 15.7 Tape Time (hrs:min)6:50 6:50 0:00 Tape Size (meg) 54712.454710.02.4 Tape Used (%) 156.3 156.30.0 (level:#disks ...) Filesystems Taped33 28 5 (1:5) From the 'Tape Used' it appears that amanda is only filling 50% of the second tape. The 'Tape Size' seems to indicate I'm only filling about 55GB worth of tape. I'm using a DLT7000 drive with DLT4 tapes. I should be able to get 70GBs worth of data across 2 tapes, no? So, I should be able to get another 15GBs onto the second tape, by my calculations, which is fine, since there's less than 12GB currently failing. Any ideas? Thanks, -- Seeya, Paul God Bless America! ...we don't need to be perfect to be the best around, and we never stop trying to be better. Tom Clancy, The Bear and The Dragon
3 Problems involving dumps
I have three simple questions: 1) I am getting warning messages like: bandai c0t2d0s3 lev 0 FAILED [dumps too big, but cannot incremental dump new disk] bandai c0t2d0s0 lev 0 FAILED [dumps too big, but cannot incremental dump new disk] tyco c0t5d0s1 lev 0 FAILED [dumps too big, but cannot incremental dump new disk] tyco c0t5d0s0 lev 0 FAILED [dumps too big, but cannot incremental dump new disk] cs c0t0d0s5 lev 7 FAILED [writing file: short write] But the holding disk is far bigger than the areas that are trying to be backed up and the amanda.conf allocates almost all of it to backups. We dont know why this is happening. The machines are all comp-user dump types. 2) If I want to perform multiple dumps in the same day in order to try to fix some of the backup problems I am having, will that seriously mess with the date accounting software, the stuff that records dumpdates etc? 3) Which is the setting that gives the best compression on a fast system where time is not an issue? comp-user, comp-root, comp-high Thanks, Michael Campfield Labstaff Computer Science Department University of Tennessee
