Re: [UPDATE] How to control which tape is next?
> > Check to see if some problem has truncated your tapelist file. If a > > problem (e.g., no space left on a device) prevents the tapelist from > > being created or some other problem truncated the file, then you > > could expect to see a problem like this. Check to see if there have > > been any drive faults or other system events at the time when Amanda > > started giving you strange results. > > I have created a patch, which seems not yet included in the current > sources, for similar errors: > > http://groups.yahoo.com/group/amanda-hackers/message/3769 > > (but it seems that this is not the problem, as Lucio seems to indicate > that there ARE enough entries in the tapelist file. Maybe a permission > problem? Or looking at a file with the same name but not the one > as configured in amanda.conf?) > The file is not truncated nor there are permission problems. There are five entries in the tapelist file and tapecycle is set to five tapes. Every entry matches the labelstr and every entry is marker as "reuse". The only strange thing is that the timestamp for each entry dates back to several days ago while the backup is due every night and the backup reports tell everything is ok every morning. There is a write permission problem on amanda.conf (root.root rw-r--r--), but I guess this has nothing to do with the tapelist, right?
Re: [UPDATE] How to control which tape is next?
> > Or looking at a file with the same name but not the one > > as configured in amanda.conf?) I can't tell how stupid I feel just now. The one above was the reason. Thanks everybody. Lucio.
Re: [UPDATE] How to control which tape is next?
On Thursday 23 October 2003 05:38, Lucio wrote: >> > Check to see if some problem has truncated your tapelist file. >> > If a problem (e.g., no space left on a device) prevents the >> > tapelist from being created or some other problem truncated the >> > file, then you could expect to see a problem like this. Check >> > to see if there have been any drive faults or other system >> > events at the time when Amanda started giving you strange >> > results. >> >> I have created a patch, which seems not yet included in the >> current sources, for similar errors: >> >> http://groups.yahoo.com/group/amanda-hackers/message/3769 >> >> (but it seems that this is not the problem, as Lucio seems to >> indicate that there ARE enough entries in the tapelist file. >> Maybe a permission problem? Or looking at a file with the same >> name but not the one as configured in amanda.conf?) > >The file is not truncated nor there are permission problems. There > are five entries in the tapelist file and tapecycle is set to five > tapes. Every entry matches the labelstr and every entry is marker > as "reuse". The only strange thing is that the timestamp for each > entry dates back to several days ago while the backup is due every > night and the backup reports tell everything is ok every morning. > >There is a write permission problem on amanda.conf (root.root > rw-r--r--), but I guess this has nothing to do with the tapelist, > right? Or everything maybe, since the user amanda:disk should own all files in that same directory. The perms should look something like this: [EMAIL PROTECTED] root]# ls -l /usr/local/etc/amanda/DailySet1 total 48 -rw-r--r--1 amanda disk20832 Aug 3 04:29 amanda.conf -rw-r--r--1 amanda disk 693 Dec 24 2002 chg-scsi.conf -rw-r--r--1 amanda disk 5502 Jul 13 09:16 disklist -rw---1 amanda disk 784 Oct 23 00:30 tapelist -rw---1 amanda disk 757 Jun 10 16:26 tapelist.amlabel -rw---1 amanda disk 784 Oct 23 00:30 tapelist.yesterday This is beginning to look as if you have chowned things a bit somehow. Please chown them back to resemble the above. This is possibly something that rpms may not handle properly. When useing the tarballs, it is unpacked, configured, and built by amanda, then is installed by root, automaticly taking care of all required permissions when done in that manner. It just works. Likewise, your /usr/local/var/amanda/DailySet1 tree (or wherever the rpms keep the records) should also all belong to amanda:disk. The executables, probably in /usr/local/libexec should look like this: [EMAIL PROTECTED] root]# ls -l /usr/local/libexec total 1904 -rwxr-xr-x1 amanda disk57760 Oct 20 05:05 amandad -rw-r--r--1 amanda disk 180 Oct 20 05:05 amcat.awk -rwxr-xr-x1 amanda disk52567 Oct 20 05:05 amcleanupdisk -rwxr-xr-x1 amanda disk59680 Oct 20 05:05 amidxtaped -rwxr-xr-x1 amanda disk 114258 Oct 20 05:05 amindexd -rwxr-xr-x1 amanda disk46638 Oct 20 05:05 amlogroll -rw-r--r--1 amanda disk17439 Oct 20 05:05 amplot.awk -rw-r--r--1 amanda disk 3283 Oct 20 05:05 amplot.g -rw-r--r--1 amanda disk 3293 Oct 20 05:05 amplot.gp -rwxr-xr-x1 amanda disk52927 Oct 20 05:05 amtrmidx -rwxr-xr-x1 amanda disk51722 Oct 20 05:05 amtrmlog -rwsr-x---1 root disk47402 Oct 20 05:05 calcsize -rwxr-xr-x1 amanda disk11165 Oct 20 05:05 chg-chio -rwxr-xr-x1 amanda disk10066 Oct 20 05:05 chg-chs -rwxr-xr-x1 amanda disk 5160 Oct 20 05:05 chg-juke -rwxr-xr-x1 amanda disk 6769 Oct 20 05:05 chg-manual -rwxr-xr-x1 amanda disk13096 Oct 20 05:05 chg-mcutil -rwxr-xr-x1 amanda disk 5596 Oct 20 05:05 chg-mtx -rwxr-xr-x1 amanda disk11962 Oct 20 05:05 chg-multi -rwxr-xr-x1 amanda disk 1703 Oct 20 05:05 chg-null -rwxr-xr-x1 amanda disk 4006 Oct 20 05:05 chg-rait -rwxr-xr-x1 amanda disk 6691 Oct 20 05:05 chg-rth -rwxr-xr-x1 amanda disk 401126 Oct 20 05:05 chg-scsi -rwxr-xr-x1 amanda disk37294 Oct 20 05:05 chg-zd-mtx -rwxr-xr-x1 amanda disk97207 Oct 20 05:05 driver -rwsr-x---1 root disk90217 Oct 20 05:05 dumper -rwsr-x---1 root disk41995 Oct 20 05:05 killpgrp -rwxr-xr-x1 amanda disk 4848 Oct 20 05:05 patch-system -rwsr-x---1 root disk91428 Oct 20 05:05 planner -rwsr-x---1 root disk38963 Oct 20 05:05 rundump -rwsr-x---1 root disk40270 Oct 20 05:05 runtar -rwxr-xr-x1 amanda disk63188 Oct 20 05:05 selfcheck -rwxr-xr-x1 amanda disk 121100 Oct 20 05:05 sendbackup -rwxr-xr-x1 amanda disk79728 Oct 20 05:05 sendsize -rwxr-xr-x1 amanda disk93117 Oct 20 05:0
Re: problem labelling tapes
Hi all,
I am still having trouble trying to label tapes and Amanda
recognising them.
I label a tape:
bash-2.05a$ /usr/sbin/amlabel daily daily01fri
rewinding, reading labelamlabel: strange amanda header: "AMANDA:
T"
, not an amanda tape
rewinding, writing label daily01fri, checking label, done.
I then check the tape:
bash-2.05a$ dd bs=32k if=/dev/st0
AMANDA: TAPESTART DATE X TAPE daily01fri
1+0 records in
1+0 records out
So I then run amcheck:
bash-2.05a$ /usr/sbin/amcheck daily
Amanda Tape Server Host Check
-
Holding disk /tmp: 521540 KB disk space available, that's plenty
amcheck-server: strange amanda header: "AMANDA: T"
ERROR: /dev/nst0: not an amanda tape
(expecting tape daily01tue or a new tape)
If I continually run amcheck, about maybe 5% of the time I will
get the response "Tape daily01fri label ok", to indicate that it
was actually able to read the label on the tape. This is VERY
strange !
I have downloaded and installed 2.4.4p1 and it is a RH7.3
machine.
As an aside, I did manage to work out the stinit stuff and the
drive is no longer using hardware compression. I did another
tapetype and got the following:
define tapetype dds4 {
comment "produced by tapetype prog (HW compresssion off)"
length 19503 mbytes
filemark 0 kbytes
speed 2693 kps
}
which is a lot more like what it should be.
Any suggestions on why it is not recognising the label ?
Thanks,
Tony.
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk
Re: problem labelling tapes
> Any suggestions on why it is not recognising the label ? is your drive new/old/dirty/clean? what about SCSI termination? have you tried a different cable? has this drive/cable setup ever worked? Tom
Re: problem labelling tapes
Tony wrote: As an aside, I did manage to work out the stinit stuff and the drive is no longer using hardware compression. I did another tapetype and got the following: ... which is a lot more like what it should be. Any suggestions on why it is not recognising the label ? Now that you have a correct stinit.def, the stuff should work better. But there is still one gotcha. When you insert a tape that was written with other settings, and you READ something on that tape, the drive adjusts itself automatically to the settings of the tape. This is very convenient to read a tape (you don't have to be guess what the settings were), but when you write subsequently to that tape, the drive does it with these settings, and those that you specified in stinit.def. I've been hit (and many people on this list) a few times with the compression status. You label a few tapes (or all tapes in my case) with compression on (because you didn't notice, or by accident). Later you find out about stinit.def and how to disable compression with "mt" etc and you think you're safe now. But when amanda verifies the label, it automatically resets the drive to "compression on" for those tapes. Writing this tape is silently done with compression on, resulting is about 20-30% capacity loss. Many people don't even notice, until they hit EOT prematurely (and sometimes think it is a bad tape). To correct this behaviour, you have to set the correct parameters in the drive (in stinit.def and/or using mt) and then write some data to the tape WITHOUT reading it. You can't use amlabel for this, because it first verifies the tape in the drive, to check for an already existing amanda label. The program amtapetype does work to erase a tape. You don't need to run it completely to the end; using the new "-c" option is sufficient and takes only a few minutes for each tape. Something like: amtapetype -c -f /dev/st0 And then run amlabel again. If I continually run amcheck, about maybe 5% of the time I will get the response "Tape daily01fri label ok", to indicate that it was actually able to read the label on the tape. This is VERY strange ! The above does not explain why you get in about 5% of the cases a correct labelcheck. There is still "something else"... Maybe even a hardware problem. (But why does it consistently shows 9 bytes of the label is strange in that case too.) -- 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: problem labelling tapes
Sorry, not read before hitting send... Paul Bijnens wrote: what the settings were), but when you write subsequently to that tape, the drive does it with these settings, and those that you specified in stinit.def. Should be: .. the drive does it with these settings and NOT those that you specified in stinit.def. -- 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 * ***
More than one tape per run
I'm thinking about using more than one tape, i.e. set "runtapes" parameter to a value > 1, for my updated archival setup. Is there anything special I need to keep in mind when doing this? Also, how do I set up runspercycle in this case? Is it the total number of tapes runspercycle * runtapes, or just runspercycle? - Toralf
Re: More than one tape per run
Toralf Lund wrote: I'm thinking about using more than one tape, i.e. set "runtapes" parameter to a value > 1, for my updated archival setup. Is there anything special I need to keep in mind when doing this? Also, how do I set up runspercycle in this case? Is it the total number of tapes runspercycle * runtapes, or just runspercycle? runspercycle does not need to be changed. The "runtapes" means that for each run up to that number of tapes may be used (note: not "must"). You have to increase your tapecycle probably to cover the same dumpcycle(s), because you'll burn twice as much tapes for each run. (well, "burn", hopefully not litteraly). The parameter "taperalgo largestfit" will help to fill the first tape(s) to 100%. (New since amanda 2.4.3.) This works better when also using: dumporder "SS" # as many S's as you have dumpers (or use "TT", which is a good approximation of , but optimises the total runtime of your backups better; I use T). For a complete explanation why this works better, see: http://groups.yahoo.com/group/amanda-users/message/46327 -- 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: Mixing backups to disk and tape?
I am interested quite a lot in making backups on two different media, like what you said disk and tape. In my case I would like to write my data on disk and disk, but with 800km between the 2 disk shelves. I don't think RAIT can handle this. And if there's no existing solution, I don't mind developing it from scratch. Is someone interested in coding it with me? On Wed, 22 Oct 2003 15:55:58 -0500 Frank Smith <[EMAIL PROTECTED]> wrote: > Since the list has been pretty quiet lately: > > Is there a (relatively) easy way of backing up to both disk and > tape from a single config? I was thinking of using the file driver > to do backups to disk (for faster recoveries) while also using > tapes (for archiving and offsite purposes). > > Options I've considered: > > Just using the file driver and then dd'ing those to tape later. > But since I couldn't keep as many file 'tapes' around as I would > keep tapes, how would I handle recoveries of older data? Just > delete the file 'tapes' as needed, and to do a restore, first > dd the tape back to the properly named file? > > Using the RAIT driver (does it still exist?) to mirror a backup > between disk and file? How would a restore work in this case; > would Amanda expect both tape and file to be present? Could > a changer script handle the two diferent mediums? > > Two configs. It would double the backup window and I"m soaking > some WAN links too long already. > > Something else? > > My idea is to somehow use the file driver to keep a couple of > dumpcycle's worth of backups on disk, but to also have a > tapecycle's worth of tapes (which is many times dumpcycle). > Anybody tried anything similar? > > Frank > > -- > Frank Smith [EMAIL PROTECTED] > Systems Administrator Voice: 512-374-4673 > Hoover's Online Fax: 512-374-4501
amoverview output
Attached are my amoverview and disklist files. I see some { brackets,
include
statements etc., in my amoverview output. These were not there before I
introduced include,exclude in the disklist file. Amreports everything fine
for
all in the disklists though.
Any idea?
Rohit
# localhost /etc comp-root-tar
machine1 /vl tar-low
machine1 /vw tar-high
machine1 /vm tar-high
machine1 /htar-low
machine3 /rp cvs-backup-full -1 local
machine3 /vw tar-low
machine3 /vm tar-low
machine3 /hAM /h {
tar-low
include "./[a-m]*"
} -1 local
machine3 /hNZ /h {
tar-low
include "./[n-z]*"
} -1 local
machine2 /vmtar-low
machine2 /vwtar-med
machine2 /hAM /h {
tar-med
include "./[a-m]*"
} 1
machine2 /hNZ /h {
tar-med
include "./[n-z]*"
} 1
machine2 /h2AM /h2 {
tar-med
include "./[a-m]*"
} 1
machine2 /h2NZ /h2 {
tar-med
include "./[n-z]*"
} 1
machine2 /h3NZ /h3 {
tar-med
include "./rohit"
} 1
# machine2/vl tar-low
# machine2 //meosis/users windows-high
# machine2 //meosis/UsersG2 windows-high
# machine2 //meosis/UsersG3 windows-high
date 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
host disk 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
machine1 /h0 E E E E1 2 2 2 2 E 0
machine1 /vl E 0 E E EE 0 1 0 1 E 1 0 1
machine1 /vm 0 1 1 0 00 1 0 1 1 1 1 0 1
machine1 /vw E 0 E 1 22 0 1 0 1 1 1 1 1
machine2 /h2AM 0 1 1
machine2 /h2NZ 0 1 1
machine2 /h3NZ
machine2 /hAM 0 1 1
machine2 /hNZ 0 1 1
machine2 /vm
machine2 /vw E E 0 E1 1 0 1 1 2 0 1
include "./[a-m]*"
include "./[n-z]*"
include "./rohit"
machine3/hAM 0
machine3/hNZ 0
machine3/rp0
machine3/vm
machine3/vw
tar-low
tar-med
}-1
}1
NFS mount as second holding disk
Hello. I am still experimenting with my Amanda setup. I have dedicated essentially all of the available disk space on an HP LH3 for my Amanda holding disk (approx 50 gig). However, I still have some partitions to be backed up which exceed the size of the holding disk. I know that an NFS mount would not be the ideal holding disk (I have googled on the subject before posting), but it is not practical for me to add disk space to the LH3 at this time. I can live with a performance hit as long as the backup was reliable. Has anyone successfully used an NFS mount as a secondary holding disk? Can backups still be run through dump or should they all be tar going this route? Or is this just not advisable at all? Thanks, Dan Willis
Re: More than one tape per run
Paul Bijnens wrote: Toralf Lund wrote: I'm thinking about using more than one tape, i.e. set "runtapes" parameter to a value > 1, for my updated archival setup. Is there anything special I need to keep in mind when doing this? Also, how do I set up runspercycle in this case? Is it the total number of tapes runspercycle * runtapes, or just runspercycle? runspercycle does not need to be changed. The "runtapes" means that for each run up to that number of tapes may be used (note: not "must"). You have to increase your tapecycle probably to cover the same dumpcycle(s), because you'll burn twice as much tapes for each run. (well, "burn", hopefully not litteraly). I'm still not sure I understand. If I have runspercycle 2 and runtapes 2 will amanda try to distribute the full dumps across 4 tapes, or just 2? When I think about it, the first answer makes most sense, as the parameter otherwise ought to have been called "tapespercycle". The parameter "taperalgo largestfit" will help to fill the first tape(s) to 100%. (New since amanda 2.4.3.) I'm using that already. This works better when also using: dumporder "SS" # as many S's as you have dumpers (or use "TT", which is a good approximation of , but optimises the total runtime of your backups better; I use T). For a complete explanation why this works better, see: http://groups.yahoo.com/group/amanda-users/message/46327 This is very helpful indeed. Thanks. I've been wondering how I might avoid having the largest image left on the holding disk when the total size is only just larger than the tape (like you say, taperalgo often doesn't help), but never noticed this parameter, or the message you are referring to. -- - Toralf
FAILED [[parse of reply message failed]]
Title: FAILED [[parse of reply message failed]] Hi there, Newbie question, I'm running amanda server on Debian Linux amanda-server 2.4.2p2-4 I get the above parse error 'parse of reply message failed' when backing up a Solaris 2.6 client running amanda-2.4.4 Does anyone have any idea what may be causing this parsing error. A Google serch seems to suggest it's a problem with the client's version but I'm not sure, would appreciate any help or pointers. regards, Stephen
KIND ATTENTION !!!
EXTREMELY CONFIDENTIAL. ATTENTION: THE PRESIDENT/CHAIRMAN. First, may I solicit your confidentiality in this transaction, this by virtue of its nature I am Fredrick Taylor, a cousin to the former and exiled president Charles Taylor of Liberia. As a result of his step down and exile, he has mandated me to look for a reliable partner who will urgently assist us in the claims of a consignment contained in a trunk box (containing cash of $39.8m deposited as family treasures in the safe deposit custody of the diplomatic de espanol non inspection deposit unit in madrid-spain under an assigned diplomatic agent during his regime. We need a foreigner, private or company of high magnitude of honesty and reliability whom we will portray as the bona-fide owner of the consignment during the change of beneficiary/ownership when applied upon your reconfirmation, which a certificate of change of ownership will be issued in your new name as the beneficiary before our meeting in madrid spain for the claims and banking processes to the account you will provide with the assistance of the assigned agent.[the Euro Diplomatic Services] Thereafter, this fund will be invested in your company or you advice us on any lucrative project to invest the fund into,after rewarding you for your efforts and assitances through out the period of the transaction which you will be entitled to 20% of the total sum. My cousin has handed over to me the transaction to follow up as a result of his step down and exile, as all necessary arrangements have been made to perfection awaiting the immediate commencement of this transaction upon your reconfirmation. . I will want to be guaranteed that you will be able to handle this transaction with utmost confidentiality and honesty as a result of Mr. Charles commitments with the international community through out the rebeling period untill his current step down and exile,as i am assuring you same from my side. Upon receipt of your positive response, including your complete personal datas, i will immediately make an application for the change of ownership. Please contact me on this email address: or through my private thuraya satelite number:+88-216-520-700-41 .as i will be expecting your responce. Best Regards Fredrick . Taylor
Re: amoverview output
Hi Rohit,
Could you try this patch
Jean-Louis
On Thu, Oct 23, 2003 at 07:00:56PM +0530, Rohit Peyyeti wrote:
> Attached are my amoverview and disklist files. I see some { brackets,
> include
> statements etc., in my amoverview output. These were not there before I
> introduced include,exclude in the disklist file. Amreports everything fine
> for
> all in the disklists though.
>
> Any idea?
>
> Rohit
> # localhost /etc comp-root-tar
>
> machine1 /vl tar-low
> machine1 /vw tar-high
> machine1 /vm tar-high
> machine1 /htar-low
>
> machine3 /rp cvs-backup-full -1 local
> machine3 /vw tar-low
> machine3 /vm tar-low
>
> machine3 /hAM /h {
> tar-low
> include "./[a-m]*"
> } -1 local
>
> machine3 /hNZ /h {
> tar-low
> include "./[n-z]*"
> } -1 local
>
>
> machine2 /vmtar-low
> machine2 /vwtar-med
>
> machine2 /hAM /h {
> tar-med
> include "./[a-m]*"
> } 1
>
> machine2 /hNZ /h {
> tar-med
> include "./[n-z]*"
> } 1
>
> machine2 /h2AM /h2 {
> tar-med
> include "./[a-m]*"
> } 1
>
> machine2 /h2NZ /h2 {
> tar-med
> include "./[n-z]*"
> } 1
>
> machine2 /h3NZ /h3 {
> tar-med
> include "./rohit"
> } 1
>
> # machine2/vl tar-low
> # machine2 //meosis/users windows-high
> # machine2 //meosis/UsersG2 windows-high
> # machine2 //meosis/UsersG3 windows-high
> date 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10
> host disk 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
>
> machine1 /h0 E E E E1 2 2 2 2 E 0
> machine1 /vl E 0 E E EE 0 1 0 1 E 1 0 1
> machine1 /vm 0 1 1 0 00 1 0 1 1 1 1 0 1
> machine1 /vw E 0 E 1 22 0 1 0 1 1 1 1 1
> machine2 /h2AM 0 1 1
> machine2 /h2NZ 0 1 1
> machine2 /h3NZ
> machine2 /hAM 0 1 1
> machine2 /hNZ 0 1 1
> machine2 /vm
> machine2 /vw E E 0 E1 1 0 1 1 2 0 1
> include "./[a-m]*"
> include "./[n-z]*"
> include "./rohit"
> machine3/hAM 0
> machine3/hNZ 0
> machine3/rp0
> machine3/vm
> machine3/vw
> tar-low
> tar-med
> }-1
> }1
--
Jean-Louis Martineau email: [EMAIL PROTECTED]
Département IRO, Université de Montréal
C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529
Montréal, Canada, H3C 3J7Fax: (514) 343-5834
--- amanda-2.4.4p1.orig/server-src/amadmin.c2003-01-03 22:35:54.0 -0500
+++ amanda-2.4.4p1.new/server-src/amadmin.c 2003-10-23 09:44:08.0 -0400
@@ -1454,7 +1454,7 @@
ip->name[0] ? ip->name : "default");
printf("disk %s:\n", dp->name);
-if(dp->device) printf("device: %s\n", dp->device);
+if(dp->device) printf("device %s\n", dp->device);
printf("program \"%s\"\n", dp->program);
if(dp->exclude_file != NULL && dp->exclude_file->nb_element > 0) {
RE: FAILED [[parse of reply message failed]]
Title: RE: FAILED [[parse of reply message failed]] On Thu, Oct 23, 2003 at 03:05:57PM +0100, Yeates, Stephen [Heanet] wrote: > Hi there, > Newbie question, I'm running amanda server on Debian Linux > amanda-server 2.4.2p2-4 >> >> I get the above parse error 'parse of reply message failed' >> when backing up a Solaris 2.6 client running amanda-2.4.4 >> >> Does anyone have any idea what may be causing this parsing error. >> >> A Google serch seems to suggest it's a problem with the client's version but >> I'm not sure, would appreciate any help or pointers. >My recollection is that a newer server can handle clients of all >previous 4.? clients. However the newer versions added some optional >features that would stump older servers. However if you do not use >these optional new features (not sure what they were :-( ) then you >should be compatible with new client and old server. Hi Jon, Thanks for your quick response. I'll try upgrading the amanda server and see if it helps. I'll post the results to the list. regards, Stephen -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road (609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
amusing, huge amreport
Woke up this morning to a 1 line, 70 byte mail message from my amdump overnight. I was working on the system at 2AM when the backup kicked in. At the time I was moving things around to empty space on an new disk drive and doing general cleanup (aka deletions of old garbage). Turns out I deleted or moved thousands of files between the time amanda made a list of what files to backup on my /w file system and the actual tar'ing of those files. So I got thousands of "can not stat" messages. :) I don't think I will bother to archive that email. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amoverview output
Thanks Jean, but I have a binary RPM version installed on my
tape server. I'll download sources and try this later later.
Thanks again.
- Original Message -
From: "Jean-Louis Martineau" <[EMAIL PROTECTED]>
To: "Rohit Peyyeti" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 23, 2003 7:40 PM
Subject: Re: amoverview output
> Hi Rohit,
>
> Could you try this patch
>
> Jean-Louis
>
> On Thu, Oct 23, 2003 at 07:00:56PM +0530, Rohit Peyyeti wrote:
> > Attached are my amoverview and disklist files. I see some { brackets,
> > include
> > statements etc., in my amoverview output. These were not there before I
> > introduced include,exclude in the disklist file. Amreports everything
fine
> > for
> > all in the disklists though.
> >
> > Any idea?
> >
> > Rohit
>
> > # localhost /etc comp-root-tar
> >
> > machine1 /vl tar-low
> > machine1 /vw tar-high
> > machine1 /vm tar-high
> > machine1 /htar-low
> >
> > machine3 /rp cvs-backup-full -1 local
> > machine3 /vw tar-low
> > machine3 /vm tar-low
> >
> > machine3 /hAM /h {
> > tar-low
> > include "./[a-m]*"
> > } -1 local
> >
> > machine3 /hNZ /h {
> > tar-low
> > include "./[n-z]*"
> > } -1 local
> >
> >
> > machine2 /vmtar-low
> > machine2 /vwtar-med
> >
> > machine2 /hAM /h {
> > tar-med
> > include "./[a-m]*"
> > } 1
> >
> > machine2 /hNZ /h {
> > tar-med
> > include "./[n-z]*"
> > } 1
> >
> > machine2 /h2AM /h2 {
> > tar-med
> > include "./[a-m]*"
> > } 1
> >
> > machine2 /h2NZ /h2 {
> > tar-med
> > include "./[n-z]*"
> > } 1
> >
> > machine2 /h3NZ /h3 {
> > tar-med
> > include "./rohit"
> > } 1
> >
> > # machine2/vl tar-low
> > # machine2 //meosis/users windows-high
> > # machine2 //meosis/UsersG2 windows-high
> > # machine2 //meosis/UsersG3 windows-high
>
> > date 10 10 10 10 10 10 10 10 10 10 10 10 10 10
10 10 10
> > host disk 07 08 09 10 11 12 13 14 15 16 17 18 19 20
21 22 23
> >
> > machine1 /h0 E E E E1 2 2 2 2 E
0
> > machine1 /vl E 0 E E EE 0 1 0 1 E
1 0 1
> > machine1 /vm 0 1 1 0 00 1 0 1 1 1
1 0 1
> > machine1 /vw E 0 E 1 22 0 1 0 1 1
1 1 1
> > machine2 /h2AM
0 1 1
> > machine2 /h2NZ
0 1 1
> > machine2 /h3NZ
> > machine2 /hAM
0 1 1
> > machine2 /hNZ
0 1 1
> > machine2 /vm
> > machine2 /vw E E 0 E1 1 0 1 1 2
0 1
> > include "./[a-m]*"
> > include "./[n-z]*"
> > include "./rohit"
> > machine3/hAM
0
> > machine3/hNZ
0
> > machine3/rp
0
> > machine3/vm
> > machine3/vw
> > tar-low
> > tar-med
> > }-1
> > }1
>
> --
> Jean-Louis Martineau email: [EMAIL PROTECTED]
> Département IRO, Université de Montréal
> C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529
> Montréal, Canada, H3C 3J7Fax: (514) 343-5834
>
Re: FAILED [[parse of reply message failed]]
On Thu, Oct 23, 2003 at 03:05:57PM +0100, Yeates, Stephen [Heanet] wrote: > Hi there, > Newbie question, I'm running amanda server on Debian Linux > amanda-server 2.4.2p2-4 > > I get the above parse error 'parse of reply message failed' > when backing up a Solaris 2.6 client running amanda-2.4.4 > > Does anyone have any idea what may be causing this parsing error. > > A Google serch seems to suggest it's a problem with the client's version but > I'm not sure, would appreciate any help or pointers. My recollection is that a newer server can handle clients of all previous 4.? clients. However the newer versions added some optional features that would stump older servers. However if you do not use these optional new features (not sure what they were :-( ) then you should be compatible with new client and old server. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: More than one tape per run
runspercycle does not need to be changed. The "runtapes" means that for each run up to that number of tapes may be used (note: not "must"). You have to increase your tapecycle probably to cover the same dumpcycle(s), because you'll burn twice as much tapes for each run. (well, "burn", hopefully not litteraly). I'm still not sure I understand. If I have runspercycle 2 and runtapes 2 will amanda try to distribute the full dumps across 4 tapes, or just 2? When I think about it, the first answer makes most sense, as the parameter otherwise ought to have been called "tapespercycle". "Sense" is a funny thing. Amanda will "try" to fit each run on a single tape. But will use a second tape during that run if necessary. Ah, I see. So it won't actually multiply tape size by runtapes when trying to figure out how much it can write... I'm not sure the functionaltiy is of much use to me then, but perhaps I could cheat and pretend the tapes are "runtapes" times larger than they really are? Thus the answer is "it depends". It will try to use 2 tapes, but may use 3 or 4. BTW I find it strange that an "archival" configuration would be setup with a dumpcycle > 0 (or 1?) and with runspercycle > 1. When I want an archive dump I want it to be the state of the system now. Not the current state of half the DLE's and incrementals from the last 'archive' of the other half. Maybe that is just me ;) The archival config disables incrementals, obsiously. And *of course* I have to split the backup across several tapes; isn't the data in any real setup larger than what fits on a tape? But actually, one of the reasons why I'm asking about runtapes > 1 is that I've considered setting up so that everything is dumped in one run... - Toralf
Re: More than one tape per run
--On Thursday, October 23, 2003 15:53:23 +0200 Toralf Lund <[EMAIL PROTECTED]> wrote: > Paul Bijnens wrote: > >> Toralf Lund wrote: >> >>> I'm thinking about using more than one tape, i.e. set "runtapes" >>> parameter to a value > 1, for my updated archival setup. Is there >>> anything special I need to keep in mind when doing this? Also, how do >>> I set up runspercycle in this case? Is it the total number of tapes >>> runspercycle * runtapes, or just runspercycle? >> >> >> runspercycle does not need to be changed. The "runtapes" means that >> for each run up to that number of tapes may be used (note: not "must"). > >> You have to increase your tapecycle probably to cover the same >> dumpcycle(s), because you'll burn twice as much tapes for each run. >> (well, "burn", hopefully not litteraly). > > I'm still not sure I understand. If I have > > runspercycle 2 > > and > > runtapes 2 > > will amanda try to distribute the full dumps across 4 tapes, or just 2? Well, technically your data could be spread over up to four tapes, but you are only going to have one full backup of a single filesystem on one of the tapes (assuming no promotions were made) and not on the others. Increasing runtapes just gives amanda more room to write a single day's backups, but it is a maximum, so if all the scheduled backups fit on one tape then it won't use the second one until the next run. Frank > When I think about it, the first answer makes most sense, as the parameter otherwise > ought to have been called "tapespercycle". > >> >> The parameter "taperalgo largestfit" will help to fill the first >> tape(s) to 100%. (New since amanda 2.4.3.) > > I'm using that already. > >> >> This works better when also using: >> >> dumporder "SS" # as many S's as you have dumpers >> >> (or use "TT", which is a good approximation of , but optimises >> the total runtime of your backups better; I use T). >> >> For a complete explanation why this works better, see: >> >> >> http://groups.yahoo.com/group/amanda-users/message/46327 > > This is very helpful indeed. Thanks. > > I've been wondering how I might avoid having the largest image left on the holding > disk when the total size is only just larger than the tape (like you say, taperalgo > often doesn't help), but never noticed this parameter, or the message you are > referring to. > > -- > - Toralf > > -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: [UPDATE] How to control which tape is next?
Is the modification date on the tapelist file changing? If the entries in the tapelist are not keeping up with the Amanda processes, then this implies that something is preventing Amanda from keeping the tapelist up to date. One thing occurs to me, check the permissions on the config directory, if it is read-only or owned and writable only by root, then Amanda cannot manipulate the files necessary to change the tapelist. It's the little things that get you, Don Donald L. (Don) Ritchey E-mail: [EMAIL PROTECTED] -Original Message- From: Lucio [mailto:[EMAIL PROTECTED] Sent: Thursday, October 23, 2003 4:38 AM To: [EMAIL PROTECTED] Subject: Re: [UPDATE] How to control which tape is next? > > Check to see if some problem has truncated your tapelist file. If a > > problem (e.g., no space left on a device) prevents the tapelist from > > being created or some other problem truncated the file, then you > > could expect to see a problem like this. Check to see if there have > > been any drive faults or other system events at the time when Amanda > > started giving you strange results. > > I have created a patch, which seems not yet included in the current > sources, for similar errors: > > http://groups.yahoo.com/group/amanda-hackers/message/3769 > > (but it seems that this is not the problem, as Lucio seems to indicate > that there ARE enough entries in the tapelist file. Maybe a permission > problem? Or looking at a file with the same name but not the one > as configured in amanda.conf?) > The file is not truncated nor there are permission problems. There are five entries in the tapelist file and tapecycle is set to five tapes. Every entry matches the labelstr and every entry is marker as "reuse". The only strange thing is that the timestamp for each entry dates back to several days ago while the backup is due every night and the backup reports tell everything is ok every morning. There is a write permission problem on amanda.conf (root.root rw-r--r--), but I guess this has nothing to do with the tapelist, right? This e-mail and any of its attachments may contain Exelon Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Exelon Corporation family of Companies. This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout. Thank You.
I REQUIRE YOUR APPROVAL
Dear Friend, ASSISTANCE REQUIRED FOR ACQUISITION OF ESTATES. I write to inform you of my desire to acquire estates or landed properties in your country on behalf of the Director of Contracts and Finance Allocation of the Federal Ministry of works and Housing in Nigeria. Considering his very strategic and influential position, he would want the transaction to be strictly as confidential as possible. First i will want to introduce myself to you, i am Mr Kola Brown the personal assistant to Director of Contracts and Finance Allocation of the Federal Ministry of works and Housing in Nigeria. I came across your contact information due to my desperate search for a reliable hand in assisting us, hence I am contacting you in assisting us in this our mutual beneficial transaction (please my apologies for reaching you through this manner). He further want his identity to remain undisclosed at least for now, until the completion of the transaction. Hence our desire to have an overseas agent or rather an oversea partner. I have therefore been directed to inquire if you would agree to act as our overseas agent in order to actualise this transaction. The deal in brief is that the funds with which to carry out our proposed investments in your country is presently in a coded account in the Nigerian apex bank and we need your assistance to transfer the funds to your country or any safe account outside your country in a convenient bank account that will be provided by you before we can put the funds into use. For this you shall be considered to have executed a contract for the ministry. The contract sum of which shall run into US$16.5Million of which your share shall be duely given to you if you agree to be our overseas agent. Your area of specialisation does not matter in this transaction, all that is required of you is a safe account and your willingness to assist us acquire estates in your country. As soon as payment is effected and the amount mentioned above is successfully transferred into your account, we intend to use our own share in acquiring some estates abroad. For this too, we will rely on your advice. It might interest you to note that last year, a similar transaction was carried out with one MR. CHIENCHEN YU of Taiwan but after securing the payment approvals, and payment effected, MR.CHIENCHEN YU changed his numbers and addresses, and was no where to be found on our getting to Taiwan. That was how a former government official lost US$17.5Million. So this time around, I will be with you before the remmittance is made into your provided account to avoid future occurrence and allow trust to play a very minimal role until performance is seen. You are requested to communicate your acceptance or otherwise of this proposal,after which we shall discuss in details the modalities for seeing this transaction through. If however, you are not disposed to assist, kindly destroy this letter in view of the confidentiality of the proposed transaction and interest of personalities involved. If you will be willing to assist us as it will definately benefit all involved, you should please send to me your phone number to enable me speak with you on the modalities of securing this transaction successfully. Thank you in anticipation of your co-operation. Best Regards, Mr Kola Brown.
Re: More than one tape per run
On Thu, Oct 23, 2003 at 03:53:23PM +0200, Toralf Lund wrote: > Paul Bijnens wrote: > > >Toralf Lund wrote: > > > >>I'm thinking about using more than one tape, i.e. set "runtapes" > >>parameter to a value > 1, for my updated archival setup. Is there > >>anything special I need to keep in mind when doing this? Also, how do > >>I set up runspercycle in this case? Is it the total number of tapes > >>runspercycle * runtapes, or just runspercycle? > > > > > >runspercycle does not need to be changed. The "runtapes" means that > >for each run up to that number of tapes may be used (note: not "must"). > > >You have to increase your tapecycle probably to cover the same > >dumpcycle(s), because you'll burn twice as much tapes for each run. > >(well, "burn", hopefully not litteraly). > > I'm still not sure I understand. If I have > > runspercycle 2 > > and > > runtapes 2 > > will amanda try to distribute the full dumps across 4 tapes, or just 2? > > When I think about it, the first answer makes most sense, as the > parameter otherwise ought to have been called "tapespercycle". "Sense" is a funny thing. Amanda will "try" to fit each run on a single tape. But will use a second tape during that run if necessary. Thus the answer is "it depends". It will try to use 2 tapes, but may use 3 or 4. BTW I find it strange that an "archival" configuration would be setup with a dumpcycle > 0 (or 1?) and with runspercycle > 1. When I want an archive dump I want it to be the state of the system now. Not the current state of half the DLE's and incrementals from the last 'archive' of the other half. Maybe that is just me ;) -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: More than one tape per run
On Thu, Oct 23, 2003 at 05:37:02PM +0200, Toralf Lund wrote: > > >>>runspercycle does not need to be changed. The "runtapes" means that > >>>for each run up to that number of tapes may be used (note: not "must"). > >>> > >>> > >>>You have to increase your tapecycle probably to cover the same > >>>dumpcycle(s), because you'll burn twice as much tapes for each run. > >>>(well, "burn", hopefully not litteraly). > >>> > >>> > >>I'm still not sure I understand. If I have > >> > >>runspercycle 2 > >> > >>and > >> > >>runtapes 2 > >> > >>will amanda try to distribute the full dumps across 4 tapes, or just 2? > >> > >>When I think about it, the first answer makes most sense, as the > >>parameter otherwise ought to have been called "tapespercycle". > >> > >> > > > >"Sense" is a funny thing. > > > >Amanda will "try" to fit each run on a single tape. But will use a > >second tape during that run if necessary. > > > Ah, I see. So it won't actually multiply tape size by runtapes when > trying to figure out how much it can write... I'm not sure the > functionaltiy is of much use to me then, but perhaps I could cheat and > pretend the tapes are "runtapes" times larger than they really are? > Won't buy you anything. Amanda will reach the actual end of the tape and not be able to go on to a second tape because runtapes is 1. > > Thus the answer is "it depends". > >It will try to use 2 tapes, but may use 3 or 4. > > > >BTW I find it strange that an "archival" configuration would be setup with > >a dumpcycle > 0 (or 1?) and with runspercycle > 1. > > > >When I want an archive dump I want it to be the state of the system now. > >Not the current state of half the DLE's and incrementals from the last > >'archive' of the other half. Maybe that is just me ;) > > > > > The archival config disables incrementals, obsiously. And *of course* I > have to split the backup across several tapes; isn't the data in any > real setup larger than what fits on a tape? Total data, yes. Data per DLE, no. Because amanda can not deal with individual DLE's larger than a single tape capacity. But it will happily put 10 DLE's on the first tape, 20 on the second and 4 on the third if that is what fits, is needed, and runtapes is >= 3. > > But actually, one of the reasons why I'm asking about runtapes > 1 is > that I've considered setting up so that everything is dumped in one run... Assuming that each individual DLE, when given a level 0, fits on a single tape, then set dumpcycle = 0, runspercycle = 1, and runtapes = 1000. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: NFS mount as second holding disk
On Thu, Oct 23, 2003 at 08:32:31AM -0500, Dan Willis wrote: > Has anyone successfully used an NFS mount as a secondary holding disk? Haven't tried it. > Can backups still be run through dump or should they all be tar > going this route? I don't see offhand why it would make a difference. From the Amanda server's point of view, they're both just byte streams coming in over a socket. > Or is this just not advisable at all? Perhaps this is overly alarmist, but over on the info-cvs list, the common wisdom is that people should *not* access their CVS repositories over NFS, but use the CVS client/server protocol instead. That's because interoperability problems between different O/S's have been known to knock holes out of files (whole blocks of NULs instead of the data that should be there). A recent thread discussed the problem, and the circumstances in which one can probably get away with NFS-mounting one's repo. See this message from Larry Jones, one of the main CVS maintainers at this point, and a guy who, IMO, generally seems to know what he's talking about: http://mail.gnu.org/archive/html/info-cvs/2003-10/msg00060.html and the final paragraph of this one: http://mail.gnu.org/archive/html/info-cvs/2003-10/msg00064.html (The rest of the thread is of less interest, since it deals with more CVS-specific issues.) There are circumstances in which that problem isn't as critical (e.g. CVS working directories; since everything's in the repo anyway, all you risk is your latest round of changes). But a backup isn't the kind of thing I'd want to gamble with -- especially not a compressed one, where an error would trash the rest of the file! -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / When I came back around from the dark side, there in front of me would be the landing area where the crew was, and the Earth, all in the view of my window. I couldn't help but think that there in front of me was all of humanity, except me. - Michael Collins, Apollo 11 Command Module Pilot
Re: FAILED [[parse of reply message failed]]
I Stephen, Newer client should be compatible with older server. Could you send the amandad..debug on the client for the sendbackup services. I would like to see the reply message. Jean-Louis On Thu, Oct 23, 2003 at 03:05:57PM +0100, Yeates, Stephen [Heanet] wrote: > Hi there, > Newbie question, I'm running amanda server on Debian Linux > amanda-server 2.4.2p2-4 > > I get the above parse error 'parse of reply message failed' > when backing up a Solaris 2.6 client running amanda-2.4.4 > > Does anyone have any idea what may be causing this parsing error. > > A Google serch seems to suggest it's a problem with the client's version but > I'm not sure, would appreciate any help or pointers. > > regards, > > Stephen > > -- Jean-Louis Martineau email: [EMAIL PROTECTED] Département IRO, Université de Montréal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montréal, Canada, H3C 3J7Fax: (514) 343-5834
Re: NFS mount as second holding disk
On Thu, Oct 23, 2003 at 08:32:31AM -0500, Dan Willis wrote: > Has anyone successfully used an NFS mount as a secondary holding disk? I currently am. Actually it's the *only* holdingdisk. :-) > Can backups still be run through dump or should they all be tar going > this route? Makes absolutely no difference. It's just holdingdisk, ordinary file open/write/read, nothing special from a functionality POV. > Or is this just not advisable at all? As long as you've comprehended the bandwidth costs, there is no particular problem. In my case, I'm taking about a 25% backup window elapsed time hit, but a cheap 200GB IDE disk in a castoff Linux box is freeing up six very expensive Solaris fibre-channel disks for other purposes. (As soon as I get around to acquiring GB-E and HVD SCSI cards for the linux box, *it* becomes the new Amanda server and the 25% hit goes away...) -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Samba - which does compress-client-best point to?
System: RedHat 7.1, kernel 2.4.19 amanda 2.4.2p2, samba 2.2.6 I've been backing up several Windows machines for a while now (months). Recently, I've been getting cramped with tape space, so I added "compress-client-best" to my samba-pc dump type. However, while watching amanda perform the dump, it seems as if the linux server is compressing the data, and not the windows client. The more I think about it, the more it makes sense, since amanda treats the smbclient connection as an ftp connection rather than an amanda client machine. So the amanda server itself is the client, and the server in one for the samba backups (right?) But, my amanda server is slow. So the PC stays connected while the dumper compresses the dumped files. Would the dumper relinquish the machine faster if I used compress-svr-fast vs. compress-client-fast? -Rob
lev 0 FAILED [can't switch to incremental dump]
Hi there - I'm running amanda2.4.2p2 on a RH8.0 box - the client is a RH7.2 box also running amanda2.4.2p2. The client has two disks, the first disk is partitioned in a standard way - the second disk only has one partition /docs; and docs is the only thing I want to back up. Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 350021 66155265795 20% / /dev/hda177750 5957 67779 9% /boot /dev/hda2 1510060 35812 1397540 3% /home /dev/hdd1 19243804 6235232 12031016 35% /docs none 63352 0 63352 0% /dev/shm /dev/hda7 147766 4153135984 3% /tmp /dev/hda8 4759544898008 3619760 20% /usr /dev/hda3 1004052 51352901696 6% /var My disklist entry looks like this: client.unterlaw.com /docs user-tar amcheck runs fine, detects no problems, but the dump didn't run... client.u /docs lev 0 FAILED [can't switch to incremental dump] Why does amanda think I'm running an incremental dump on a this partition? Also - this dump went to holding disk due to a tape error...is it just saying that it couldn't drop this to a level 1? Rebecca A. Crum Systems Administrator Unterberg & Associates, P.C. (219) 736-5579 ext. 184
Re: lev 0 FAILED [can't switch to incremental dump]
Rebecca Pakish Crum wrote: amcheck runs fine, detects no problems, but the dump didn't run... client.u /docs lev 0 FAILED [can't switch to incremental dump] Why does amanda think I'm running an incremental dump on a this partition? Also - this dump went to holding disk due to a tape error...is it just saying that it couldn't drop this to a level 1? I guess the "reserve" parameter is configured to 100 (the default) or only so much that the 6.2 Gbyte full dump does not fit. The reserve parameter indicates how much to reserve to full dumps on holdingdisk when dumping in degraded mode. You had a tape error, and amanda decides to degrade some or all full dumps to incrementals and continue with dumps to holdingdisk. But, because (from the context) it seems it never did a full dump, amanda can't switch to incremental, because there is no previous full dump to base the increments on. Was this what happened? -- Paul @ Home
RE: lev 0 FAILED [can't switch to incremental dump]
> I guess the "reserve" parameter is configured to 100 (the > default) or only so much that the 6.2 Gbyte full dump does > not fit. The reserve parameter indicates how much to reserve > to full dumps on holdingdisk when dumping in degraded mode. > > You had a tape error, and amanda decides to degrade some or > all full dumps to incrementals and continue with dumps to holdingdisk. > > But, because (from the context) it seems it never did a full > dump, amanda can't switch to incremental, because there is no > previous full dump to base the increments on. > > Was this what happened? I'll check on the reserve parameter - I just checked my holding disk size and it was set at 15000 MB, which this 6.2 GB full dump would not fit on the holding disk with the over 10GB from my other disks...I increased the size of my holding disk so that would not be a problem. This would have been the first time I backed up this client, so that's why I didn't totally understand the error. You are absolutely right...how can I expect it to do an incremental due to lack of holding disk space when it's never done the full level 0 Amanda is so much smarter than me. With the hopes of no media errors on the horizon, I'm sure it will work tonight. Thanks for the input.
Re: Samba - which does compress-client-best point to?
Dege, Robert C. wrote: System: RedHat 7.1, kernel 2.4.19 amanda 2.4.2p2, samba 2.2.6 I've been backing up several Windows machines for a while now (months). Recently, I've been getting cramped with tape space, so I added "compress-client-best" to my samba-pc dump type. In my experience the compress best uses 4 times as much CPU for only 5% better compression, so it's not worth it, unless you have spare CPU cycles to burn. Maybe it's better to increase the dumpcycle (maybe add more tapes to the tapecycle too), at the cost of having higher incrementals. Unless you have already a dumpcycle that's very long... (Many people run with a dumpcycle of 2 weeks, some even more.) If you don't have a changer, but you do have large enough holdingdisk, one of the options is also to set "runtapes 2" and "reserve 0", and let the dumps go to one tape, and overflow on holdingdisk, which you flush each morning manually. However, while watching amanda perform the dump, it seems as if the linux server is compressing the data, and not the windows client. The more I think about it, the more it makes sense, since amanda treats the smbclient connection as an ftp connection rather than an amanda client machine. So the amanda server itself is the client, and the server in one for the samba backups (right?) Right. If you think a litter more about this, the amanda server does not need to be the computer that runs smbclient. My amandaserver has already his cpu fully loaded, and two other machines do the smbclient backups for my window machines, and they do the compression too. But, my amanda server is slow. So the PC stays connected while the dumper compresses the dumped files. Would the dumper relinquish the machine faster if I used compress-svr-fast vs. compress-client-fast? Execute "compress" on the machine that has the free CPU cycles, be it your amanda server, be it one or more other machines. Another possibility is to run the cygwin client on the windows PC's themselves, and then they can do their own compression (but some recent messages on this list indicate cygwin+amanda+compression has some problems, yet to be solved). -- Paul @ Home
problem taking backups
hi, I am having some trouble taking backups using amanda. amcheck says that everything is fine but when I try using amdump, nothing happens. The tape drive is on a P200 MMX machine running RedHat Linux 9.0. Kernel version is 2.4.20-20.9.XFS1.3.1. In the amdump log files, I see a message which says "FloatingPointException". I have no idea what could possibly be causing this. The dumpcycle, runspercycle and tapecycle are 3 weeks, 9 and 9 tapes respectively. The tape drive is Quantum DLT800. Below are the last few lines from the amdump log file: driver: adding holding disk 0 dir /var/lib/amanda/Weekly/holding size 15254652 reserving 15254652 out of 15254652 for degraded-mode dumps driver: start time 750.775 inparallel 4 bandwidth 205800 diskspace 15254652 dir OBSOLETE datestamp 20031017 driver: drain-ends tapeq FIRST big-dumpers ttt driver: result time 750.776 from taper: TAPER-OK taper: DONE [idle wait: 742.386 secs] /usr/local/sbin/amdump: line 99: 28089 Done $libexecdir/planner$SUF "$@" 28090 *Floating point exception*| $libexecdir/driver$SUF $conf taper: writing end marker. [Weekly1 OK kb 0 fm 0] amdump: end at Fri Oct 17 11:44:33 EDT 2003 I have also attached the full amdump log file. I would greatly appreciate any help that I can get. Thanks, Amit -- Amit Kumar Dept. of Chemical Engg. University of Delaware Newark, DE 19716 Ph: (302) 831-2345 amdump: start at Fri Oct 17 11:32:03 EDT 2003 amdump: datestamp 20031017 planner: pid 28089 executable /usr/local//libexec/planner version 2.4.4p1 planner: build: VERSION="Amanda-2.4.4p1" planner:BUILT_DATE="Fri Oct 17 10:24:50 EDT 2003" planner:BUILT_MACH="Linux hydra.che.udel.edu 2.4.20-20.9.XFS1.3.1 #1 Sat Oct 11 13:38:26 CDT 2003 i586 i586 i386 GNU/Linux" planner:CC="gcc" planner:CONFIGURE_COMMAND="'./configure' '--prefix=/usr/local/' '--with-user=amanda' '--with-group=disk' '--with-config=Weekly'" planner: paths: bindir="/usr/local//bin" sbindir="/usr/local//sbin" planner:libexecdir="/usr/local//libexec" mandir="/usr/local//man" planner:AMANDA_TMPDIR="/tmp/amanda" AMANDA_DBGDIR="/tmp/amanda" planner:CONFIG_DIR="/usr/local//etc/amanda" DEV_PREFIX="/dev/" planner:RDEV_PREFIX="/dev/" DUMP="/sbin/dump" planner:RESTORE="/sbin/restore" SAMBA_CLIENT="/usr/bin/smbclient" planner:GNUTAR="/bin/gtar" COMPRESS_PATH="/bin/gzip" planner:UNCOMPRESS_PATH="/bin/gzip" MAILER="/usr/bin/Mail" planner:listed_incr_dir="/usr/local//var/amanda/gnutar-lists" planner: defs: DEFAULT_SERVER="hydra.che.udel.edu" planner:DEFAULT_CONFIG="Weekly" planner:DEFAULT_TAPE_SERVER="hydra.che.udel.edu" planner:DEFAULT_TAPE_DEVICE="/dev/null" HAVE_MMAP HAVE_SYSVSHM planner:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE planner:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS planner:CLIENT_LOGIN="amanda" FORCE_USERID HAVE_GZIP planner:COMPRESS_SUFFIX=".gz" COMPRESS_FAST_OPT="--fast" planner:COMPRESS_BEST_OPT="--best" UNCOMPRESS_OPT="-dc" planner: time 0.003: dgram_bind: socket bound to 0.0.0.0.812 READING CONF FILES... planner: time 0.024: startup took 0.024 secs SETTING UP FOR ESTIMATES... planner: time 0.024: setting up estimates for mohawk.che.udel.edu:/dev/dsk/dks1d4s7 mohawk.che.udel.edu:/dev/dsk/dks1d4s7 overdue 4 days for level 0 setup_estimate: mohawk.che.udel.edu:/dev/dsk/dks1d4s7: command 0, options: last_level 0 next_level0 -4 level_days 0 getting estimates 0 (10307792) 1 (0) -1 (-1) planner: time 0.026: setting up estimates for mohawk.che.udel.edu:/ mohawk.che.udel.edu:/ overdue 29 days for level 0 setup_estimate: mohawk.che.udel.edu:/: command 0, options: last_level 1 next_level0 -29 level_days 1 getting estimates 0 (4243080) 1 (11730) -1 (-1) planner: time 0.028: setting up estimates took 0.003 secs GETTING ESTIMATES... taper: pid 28091 executable taper version 2.4.4p1 taper: page size is 4096 taper: buffer size is 32768 taper: buffer[00] at 0x401ef000 taper: buffer[01] at 0x401f7000 taper: buffer[02] at 0x401ff000 taper: buffer[03] at 0x40207000 taper: buffer[04] at 0x4020f000 taper: buffer[05] at 0x40217000 taper: buffer[06] at 0x4021f000 taper: buffer[07] at 0x40227000 taper: buffer[08] at 0x4022f000 taper: buffer[09] at 0x40237000 taper: buffer[10] at 0x4023f000 taper: buffer[11] at 0x40247000 taper: buffer[12] at 0x4024f000 taper: buffer[13] at 0x40257000 taper: buffer[14] at 0x4025f000 taper: buffer[15] at 0x40267000 taper: buffer[16] at 0x4026f000 taper: buffer[17] at 0x40277000 taper: buffer[18] at 0x4027f000 taper: buffer[19] at 0x40287000 taper: buffer structures at 0x4028f000 for 240 bytes driver: pid 28090 executable /usr/local//libexec/driver version 2.4.4p1 driver: send-cmd time 0.042 to taper: START-TAPER 20031017 driver: started dumper0 pid 28093 driver: started dumper1 pid 28094 driver: started dumper2 pid 28095 dumper: dgram_bind: socket bound to 0.0.
Re: problem labelling tapes
On Thursday 23 October 2003 05:48, Tony wrote:
>Hi all,
>
>I am still having trouble trying to label tapes and Amanda
>recognising them.
>
>I label a tape:
>
>bash-2.05a$ /usr/sbin/amlabel daily daily01fri
>rewinding, reading labelamlabel: strange amanda header: "AMANDA:
>T"
>, not an amanda tape
>rewinding, writing label daily01fri, checking label, done.
>
>I then check the tape:
>
>bash-2.05a$ dd bs=32k if=/dev/st0
>AMANDA: TAPESTART DATE X TAPE daily01fri
>
>1+0 records in
>1+0 records out
>
>So I then run amcheck:
>
>bash-2.05a$ /usr/sbin/amcheck daily
>Amanda Tape Server Host Check
>-
>Holding disk /tmp: 521540 KB disk space available, that's plenty
>amcheck-server: strange amanda header: "AMANDA: T"
>ERROR: /dev/nst0: not an amanda tape
> (expecting tape daily01tue or a new tape)
>
>
>If I continually run amcheck, about maybe 5% of the time I will
>get the response "Tape daily01fri label ok", to indicate that it
>was actually able to read the label on the tape. This is VERY
>strange !
>
>I have downloaded and installed 2.4.4p1 and it is a RH7.3
>machine.
>
>As an aside, I did manage to work out the stinit stuff and the
>drive is no longer using hardware compression. I did another
>tapetype and got the following:
>
>define tapetype dds4 {
> comment "produced by tapetype prog (HW compresssion off)"
> length 19503 mbytes
> filemark 0 kbytes
> speed 2693 kps
>}
>
>which is a lot more like what it should be.
>
>
>Any suggestions on why it is not recognising the label ?
>
The only idea I keep coming up with is that for DDS tapes, the status
of the tapes compression is recorded in a hidden header on the tape.
Simply turning off the compression and relabeling the tape will turn
it back in in the initial label read, so you wind up with the
compression on regardless. The workaround I've used is to read out
the label with dd and save it to a scratch file. Rewind the tape and
issue the compression off commands, then dd the label file back to
the tape useing the non-rewinding device. This will not normally
move the tape, or flush the buffers as its not a big enough write,
and you'll only succeed if you force the drive to flush its buffers
which will then record the compression off state in the header. So
one must, in addition to dd'ing the label back, follow that up with
another dd from /dev/zero thats big enough to force the buffer flush,
use at least a meg of /dev/zero more than the drives rated buffer
size.
I have a script around here someplace, and which has also been posted
to this list on 2-3 occasions, that does all this in one swell foop
per tape MOST of the time.
>Thanks,
>Tony.
>
>
>
> Want to chat instantly with your online friends? Get the FREE
> Yahoo! Messenger http://mail.messenger.yahoo.co.uk
--
Cheers, Gene
AMD [EMAIL PROTECTED] 320M
[EMAIL PROTECTED] 512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: [UPDATE] How to control which tape is next?
On Thursday 23 October 2003 06:29, Lucio wrote: >> > Or looking at a file with the same name but not the one >> > as configured in amanda.conf?) > >I can't tell how stupid I feel just now. The one above was the > reason. Thanks everybody. > >Lucio. You probably have lot of company in that, I think at one time or another, many of us have had similar problems. welcome to the real world... :) -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Mutually Beneficial
Attn: President/CEO/SIR/MADAM REQUEST FOR URGENT BUSINESS RELATIONSHIP -STRICTLY CONFIDENTIAL Firstly, I must solicit your confidentiality. This is by virtue of it's nature as being utterly "confidential" and Though I know that a transaction of this magnitude will make anyone apprehensive and worried, but I am assuring you that all will be well at the end of the day. A bold step taken shall not be regretted I assure you. I am Mr iyang and I head a seven man tender board in charge of contract awards and payment approvals. I came to know of you in my search for a reliable and reputable person to handle a very confidential business transaction, which involves the transfer of a huge sum of money to a foreign account requiring maximum confidence. My colleagues and I are top official of Federal Government Contract Review and Award Panel. Our duties include evaluation, vetting, and approval for payment of contract jobs done for the Federal Ministry of Aviation(FMA) etc. We are therefore soliciting for your assistance to enable us transfer into your account the said funds. Our country looses a lot of money everyday that is why the international community is very careful and warning their citizens to be careful but I tell you "a trial will convince you".The source of the fund is as follow: During the last military regime here in Nigeria, this committee awarded a contract of US$400 Million to a group of five construction firms on behalf of the Federal Ministry of Aviation (FMA)for the supply and installation of landing and navigational equipment in Lagos and Port Harcourt International Airports. During this process my colleagues and I decided among us to deliberately over inflate the total contract sum of US$420.5 Million with the aim of sharing the remaining sum of US$20.5 million.The government has since approved the sum of US$420.5Million for us as the contract sum, but since the contract is only worth US$400M the remaining US$20.5 Million is what we intend to transfer to a reliable and safe offshore account,we are prohibited to operate foreign account in our names since we are still in Government. Thus, making it impossible for us to acquire the money in our name right now, I have therefore been delegated as a matter of trust by my colleagues to look for an oversea partner into whose account we can transfer the sum of US$20.5Million.My colleagues and I have decided that if you/your Company can as the beneficiary of this funds on our behalf, you or your company will retain 20% of the total amount (US$20.5Million) while 75% will be for us (officials) and the remaining 5% will be used in offsetting all debts/expenses incurred during this transaction We have decided that this transaction can only proceed under the following condition (a) Our conviction of your transparent honesty and that you treat this transaction with utmost secrecy and confidentiality (b) That upon Receipt of the funds you will release the funds as instructed by us after you've removed your share of 20%. Please acknowledge the receipt of this letter using the above e-mail address. I will bring you into the complete of this transaction when I've heard from you. Your urgent response will be highly appreciated as we are already behind schedule for the financial quarter. Please do be informed that his business transaction is 100% legal and completely free from drug or money laundering. Only trust can make the reality of this transaction. Best regards, Mr iyang Note;[EMAIL PROTECTED]
Re: NFS mount as second holding disk
On Thursday 23 October 2003 09:32, Dan Willis wrote: >Hello. I am still experimenting with my Amanda setup. I have > dedicated essentially all of the available disk space on an HP LH3 > for my Amanda holding disk (approx 50 gig). However, I still have > some partitions to be backed up which exceed the size of the > holding disk. I know that an NFS mount would not be the ideal > holding disk (I have googled on the subject before posting), but it > is not practical for me to add disk space to the LH3 at this time. > I can live with a performance hit as long as the backup was > reliable. > >Has anyone successfully used an NFS mount as a secondary holding > disk? Can backups still be run through dump or should they all be > tar going this route? Or is this just not advisable at all? > >Thanks, >Dan Willis Generally speaking, dump is not the prefered utility for use with amanda. We seem to have gradually come to prefer tar, in any version 1.13-19 or higher. Are these partitions that exceed the size of the holding disk compressible? If so, that may serve as a starting point to arrive at a sequence that allows the holding disk to be used. I ask because I have several partitions that while not larger than the holding disk, do regularly compress to 20% or less of the original size. The downside is that the compression takes time and serious horsepower, and the lags its use will create will allow the holding disk's files to be written to tape in a more timely manner possibly preventing it from becomeing 100% full. Keep in mind that if the disk gets full, the next dump will go direct to the tape, and this may result in shoe-shining the drive if the machine can't compress and move the data fast enough to stream 100% of the time. The dump that fills it up may be lost, but IIRC amanda will know that and retry it again on the next run. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: NFS mount as second holding disk
On Thu, Oct 23, 2003 at 07:53:32PM -0400, Gene Heskett wrote: > On Thursday 23 October 2003 09:32, Dan Willis wrote: > >Hello. I am still experimenting with my Amanda setup. I have [clip] > Generally speaking, dump is not the prefered utility for use with > amanda. We seem to have gradually come to prefer tar, in any version > 1.13-19 or higher. Gene, though that is the conventional wisdom for Linux ext2/ext3 because of kernel buffer inconsistency issues, I don't think Dan mentioned his OS; for some OS's, like Solaris, (ufs)dump is arguably the preferred solution unless you require excludes or subdirectories. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
chunksize
Hi, I was once given the impression that chunksize in the amanda.conf could be used to control at what size a backup image would be written to tape instead of to holding disk. From reading what is in the man page, I certainly wouldn't get this idea. I made the following note in my amanda.conf at one time (possibly the negative sign alters the meaning?): # chunksize -1370 Mb # in my own words, this tells # amanda to use a single file on the holding # disk for any filesystem < 1370 Mb while # writing any filesystem > 1370 Mb directly # to tape I'm now questioning whether any of this is true. I seem to also vaguely remember something being said to me once about chunksize not even being used by AMANDA anymore. Any comments to any of this? Thanks, Paul -- Paul Yeatman (858) 534-9896[EMAIL PROTECTED] == ==Proudly brought to you by Mutt== ==
Re: NFS mount as second holding disk
Thanks to everyone who responded. My Amanda server is RH9 using the 2.4.3 amanda packages included with the distribution (head hung in shame after reading a couple of days of posts...). One client box is RH 7.3 with the 2.4.2 rh packages, one is RH9 with the 2.4.3 rh packages and the remaining boxes (to be added to the disklist later) are RH 9 as well. The largest partition I'm trying to backup is actually an SMB mount on a Windows 2000 server. I've stuck with hardware compression so far because all of these boxes are pretty old and slow (I've borrowed a Compaq SDLT220 tape drive for testing purposes while I try to get the nearly $5,000 purchase approved- the tape unit will be the most valuable piece of the whole setup!). I knew that an NFS mount couldn't be backed up with dump- I wasn't sure how an NFS holding disk would factor in. I take it that tar is the preferred backup method for ext3 filesystems? My initial config used dump on the non-SMB partitions, but I can quickly change over to tar. At 07:35 PM 10/23/2003, you wrote: On Thu, Oct 23, 2003 at 07:53:32PM -0400, Gene Heskett wrote: > On Thursday 23 October 2003 09:32, Dan Willis wrote: > >Hello. I am still experimenting with my Amanda setup. I have [clip] > Generally speaking, dump is not the prefered utility for use with > amanda. We seem to have gradually come to prefer tar, in any version > 1.13-19 or higher. Gene, though that is the conventional wisdom for Linux ext2/ext3 because of kernel buffer inconsistency issues, I don't think Dan mentioned his OS; for some OS's, like Solaris, (ufs)dump is arguably the preferred solution unless you require excludes or subdirectories. -- Jay Lessert [EMAIL PROTECTED] Accelerant Networks Inc. (voice)1.503.439.3461 Beaverton OR, USA(fax)1.503.466.9472
Re: NFS mount as second holding disk
On Thursday 23 October 2003 20:35, Jay Lessert wrote: >On Thu, Oct 23, 2003 at 07:53:32PM -0400, Gene Heskett wrote: >> On Thursday 23 October 2003 09:32, Dan Willis wrote: >> >Hello. I am still experimenting with my Amanda setup. I have > >[clip] > >> Generally speaking, dump is not the prefered utility for use with >> amanda. We seem to have gradually come to prefer tar, in any >> version 1.13-19 or higher. > >Gene, though that is the conventional wisdom for Linux ext2/ext3 >because of kernel buffer inconsistency issues, I don't think Dan >mentioned his OS; for some OS's, like Solaris, (ufs)dump is arguably >the preferred solution unless you require excludes or > subdirectories. Most of the comments I've read on this list from folks who have run dump, seem to be less than enthusiastic after it bites them in a recovery attempt. Maybe there are platform diffs that make it ok here, and a drooling dog someplace else. Its my impression that tar doesn't seem to have quite a much negative publicity as long as its new enough, and it does do excludes and subdirs quite nicely, allowing one to break up his disklist into bite sized pieces. But thats just my impression Jay... That, and a buck might get you a cup of coffee in a small town. :-) -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: chunksize
On Thursday 23 October 2003 22:14, Paul Yeatman wrote: >Hi, I was once given the impression that chunksize in the > amanda.conf could be used to control at what size a backup image > would be written to tape instead of to holding disk. From reading > what is in the man page, I certainly wouldn't get this idea. > >I made the following note in my amanda.conf at one time (possibly > the negative sign alters the meaning?): > > # chunksize -1370 Mb # in my own words, this tells > # amanda to use a single file on the > holding # disk for any filesystem < 1370 Mb while # writing any > filesystem > 1370 Mb directly # to tape > >I'm now questioning whether any of this is true. I seem to also >vaguely remember something being said to me once about chunksize not >even being used by AMANDA anymore. Any comments to any of this? > >Thanks, > >Paul Chunksize was originally a workaround for some filesystems file size limitations. When in use, the ONLY place it effects is the holding disk by breaking up a huge 30 gig total filesystem into files that it can handle in say, 2 gig hunks. These files are merged into one big file on the tape itself, and all chunks must be completed for a given filesystem before the transfer to the tape begins. And all chunks must have been written to the tape before any chunks are deleted from the holding disk. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: chunksize
> Chunksize was originally a workaround for some filesystems file size > limitations. When in use, the ONLY place it effects is the holding > disk by breaking up a huge 30 gig total filesystem into files that it > can handle in say, 2 gig hunks. These files are merged into one big > file on the tape itself, and all chunks must be completed for a given > filesystem before the transfer to the tape begins. And all chunks > must have been written to the tape before any chunks are deleted from > the holding disk. > Thanks for the reply. Is there any such setting then that would perform what I was once was lead to believe chunksize could control, ie. specifying a file size over which a backup file should be written directly to tape, bypassing the holding disk? -- Paul Yeatman (858) 534-9896[EMAIL PROTECTED] == ==Proudly brought to you by Mutt== ==
Re: chunksize
--On Thursday, October 23, 2003 21:06:36 -0700 Paul Yeatman <[EMAIL PROTECTED]> wrote: >> Chunksize was originally a workaround for some filesystems file size >> limitations. When in use, the ONLY place it effects is the holding >> disk by breaking up a huge 30 gig total filesystem into files that it >> can handle in say, 2 gig hunks. These files are merged into one big >> file on the tape itself, and all chunks must be completed for a given >> filesystem before the transfer to the tape begins. And all chunks >> must have been written to the tape before any chunks are deleted from >> the holding disk. >> > > Thanks for the reply. Is there any such setting then that would > perform what I was once was lead to believe chunksize could control, > ie. specifying a file size over which a backup file should be written > directly to tape, bypassing the holding disk? For the filesystems you want to go directly to tape, use a dumptype that specifies 'holdingdisk no'. I'm not sure why you would want to not use a holdingdisk (unless you are using the FILE driver), it is generally more efficient to use one. Frank > > -- > Paul Yeatman (858) 534-9896[EMAIL PROTECTED] >== >==Proudly brought to you by Mutt== >==
Re: chunksize
> > Thanks for the reply. Is there any such setting then that would > > perform what I was once was lead to believe chunksize could control, > > ie. specifying a file size over which a backup file should be written > > directly to tape, bypassing the holding disk? > > For the filesystems you want to go directly to tape, use a dumptype > that specifies 'holdingdisk no'. >I'm not sure why you would want to not use a holdingdisk (unless > you are using the FILE driver), it is generally more efficient to use > one. > Ah, great point! I had forgotten about this. The main reason I want to write some filesystems to tape (while writing others to holding disk) is that I have a config that backs up some laptops at noon, delaying desktop backups until 9p. If I don't have enough holding disk space for one of the laptop's filesystems, the whole job gets delayed until 9p (which can screw things up when the laptop is no longer on the net at 9p). I'm wondering if I specify for the filesystems of the laptops to always be written directly to tape if this would avoid this problem. Paul -- Paul Yeatman (858) 534-9896[EMAIL PROTECTED] == ==Proudly brought to you by Mutt== ==
Re: chunksize
--On Thursday, October 23, 2003 21:40:13 -0700 Paul Yeatman <[EMAIL PROTECTED]> wrote: >> > Thanks for the reply. Is there any such setting then that would >> > perform what I was once was lead to believe chunksize could control, >> > ie. specifying a file size over which a backup file should be written >> > directly to tape, bypassing the holding disk? >> >> For the filesystems you want to go directly to tape, use a dumptype >> that specifies 'holdingdisk no'. >>I'm not sure why you would want to not use a holdingdisk (unless >> you are using the FILE driver), it is generally more efficient to use >> one. >> > > Ah, great point! I had forgotten about this. > > The main reason I want to write some filesystems to tape (while writing > others to holding disk) is that I have a config that backs up some > laptops at noon, delaying desktop backups until 9p. If I don't > have enough holding disk space for one of the laptop's filesystems, the > whole job gets delayed until 9p (which can screw things up when the > laptop is no longer on the net at 9p). I'm wondering if I specify for > the filesystems of the laptops to always be written directly to tape if > this would avoid this problem. A larger holdingdisk (or smaller reserve) might be an easier solution. Keep in mind that going direct to tape means you do all your backups one at a time in series, but with a holding disk you can do several in parallel (as many as you have dumpers). Depending on how many (and how slow) laptops you're backing up, you might be extending your backup window too long and not having them finish before the laptops go home. You might want to consider using BackupPC to backup the laptops to a machine and then use Amanda to back that up. It would require more disk but it could be on a cheaper machine with a large IDE drive, plus the users can do their own restores. Frank > > Paul > > -- > Paul Yeatman (858) 534-9896[EMAIL PROTECTED] >== >==Proudly brought to you by Mutt== >==
RE: problem labelling tapes
Or you could check for a DIP switch and force compression off. My Sony DDS4
drive can start with compression either on or off and can either be switched
under software control or locked in one mode. I locked compression off so I
don't have this hassle.
Dana Bourgeois
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gene Heskett
> Sent: Thursday, October 23, 2003 3:00 PM
> To: Tony; [EMAIL PROTECTED]
> Subject: Re: problem labelling tapes
>
>
> On Thursday 23 October 2003 05:48, Tony wrote:
> >Hi all,
> >
> >I am still having trouble trying to label tapes and Amanda
> recognising
> >them.
> >
> >I label a tape:
> >
> >bash-2.05a$ /usr/sbin/amlabel daily daily01fri
> >rewinding, reading labelamlabel: strange amanda header: "AMANDA: T"
> >, not an amanda tape
> >rewinding, writing label daily01fri, checking label, done.
> >
> >I then check the tape:
> >
> >bash-2.05a$ dd bs=32k if=/dev/st0
> >AMANDA: TAPESTART DATE X TAPE daily01fri
> >
> >1+0 records in
> >1+0 records out
> >
> >So I then run amcheck:
> >
> >bash-2.05a$ /usr/sbin/amcheck daily
> >Amanda Tape Server Host Check
> >-
> >Holding disk /tmp: 521540 KB disk space available, that's plenty
> >amcheck-server: strange amanda header: "AMANDA: T"
> >ERROR: /dev/nst0: not an amanda tape
> > (expecting tape daily01tue or a new tape)
> >
> >
> >If I continually run amcheck, about maybe 5% of the time I
> will get the
> >response "Tape daily01fri label ok", to indicate that it was
> actually
> >able to read the label on the tape. This is VERY strange !
> >
> >I have downloaded and installed 2.4.4p1 and it is a RH7.3 machine.
> >
> >As an aside, I did manage to work out the stinit stuff and
> the drive is
> >no longer using hardware compression. I did another tapetype and got
> >the following:
> >
> >define tapetype dds4 {
> > comment "produced by tapetype prog (HW compresssion off)"
> > length 19503 mbytes
> > filemark 0 kbytes
> > speed 2693 kps
> >}
> >
> >which is a lot more like what it should be.
> >
> >
> >Any suggestions on why it is not recognising the label ?
> >
> The only idea I keep coming up with is that for DDS tapes, the status
> of the tapes compression is recorded in a hidden header on the tape.
> Simply turning off the compression and relabeling the tape will turn
> it back in in the initial label read, so you wind up with the
> compression on regardless. The workaround I've used is to read out
> the label with dd and save it to a scratch file. Rewind the tape and
> issue the compression off commands, then dd the label file back to
> the tape useing the non-rewinding device. This will not normally
> move the tape, or flush the buffers as its not a big enough write,
> and you'll only succeed if you force the drive to flush its buffers
> which will then record the compression off state in the header. So
> one must, in addition to dd'ing the label back, follow that up with
> another dd from /dev/zero thats big enough to force the buffer flush,
> use at least a meg of /dev/zero more than the drives rated buffer
> size.
>
> I have a script around here someplace, and which has also been posted
> to this list on 2-3 occasions, that does all this in one swell foop
> per tape MOST of the time.
>
> >Thanks,
> >Tony.
> >
> >
> >
> > Want to chat instantly with your online friends? Get the FREE
> >Yahoo! Messenger http://mail.messenger.yahoo.co.uk
>
> --
> Cheers, Gene
> AMD [EMAIL PROTECTED] 320M
> [EMAIL PROTECTED] 512M
> 99.27% setiathome rank, not too shabby for a WV hillbilly
> Yahoo.com attornies please note, additions to this message by
> Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett,
> all rights reserved.
>
>
Re: chunksize
On Thu, Oct 23, 2003 at 09:06:36PM -0700, Paul Yeatman wrote: > > Thanks for the reply. Is there any such setting then that would > perform what I was once was lead to believe chunksize could control, > ie. specifying a file size over which a backup file should be written > directly to tape, bypassing the holding disk? > I'm pretty sure the size of the holding disk already does this. If the estimated size of the backup is larger than the holding disk space it is taped directly. For this determination I believe the space available has already been reduced by the percentage specified by the "reserve" parameter in amanda.conf and by the amount of space the other currently running dumps will take. BTW the "negative number" you thought applied to chunksize might have been the holding disk size. A positive number means use up to the specified amount of space while a negative number means use all the space on the disk except the specified amount. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
