Re: A bit of a bug - or I'm missing something?
On 10/25/07, Lindsay Haisley [EMAIL PROTECTED] wrote: Well fstab is the only data structure on the box that relates /dev/sda1 to /boot, which is what gets backed up willy-nilly. It has to be referenced _somewhere_ in the process! You're right -- Amanda does use fstab for that. Sorry! Dustin -- Storage Software Engineer http://www.zmanda.com
Re: A bit of a bug - or I'm missing something?
On Wed, 2007-10-24 at 22:43 -0500, Dustin J. Mitchell wrote: On 10/24/07, Lindsay Haisley [EMAIL PROTECTED] wrote: I have a DLE in my disklist which specifies a dump of /dev/sda1 on a client box. /dev/sda1 is the /boot partition and is generally not mounted unless I'm doing something such as installing a new kernel. What amandad on the client system is apparently doing is looking at /etc/fstab, which contains a noauto entry for /dev/sda1 so that it can be mounted easily, and then backing up /boot which is the mountpoint for /dev/sda1. /boot contains only a couple of placeholder files of no consequence. amandad's not looking at fstab, AFAIK, Well fstab is the only data structure on the box that relates /dev/sda1 to /boot, which is what gets backed up willy-nilly. It has to be referenced _somewhere_ in the process! and certainly isn't going to mount anything. If you want to do this, you should either use DUMP for that partition, or just mount it (read-only, if you'd like) so Amanda can back it up. Pre-mounting is probably the way to go here. If you're feeling really excited to spend some time, you could write a gtar wrapper that mounts the fs for the duration of the backup, then unmounts it.. Been there, done that (for other problems). I think I'll let this one pass grin. Thanks. -- Lindsay Haisley | In an open world,| PGP public key FMP Computer Services |who needs Windows | available at 512-259-1190 | or Gates| http://pubkeys.fmp.com http://www.fmp.com| |
discrepency between amadmin, logs and tape content?
Hi,
With amanda-2.5.2p1 I did an archive a few days ago and trying to
restore it caused me a few problems: amfetchdump tells me that
there is no valid data to be restored for that date and amadmin
reports a connection timeout:
grumpy: /opt/amanda/sbin/amfetchdump -p -d /dev/nst1 archive-nihpd3-right1 \
yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 | tar -tvf -
No matching dumps found
grumpy: su amanda -c /opt/amanda/sbin/amadmin archive-nihpd3-right1 \
find yorick /data/nihpd/nihpd3/data/mri_processing/1.1
2007-10-22 yorick /data/nihpd/nihpd3/data/mri_processing/1.1 0
av24-1_archive-nihpd3-right1_T6L30 -- FAILED (dumper) [data
read: recv error: Connection timed out]
However I was able to manually extract all the chunks on that tape
and, after reassembling them, to untar everything without a glitch.
Looking at the logs I see that it was retried with success:
DISK planner yorick /data/nihpd/nihpd3/data/mri_processing/1.1
FAIL dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022
0 [data read: recv error: Connection timed out]
sendbackup: start [yorick:/data/nihpd/nihpd3/data/mri_processing/1.1
level 0]
PARTIAL chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 9771.397 kb 105401080 kps 10786.7]
SUCCESS dumper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 10432.472 kb 113375650 kps 10867.6 orig-kb 113375650]
SUCCESS chunker yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 10432.600 kb 113375650 kps 10867.4]
STATS driver estimate yorick /data/nihpd/nihpd3/data/mri_processing/1.1
20071022 0 [sec 8192 nkb 113375682 ckb 113375712 kps 13840]
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 1 0 [sec
197.311 kb 5242848 kps 26571.5 {wr: writers 163840 rdwait
79.637 wrwait 112.112 filemark 4.930}]
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 2 0 [sec
101.364 kb 5242848 kps 51722.7 {wr: writers 163840 rdwait
42.617 wrwait 57.238 filemark 1.013}]
...
CHUNK taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 22 0
[sec 60.077 kb 3275872 kps 54527.8 {wr: writers 102372 rdwait
3.036 wrwait 55.529 filemark 1.051}]
CHUNKSUCCESS taper yorick /data/nihpd/nihpd3/data/mri_processing/1.1 20071022 0
[sec 2313.467 kb 113376352 kps 49007.1 {wr: writers 102372
rdwait 3.036 wrwait 55.529 filemark 1.051}]
what gives?
jf
--
°
[no subject]
Here is the amstatus of our amdump. What performance problems can be seen from the output below? For ex. 12 dumpers busy : 0:02:30 ( 1.83%) client-constrained: 0:02:30 ( 99.99%) 13 dumpers busy : 0:04:03 ( 2.95%) client-constrained: 0:04:03 (100.00%) 14 dumpers busy : 0:00:06 ( 0.08%) client-constrained: 0:00:06 (100.00%) What improvements can be made to not have these client-constrained messages? /opt/amanda/server/sbin/amstatus --config Full | more Using /var/log/debug/Full/amdump from Thu Oct 25 12:13:00 CDT 2007 qaapp05-bkup.1sync.org:/home 1 151k finished (12:24:25) qaapp05-bkup.1sync.org:/opt1 5757455k dumping 2704928k ( 46.98%) (12:23:24) qaapp70-bkup.1sync.org:/ 1 9805k finished (12:29:08) qaapp70-bkup.1sync.org:/home 128k finished (12:23:36) qadb01-bkup.1sync.org:/u02 1 1k finished (12:24:29) qadb01-bkup.1sync.org:/u03 1 1k finished (12:23:58) qadb01-bkup.1sync.org:/u04 1 21417710k dumping 1515328k ( 7.08%) (12:23:24) qadb06-bkup.1sync.org:/home1 5k finished (12:24:42) qadb06-bkup.1sync.org:/opt 0 4764470k dumping 3788192k ( 79.51%) (12:23:59) qadb06-bkup.1sync.org:/var 1 1078k finished (12:23:45) qadb11-bkup.1sync.org:/1 3236k finished (12:26:54) qadb11-bkup.1sync.org:/home122k finished (12:23:54) qadb11-bkup.1sync.org:/opt 0 3797655k dumping 2590176k ( 68.20%) (12:24:01) qadb70-bkup.1sync.org:/1 3505k finished (12:27:37) qadb70-bkup.1sync.org:/U 0 21387400k dumping 1621856k ( 7.58%) (12:23:24) qadb70-bkup.1sync.org:/home112k finished (12:24:03) qadb70-bkup.1sync.org:/opt 1 7417055k dumping 850336k ( 11.46%) (12:23:40) qadb70-bkup.1sync.org:/var 1 4910k finished (12:26:31) SUMMARY part real estimated size size partition : 56 estimated : 56 76330503k flush : 0 0k failed : 00k ( 0.00%) wait for dumping: 00k ( 0.00%) dumping to tape : 00k ( 0.00%) dumping : 6 13070816k 64541745k ( 20.25%) ( 17.12%) dumped : 50 5497439k 11788758k ( 46.63%) ( 7.20%) wait for writing: 0 0k 0k ( 0.00%) ( 0.00%) wait to flush : 0 0k 0k (100.00%) ( 0.00%) writing to tape : 0 0k 0k ( 0.00%) ( 0.00%) failed to tape : 0 0k 0k ( 0.00%) ( 0.00%) taped : 50 5497439k 11788758k ( 46.63%) ( 7.20%) tape 1: 50 5497439k 11788758k ( 1.39%) EGV007 14 dumpers idle : no-dumpers taper writing, tapeq: 0 network free kps: 3696868 holding space : 436734564k ( 86.77%) chunker0 busy : 0:09:58 ( 7.25%) chunker1 busy : 0:03:50 ( 2.79%) chunker4 busy : 0:05:41 ( 4.14%) chunker6 busy : 1:26:33 ( 62.88%) chunker7 busy : 2:04:38 ( 90.54%) chunker8 busy : 0:00:29 ( 0.36%) chunker9 busy : 0:12:16 ( 8.92%) chunker10 busy : 0:05:15 ( 3.82%) chunker11 busy : 0:05:21 ( 3.89%) chunker12 busy : 0:00:21 ( 0.25%) chunker14 busy : 2:05:05 ( 90.87%) chunker15 busy : 0:09:29 ( 6.90%) chunker16 busy : 0:04:07 ( 2.99%) chunker17 busy : 0:05:18 ( 3.86%) chunker18 busy : 1:32:47 ( 67.42%) chunker19 busy : 0:32:07 ( 23.34%) dumper0 busy : 0:09:57 ( 7.24%) dumper1 busy : 0:03:49 ( 2.78%) dumper2 busy : 2:07:14 ( 92.44%) dumper3 busy : 2:07:14 ( 92.44%) dumper4 busy : 0:05:41 ( 4.14%) dumper5 busy : 2:07:14 ( 92.44%) dumper6 busy : 1:26:32 ( 62.88%) dumper7 busy : 2:04:38 ( 90.54%) dumper8 busy : 2:07:09 ( 92.38%) dumper9 busy : 0:12:16 ( 8.92%) dumper10 busy : 0:05:15 ( 3.82%) dumper11 busy : 0:05:21 ( 3.89%) dumper12 busy : 2:06:59 ( 92.25%) dumper13 busy : 2:06:59 ( 92.25%) dumper14 busy : 2:05:05 ( 90.87%) dumper15 busy : 0:09:29 ( 6.90%) dumper16 busy : 0:04:07 ( 2.99%) dumper17 busy : 0:05:18 ( 3.86%) dumper18 busy : 1:32:47 ( 67.42%) dumper19 busy : 0:32:07 ( 23.34%) taper busy : 0:06:18 ( 4.58%) 0 dumpers busy : 0:10:22 ( 7.54%)not-idle: 0:10:22 (100.00%) 1 dumper busy : 0:00:00 ( 0.00%) 2 dumpers busy : 0:00:00 ( 0.00%) 3 dumpers busy : 0:00:00 ( 0.00%) 4 dumpers busy : 0:00:00 ( 0.00%) 5 dumpers busy : 0:00:00 ( 0.00%) 6 dumpers busy : 0:01:53 ( 1.38%) no-dumpers: 0:01:53 (100.00%) 7 dumpers busy : 0:00:42 ( 0.52%) no-dumpers: 0:00:42 (100.00%) 8 dumpers busy : 0:31:39 ( 22.99%) no-dumpers: 0:31:33 ( 99.70%) start-wait: 0:00:05 ( 0.30%) 9 dumpers
