Re: post-upgrade, multiple errors
On Friday 30 March 2007, Charles Sprickman wrote: >On Fri, 30 Mar 2007, Gene Heskett wrote: >> On Friday 30 March 2007, Charles Sprickman wrote: >>> Hello all, >>> >>> I recently upgraded from 2.4.3 to 2.5.1p3 and things have mostly been >>> working correctly except for a few rough edges. To complicate >>> matters, we also upgraded from an AIT drive to an LTO drive. We're >>> currently using 100GB tapes, which comfortably fit an entire level 0 >>> dump (about 60GB). >>> >>> We run bsdtcp auth on all hosts (the main thing driving the update, >>> some remote sites had mtu issues that would cause big estimates to >>> get dropped). >>> >>> We have about 20GB of holding disk space available. >>> >>> We use a mix of gtar (1.16.1) and dump, all on FreeBSD 4.11. >>> >>> Going through the logs it looks like I've got a number of problems. >>> >>> First is the tape size issue: >>> >>> [devel2]/var/log/amanda # grep FAIL log.20070329.0 >>> FAIL planner b02.foo.com /var/qmail 20070329 0 [dump larger than >>> available tape space, 2147483647 KB, but cannot incremental dump new >>> disk] FAIL planner b02.foo.com /var/db/pkg 20070329 0 [dump larger >>> than available tape space, 2147483647 KB, but cannot incremental dump >>> new disk] >> >> Hummm, why do I seem to detect the odor of a 2GB file size limit in >> your BSD filesystems? I'd surely think this has been fixed, but I >> believe that number is 2GB-1 in decimal notation. > >Nope, no such limitation. Plus the sizes of those two disks are only a >few MB, not GB (see next paragraph). It seems like somewhere amanda is >getting very confused, or some number is wrapping. > >>> This seems odd since not only do we have more than enough tape space, >>> but those are very, very small tar backups: >>> >>> [b02]/var/db/pkg # du -hs >>> 3.8M. >>> [b02]/var/qmail # du -hs >>> 1.5M. >>> >>> Then we have issues that look like permissions issues, but I can't >>> reproduce them by hand: >>> >>> FAIL dumper b02.foo.com / 20070329 0 [err create >>> /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp: Operation not >>> permitted] >> >> Selinux? Or are you perchance running amdump as root? > >Nope, all clients and the server are FreeBSD 4.11. Amanda runs as >operator. As I show below, the operator user is able to create the file >with no problems. > >>> [devel2]/var/log/amanda # su -m operator -c "touch >>> /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp" >>> [devel2]/var/log/amanda # ls -l >>> /var/db/amanda/index/b02.fo.com/_/20070329_0.gz.tmp >>> -rw-r--r-- 1 operator wheel 0 Mar 30 20:24 >>> /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp >>> >>> And then I assume this error is related: >>> >>> FAIL chunker b02.foo.com / 20070329 0 [cannot read header: got 0 >>> instead of 32768] >>> >>> And on the client side: >>> >>> sendbackup: time 1.226: 87: normal(|): DUMP: dumping (Pass III) >>> [directories] >>> sendbackup: time 1.387: 87: normal(|): DUMP: dumping (Pass IV) >>> [regular files] >>> sendbackup: time 6426.054: index tee cannot write [Broken pipe] >>> sendbackup: time 6426.055: pid 64720 finish time Thu Mar 29 05:19:43 >>> 2007 >>> >>> And also some chunker errors that have no corresponding dumper >>> errors: >>> >>> FAIL chunker h10.foo.com /spool 20070329 0 [cannot read header: got 0 >>> instead of 32768] >>> >>> On the client: >>> >>> sendbackup: time 5543.622: 87: normal(|): DUMP: 3.63% done, >>> finished in 37:33 >>> sendbackup: time 5843.560: 87: normal(|): DUMP: 3.86% done, >>> finished in 37:19 >>> sendbackup: time 6143.781: 87: normal(|): DUMP: 4.09% done, >>> finished in 37:07 >>> sendbackup: time 6358.556: index tee cannot write [Broken pipe] >>> sendbackup: time 6358.557: pid 67054 finish time Thu Mar 29 05:20:00 >>> 2007 >>> >>> And then at the end of the log I have a number of warnings: >>> >>> WARNING driver chunker4 pid 18178 exited with signal 1 >>> WARNING driver dumper4 pid 18032 exited with signal 1 >>> WARNING driver dumper3 pid 18031 exited with signal 1 >>> WARNING driver dumper2 pid 18030 exited with signal 1 >>> WARNING driver chunker2 pid 18852 exited with signal 1 >>> >>> Can anyone help me kind of focus on a few root issues here? I'm >>> having a really hard time chasing down all these different errors at >>> once. >>> >>> Thanks, >>> >>> Charles >> >> First, and it might not be related, amanda is to be built by a normal >> user, preferably a user named amanda that you have added, and who has >> been made a member of the group disk (or backup, there are others too) >> that have enough perms to wander about the system. > >I built amanda from the ports collection, and the build does run as > root, but as there are thousands of other people using that same method > I'm going to assume that should not cause any problems. I may be full of it, but amanda, built as root, is going to have perms problems because that ruins the suid stuff it does when it needs to, but runs as an unprivileged user the rest of
Re: post-upgrade, multiple errors
On Fri, 30 Mar 2007, Gene Heskett wrote: On Friday 30 March 2007, Charles Sprickman wrote: Hello all, I recently upgraded from 2.4.3 to 2.5.1p3 and things have mostly been working correctly except for a few rough edges. To complicate matters, we also upgraded from an AIT drive to an LTO drive. We're currently using 100GB tapes, which comfortably fit an entire level 0 dump (about 60GB). We run bsdtcp auth on all hosts (the main thing driving the update, some remote sites had mtu issues that would cause big estimates to get dropped). We have about 20GB of holding disk space available. We use a mix of gtar (1.16.1) and dump, all on FreeBSD 4.11. Going through the logs it looks like I've got a number of problems. First is the tape size issue: [devel2]/var/log/amanda # grep FAIL log.20070329.0 FAIL planner b02.foo.com /var/qmail 20070329 0 [dump larger than available tape space, 2147483647 KB, but cannot incremental dump new disk] FAIL planner b02.foo.com /var/db/pkg 20070329 0 [dump larger than available tape space, 2147483647 KB, but cannot incremental dump new disk] Hummm, why do I seem to detect the odor of a 2GB file size limit in your BSD filesystems? I'd surely think this has been fixed, but I believe that number is 2GB-1 in decimal notation. Nope, no such limitation. Plus the sizes of those two disks are only a few MB, not GB (see next paragraph). It seems like somewhere amanda is getting very confused, or some number is wrapping. This seems odd since not only do we have more than enough tape space, but those are very, very small tar backups: [b02]/var/db/pkg # du -hs 3.8M. [b02]/var/qmail # du -hs 1.5M. Then we have issues that look like permissions issues, but I can't reproduce them by hand: FAIL dumper b02.foo.com / 20070329 0 [err create /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp: Operation not permitted] Selinux? Or are you perchance running amdump as root? Nope, all clients and the server are FreeBSD 4.11. Amanda runs as operator. As I show below, the operator user is able to create the file with no problems. [devel2]/var/log/amanda # su -m operator -c "touch /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp" [devel2]/var/log/amanda # ls -l /var/db/amanda/index/b02.fo.com/_/20070329_0.gz.tmp -rw-r--r-- 1 operator wheel 0 Mar 30 20:24 /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp And then I assume this error is related: FAIL chunker b02.foo.com / 20070329 0 [cannot read header: got 0 instead of 32768] And on the client side: sendbackup: time 1.226: 87: normal(|): DUMP: dumping (Pass III) [directories] sendbackup: time 1.387: 87: normal(|): DUMP: dumping (Pass IV) [regular files] sendbackup: time 6426.054: index tee cannot write [Broken pipe] sendbackup: time 6426.055: pid 64720 finish time Thu Mar 29 05:19:43 2007 And also some chunker errors that have no corresponding dumper errors: FAIL chunker h10.foo.com /spool 20070329 0 [cannot read header: got 0 instead of 32768] On the client: sendbackup: time 5543.622: 87: normal(|): DUMP: 3.63% done, finished in 37:33 sendbackup: time 5843.560: 87: normal(|): DUMP: 3.86% done, finished in 37:19 sendbackup: time 6143.781: 87: normal(|): DUMP: 4.09% done, finished in 37:07 sendbackup: time 6358.556: index tee cannot write [Broken pipe] sendbackup: time 6358.557: pid 67054 finish time Thu Mar 29 05:20:00 2007 And then at the end of the log I have a number of warnings: WARNING driver chunker4 pid 18178 exited with signal 1 WARNING driver dumper4 pid 18032 exited with signal 1 WARNING driver dumper3 pid 18031 exited with signal 1 WARNING driver dumper2 pid 18030 exited with signal 1 WARNING driver chunker2 pid 18852 exited with signal 1 Can anyone help me kind of focus on a few root issues here? I'm having a really hard time chasing down all these different errors at once. Thanks, Charles First, and it might not be related, amanda is to be built by a normal user, preferably a user named amanda that you have added, and who has been made a member of the group disk (or backup, there are others too) that have enough perms to wander about the system. I built amanda from the ports collection, and the build does run as root, but as there are thousands of other people using that same method I'm going to assume that should not cause any problems. I'll also add that I did the update over the period of a month or so by upgrading the clients first. There were not any problems during that trial, the oddities only started showing up after the server was also upgraded. Any other ideas? I had a hard time finding any upgrade guides, but looking at the changelog I think I found all the major gotchas to look for (underscores in disk names, quoting of all amanda.conf values, changes to .amandahosts that make permissions more granular, ownership of .amandahosts). Thanks, Charles Only the install is to be done as root. Doing that will eliminate one poten
Re: post-upgrade, multiple errors
On Friday 30 March 2007, Charles Sprickman wrote: >Hello all, > >I recently upgraded from 2.4.3 to 2.5.1p3 and things have mostly been >working correctly except for a few rough edges. To complicate matters, > we also upgraded from an AIT drive to an LTO drive. We're currently > using 100GB tapes, which comfortably fit an entire level 0 dump (about > 60GB). > >We run bsdtcp auth on all hosts (the main thing driving the update, some >remote sites had mtu issues that would cause big estimates to get >dropped). > >We have about 20GB of holding disk space available. > >We use a mix of gtar (1.16.1) and dump, all on FreeBSD 4.11. > >Going through the logs it looks like I've got a number of problems. > >First is the tape size issue: > >[devel2]/var/log/amanda # grep FAIL log.20070329.0 >FAIL planner b02.foo.com /var/qmail 20070329 0 [dump larger than >available tape space, 2147483647 KB, but cannot incremental dump new > disk] FAIL planner b02.foo.com /var/db/pkg 20070329 0 [dump larger than > available tape space, 2147483647 KB, but cannot incremental dump new > disk] > Hummm, why do I seem to detect the odor of a 2GB file size limit in your BSD filesystems? I'd surely think this has been fixed, but I believe that number is 2GB-1 in decimal notation. >This seems odd since not only do we have more than enough tape space, > but those are very, very small tar backups: > >[b02]/var/db/pkg # du -hs >3.8M. >[b02]/var/qmail # du -hs >1.5M. > >Then we have issues that look like permissions issues, but I can't >reproduce them by hand: > >FAIL dumper b02.foo.com / 20070329 0 [err create >/var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp: Operation not >permitted] Selinux? Or are you perchance running amdump as root? > >[devel2]/var/log/amanda # su -m operator -c "touch >/var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp" >[devel2]/var/log/amanda # ls -l >/var/db/amanda/index/b02.fo.com/_/20070329_0.gz.tmp >-rw-r--r-- 1 operator wheel 0 Mar 30 20:24 >/var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp > >And then I assume this error is related: > >FAIL chunker b02.foo.com / 20070329 0 [cannot read header: got 0 >instead of 32768] > >And on the client side: > >sendbackup: time 1.226: 87: normal(|): DUMP: dumping (Pass III) >[directories] >sendbackup: time 1.387: 87: normal(|): DUMP: dumping (Pass IV) >[regular files] >sendbackup: time 6426.054: index tee cannot write [Broken pipe] >sendbackup: time 6426.055: pid 64720 finish time Thu Mar 29 05:19:43 > 2007 > >And also some chunker errors that have no corresponding dumper errors: > >FAIL chunker h10.foo.com /spool 20070329 0 [cannot read header: got 0 >instead of 32768] > >On the client: > >sendbackup: time 5543.622: 87: normal(|): DUMP: 3.63% done, finished >in 37:33 >sendbackup: time 5843.560: 87: normal(|): DUMP: 3.86% done, finished >in 37:19 >sendbackup: time 6143.781: 87: normal(|): DUMP: 4.09% done, finished >in 37:07 >sendbackup: time 6358.556: index tee cannot write [Broken pipe] >sendbackup: time 6358.557: pid 67054 finish time Thu Mar 29 05:20:00 > 2007 > >And then at the end of the log I have a number of warnings: > >WARNING driver chunker4 pid 18178 exited with signal 1 >WARNING driver dumper4 pid 18032 exited with signal 1 >WARNING driver dumper3 pid 18031 exited with signal 1 >WARNING driver dumper2 pid 18030 exited with signal 1 >WARNING driver chunker2 pid 18852 exited with signal 1 > >Can anyone help me kind of focus on a few root issues here? I'm having > a really hard time chasing down all these different errors at once. > >Thanks, > >Charles First, and it might not be related, amanda is to be built by a normal user, preferably a user named amanda that you have added, and who has been made a member of the group disk (or backup, there are others too) that have enough perms to wander about the system. Only the install is to be done as root. Doing that will eliminate one potential list of perms problems. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) We were so poor we couldn't afford a watchdog. If we heard a noise at night, we'd bark ourselves. -- Crazy Jimmy
post-upgrade, multiple errors
Hello all, I recently upgraded from 2.4.3 to 2.5.1p3 and things have mostly been working correctly except for a few rough edges. To complicate matters, we also upgraded from an AIT drive to an LTO drive. We're currently using 100GB tapes, which comfortably fit an entire level 0 dump (about 60GB). We run bsdtcp auth on all hosts (the main thing driving the update, some remote sites had mtu issues that would cause big estimates to get dropped). We have about 20GB of holding disk space available. We use a mix of gtar (1.16.1) and dump, all on FreeBSD 4.11. Going through the logs it looks like I've got a number of problems. First is the tape size issue: [devel2]/var/log/amanda # grep FAIL log.20070329.0 FAIL planner b02.foo.com /var/qmail 20070329 0 [dump larger than available tape space, 2147483647 KB, but cannot incremental dump new disk] FAIL planner b02.foo.com /var/db/pkg 20070329 0 [dump larger than available tape space, 2147483647 KB, but cannot incremental dump new disk] This seems odd since not only do we have more than enough tape space, but those are very, very small tar backups: [b02]/var/db/pkg # du -hs 3.8M. [b02]/var/qmail # du -hs 1.5M. Then we have issues that look like permissions issues, but I can't reproduce them by hand: FAIL dumper b02.foo.com / 20070329 0 [err create /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp: Operation not permitted] [devel2]/var/log/amanda # su -m operator -c "touch /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp" [devel2]/var/log/amanda # ls -l /var/db/amanda/index/b02.fo.com/_/20070329_0.gz.tmp -rw-r--r-- 1 operator wheel 0 Mar 30 20:24 /var/db/amanda/index/b02.foo.com/_/20070329_0.gz.tmp And then I assume this error is related: FAIL chunker b02.foo.com / 20070329 0 [cannot read header: got 0 instead of 32768] And on the client side: sendbackup: time 1.226: 87: normal(|): DUMP: dumping (Pass III) [directories] sendbackup: time 1.387: 87: normal(|): DUMP: dumping (Pass IV) [regular files] sendbackup: time 6426.054: index tee cannot write [Broken pipe] sendbackup: time 6426.055: pid 64720 finish time Thu Mar 29 05:19:43 2007 And also some chunker errors that have no corresponding dumper errors: FAIL chunker h10.foo.com /spool 20070329 0 [cannot read header: got 0 instead of 32768] On the client: sendbackup: time 5543.622: 87: normal(|): DUMP: 3.63% done, finished in 37:33 sendbackup: time 5843.560: 87: normal(|): DUMP: 3.86% done, finished in 37:19 sendbackup: time 6143.781: 87: normal(|): DUMP: 4.09% done, finished in 37:07 sendbackup: time 6358.556: index tee cannot write [Broken pipe] sendbackup: time 6358.557: pid 67054 finish time Thu Mar 29 05:20:00 2007 And then at the end of the log I have a number of warnings: WARNING driver chunker4 pid 18178 exited with signal 1 WARNING driver dumper4 pid 18032 exited with signal 1 WARNING driver dumper3 pid 18031 exited with signal 1 WARNING driver dumper2 pid 18030 exited with signal 1 WARNING driver chunker2 pid 18852 exited with signal 1 Can anyone help me kind of focus on a few root issues here? I'm having a really hard time chasing down all these different errors at once. Thanks, Charles
Re: Delaying tape flush ?
2007/3/30, Joshua Baker-LePain <[EMAIL PROTECTED]>: What exactly was the dd command you used to test with? Specifically, what blocksize did you use? I tried with 32k and 256k. No difference. Maybe I should try with a bigger block size. But I think I'll instead create a software raid0 or try Jon's suggestion and fiddle with the config before launching amdump and after.
Re: Delaying tape flush ?
2007/3/30, Jon LaBadie <[EMAIL PROTECTED]>: With cronjobs, or as part of the amdump cronjob, could you do some pre-amdump and post-amdump activity. For example, if you install or modify amanda.conf to have a non-existant device as tapedev, that would be the equivalent of not inserting a tape. Then after amdump, you could install/modify amdanda.conf with the correct tapedev and do the amflush. (or a check for total amount of data in the holding disk to determine if you want to amflush yet) That's a nice idea. I wonder why I had not taught of it in the first place.
Re: Does amrecover automatically use "unflushed" files on the holding disk ?
[EMAIL PROTECTED] wrote: > On Fri, Mar 30, 2007 at 03:19:35PM -0400, Guy Dallaire wrote: >>A quick question. >>Suppose you run some level 0 backup (GTAR method) with amanda and leav >>the files on the holding disks until there is enough files to fill a >>tape and run amflush. Say this takes 5-6 working days. >>Now, if, after 3 days, I have to restore something that has been >>dumped on the disk on the first day and run "amrecover" on the client >>and "setdate -MM-DD (today - 3 days)" >>Are the holding disk files "indexed" ? Will amanda use them and not >>ask for a tape when comes the time to extract ? > > Quick answer: yep! > And as an added bonus, its faster than restoring from tape. Frank -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Delaying tape flush ?
How about putting ina second SATA drive and using software RAID 0 striping? Also Sprach Guy Dallaire: What are my options ? We can't afford to buy a beefy server just to do backups. We are uning a centos beige commodity box. Even then, the server seems to be I/O bound. What could I do anyway ? Buy a faster disk subsystem ? What kind of subsystem ? -- C. Chan GPG Public Key registered at pgp.mit.edu
Re: Delaying tape flush ?
On Fri, Mar 30, 2007 at 03:15:38PM -0400, Guy Dallaire wrote: > > Of course, I could remove the tape from the drive, and in the morning > manually run amflush, but it's not very very convenient or elegant and it > will monopolize the tape for a couple of hours in case I need to restore > something in an emergency it will be a mess. With cronjobs, or as part of the amdump cronjob, could you do some pre-amdump and post-amdump activity. For example, if you install or modify amanda.conf to have a non-existant device as tapedev, that would be the equivalent of not inserting a tape. Then after amdump, you could install/modify amdanda.conf with the correct tapedev and do the amflush. (or a check for total amount of data in the holding disk to determine if you want to amflush yet) -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Delaying tape flush ?
What are my options ? We can't afford to buy a beefy server just to do backups. We are uning a centos beige commodity box. Even then, the server seems to be I/O bound. What could I do anyway ? Buy a faster disk subsystem ? What kind of subsystem ? Well, first off is that extra 4mb/s really going to make a difference to you? Next, is it really the I/O causing the bottle next? Install the sysstat package and make sure its collecting data. Then tomorrow after the backups you can see if you really did spend a lot of time in iowait. Finally, the cheapest option would be to add another sata disk, and do raid0 between the two disks for your holding space.
Re: Delaying tape flush ?
On Fri, 30 Mar 2007 at 3:15pm, Guy Dallaire wrote I noticed that my LTO-2 tape drive was "starving" for data and shoe-shinning. I was dumping to tape at 12Mb/sec and the minimum speed to prevent shoe-shinning on an LTO-2 drive is 19Mb/sec. So I did a check by timing a 'dd' of 10 Gb to the tape drive. It was indeed topped at 12 Mb/sec. It took 13m51s What exactly was the dd command you used to test with? Specifically, what blocksize did you use? Now, I replaced the antedeluvian adaptec 2940 with an adaptec 29160 ultra 160 car and redid the exercice. This time, it took 6m51s, so I was running at about 24 Mb/Sec. That was ok. Not very fast, bot OK. Now, when I looked at my amanda log this morning, I was very sad to see the following: *snip* Avg Tp Write Rate (k/s) 17549.520734.512469.2 *snip* Now, I figure the problem is that when I did the "dd" test, all my holding disk had to do is read the files. Now, it has to read the files whil amanda is pounding at it, wrinting dump files coming from the clients... and unfortunately, it seems my single SATA disk can't keep up with all those I/Os Quite possible. What are my options ? We can't afford to buy a beefy server just to do backups. We are uning a centos beige commodity box. Even then, the server seems to be I/O bound. What could I do anyway ? Buy a faster disk subsystem ? What kind of subsystem ? The first thing to look into is if a larger blocksize will help you. On my LTO3, going to 2MB blocksize significantly sped things up. Test with larger blocksizes (via dd or tar) and, if they help, recompile amanda to allow you to use a bigger blocksize. In terms of beefing up your disk system, if you could just add a drive or two and do a software RAID0, that would speed things up. But try the blocksize fix first. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Does amrecover automatically use "unflushed" files on the holding disk ?
On Fri, Mar 30, 2007 at 03:19:35PM -0400, Guy Dallaire wrote: >A quick question. >Suppose you run some level 0 backup (GTAR method) with amanda and leav >the files on the holding disks until there is enough files to fill a >tape and run amflush. Say this takes 5-6 working days. >Now, if, after 3 days, I have to restore something that has been >dumped on the disk on the first day and run "amrecover" on the client >and "setdate -MM-DD (today - 3 days)" >Are the holding disk files "indexed" ? Will amanda use them and not >ask for a tape when comes the time to extract ? Quick answer: yep! Dustin -- Dustin J. Mitchell Storage Software Engineer, Zmanda, Inc. http://www.zmanda.com/
Does amrecover automatically use "unflushed" files on the holding disk ?
A quick question. Suppose you run some level 0 backup (GTAR method) with amanda and leav the files on the holding disks until there is enough files to fill a tape and run amflush. Say this takes 5-6 working days. Now, if, after 3 days, I have to restore something that has been dumped on the disk on the first day and run "amrecover" on the client and "setdate -MM-DD (today - 3 days)" Are the holding disk files "indexed" ? Will amanda use them and not ask for a tape when comes the time to extract ? Thanks
Delaying tape flush ?
I noticed that my LTO-2 tape drive was "starving" for data and
shoe-shinning.
I was dumping to tape at 12Mb/sec and the minimum speed to prevent
shoe-shinning on an LTO-2 drive is 19Mb/sec.
So I did a check by timing a 'dd' of 10 Gb to the tape drive. It was indeed
topped at 12 Mb/sec. It took 13m51s
Now, I replaced the antedeluvian adaptec 2940 with an adaptec 29160 ultra
160 car and redid the exercice.
This time, it took 6m51s, so I was running at about 24 Mb/Sec. That was ok.
Not very fast, bot OK.
Now, when I looked at my amanda log this morning, I was very sad to see the
following:
8<--
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:06
Run Time (hrs:min) 2:03
Dump Time (hrs:min)4:32 2:49 1:44
Output Size (meg) 12963.4 9414.1 3549.3
Original Size (meg) 48289.831693.316596.6
Avg Compressed Size (%)22.5 23.1 21.4 (level:#disks ...)
Filesystems Dumped 53 12 41 (1:41)
Avg Dump Rate (k/s) 812.7 952.5 585.1
Tape Time (hrs:min)0:13 0:08 0:05
Tape Size (meg) 12963.5 9414.2 3549.3
Tape Used (%) 6.74.91.8 (level:#disks ...)
Filesystems Taped53 12 41 (1:41)
Avg Tp Write Rate (k/s) 17549.520734.512469.2
USAGE BY TAPE:
Label Time Size %Nb
DailySet1-018 0:1312963M6.753
---8<-
I'm still under 20Mb/Sec
Now, I figure the problem is that when I did the "dd" test, all my holding
disk had to do is read the files. Now, it has to read the files whil amanda
is pounding at it, wrinting dump files coming from the clients... and
unfortunately, it seems my single SATA disk can't keep up with all those
I/Os
What are my options ? We can't afford to buy a beefy server just to do
backups. We are uning a centos beige commodity box. Even then, the server
seems to be I/O bound. What could I do anyway ? Buy a faster disk subsystem
? What kind of subsystem ?
Of course, I could remove the tape from the drive, and in the morning
manually run amflush, but it's not very very convenient or elegant and it
will monopolize the tape for a couple of hours in case I need to restore
something in an emergency it will be a mess.
Thanks
Re: Fwd: Daily Backup AMFLUSH MAIL REPORT FOR March 30, 2007
FL wrote:
What does the fllowing error mean?
Something really bad, could you post the amflush.1 log file?
What's in your holding disk? ls -alR /path/to/holding/disk
-- Forwarded message --
From: backup <[EMAIL PROTECTED]>
Date: Mar 30, 2007 12:09 AM
Subject: Daily Backup AMFLUSH MAIL REPORT FOR March 30, 2007
To: [EMAIL PROTECTED]
*** THE DUMPS DID NOT FINISH PROPERLY!
The next tape Amanda expects to use is: Daily-12.
FAILURE AND STRANGE DUMP SUMMARY:
driver: FATAL flush line 2: syntax error (bad level)
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
NOTES:
driver: 1: ignoring cruft file.
taper: Received signal 1
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISKL ORIG-MB OUT-MB COMP% MMM:SS KB/s
MMM:SS KB/s
-- -
-
wilf -anda/Daily NO FILE TO FLUSH
--
wilf /etc/udev NO FILE TO FLUSH
--
wilf -EGANAS/Mac NO FILE TO FLUSH
--
wilf -S/RECYCLER NO FILE TO FLUSH
--
wilf -NAS/Shared NO FILE TO FLUSH
--
wilf -NAS/System NO FILE TO FLUSH
--
wilf -S/VertasBE NO FILE TO FLUSH
--
wilf -/local/bin NO FILE TO FLUSH
--
(brought to you by Amanda version 2.5.1p1)
Thanks,
FL
Re: File driver usage
> >> Yes, dear, the file _does_ actually exist: > >>> ls -la /xlv1/amanda/algo_test/tape1 > >> > >> total 0 > >> drwxrwxr-x3 amanda amanda22 Mar 28 12:57 . > >> drwxrwxr-x3 amanda amanda23 Mar 28 12:57 .. > >> drwxrwxr-x2 amanda amanda 9 Mar 28 12:57 data > > > > (...) > > > >> runtapes 1 tapedev "file:/xlv1/amanda/algo_test/tape1" > > > > Hmm, weird... tapedev should be on a separate line, but I guess something > > was wrong with your copy/paste (?), otherwise amcheck would have choke on > > it > > > > Anyway, your setup seems to be wrong: tapedev should be a directory > > containing the tapes, not the tape itself, and data must be a sym link > > pointing to one of the tapes. For instance, I have > > tapedev="file:/backup/archive" and: > > I have a strong suspicion that you are wrong, and the setup was correct. > There is no requirement for data being a symlink. > Note he is using a simple file driver, no changer involved. > And even changer "chg-multi" does not use need data to be a symlink, > only the chg-disk implementation uses symlinks. > Yes you're right, I understood that Jurgen wanted to setup a chg-disk. I didn't know it was possible to use the file driver with no changer at all, now I understand all the strange things I've read about that :) Thank you. -- Cédric Lucantis
Re: File driver usage
On 2007-03-29 17:56, Cédric Lucantis wrote: >> Yes, dear, the file _does_ actually exist: >>> ls -la /xlv1/amanda/algo_test/tape1 >> total 0 >> drwxrwxr-x3 amanda amanda22 Mar 28 12:57 . >> drwxrwxr-x3 amanda amanda23 Mar 28 12:57 .. >> drwxrwxr-x2 amanda amanda 9 Mar 28 12:57 data >> > (...) >> runtapes 1 tapedev "file:/xlv1/amanda/algo_test/tape1" > > Hmm, weird... tapedev should be on a separate line, but I guess something was > wrong with your copy/paste (?), otherwise amcheck would have choke on it > > Anyway, your setup seems to be wrong: tapedev should be a directory > containing > the tapes, not the tape itself, and data must be a sym link pointing to one > of the tapes. For instance, I have tapedev="file:/backup/archive" and: I have a strong suspicion that you are wrong, and the setup was correct. There is no requirement for data being a symlink. Note he is using a simple file driver, no changer involved. And even changer "chg-multi" does not use need data to be a symlink, only the chg-disk implementation uses symlinks. The setup is correct, but amanda 2.4.2 does not have a filedriver. There was already a strong hint about that problem: the commands ammt and amdd did not exist either. -- 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 * ***
