Paul Bijnens wrote: > On 2006-03-09 13:25, Iulian Topliceanu wrote: >> >> I'm using AMANDA server 2.4.5p1 on a RH 9 having DLT tapes and vtapes as >> well. >> >> All the backup clients are Linux machines using ext3 fs. >> >> I had two particular problem with a client running CentOS and using >> tar-1.14 and amanda-client 2.4.5p1. > > The CentOS tar-1.14 that I use does work fine AFAIK, and I also use Amanda 2.4.5p1 on the production server (and clients). > > >> 1: amadmin (and the mail reports as well) reported that /var/spool/mail/p >> level 0 dump, was on vtape-7, but for unknown reasons, vtape-7 didn't >> contain any data regarding /var/spool/mail/p, it contained >> other data that had no relevance. > > Here you talk about "vtape-7", below you talk about "vtapes-7", plural. > Typing mistake in the mail, I presume... Typo, sorry. > > "other data"? amanda backups? or garbage? It contained other data, not garbage. It contained data that was reported as failed to be backuped.
baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] > > One other thing: is the /var/spool/mail/p a directory or a plain file? /var/spool/mail/p is a directory. > >> >> I wasn't able to find /var/spool/mail/p level 0 dump, on any of the >> vtapes. The backup was inconsistent. > > What do you mean with "inconsistent" here? > Is that entry the only one that is missing, and seems the rest to > be OK? It wasn't the only entry that wasn't ok, I had another 7 DLE's which had the same problem, all of them reported to be also on vtape-7 (singular) > > >> >> I've checked the history of AMANDA, and /var/spool/mail/p level 0 dump, >> was reported to be on vtapes-7, and there wasn't any error during the >> backup procedure. > > ... "vtapes-7" ... > > >> >> The dump definition looks like this: >> >> dumpcycle 10 day # the number of days in the normal dump cycle >> runspercycle 8 day # the number of amdump runs in dumpcycle days >> tapecycle 12 tapes # the number of tapes in rotation > > seems fine. > >> >> Can I still trust AMANDA reports or should I do a manual check? > > I trust them. But you don't have to believe me. I've trusted them as well and I will still trust them > If you have reason to not trust them, then extra checks are appropriate. > However, would those extra checks have detected an error that Amanda > was unable to? What kind of extra checks did you think of? Amanda reported that the dumps where successfully to tape vtape-7, but taking a simple look to what that vtape-7 contained (using ls), has proved the opposite, there was no sign of /var/spool/mail/p (and the other DLE's which had the same problem) on vtape-7. vtape-7 contained /data/data0/share1 (directory, which I said above, was reported not to be backuped successfully) I should mention that these this didn't occure on the same run. My guess is that Amanda backuped successfully /var/spool/mail/p (and the other DLE's) on the 24.02 and wrote them to vtape-7, but on the 2.03 when this error occured: baal /data/data0/share1 lev 0 FAILED [dump larger than tape, 31665455 KB, incremental dump also larger than tape] The dumps where written again on vtape-7, so that's the reason why /data/data0/share1 appears to pe on vtape-7 instead of /var/spool/mail/p (and the other DLE's) But why doesn't amadmin report that? Why doesn't Amanda make again a level 0 dump of /var/spool/mail/p? I've noticed that 12 vtapes where used in less than 10 days (the dumpcycle = 10 days) but is that an excuse for missing data? > > >> >> 2: the last level 0 dump of /var/spool/mail/p was on the 24.02, and the >> next incremental dump took place on the 27.02, so, though the level 0 dump >> of /var/spool/mail/p was missing, the incremental backup of >> /var/spool/mail/p should have had included all the new mails between 24.02 >> - 27.02. >> >> How is is possible for GNUtar to skip files that have a ctime newer than >> the last level 0 dump? > > Do you mean that the level 1 dump did not contain the expected files either? Did it contain anything at all? Level 1 dump didn't contain *all* of the expected files. Some of the mails received during the level 0 dump and level 1 dump, where not present. I should add that the volume /var/spool/mail (which is split in /var/spool/mail/[a-z]) is 130 GB big and has ~7 million inodes. Iulian Topliceanu
