Re: backup just on holding disks makes many level 0
On Tue, 2006-03-14 at 22:49 +0100, Stefan G. Weichinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Widhalm schrieb:
Have you tried resetting some parameters like bumpsize, bumpmult,
and bumpdays? They may have an affect on your situation.
This could really be it. bumpsize was set 100Mb. Maybe, because this
setup was used to backup on a tape just once in a week. Unfortunately I
had to take over the whole machine without having time to look through
the configuration too much.
If that didn't solve your issues you maybe share your config with us.
This would help to get the picture.
Ok. It's below
You mentioned you had to take over that server:
Do you have any experience with Amanda already or not?
Well. All my experience with amanda I got with experimenting with this
server.
Stefan.
amanda-shared.conf:
#
# amanda.conf - sample Amanda configuration file. This started off life
as
# the actual config file in use at CS.UMD.EDU.
#
# If your configuration is called, say, csd, then this file normally
goes
# in /etc/amanda/csd/amanda.conf.
#
mailto root # space separated list of operators at your site
dumpuser amanda # the user to run dumps under
netusage 10 Kbps # maximum net bandwidth for Amanda, in KB per
sec
# 4 weeks (dumpcycle) times 5 tapes per week
(just
# the weekdays) plus a few to handle errors that
# need amflush and so we do not overwrite the
full
# backups performed at the beginning of the
previous
# cycle
maxdumps 1
### ### ###
# WARNING: don't use `inf' for tapecycle, it's broken!
### ### ###
bumpsize 10 Mb # minimum savings (threshold) to bump level 1 -
2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
etimeout 1800 # number of seconds per filesystem for
estimates.
#etimeout -600 # total number of seconds for estimates.
# a positive number will be multiplied by the number of filesystems on
# each host; a negative number will be taken as an absolute total time-
out.
# The default is 5 minutes per filesystem.
# Specify tape device and/or tape changer. If you don't have a tape
# changer, and you don't want to use more than one tape per run of
# amdump, just comment out the definition of tpchanger.
# Some tape changers require tapedev to be defined; others will use
# their own tape device selection mechanism. Some use a separate tape
# changer device (changerdev), others will simply ignore this
# parameter. Some rely on a configuration file (changerfile) to
# obtain more information about tape devices, number of slots, etc;
# others just need to store some data in files, whose names will start
# with changerfile. For more information about individual tape
# changers, read docs/TAPE.CHANGERS.
# At most one changerfile entry must be defined; select the most
# appropriate one for your configuration. If you select man-changer,
# keep the first one; if you decide not to use a tape changer, you may
# comment them all out.
runtapes 1 # number of tapes to be used in a single run of
amdump
#tpchanger chg-manual # the tape-changer glue script
#tapedev file:/data/amanda/ # the no-rewind tape device to be used
#tapedev no-such-device # the no-rewind tape device to be used
#tapedev /dev/null# the no-rewind tape device to be used
#rawtapedev /dev/null # the raw device to be used (ftape only)
#rawtapedev no-such-device# the raw device to be used (ftape only)
#changerfile /var/lib/amanda/DailySet1/changer
#changerfile /var/lib/amanda/DailySet1/changer-status
#changerfile /etc/amanda/DailySet1/changer.conf
#changerdev /dev/null
#changerdev no-such-device
#tapetype HP-DAT# what kind of tape it is (see tapetypes
below)
#labelstr ^DailySet1[0-9][0-9]*$ # label constraint regex: all
tapes must match
#tapetype CISOS-notape
#labelstr ^ONYX[0-9][0-9]*$ # label constraint regex: all tapes must
match
# Specify holding disks. These are used as a temporary staging area for
# dumps before they are written to tape and are recommended for most
sites.
# The advantages include: tape drive is more likely to operate in
streaming
# mode (which reduces tape and drive wear, reduces total dump time);
multiple
# dumps can be done in parallel (which can dramatically reduce total
dump time.
# The main disadvantage is that dumps on the holding disk need to be
flushed
# (with amflush) to tape after an operating system crash or a tape
failure.
# If no holding disks are specified then all dumps will be written
directly
# to tape. If a dump is too big to fit on the holding disk than it will
be
# written directly to tape. If more than one holding disk is specified
then
# they will all be used round-robin.
#holdingdisk hd2 {
#directory
Ultrium tapetype
Here is the tapetype I got for my HP SorageWorks 960
Ultrium 3 unit.
Hopefully it will help others.
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 386048 mbytes
filemark 0 kbytes
speed 49993 kps
}
--
U.S. Encouraged by Vietnam Vote - Officials Cite 83% Turnout Despite Vietcong
Terror
- New York Times 9/3/1967
Re: backup just on holding disks makes many level 0
On Tue, 2006-03-14 at 22:49 +0100, Stefan G. Weichinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Widhalm schrieb:
Have you tried resetting some parameters like bumpsize, bumpmult,
and bumpdays? They may have an affect on your situation.
This could really be it. bumpsize was set 100Mb. Maybe, because this
setup was used to backup on a tape just once in a week. Unfortunately I
had to take over the whole machine without having time to look through
the configuration too much.
If that didn't solve your issues you maybe share your config with us.
This would help to get the picture.
Here are the 2 parts of the config:
first file:
#
# amanda.conf - sample Amanda configuration file. This started off life
as
# the actual config file in use at CS.UMD.EDU.
#
# If your configuration is called, say, csd, then this file normally
goes
# in /etc/amanda/csd/amanda.conf.
#
mailto root # space separated list of operators at your site
dumpuser amanda # the user to run dumps under
netusage 10 Kbps # maximum net bandwidth for Amanda, in KB per
sec
# 4 weeks (dumpcycle) times 5 tapes per week
(just
# the weekdays) plus a few to handle errors that
# need amflush and so we do not overwrite the
full
# backups performed at the beginning of the
previous
# cycle
maxdumps 1
### ### ###
# WARNING: don't use `inf' for tapecycle, it's broken!
### ### ###
bumpsize 10 Mb # minimum savings (threshold) to bump level 1 -
2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
etimeout 1800 # number of seconds per filesystem for
estimates.
#etimeout -600 # total number of seconds for estimates.
# a positive number will be multiplied by the number of filesystems on
# each host; a negative number will be taken as an absolute total time-
out.
# The default is 5 minutes per filesystem.
# Specify tape device and/or tape changer. If you don't have a tape
# changer, and you don't want to use more than one tape per run of
# amdump, just comment out the definition of tpchanger.
# Some tape changers require tapedev to be defined; others will use
# their own tape device selection mechanism. Some use a separate tape
# changer device (changerdev), others will simply ignore this
# parameter. Some rely on a configuration file (changerfile) to
# obtain more information about tape devices, number of slots, etc;
# others just need to store some data in files, whose names will start
# with changerfile. For more information about individual tape
# changers, read docs/TAPE.CHANGERS.
# At most one changerfile entry must be defined; select the most
# appropriate one for your configuration. If you select man-changer,
# keep the first one; if you decide not to use a tape changer, you may
# comment them all out.
runtapes 1 # number of tapes to be used in a single run of
amdump
#tpchanger chg-manual # the tape-changer glue script
#tapedev file:/data/amanda/ # the no-rewind tape device to be used
#tapedev no-such-device # the no-rewind tape device to be used
#tapedev /dev/null# the no-rewind tape device to be used
#rawtapedev /dev/null # the raw device to be used (ftape only)
#rawtapedev no-such-device# the raw device to be used (ftape only)
#changerfile /var/lib/amanda/DailySet1/changer
#changerfile /var/lib/amanda/DailySet1/changer-status
#changerfile /etc/amanda/DailySet1/changer.conf
#changerdev /dev/null
#changerdev no-such-device
#tapetype HP-DAT# what kind of tape it is (see tapetypes
below)
#labelstr ^DailySet1[0-9][0-9]*$ # label constraint regex: all
tapes must match
#tapetype CISOS-notape
#labelstr ^ONYX[0-9][0-9]*$ # label constraint regex: all tapes must
match
# Specify holding disks. These are used as a temporary staging area for
# dumps before they are written to tape and are recommended for most
sites.
# The advantages include: tape drive is more likely to operate in
streaming
# mode (which reduces tape and drive wear, reduces total dump time);
multiple
# dumps can be done in parallel (which can dramatically reduce total
dump time.
# The main disadvantage is that dumps on the holding disk need to be
flushed
# (with amflush) to tape after an operating system crash or a tape
failure.
# If no holding disks are specified then all dumps will be written
directly
# to tape. If a dump is too big to fit on the holding disk than it will
be
# written directly to tape. If more than one holding disk is specified
then
# they will all be used round-robin.
#holdingdisk hd2 {
#directory /dumps2/amanda
#use 1000 Mb
#}
#holdingdisk hd3 {
#directory /mnt/disk4
#use 1000 Mb
#}
# If amanda cannot find a tape on which to store backups, it will run
# as many
Re: Ultrium tapetype
On Wed, 15 Mar 2006 at 6:50am, stan wrote
Here is the tapetype I got for my HP SorageWorks 960
Ultrium 3 unit.
Hopefully it will help others.
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 386048 mbytes
filemark 0 kbytes
speed 49993 kps
}
FYI, I found that I got faster speeds with LTO3 by using larger than the
default blocksize of 32KB. My nightly amanda backups get ~70MB/s using
2MB blocks.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
Re: Ultrium tapetype
Joshua Baker-LePain wrote: FYI, I found that I got faster speeds with LTO3 by using larger than the default blocksize of 32KB. My nightly amanda backups get ~70MB/s using 2MB blocks. Hrm... I'm not being tapespeed limited (yet), but where do you configure the blocksize in Amanda? Graeme -- Graeme Humphries ([EMAIL PROTECTED]) (306) 955-7075 ext. 485 My views are not the views of my employers.
Re: backup just on holding disks makes many level 0
On Wed, Mar 15, 2006 at 01:03:51PM +0100, Thomas Widhalm wrote:
On Tue, 2006-03-14 at 22:49 +0100, Stefan G. Weichinger wrote:
If that didn't solve your issues you maybe share your config with us.
This would help to get the picture.
Here are the 2 parts of the config:
I took the liberty of deleting the comments and unneeded
tapetypes/dumptypes. 800 lines dropped to about 50.
Hope I did not drop anything significant to the discussion.
Amazing how simple amanda.conf can become.
I put two questions inline.
||
|| Here are the 2 parts of the config:
||
|| first file:
|| =
||
|| mailto root
|| dumpuser amanda
|| netusage 10 Kbps
|| maxdumps 1
||
|| bumpsize 10 Mb
|| bumpdays 1
|| bumpmult 4
||
|| etimeout 1800
||
|| runtapes 1
|| reserve 0
||
|| define tapetype DEC-TZ89 {
|| comment DEC TZ89 (hardware compression on: Xmn)
|| length 29414 mbytes
|| filemark 24 kbytes
|| speed 1634 kps
|| }
||
|| ==
||
|| and the other:
||
|| ==
||
|| org IS
||
|| inparallel 1
||
|| dumpcycle 8
|| runspercycle 0
|| tapecycle 4
Not sure I understand this set of parameters.
runspercycle == 0 causes all level 0 dumps I believe.
In that case the length of the dumpcycle is immaterial.
Each time you run amdump, everything will get full dumps.
Are you saying you plan to run amdump once each 8 days
and that you want only level 0 dumps each run?
And further, you will rotate 4 tapes totaling 32 days
of backups available?
||
|| holdingdisk hd1 {
|| comment main holding disk for IS
|| directory /data/amanda/IS
|| use -1
|| chunksize 2 Gb
|| }
||
||
|| tapedev /dev/null
|| tapetype DEC-TZ89
Is your DEC tapedrive really attached to the null device?
Doesn't work very well that way does it? :))
|| labelstr ^IS[0-9][0-9]*$
||
|| infofile /var/lib/amanda/IS/curinfo
|| logdir /var/lib/amanda/IS
|| indexdir /var/lib/amanda/IS/index
||
|| includefile /etc/amanda/amanda-shared.conf
||
|| ===
||
|| the first file is used by all configs. The second one is one specific
|| config.
||
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Ultrium tapetype
On Wed, 15 Mar 2006 at 8:40am, Graeme Humphries wrote Joshua Baker-LePain wrote: FYI, I found that I got faster speeds with LTO3 by using larger than the default blocksize of 32KB. My nightly amanda backups get ~70MB/s using 2MB blocks. Hrm... I'm not being tapespeed limited (yet), but where do you configure the blocksize in Amanda? Well, you have to be careful with LTO3. You want to feed the tape at at least 1/2 native speed (native speed is rated to be 80MB/s). Slower than that, and the drive will have to start and stop the tape frequently (aka shoe-shining), which is bad for both tapes and the drive (and capacity, for that matter). This generally means actually putting some thought/$$ into the backup server's disk system. For amdump and friends, blocksize is set in the tapetype. For amtapetype, you can set it on the command line. 'man amanda.conf' and 'man amtapetype' are your friends. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Ultrium tapetype
Joshua Baker-LePain wrote: Well, you have to be careful with LTO3. You want to feed the tape at at least 1/2 native speed (native speed is rated to be 80MB/s). Slower than that, and the drive will have to start and stop the tape frequently (aka shoe-shining), which is bad for both tapes and the drive (and capacity, for that matter). This generally means actually putting some thought/$$ into the backup server's disk system. Yep, I'm not having any problems there, I've got some SATA discs in RAID 0 for the dump drives, so they can blast out at 60+MB/sec. For amdump and friends, blocksize is set in the tapetype. For amtapetype, you can set it on the command line. 'man amanda.conf' and 'man amtapetype' are your friends. Cool, I'll look into that, I'm actually upgrading out backup server today, so now's a good time to play with that. Thanks! Graeme -- Graeme Humphries ([EMAIL PROTECTED]) (306) 955-7075 ext. 485 My views are not the views of my employers.
Re: backup just on holding disks makes many level 0
On Wed, 2006-03-15 at 09:45 -0500, Jon LaBadie wrote:
On Wed, Mar 15, 2006 at 01:03:51PM +0100, Thomas Widhalm wrote:
On Tue, 2006-03-14 at 22:49 +0100, Stefan G. Weichinger wrote:
If that didn't solve your issues you maybe share your config with us.
This would help to get the picture.
Here are the 2 parts of the config:
I took the liberty of deleting the comments and unneeded
tapetypes/dumptypes. 800 lines dropped to about 50.
Hope I did not drop anything significant to the discussion.
So sorry. We had a lot of troubles migrating our other servers from
legato to data protector, so I missed to clean the files before posting.
I'm really ver sorry.
Amazing how simple amanda.conf can become.
I put two questions inline.
||
|| Here are the 2 parts of the config:
||
|| first file:
|| =
||
|| mailto root
|| dumpuser amanda
|| netusage 10 Kbps
|| maxdumps 1
||
|| bumpsize 10 Mb
|| bumpdays 1
|| bumpmult 4
||
|| etimeout 1800
||
|| runtapes 1
|| reserve 0
||
|| define tapetype DEC-TZ89 {
|| comment DEC TZ89 (hardware compression on: Xmn)
|| length 29414 mbytes
|| filemark 24 kbytes
|| speed 1634 kps
|| }
||
|| ==
||
|| and the other:
||
|| ==
||
|| org IS
||
|| inparallel 1
||
|| dumpcycle 8
|| runspercycle 0
|| tapecycle 4
Not sure I understand this set of parameters.
runspercycle == 0 causes all level 0 dumps I believe.
In that case the length of the dumpcycle is immaterial.
Each time you run amdump, everything will get full dumps.
runspercycle = 0 means same as tapecycle as mentionend in another post
here. If this is not correct (at least the docu says, it is correct)
than please tell me. I want amanda to know that there is one run every
day, despite of manual runs after fixing errors.
Are you saying you plan to run amdump once each 8 days
and that you want only level 0 dumps each run?
And further, you will rotate 4 tapes totaling 32 days
of backups available?
I removed all tapes from the config. I just save to the holding disk. I
can live with the daily tape error, but I want amanda to do less full
backups.
||
|| holdingdisk hd1 {
|| comment main holding disk for IS
|| directory /data/amanda/IS
|| use -1
|| chunksize 2 Gb
|| }
||
||
|| tapedev /dev/null
|| tapetype DEC-TZ89
Is your DEC tapedrive really attached to the null device?
Doesn't work very well that way does it? :))
It is disconnected from the server as it produced some driver problems
recently. So we switched to backup to the holdingsdisk.
|| labelstr ^IS[0-9][0-9]*$
||
|| infofile /var/lib/amanda/IS/curinfo
|| logdir /var/lib/amanda/IS
|| indexdir /var/lib/amanda/IS/index
||
|| includefile /etc/amanda/amanda-shared.conf
||
|| ===
||
|| the first file is used by all configs. The second one is one specific
|| config.
||
--
*
* Thomas Widhalm Unix Administrator *
* University of Salzburg ITServices (ITS) *
* Systems Management Unix Systems *
* Hellbrunnerstr. 34 5020 Salzburg, Austria *
* [EMAIL PROTECTED] +43/662/8044-6774 *
* gpg: 6265BAE6 *
* http://www.sbg.ac.at/zid/organisation/mitarbeiter/widhalm.htm *
*
signature.asc
Description: This is a digitally signed message part
Re: Ultrium tapetype
Joshua Baker-LePain wrote: For amdump and friends, blocksize is set in the tapetype. For amtapetype, you can set it on the command line. 'man amanda.conf' and 'man amtapetype' are your friends. When changing the blocksize, will amanda happily read (restore) older tapes written with a different blocksize, or will I have to recover them manually? Will she correctly overwrite recycled tapes with the new blocksize? Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
Re: Ultrium tapetype
Alexander Jolk wrote: When changing the blocksize, will amanda happily read (restore) older tapes written with a different blocksize, or will I have to recover them manually? Will she correctly overwrite recycled tapes with the new blocksize? I believe the blocksize just affects how much data is read/written at once to/from the tape, it doesn't affect the actual data at all. Someone please correct me if I'm wrong? :) Graeme
Re: backup just on holding disks makes many level 0
On Wednesday 15 March 2006 04:48, Thomas Widhalm wrote:
On Tue, 2006-03-14 at 22:49 +0100, Stefan G. Weichinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Widhalm schrieb:
Have you tried resetting some parameters like bumpsize, bumpmult,
and bumpdays? They may have an affect on your situation.
This could really be it. bumpsize was set 100Mb. Maybe, because
this setup was used to backup on a tape just once in a week.
Unfortunately I had to take over the whole machine without having
time to look through the configuration too much.
If that didn't solve your issues you maybe share your config with
us. This would help to get the picture.
Ok. It's below
You mentioned you had to take over that server:
Do you have any experience with Amanda already or not?
Well. All my experience with amanda I got with experimenting with this
server.
Stefan.
amanda-shared.conf:
#
# amanda.conf - sample Amanda configuration file. This started off
life as
# the actual config file in use at CS.UMD.EDU.
#
# If your configuration is called, say, csd, then this file normally
goes
# in /etc/amanda/csd/amanda.conf.
#
mailto root # space separated list of operators at your
site dumpuser amanda # the user to run dumps under
netusage 10 Kbps # maximum net bandwidth for Amanda, in KB per
sec
# 4 weeks (dumpcycle) times 5 tapes per week
(just
# the weekdays) plus a few to handle errors
that # need amflush and so we do not overwrite the full
# backups performed at the beginning of the
previous
# cycle
maxdumps 1
Even afer I back out the line wrapping, I cannot find any of the
keywords 'dumpcycle', 'runspercycle', or 'tapecycle'
in this listing, so I would call this amanda.conf broken. And I'm not
sure if 'maxdumps 1' is a valid keyword.
Have you not run am 'amcheck nameofconfig_dir' on this? I'm sure it
will note errors about this.
[... most of remainder]
# You may include other amanda configuration files, so you can share
# dumptypes, tapetypes and interface definitions among several
# configurations.
#includefile /usr/local/amanda.conf.main
one of the amanda.confs:
org IS # your organization name for reports
inparallel 1 # maximum dumpers that will run in parallel
dumpcycle 8 # the number of days in the normal dump cycle
runspercycle 0 # the number of amdump runs in dumpcycle days
tapecycle 4 tapes # the number of tapes in rotation
This is not enough tapes, you need at least 1.5x dumpcycle tapes in
order to have a full backup on hand at all times.
# 4 weeks (dumpcycle) times 5 tapes per week
(just
# the weekdays) plus a few to handle errors
that # need amflush and so we do not overwrite the full
# backups performed at the beginning of the
previous
# cycle
holdingdisk hd1 {
comment main holding disk for IS
directory /data/amanda/IS# where the holding disk is
use -1 # how much space can we use on it
#use 70 Mb # how much space can we use on it
# a negative value mean:
#use all space except that value
chunksize 2 Gb # size of chunk if you want big dump to be
# dumped on multiple files on holding disks
# N Kb/Mb/Gb split disks in chunks of size N
# 0 split disks in INT_MAX/1024 Kb
chunks
# -N Kb/Mb/Gb dont split, dump larger
# filesystems directly to tape
# (example: -2 Gb)
}
#tapedev /dev/rmt/0mn# the no-rewind tape device to be used
#da 2.band defekt... #tapedev /dev/nst1# the no-rewind tape
device to be used
#tapedev /dev/nst0# the no-rewind tape device to be used
tapedev /dev/null
tapetype DEC-TZ89 # see tapetype in amanda-shared.conf
labelstr ^IS[0-9][0-9]*$# label constraint regex: all tapes must
match
infofile /var/lib/amanda/IS/curinfo# database filename
logdir /var/lib/amanda/IS# log directory
indexdir /var/lib/amanda/IS/index # index directory
includefile /etc/amanda/amanda-shared.conf
I was thrown off by your doing the incouded files in reverse of their
useage, so I did not see the include line at first.
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
Re: backup just on holding disks makes many level 0
On Wednesday 15 March 2006 07:03, Thomas Widhalm wrote:
On Tue, 2006-03-14 at 22:49 +0100, Stefan G. Weichinger wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Widhalm schrieb:
Have you tried resetting some parameters like bumpsize, bumpmult,
and bumpdays? They may have an affect on your situation.
This could really be it. bumpsize was set 100Mb. Maybe, because
this setup was used to backup on a tape just once in a week.
Unfortunately I had to take over the whole machine without having
time to look through the configuration too much.
If that didn't solve your issues you maybe share your config with
us. This would help to get the picture.
Here are the 2 parts of the config:
first file:
But what is this files name?
#
# amanda.conf - sample Amanda configuration file. This started off
life as
# the actual config file in use at CS.UMD.EDU.
#
# If your configuration is called, say, csd, then this file normally
goes
# in /etc/amanda/csd/amanda.conf.
#
mailto root # space separated list of operators at your
site dumpuser amanda # the user to run dumps under
netusage 10 Kbps # maximum net bandwidth for Amanda, in KB per
sec
# 4 weeks (dumpcycle) times 5 tapes per week
(just
# the weekdays) plus a few to handle errors
that # need amflush and so we do not overwrite the full
# backups performed at the beginning of the
previous
# cycle
maxdumps 1
### ### ###
# WARNING: don't use `inf' for tapecycle, it's broken!
### ### ###
bumpsize 10 Mb # minimum savings (threshold) to bump level 1
- 2
bumpdays 1 # minimum days at each level
bumpmult 4 # threshold = bumpsize * bumpmult^(level-1)
etimeout 1800 # number of seconds per filesystem for
estimates.
#etimeout -600 # total number of seconds for estimates.
# a positive number will be multiplied by the number of filesystems on
# each host; a negative number will be taken as an absolute total
time- out.
# The default is 5 minutes per filesystem.
# Specify tape device and/or tape changer. If you don't have a tape
# changer, and you don't want to use more than one tape per run of
# amdump, just comment out the definition of tpchanger.
# Some tape changers require tapedev to be defined; others will use
# their own tape device selection mechanism. Some use a separate tape
# changer device (changerdev), others will simply ignore this
# parameter. Some rely on a configuration file (changerfile) to
# obtain more information about tape devices, number of slots, etc;
# others just need to store some data in files, whose names will start
# with changerfile. For more information about individual tape
# changers, read docs/TAPE.CHANGERS.
# At most one changerfile entry must be defined; select the most
# appropriate one for your configuration. If you select man-changer,
# keep the first one; if you decide not to use a tape changer, you may
# comment them all out.
runtapes 1 # number of tapes to be used in a single run
of amdump
#tpchanger chg-manual # the tape-changer glue script
#tapedev file:/data/amanda/ # the no-rewind tape device to be used
#tapedev no-such-device # the no-rewind tape device to be used
#tapedev /dev/null# the no-rewind tape device to be used
#rawtapedev /dev/null # the raw device to be used (ftape only)
#rawtapedev no-such-device# the raw device to be used (ftape
only) #changerfile /var/lib/amanda/DailySet1/changer
#changerfile /var/lib/amanda/DailySet1/changer-status
#changerfile /etc/amanda/DailySet1/changer.conf
#changerdev /dev/null
#changerdev no-such-device
#tapetype HP-DAT# what kind of tape it is (see
tapetypes below)
#labelstr ^DailySet1[0-9][0-9]*$ # label constraint regex: all
tapes must match
#tapetype CISOS-notape
#labelstr ^ONYX[0-9][0-9]*$ # label constraint regex: all tapes
must match
# Specify holding disks. These are used as a temporary staging area
for # dumps before they are written to tape and are recommended for
most sites.
# The advantages include: tape drive is more likely to operate in
streaming
# mode (which reduces tape and drive wear, reduces total dump time);
multiple
# dumps can be done in parallel (which can dramatically reduce total
dump time.
# The main disadvantage is that dumps on the holding disk need to be
flushed
# (with amflush) to tape after an operating system crash or a tape
failure.
# If no holding disks are specified then all dumps will be written
directly
# to tape. If a dump is too big to fit on the holding disk than it
will be
# written directly to tape. If more than one holding disk is
specified then
# they will all be used round-robin.
#holdingdisk hd2 {
#directory /dumps2/amanda
#use 1000 Mb
#}
#holdingdisk hd3 {
#directory /mnt/disk4
#use 1000 Mb
#}
# If amanda cannot find a tape on
Re: backup just on holding disks makes many level 0
Thomas Widhalm schrieb:
I removed all tapes from the config. I just save to the holding disk. I
can live with the daily tape error, but I want amanda to do less full
backups.
||
|| holdingdisk hd1 {
|| comment main holding disk for IS
|| directory /data/amanda/IS
|| use -1
|| chunksize 2 Gb
|| }
||
||
|| tapedev /dev/null
|| tapetype DEC-TZ89
Is your DEC tapedrive really attached to the null device?
Doesn't work very well that way does it? :))
It is disconnected from the server as it produced some driver problems
recently. So we switched to backup to the holdingsdisk.
Why not switch to backup to file-based virtual tapes?
Why ignore errors if you could choose a setup without errors?
Have a look at http://www.amanda.org/docs/howto-filedriver.html for an
overview.
If you have sufficient disk-space, this is the better solution as long
as you don't want to use physical tapes.
Stefan.
Re: Ultrium tapetype
On Wed, 15 Mar 2006 at 4:14pm, Alexander Jolk wrote Joshua Baker-LePain wrote: For amdump and friends, blocksize is set in the tapetype. For amtapetype, you can set it on the command line. 'man amanda.conf' and 'man amtapetype' are your friends. When changing the blocksize, will amanda happily read (restore) older tapes written with a different blocksize, or will I have to recover them manually? Will she correctly overwrite recycled tapes with the new blocksize? Amanda will happily restore older tapes -- amrestore can determine the blocksize itself and/or you can specify it on the command line. And I'm fairly certain it'll overwrite recycyled tapes, but that's easily tested. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: backup just on holding disks makes many level 0
On Wed, Mar 15, 2006 at 04:08:05PM +0100, Thomas Widhalm wrote:
On Wed, 2006-03-15 at 09:45 -0500, Jon LaBadie wrote:
On Wed, Mar 15, 2006 at 01:03:51PM +0100, Thomas Widhalm wrote:
Here are the 2 parts of the config:
I took the liberty of deleting the comments and unneeded
tapetypes/dumptypes. 800 lines dropped to about 50.
Hope I did not drop anything significant to the discussion.
So sorry. We had a lot of troubles migrating our other servers from
legato to data protector, so I missed to clean the files before posting.
I'm really ver sorry.
The amanda.conf file, as distributed, is heavily overloaded
with commentary and unused definitions. It seldom is cleaned up.
I was not admonishing your posting, just explaining what I did
in case there were errors in my editing.
Amazing how simple amanda.conf can become.
I put two questions inline.
||
|| Here are the 2 parts of the config:
||
|| first file:
|| =
||
|| mailto root
|| dumpuser amanda
|| netusage 10 Kbps
|| maxdumps 1
||
|| bumpsize 10 Mb
|| bumpdays 1
|| bumpmult 4
||
|| etimeout 1800
||
|| runtapes 1
|| reserve 0
||
|| define tapetype DEC-TZ89 {
|| comment DEC TZ89 (hardware compression on: Xmn)
|| length 29414 mbytes
|| filemark 24 kbytes
|| speed 1634 kps
|| }
||
|| ==
||
|| and the other:
||
|| ==
||
|| org IS
||
|| inparallel 1
||
|| dumpcycle 8
|| runspercycle 0
|| tapecycle 4
Not sure I understand this set of parameters.
runspercycle == 0 causes all level 0 dumps I believe.
In that case the length of the dumpcycle is immaterial.
Each time you run amdump, everything will get full dumps.
runspercycle = 0 means same as tapecycle as mentionend
in another post here.
That was me in the other post. That is not what I wrote.
If this is not correct (at least the docu says, it is correct)
than please tell me. I want amanda to know that there is one
run every day, despite of manual runs after fixing errors.
The docs (and I) said same as dumpcycle. How soon I forget
even what I wrote and read. Must be a sign of senility. :(
I was thinking dumpcycle == 0 would cause all level 0 dumps.
With your settings it does suggest one run per day. Sorry.
I know you are not using tape now, but whenever you run
amcheck (you do don't right?) it will complain tapecycle
less than runspercycle.
Are you saying you plan to run amdump once each 8 days
and that you want only level 0 dumps each run?
And further, you will rotate 4 tapes totaling 32 days
of backups available?
I removed all tapes from the config. I just save to the holding disk. I
can live with the daily tape error, but I want amanda to do less full
backups.
The general way to reduce full dump frequency is increase dumpcycle.
If that doesn't help then perhaps other factors are coming into play.
For example, amanda will promote a very active DLE thinking so much
has changed the savings of a level 1 aren't worth it, lets just do
another level 0.
Sometimes an activity on your computer will make it seem like things
have changed when they have not. I believe gnutar relies heavily
on the ctime parameter of unix files. Some activities affect ctime
and could make it look like the file changes (ex. moving a file).
Other than that I don't see any reason you are not getting higher
number levels on your holding disk. I certainly do on a new setup
I'm testing but not providing any tapes.
I don't think this is the problem, but I do not see a record yes
setting. I wonder if that is needed to ensure amanda knows when
the last full dump was done? It is needed for dump, but I'm
uncertain about gnutar.
||
|| holdingdisk hd1 {
|| comment main holding disk for IS
|| directory /data/amanda/IS
|| use -1
|| chunksize 2 Gb
|| }
||
||
|| tapedev /dev/null
|| tapetype DEC-TZ89
Is your DEC tapedrive really attached to the null device?
Doesn't work very well that way does it? :))
It is disconnected from the server as it produced some driver problems
recently. So we switched to backup to the holdingsdisk.
|| labelstr ^IS[0-9][0-9]*$
||
|| infofile /var/lib/amanda/IS/curinfo
|| logdir /var/lib/amanda/IS
|| indexdir /var/lib/amanda/IS/index
||
|| includefile /etc/amanda/amanda-shared.conf
||
|| ===
||
|| the first file is used by all configs. The second one is one specific
|| config.
||
--
End of included message
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Ultrium tapetype
On Wed, Mar 15, 2006 at 11:04:53AM -0500, Joshua Baker-LePain wrote: On Wed, 15 Mar 2006 at 4:14pm, Alexander Jolk wrote Joshua Baker-LePain wrote: For amdump and friends, blocksize is set in the tapetype. For amtapetype, you can set it on the command line. 'man amanda.conf' and 'man amtapetype' are your friends. When changing the blocksize, will amanda happily read (restore) older tapes written with a different blocksize, or will I have to recover them manually? Will she correctly overwrite recycled tapes with the new blocksize? Amanda will happily restore older tapes -- amrestore can determine the blocksize itself and/or you can specify it on the command line. And I'm fairly certain it'll overwrite recycyled tapes, but that's easily tested. I'm on really shakey ground here, but doesn't the tape have to be relabeled to get the tape header set to the new block size? Or maybe it can be read at the 32K size, and when rewritten by taper becomes the new size automagically. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Is my tape drive shoe shinning ?
There was a recent discussion on the list regarding ultrium LTO3 tape speed/performances. According to my vendor, the LTO2 drive I'm about to buy is capable of 80Gb/Hour, that is approx 50 Mb/Sec if I'm right. I'm currently using an adaptec AHA2940U adapter with my DLT4000 drive. I think it's only capable of 20 Mb / Sec... I have a couple of question: What adapter should I buy to feed the LTO2 drive ? It need to be compatible with centos 4.2 (RHEL 4 clone) Provided I buy the correct adapter along with the tape drive, and my holding disk is dedicated to amanda (it's a single 200 Gb ATA drive) how am I to know (measure) if my tape server is feeding the tape drive appropriately ? Would I be better using an SATA drive instead of an ATA drive ? Wouldn't the dumpers compete for I/O's on the holding disk with the taper process ? Or does the taper process begins writting to tape only when all the dumpers have finished ? Where sould I look to see if my tape drive is fed properly ? Thanks
Re: backup just on holding disks makes many level 0
Am Mittwoch, 15. März 2006 17:27 schrieb Jon LaBadie:
On Wed, Mar 15, 2006 at 04:08:05PM +0100, Thomas Widhalm wrote:
On Wed, 2006-03-15 at 09:45 -0500, Jon LaBadie wrote:
On Wed, Mar 15, 2006 at 01:03:51PM +0100, Thomas Widhalm wrote:
Here are the 2 parts of the config:
Amazing how simple amanda.conf can become.
I put two questions inline.
|| Here are the 2 parts of the config:
||
|| first file:
|| =
||
|| mailto root
|| dumpuser amanda
|| netusage 10 Kbps
|| maxdumps 1
||
|| bumpsize 10 Mb
|| bumpdays 1
|| bumpmult 4
||
|| etimeout 1800
||
|| runtapes 1
|| reserve 0
||
|| define tapetype DEC-TZ89 {
|| comment DEC TZ89 (hardware compression on: Xmn)
|| length 29414 mbytes
|| filemark 24 kbytes
|| speed 1634 kps
|| }
||
|| ==
||
|| and the other:
||
|| ==
||
|| org IS
||
|| inparallel 1
||
|| dumpcycle 8
|| runspercycle 0
|| tapecycle 4
Not sure I understand this set of parameters.
runspercycle == 0 causes all level 0 dumps I believe.
In that case the length of the dumpcycle is immaterial.
Each time you run amdump, everything will get full dumps.
I know you are not using tape now, but whenever you run
amcheck (you do don't right?) it will complain tapecycle
less than runspercycle.
I do call amcheck from a script (just su's to amanda and then runs amcheck. It
doesn't complain.
Are you saying you plan to run amdump once each 8 days
and that you want only level 0 dumps each run?
And further, you will rotate 4 tapes totaling 32 days
of backups available?
I removed all tapes from the config. I just save to the holding disk. I
can live with the daily tape error, but I want amanda to do less full
backups.
The general way to reduce full dump frequency is increase dumpcycle.
I tried this. But it just overloads my harddisks, because there are so many
level 0s.
If that doesn't help then perhaps other factors are coming into play.
For example, amanda will promote a very active DLE thinking so much
has changed the savings of a level 1 aren't worth it, lets just do
another level 0.
Sometimes an activity on your computer will make it seem like things
have changed when they have not. I believe gnutar relies heavily
on the ctime parameter of unix files. Some activities affect ctime
and could make it look like the file changes (ex. moving a file).
Hm, this can't be either. Of course, there are some hosts having a lot of
traffic, but some get level 0 on / where is exactly no traffic and no
cronjob.
Other than that I don't see any reason you are not getting higher
number levels on your holding disk. I certainly do on a new setup
I'm testing but not providing any tapes.
A co-worker told me the same. He uses amanda in the same configuration
I don't think this is the problem, but I do not see a record yes
setting. I wonder if that is needed to ensure amanda knows when
the last full dump was done? It is needed for dump, but I'm
uncertain about gnutar.
The docs say, record has default value yes. I tried to include it, but
amcheck complains, that it's no valid option.
Maybe I found it deep within the comments. There is one line reserve 0. I
can remember I changed this on the very day I got to use this server, for it
didn't backup anymore. Or maybe it was some similar option. The comments
read, that this just applies to backing up to the holding disk and reserve
100 means, that there are just incremental backups and that a smaller value
gets amanda to do fullbackups till the holdingdisk is full. So I tried now
and set it to reserve 50. We are very well beyond that now so amanda should
just do incremental backups by now. I can imagine that when it comes to
deleting old backups there will be enough free space for 1 or 2 level 0 for
every disk. I will test and watch because this could mean that sometimes I
miss a level 0 for a disk. Maybe a mixture of reserver 50 and a cronjob
doing a forced full every tapecycle like somebody mentioned, will do the job.
I will report the outcome of this.
Regards,
Thomas
|| holdingdisk hd1 {
|| comment main holding disk for IS
|| directory /data/amanda/IS
|| use -1
|| chunksize 2 Gb
|| }
||
||
|| tapedev /dev/null
|| tapetype DEC-TZ89
Is your DEC tapedrive really attached to the null device?
Doesn't work very well that way does it? :))
It is disconnected from the server as it produced some driver problems
recently. So we switched to backup to the holdingsdisk.
|| labelstr ^IS[0-9][0-9]*$
||
|| infofile /var/lib/amanda/IS/curinfo
|| logdir /var/lib/amanda/IS
|| indexdir /var/lib/amanda/IS/index
||
|| includefile /etc/amanda/amanda-shared.conf
||
|| ===
||
|| the first
Re: backup just on holding disks makes many level 0
On 2006-03-15 17:27, Jon LaBadie wrote: I don't think this is the problem, but I do not see a record yes setting. I wonder if that is needed to ensure amanda knows when the last full dump was done? It is needed for dump, but I'm uncertain about gnutar. I think you hit the nail right on the head. For gnutar, amanda uses the /etc/amandates files similar to the file /etc/dumpdates used by dump. If that file is empty, then amanda thinks it never did a level 0 dump, and hence does it now. However, with record no that file is never updated either, resulting in always level 0 for those filesystems missing in the file. I have to time to try to this out, but I'm interested if this theory is correct. -- 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: Is my tape drive shoe shinning ?
Guy Dallaire wrote: According to my vendor, the LTO2 drive I'm about to buy is capable of 80Gb/Hour, that is approx 50 Mb/Sec if I'm right. I wouldn't be too surprised if that very same controller negociated 80Mb/s with an LTO-2 drive. But anyway, don't believe what they say. Vendors quote fantasy numbers assuming that you use hardware compression, and that your data compresses 2:1. An LTO-2 drive is capable of about 30Mb/s uncompressed, and proportionally higher if you use hardware compression. I'm currently using an adaptec AHA2940U adapter with my DLT4000 drive. I think it's only capable of 20 Mb / Sec... That means that if you don't use hardware compression, 20Mb/s is quite acceptable for LTO-2. If on the contrary, you *do* use hardware compression, you'd need to observe the average compressibility of your data, and scale the figures appropriately. In that case, 20Mb/s might be a bit slow. Alex -- Alexander Jolk / BUF Compagnie tel +33-1 42 68 18 28 / fax +33-1 42 68 18 29
Re: Is my tape drive shoe shinning ?
I have the same issue. I have a SDLT/320 tape drive, capable of 56 Gb/h. My holding disk is a two 73x10k Gb SCSI U320 Raid 0 array, and in my reports the total tape time is much smaller than the run time, since my tape writes at ~16 MB/s and the dump speed to the holding disk performs only at (depending on the disk being dumped) 5-7 MB/s. I think the dumpers and the taper compete for I/Os, when they access the holding disk at the same time, the dumper for writing and the dumper for reading. Cheers, -- Iñaki Sánchez Servicios Informáticos Universidad de Navarra Ed. de Derecho, Campus Universitario 31080 Pamplona (Navarra), España tfno: +34 948 425600 Ext. 2106 http://www.unav.es/SI Guy Dallaire wrote: There was a recent discussion on the list regarding ultrium LTO3 tape speed/performances. According to my vendor, the LTO2 drive I'm about to buy is capable of 80Gb/Hour, that is approx 50 Mb/Sec if I'm right. I'm currently using an adaptec AHA2940U adapter with my DLT4000 drive. I think it's only capable of 20 Mb / Sec... I have a couple of question: What adapter should I buy to feed the LTO2 drive ? It need to be compatible with centos 4.2 (RHEL 4 clone) Provided I buy the correct adapter along with the tape drive, and my holding disk is dedicated to amanda (it's a single 200 Gb ATA drive) how am I to know (measure) if my tape server is feeding the tape drive appropriately ? Would I be better using an SATA drive instead of an ATA drive ? Wouldn't the dumpers compete for I/O's on the holding disk with the taper process ? Or does the taper process begins writting to tape only when all the dumpers have finished ? Where sould I look to see if my tape drive is fed properly ? Thanks
Re: backup just on holding disks makes many level 0
Paul Bijnens schrieb: On 2006-03-15 17:27, Jon LaBadie wrote: I don't think this is the problem, but I do not see a record yes setting. I wonder if that is needed to ensure amanda knows when the last full dump was done? It is needed for dump, but I'm uncertain about gnutar. I think you hit the nail right on the head. For gnutar, amanda uses the /etc/amandates files similar to the file /etc/dumpdates used by dump. If that file is empty, then amanda thinks it never did a level 0 dump, and hence does it now. However, with record no that file is never updated either, resulting in always level 0 for those filesystems missing in the file. I have to time to try to this out, but I'm interested if this theory is correct. Sounds very reasonable, combined with that reserve-value ... Stefan.
RE: Tape Type
If you plan to use this drive with the compressor on you should not
ALSO use software compression. The tapes capacity for gzipped data
would be closer to 50GB without the compressor. You would need
another amtapetype run without HW compression to check the actual
capacity.
Is there a way that I can turn off hardware compression in Amanada? I do
not have that option on the tape loader I use.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon LaBadie
Sent: Tuesday, March 14, 2006 3:52 PM
To: amanda-users@amanda.org
Subject: Re: Tape Type
On Tue, Mar 14, 2006 at 01:23:17PM -0500, Carl Holzhauer wrote:
Just wanted to post this incase some one else has the same backup
device.
Backup device is a Comapq Storage Works SSL2020 Tapes are Compaq AIT
50GB amtapetype returns the following:
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression on)
length 43605 mbytes
filemark 0 kbytes
speed 5583 kps
}
The typical 15% loss of native capacity when random data is fed through
the tape drive's compressor due to its expansion of the random data
rather than compression.
If you plan to use this drive with the compressor on you should not ALSO
use software compression. The tapes capacity for gzipped data would be
closer to 50GB without the compressor. You would need another
amtapetype run without HW compression to check the actual capacity.
If, OTOH, you don't plan to gzip (SW compression) your amanda dumps and
plan to let the drive's compressor do the job, then the above tapetype
is meaningless. Depending on the compress- ability of your data, it
could be anywhere from 50 to 150GB.
It will be just a guesstimate. If amanda keeps filling your tapes,
lower your guess.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
__
Message transport security by GatewayDefender.com
3:54:47 PM ET - 3/14/2006
__
Message transport security by GatewayDefender.com
1:03:11 PM ET - 3/15/2006
Re: backup just on holding disks makes many level 0
On Wed, Mar 15, 2006 at 06:05:05PM +0100, Thomas Widhalm wrote:
Am Mittwoch, 15. März 2006 17:27 schrieb Jon LaBadie:
I know you are not using tape now, but whenever you run
amcheck (you do don't right?) it will complain tapecycle
less than runspercycle.
I do call amcheck from a script (just su's to amanda and then runs amcheck.
It
doesn't complain.
Maybe you are running with some option like -c which eliminates
tape system checks. If not, then your amcheck has serious probs.
The general way to reduce full dump frequency is increase dumpcycle.
I tried this. But it just overloads my harddisks,
because there are so many level 0s.
Doesn't make sense to me. Currently you say do a full dump
every 8 days. To change it to every 30 days should NOT
cause more overloading than 8.
I don't think this is the problem, but I do not see a record yes
setting. I wonder if that is needed to ensure amanda knows when
the last full dump was done? It is needed for dump, but I'm
uncertain about gnutar.
When I grep'ped your original config posting I found only one
instance of record. It is in this dumptype:
define dumptype nocomp-test {
global
comment test dump without compression, no /etc/dumpdates recording
compress none
record no
priority medium
}
Is that a dumptype you use or include into one you do use?
Another way to check the setting is with amadmin. The disklist
command prints out many of the parameters for each, or the
specifiec, DLEs. See if you get record yes or no.
The docs say, record has default value yes.
I tried to include it, but amcheck complains,
that it's no valid option.
Then type it correctly :) And in the correct location.
Maybe I found it deep within the comments. There is one line reserve 0. I
can remember I changed this on the very day I got to use this server, for it
didn't backup anymore. Or maybe it was some similar option. The comments
read, that this just applies to backing up to the holding disk and reserve
100 means, that there are just incremental backups and that a smaller value
gets amanda to do fullbackups till the holdingdisk is full. So I tried now
and set it to reserve 50. We are very well beyond that now so amanda should
just do incremental backups by now. I can imagine that when it comes to
deleting old backups there will be enough free space for 1 or 2 level 0 for
every disk. I will test and watch because this could mean that sometimes I
miss a level 0 for a disk. Maybe a mixture of reserver 50 and a cronjob
doing a forced full every tapecycle like somebody mentioned, will do the job.
I will report the outcome of this.
I look forward to it. But I fear it will only mask an underlying
problem. Up to the reserve you are correct, amanda can put level 0
backups onto the holding disk. But it can also put incrementals
there as well. I.e. up to the reserve, it can do its normal
scheduling. After that, things scheduled for level 0 backups
are demoted to incrementals.
The actual question is why is amanda scheduling so many level 0s.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Ultrium tapetype
On Wed, 15 Mar 2006 at 11:31am, Jon LaBadie wrote I'm on really shakey ground here, but doesn't the tape have to be relabeled to get the tape header set to the new block size? IIRC, amanda rewrites the tape header at the start of every amdump. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Is my tape drive shoe shinning ?
On Wed, Mar 15, 2006 at 11:48:57AM -0500, Guy Dallaire wrote: There was a recent discussion on the list regarding ultrium LTO3 tape speed/performances. According to my vendor, the LTO2 drive I'm about to buy is capable of 80Gb/Hour, that is approx 50 Mb/Sec if I'm right. I'm currently using an adaptec AHA2940U adapter with my DLT4000 drive. I think it's only capable of 20 Mb / Sec... I have a couple of question: What adapter should I buy to feed the LTO2 drive ? It need to be compatible with centos 4.2 (RHEL 4 clone) Provided I buy the correct adapter along with the tape drive, and my holding disk is dedicated to amanda (it's a single 200 Gb ATA drive) how am I to know (measure) if my tape server is feeding the tape drive appropriately ? Would I be better using an SATA drive instead of an ATA drive ? Wouldn't the dumpers compete for I/O's on the holding disk with the taper process ? Or does the taper process begins writting to tape only when all the dumpers have finished ? Where sould I look to see if my tape drive is fed properly ? A disk system performance measuring tool you can download and compile is bonnie++. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Is my tape drive shoe shinning ?
On Wed, 15 Mar 2006 at 11:48am, Guy Dallaire wrote According to my vendor, the LTO2 drive I'm about to buy is capable of 80Gb/Hour, that is approx 50 Mb/Sec if I'm right. Be careful with your units there. b != B. According to the data sheet I have, native rate for LTO2 is 86.4 GB/hr, which is 24 MB/s. I've also seen stats quoting 108 GB/hr, which is 30 MB/s. I'm currently using an adaptec AHA2940U adapter with my DLT4000 drive. I think it's only capable of 20 Mb / Sec... More to the point, it's a narrow, SE SCSI adapter. It looks like most LTO2 drives are U160 LVD. I have a couple of question: What adapter should I buy to feed the LTO2 drive ? It need to be compatible with centos 4.2 (RHEL 4 clone) I'd buy a U320 LVD card, just to be a bit future-proof. I've got my LTO3 library hooked up to a centos-4 system with an LSI 21320-R http://www.lsilogic.com/products/scsi_hbas/lsi21320_r.html, but, from the looks of it, the LSI U320 would work just fine as well http://www.lsilogic.com/products/scsi_hbas/lsiu320.html. Those use the mptscsih driver and work very well. Wouldn't the dumpers compete for I/O's on the holding disk with the taper process ? Or does the taper process begins writting to tape only when all the dumpers have finished ? Yes, they will compete. taper writes whenever it has complete images to write -- parallelism is one of the benefits of the holding disk. That's why, with faster tape drives, a holding RAID becomes necessary. Where sould I look to see if my tape drive is fed properly ? The amanda reports will tell you what speed you're writing to tape at. Also, as noted, bonnie++ can test your disk (as can tiobench, which will test multiple threads). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Is my tape drive shoe shinning ?
2006/3/15, Joshua Baker-LePain [EMAIL PROTECTED]: Yes, they will compete. taper writes whenever it has complete images to write -- parallelism is one of the benefits of the holding disk. That's why, with faster tape drives, a holding RAID becomes necessary. Would software RAID be sufficient ? I need stripping I presume ? Al I have is a standard PC as a server. I don't want to end up with an expensive tape server, we switched to amanda basically to REDUCE costs...
Re: Is my tape drive shoe shinning ?
On Wed, 15 Mar 2006 at 2:38pm, Guy Dallaire wrote 2006/3/15, Joshua Baker-LePain [EMAIL PROTECTED]: Yes, they will compete. taper writes whenever it has complete images to write -- parallelism is one of the benefits of the holding disk. That's why, with faster tape drives, a holding RAID becomes necessary. Would software RAID be sufficient ? I need stripping I presume ? Al I have is a standard PC as a server. I don't want to end up with an expensive tape server, we switched to amanda basically to REDUCE costs... Sure, a software RAID0 would do, given sufficient disks (which for LTO2, could well be just 2). Heck, 1 disk *may* be sufficient for LTO2 -- testing will let you know. Stepping up to LTO3, though, definitely requires actually putting thought/$$ into the backup server. I'd like to point out, though, that that cost really has nothing to do with amanda itself. It's just that these tape drives are *fast*, so feeding 'em ain't as easy as feeding tape drives used to be. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: backup just on holding disks makes many level 0
Am Mittwoch, 15. März 2006 18:13 schrieb Paul Bijnens: On 2006-03-15 17:27, Jon LaBadie wrote: I don't think this is the problem, but I do not see a record yes setting. I wonder if that is needed to ensure amanda knows when the last full dump was done? It is needed for dump, but I'm uncertain about gnutar. I think you hit the nail right on the head. For gnutar, amanda uses the /etc/amandates files similar to the file /etc/dumpdates used by dump. If that file is empty, then amanda thinks it never did a level 0 dump, and hence does it now. However, with record no that file is never updated either, resulting in always level 0 for those filesystems missing in the file. I ran a amadmin config disklist right now and here is one example for the disks I encountered many level 0 backups. host springfield.edvz.sbg.ac.at: interface default disk /: program GNUTAR priority 1 dumpcycle 6 maxdumps 1 maxpromoteday 1 strategy STANDARD compress CLIENT BEST comprate 0.50 0.50 auth BSD kencrypt NO holdingdisk YES record YES index YES skip-incr NO skip-full NO Maybe you can tell me more with that. As I see, record is set to yes. But what is maxpromoteday? Can I set how many days fulls can be promoted? The mail reports tell me, that they get promoted. Regards, Thomas I have to time to try to this out, but I'm interested if this theory is correct. -- * * Thomas Widhalm Unix Administrator * * University of Salzburg ITServices (ITS) * * Systems Management Unix Systems * * Hellbrunnerstr. 34 5020 Salzburg, Austria * * [EMAIL PROTECTED] +43/662/8044-6774 * * gpg: 6265BAE6 * * http://www.sbg.ac.at/zid/organisation/mitarbeiter/widhalm.htm * * pgpI8ZX6yJtHf.pgp Description: PGP signature
Re: backup just on holding disks makes many level 0
Thomas Widhalm schrieb: I ran a amadmin config disklist right now and here is one example for the disks I encountered many level 0 backups. host springfield.edvz.sbg.ac.at: interface default disk /: program GNUTAR priority 1 dumpcycle 6 maxdumps 1 maxpromoteday 1 strategy STANDARD compress CLIENT BEST comprate 0.50 0.50 auth BSD kencrypt NO holdingdisk YES record YES index YES skip-incr NO skip-full NO Maybe you can tell me more with that. As I see, record is set to yes. Looks OK to me so far. But what is maxpromoteday? Can I set how many days fulls can be promoted? The mail reports tell me, that they get promoted. man amanda.conf maxpromoteday int Default: 1. The maximum number of day for a promotion, set it 0 if you don't want promotion, set it to 1 or 2 if your disks get overpromoted. Worth a try. Stefan.
Re: backup just on holding disks makes many level 0
Thomas Widhalm schreef: I ran a amadmin config disklist right now and here is one example for the disks I encountered many level 0 backups. host springfield.edvz.sbg.ac.at: interface default disk /: program GNUTAR priority 1 dumpcycle 6 maxdumps 1 maxpromoteday 1 strategy STANDARD compress CLIENT BEST comprate 0.50 0.50 auth BSD kencrypt NO holdingdisk YES record YES index YES skip-incr NO skip-full NO Maybe you can tell me more with that. As I see, record is set to yes. And, actually, we did not yet see how many times this DLE was dumped with level 0. Can you post the output of amadmin config balance and amoverview config (or mail it to me if it contains too much private information). -- 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, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Odd amrecover and amverify issue in 2.5.0b2
Hi Anthony, The following patch should fix the amverify problem, could you give it a try? --- amverify.sh.in 24 Feb 2006 04:44:59 - 1.35 +++ amverify.sh.in 15 Mar 2006 23:56:47 - @@ -460,6 +460,9 @@ elif [ -n $EOF ]; then report End-of-Tape detected. break + elif [ -n $EOI ]; then +report End-of-Information detected. +break else report ** Error detected ($FILE) echo $VOLUME ($FILE): $DEFECTS Anthony Valentine wrote: amrestore: missing file header block amrestore: WARNING: not at start of tape, file numbers will be offset amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: missing file header block amrestore: 10: reached end of information ** No header 0+0 in 0+0 out Too many errors. -- Thank you! Kevin Till Amanda documentation: http://wiki.zmanda.com Amanda forums:http://forums.zmanda.com
Re: backup just on holding disks makes many level 0
On Wed, Mar 15, 2006 at 11:10:15PM +0100, Thomas Widhalm wrote: Am Mittwoch, 15. März 2006 18:13 schrieb Paul Bijnens: On 2006-03-15 17:27, Jon LaBadie wrote: I don't think this is the problem, but I do not see a record yes setting. I wonder if that is needed to ensure amanda knows when the last full dump was done? It is needed for dump, but I'm uncertain about gnutar. I think you hit the nail right on the head. For gnutar, amanda uses the /etc/amandates files similar to the file /etc/dumpdates used by dump. If that file is empty, then amanda thinks it never did a level 0 dump, and hence does it now. However, with record no that file is never updated either, resulting in always level 0 for those filesystems missing in the file. I ran a amadmin config disklist right now and here is one example for the disks I encountered many level 0 backups. host springfield.edvz.sbg.ac.at: interface default disk /: program GNUTAR priority 1 dumpcycle 6 maxdumps 1 maxpromoteday 1 strategy STANDARD compress CLIENT BEST comprate 0.50 0.50 auth BSD kencrypt NO holdingdisk YES record YES index YES skip-incr NO skip-full NO Maybe you can tell me more with that. As I see, record is set to yes. But what is maxpromoteday? Can I set how many days fulls can be promoted? The mail reports tell me, that they get promoted. Do you have the file /etc/amandates on each client? What are their permissions? Reasonable contents? Something like: / 0 1104304406 / 1 1104821711 //lastchance/C 0 1104908144 -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: One DLE too many!
Mitch Collinsworth wrote: On Tue, 14 Mar 2006, Jon LaBadie wrote: On Tue, Mar 14, 2006 at 01:44:50PM -0500, Vytas Janusauskas wrote: Amanda Backup Client Hosts Check ERROR: hal: [Can't open disk '/mnt/data06/Deforest3'] ERROR: hal: [No include for '/mnt/data06/Deforest3_PART1'] Client check: 5 hosts checked in 3.259 seconds, 2 problems found IIRC amcheck does NOT run some of its checks as root. Thus if the amanda user running amcheck can not visit /mnt/data06/Deforest3 and needed directories below that, it could cause errors like that above when amcheck looked for files. It's worse than that. Include processing is performed before setuid root mode is started. selfcheck, sendsize, and sendbackup all fail to include directories that the amanda user can't read. You just lose and the directories don't get backed up. Makes it hard to provide a backup service for machines that aren't centrally managed, which is more and more the way the world (for some of us) is going. That'a not fixed in 2.5.0, that will be done after the dumper-api get implemented. Jean-Louis
Re: One DLE too many!
On Wed, 15 Mar 2006, Jean-Louis Martineau wrote: That'a not fixed in 2.5.0, that will be done after the dumper-api get implemented. dumper-api? I thought the story was that's being replaced with application-api. In any case I offered a programmer's time 2 years ago to fix this w/o waiting on any api. I just wanted agreement first that if we developed it as proposed it would be accepted. But we were never told it would be accepted. Or not accepted. Just no answer at all. -Mitch
Re: backup just on holding disks makes many level 0
On Wednesday 15 March 2006 11:27, Jon LaBadie wrote: On Wed, Mar 15, 2006 at 04:08:05PM +0100, Thomas Widhalm wrote: On Wed, 2006-03-15 at 09:45 -0500, Jon LaBadie wrote: On Wed, Mar 15, 2006 at 01:03:51PM +0100, Thomas Widhalm wrote: Here are the 2 parts of the config: [...] I don't think this is the problem, but I do not see a record yes setting. I wonder if that is needed to ensure amanda knows when the last full dump was done? It is needed for dump, but I'm uncertain about gnutar. Yes, I pretty sure its needed by gnutar also. And for exactly the same reason. -- Cheers, Gene People having trouble with vz bouncing email to me should add the word 'online' between the 'verizon', and the dot which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2006 by Maurice Eugene Heskett, all rights reserved.
