Re: What causes this error?
Looks like the bug that I posted, which I believe Jean-Louis sent the patch for. I've been unable to test it as of yet. On 11/15/2010 04:11 PM, Robert Heller wrote: At Mon, 15 Nov 2010 15:34:31 -0500 Jean-Louis Martineau wrote: Because ravel:/mnt/RAID0 was not dumped. Check the email report to know why or the client debug file (on ravel) The E-Mail report just says: FAILURE DUMP SUMMARY: ravel /mnt/RAID0 RESULTS MISSING ravel /mnt/RAID0 lev 1 FAILED [can't dump in degraded mode] And there isn't a sendbackup debug file for /mnt/RAID0. There are sendbackup debug files for the other file systems on ravel. There is a sendsize debug file for /mnt/RAID0 on ravel. Jean-Louis Robert Heller wrote: Using /var/log/amanda/60villagedrive/amdump.1 From Mon Nov 15 00:10:02 EST 2010 bach:/ 183m finished (0:17:59) haydn:/ 147m finished (0:20:35) ravel:/ 189m finished (0:20:36) ravel:/mnt/RAID0 1 816m failed: process terminated while waiting for dumping ravel:/mnt/sdb2 1 0m finished (0:20:34) .. This is in a CentOS 5.5 system: -sh-3.2$ rpm -qa amanda\* perl dump amanda-backup_server-3.2.0-1.rhel5 dump-0.4b41-4.el5 perl-5.8.8-32.el5_5.2
Re: What causes this error?
At Mon, 15 Nov 2010 15:34:31 -0500 Jean-Louis Martineau wrote: > > Because ravel:/mnt/RAID0 was not dumped. > Check the email report to know why or the client debug file (on ravel) The E-Mail report just says: FAILURE DUMP SUMMARY: ravel /mnt/RAID0 RESULTS MISSING ravel /mnt/RAID0 lev 1 FAILED [can't dump in degraded mode] And there isn't a sendbackup debug file for /mnt/RAID0. There are sendbackup debug files for the other file systems on ravel. There is a sendsize debug file for /mnt/RAID0 on ravel. > > Jean-Louis > > Robert Heller wrote: > > Using /var/log/amanda/60villagedrive/amdump.1 > > From Mon Nov 15 00:10:02 EST 2010 > > > > bach:/ 183m finished (0:17:59) > > haydn:/ 147m finished (0:20:35) > > ravel:/ 189m finished (0:20:36) > > ravel:/mnt/RAID0 1 816m failed: process terminated while waiting for > > dumping > > ravel:/mnt/sdb2 1 0m finished (0:20:34) > > .. > > > > This is in a CentOS 5.5 system: > > > > -sh-3.2$ rpm -qa amanda\* perl dump > > amanda-backup_server-3.2.0-1.rhel5 > > dump-0.4b41-4.el5 > > perl-5.8.8-32.el5_5.2 > > > > > > > > > > -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
Re: What causes this error?
Because ravel:/mnt/RAID0 was not dumped. Check the email report to know why or the client debug file (on ravel) Jean-Louis Robert Heller wrote: Using /var/log/amanda/60villagedrive/amdump.1 From Mon Nov 15 00:10:02 EST 2010 bach:/ 183m finished (0:17:59) haydn:/ 147m finished (0:20:35) ravel:/ 189m finished (0:20:36) ravel:/mnt/RAID0 1 816m failed: process terminated while waiting for dumping ravel:/mnt/sdb2 1 0m finished (0:20:34) .. This is in a CentOS 5.5 system: -sh-3.2$ rpm -qa amanda\* perl dump amanda-backup_server-3.2.0-1.rhel5 dump-0.4b41-4.el5 perl-5.8.8-32.el5_5.2
What causes this error?
Using /var/log/amanda/60villagedrive/amdump.1 >From Mon Nov 15 00:10:02 EST 2010 bach:/ 183m finished (0:17:59) haydn:/ 147m finished (0:20:35) ravel:/ 189m finished (0:20:36) ravel:/mnt/RAID0 1 816m failed: process terminated while waiting for dumping ravel:/mnt/sdb2 1 0m finished (0:20:34) .. This is in a CentOS 5.5 system: -sh-3.2$ rpm -qa amanda\* perl dump amanda-backup_server-3.2.0-1.rhel5 dump-0.4b41-4.el5 perl-5.8.8-32.el5_5.2 -- Robert Heller -- 978-544-6933 / hel...@deepsoft.com Deepwoods Software-- http://www.deepsoft.com/ () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments
Re: planner bumps to level 4 are actually done as level 0's
On Monday, November 15, 2010 07:21:15 am Jean-Louis Martineau did opine: > Don't use tar-1.24 or 1.25, they don't works with amanda according to: > http://www.mail-archive.com/bug-...@gnu.org/msg02993.html > > Jean-Louis > Which with careful reading, explains why the dumps have been so darned small the last 2 days. So I just forced tar-1.23 back in. Thanks Jean- Louis. In fact, I think I'll run my catchup script, set for dumpcycle +1 repeats as insurance. Humm, errors out, the directory it keeps a log file in had gone missing. Fixed, running. I wonder how long it will take to get a 1.26, and then get it into pclos repo's... -- 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 reject: kings, presidents, and voting. We believe in: rough consensus and working code. -- Dave Clark
Re: planner bumps to level 4 are actually done as level 0's
Don't use tar-1.24 or 1.25, they don't works with amanda according to: http://www.mail-archive.com/bug-...@gnu.org/msg02993.html Jean-Louis Gene Heskett wrote: On Sunday, November 14, 2010 02:48:23 am Jean-Louis Martineau did opine: It probably did a level 0 because it was time to do it. What's the dumpcycle? When was the last level 0? Post the amdump.1 log file. Gene Heskett wrote: From the canary; Someone using tapes which do have a fixed, finite size, is going to get bitten, but so far my messages appear to be going to a black hole. Whenever planner advances the backup level to a level 4, the rest of the system treats it as if it was a level 0. I can raise the BUMPMULT to prevent that I suppose, but wouldn't it make more sense to fix it? I get the impression there is a modulo 4 someplace in the middle. Last night planner set /home to level 4. But In /tmp/amanda-dbug/server/Daily, [r...@coyote Daily]# grep level *.20101112*.debug|grep /home shows the dumplevel as 0 in all returns. And no returns contain planner hits as planner does not say 'level', just the number. Moving to /tmp/amanda-dbg/client/Daily, that same grep shows the estimate calls only: [r...@coyote Daily]# grep level *.20101112*.debug|grep /home amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar: estimate time for /home level 0: 65.394 amgtar.20101112005020008.debug:Fri Nov 12 00:51:26 2010: amgtar: estimate size for /home level 0: 20135930 KB amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar: estimate time for /home level 3: 15.648 amgtar.20101112005020008.debug:Fri Nov 12 00:51:47 2010: amgtar: estimate size for /home level 3: 3414990 KB amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar: estimate time for /home level 4: 15.496 amgtar.20101112005020008.debug:Fri Nov 12 00:52:08 2010: amgtar: estimate size for /home level 4: 3316150 KB sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 0 sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 3 sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: getting size via application API for /home /home level 4 sendsize.20101112005019.debug:Fri Nov 12 00:50:20 2010: sendsize: running: "/usr/local/libexec/amanda/application/amgtar estimate --message line --config Daily --host coyote --device /home --disk /home --level 0 --level 3 --level 4 --exclude-list /GenesAmandaHelper-0.6/excludes --check-device no" sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 0: 20135930 KB sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 3: 3414990 KB sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate size for /home level 4: 3316150 KB sendsize.20101112005019.debug:Fri Nov 12 00:52:08 2010: sendsize: estimate time for /home all level: 107.406 But it actually did the whole 20 gigabyte level 0. gzipped to 12. ? Another run tonight is very confusing. I let synaptic install tar-1.24, and in tonights email from amanda there are several things that don't make any sense in terms of the level stated vs the level performed. Using tar-1.24, and 3.2.0-svn-3621 the levels the planner decided to use are the levels performed, but they are reported as level 0's despite the output sizes obviously being nothing more than the directory listing of say 10kb. I think I am going to backup a version a night until the mistakes disappear. But I'll start with 3.2.0.svn.3608 since I believe I saw this the first time at that snapshot. Then 3603, 3599, 3577. Earlier than that I start doing fresh tarballs. amdump.1 from this messed up run is attached.
Re: Ominous message from amrecover -- what does it mean?
Robert Heller wrote: When recovering a single directory from a backup (as a test) I got this message from amrecover: All existing files in /mnt/RAID0 can be deleted Continue [?/Y/n]? What's the significance of this rather ominous sounding line? Restoring backup can delete file to get the filesystem state exactly as it was during the backup, amanda don't know what file will be removed, so it warn that all files can vbe deleted. It's is always safer to do a restore in an empty directory. Jean-Louis
Re: Question about amrecover and deleted files.
amrecover will recover the full dump followed by the dump of day 3. The full dump will restore files a, b & c The dump of day 3 will delete file a & b The result is you get get only the file c. You get the filesystem as it was while the latest restored backup was done. Jean-Louis Robert Heller wrote: I have a client that has a (to me anyway) 'strange' scenario: "Think about this scenario. Day 1: Directory x has files, a, b & c. Amanda does a full backup Day 2: rm file a. Amanda does a differential backup Day 3: rm file b. Amanda does a differential backup, Day 4: Directory x has only file c. We remove Directory x. And restore Directory x. . From what you are saying, the restored Directory would have files a, b & c. I would expect to restore Directory x with only file c -- the state of the directory upon the last amanda backup." Question: what will be in Directory x after doing an amrecover of Directory x? Will files a and b be restored or not? And why or why not? What is considered the correct answer to this partitular thought exercise? And why? As a long time computer user *my* expectation would be for Directory x to have all three files, a, b & c in it after the recover. Is my expectation wrong? Why? Note: this is *separate* from a full restore in the event of a disk crash. Side question: would the above answers *change* if the backups were done with gnutar instead of dump?
