Re: Missing files from Samba backup
Hi Amanda Users! This morning I noticed that a DLE which has been forced (Level 0) on a NT 4.0 Service Pack 6 computer via Samba did not completely backup all files. It seem that for any file/directory listed in Amanda's report (See below) which start with a ? SUCCESS - 0 statement were not archived or added to the index files. The reason I found that there was a serious problem is that a full should contain about 88 gigs of data while only about 20 gigs were taped. This caused me to look back through the full backup logs for other computers and found similar problems. At first I thought it was due to the NT box drive being a RAID configuration be alas the problem also occurs on Win 85 and Win 98 computers. A search of the archive did not point to any solutions. Anyone have an idea of what is going wrong? Amanda version 2.4.2p2 tar (GNU tar) 1.13.25 Thanks, Vytas These dumps were to tape Daily14. The next tape Amanda expects to use is: Daily15. FAILURE AND STRANGE DUMP SUMMARY vxa2 //nt-01/nt01-d lev 0 STRANGE /-- vxa2 //nt-01/nt01-d lev 0 STRANGE sendbackup: start [vxa2://nt-01/nt01-d level 0] sendbackup: info BACKUP=/usr/bin/smbclient sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... - sendbackup: info end ? NT_STATUS_SHARING_VIOLATION opening remote file \pagefile.sys (\) ? SUCCESS - 0 opening remote file \Project\AgCan\0_Ontario\ALCDB_Vytas.zip (\Project\AgCan\0_Ontario\) ? SUCCESS - 0 opening remote file \Project\AgCan\0_Ontario\Arc_Info_Generalize.bmp (\Project\AgCan\0_Ontario\) ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend100\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend15\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend30\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend300\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend50\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\test\* ? SUCCESS - 0 opening remote file \Project\AgCan\0_Ontario\Testdata.mxd ... ... ... ? SUCCESS - 0 listing \Proposal\* ? SUCCESS - 0 listing \restore\* ? SUCCESS - 0 opening remote file \ROND.DBF (\) ? SUCCESS - 0 listing \scan2cad\* ? SUCCESS - 0 listing \Scan2Vec\* ? SUCCESS - 0 listing \Seagate Software\* ? SUCCESS - 0 opening remote file \SQL.LOG (\) ? SUCCESS - 0 listing \System\* ? SUCCESS - 0 listing \TCWIN\* ? SUCCESS - 0 listing \wag\* ? SUCCESS - 0 listing \wagner_unix\* ? SUCCESS - 0 listing \WINNT\* ? SUCCESS - 0 listing \WorkSpace\* ? SUCCESS - 0 listing \yukon scans\* | tar: dumped 29441 files and directories | Total bytes written: 21413944832 sendbackup: size 20912056 sendbackup: end \ DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- -- vxa2 -nt-01/nt01-d 0 20912056 14609312 69.9 126:22 1926.7 39:11 6214.0 Window NT drive stats. Total Files Listed: 184354 File(s) 88,102,672,147 bytes 29,309,644,800 bytes free Vytas Janusauskas Dendron Resource Surveys Inc. 880 Lady Ellen Place, Suite 206 Ottawa, Ontario, Canada K1Z 5L9 Voice: (613) 725-2971 Fax: (613) 725-1716 mailto:[EMAIL PROTECTED]
Re: Missing files from Samba backup
First let me say that you have an old version of Amanda. But I don't know where your problem come from. I only thing I can say is that, in my case (amanda 2.4.3), I also have problems with Cygwin and index generation. Amanda does not tell me that there was a problem during the backup; but when I try to amrecover my cygwin files, the program sometimes tells me no index records for host and when I go and see the file, it tells me the gzip file for record is incorrect: --- cut here --- [EMAIL PROTECTED]:~$ amgetconf test indexdir /BACKUP/amanda/var/test/index [EMAIL PROTECTED]:~$ gzip -t /BACKUP/amanda/var/test/index/mdb0/_cygdrive_g_BACKUP__MDB1_Night__dump/20030606_0.gz gzip: /BACKUP/amanda/var/test/index/mdb0/_cygdrive_g_BACKUP__MDB1_Night__dump/20030606_0.gz: unexpected end of file --- cut here --- So, in my case, I am not able to amrecover the files, but they surely went to tape and I can amrestore them without problem... Try see if you don't have a similar problem to mine. On Thu, 05 Jun 2003 13:11:16 -0400 Vytas Janusauskas [EMAIL PROTECTED] wrote: Hi Amanda Users! This morning I noticed that a DLE which has been forced (Level 0) on a NT 4.0 Service Pack 6 computer via Samba did not completely backup all files. It seem that for any file/directory listed in Amanda's report (See below) which start with a ? SUCCESS - 0 statement were not archived or added to the index files. The reason I found that there was a serious problem is that a full should contain about 88 gigs of data while only about 20 gigs were taped. This caused me to look back through the full backup logs for other computers and found similar problems. At first I thought it was due to the NT box drive being a RAID configuration be alas the problem also occurs on Win 85 and Win 98 computers. A search of the archive did not point to any solutions. Anyone have an idea of what is going wrong? Amanda version 2.4.2p2 tar (GNU tar) 1.13.25 Thanks, Vytas These dumps were to tape Daily14. The next tape Amanda expects to use is: Daily15. FAILURE AND STRANGE DUMP SUMMARY vxa2 //nt-01/nt01-d lev 0 STRANGE /-- vxa2 //nt-01/nt01-d lev 0 STRANGE sendbackup: start [vxa2://nt-01/nt01-d level 0] sendbackup: info BACKUP=/usr/bin/smbclient sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... - sendbackup: info end ? NT_STATUS_SHARING_VIOLATION opening remote file \pagefile.sys (\) ? SUCCESS - 0 opening remote file \Project\AgCan\0_Ontario\ALCDB_Vytas.zip (\Project\AgCan\0_Ontario\) ? SUCCESS - 0 opening remote file \Project\AgCan\0_Ontario\Arc_Info_Generalize.bmp (\Project\AgCan\0_Ontario\) ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend100\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend15\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend30\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend300\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\bend50\* ? SUCCESS - 0 listing \Project\AgCan\0_Ontario\test\* ? SUCCESS - 0 opening remote file \Project\AgCan\0_Ontario\Testdata.mxd ... ... ... ? SUCCESS - 0 listing \Proposal\* ? SUCCESS - 0 listing \restore\* ? SUCCESS - 0 opening remote file \ROND.DBF (\) ? SUCCESS - 0 listing \scan2cad\* ? SUCCESS - 0 listing \Scan2Vec\* ? SUCCESS - 0 listing \Seagate Software\* ? SUCCESS - 0 opening remote file \SQL.LOG (\) ? SUCCESS - 0 listing \System\* ? SUCCESS - 0 listing \TCWIN\* ? SUCCESS - 0 listing \wag\* ? SUCCESS - 0 listing \wagner_unix\* ? SUCCESS - 0 listing \WINNT\* ? SUCCESS - 0 listing \WorkSpace\* ? SUCCESS - 0 listing \yukon scans\* | tar: dumped 29441 files and directories | Total bytes written: 21413944832 sendbackup: size 20912056 sendbackup: end \ DUMP SUMMARY: DUMPER STATS TAPER STATS HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s -- -- vxa2 -nt-01/nt01-d 0 20912056 14609312 69.9 126:22 1926.7 39:11 6214.0 Window NT drive stats. Total Files Listed: 184354 File(s) 88,102,672,147 bytes 29,309,644,800 bytes free Vytas Janusauskas Dendron Resource Surveys Inc. 880 Lady Ellen Place, Suite 206 Ottawa, Ontario, Canada K1Z 5L9 Voice: (613) 725-2971 Fax: (613) 725-1716 mailto:[EMAIL PROTECTED] --- Jean-Christian SIMONETTIemail: [EMAIL PROTECTED] SysAdmin Wanadoo Portails phone: (+33)493004911 Sophia Antipolis, France ---
tar (GNU tar) 1.13.25 missing files in index
Hello, using tar (GNU tar) 1.13.25, I am missing files from the index that amrecover generates. From a folder with about 30 thousand files in it, amrecover lists about 10 files. This may or may not be related to the faq-o-matic http://amanda.sourceforge.net/fom-serve/cache/310.html, because my index file looks corrupted: 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_ISO.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_ISOW.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_OOEX.gif 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_OOEX2.gif 07544045020/./abaverh/public_html/WDBRY/wdbry_img_News_CA.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_News_FAQ.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_News_OP.jpg But please note that all hosts are using tar 1.13.25, which is later than the suspected 1.13.19 bug. The corrupted indexing is only happening on *one* of my client machines, running gnu tar 1.13.25. -- Jason Greenberg, CCNP Network Administrator Execulink, Inc. [EMAIL PROTECTED]
Re: tar (GNU tar) 1.13.25 missing files in index
On Friday 27 September 2002 08:42, Jason Greenberg wrote: Hello, using tar (GNU tar) 1.13.25, I am missing files from the index that amrecover generates. From a folder with about 30 thousand files in it, amrecover lists about 10 files. This may or may not be related to the faq-o-matic http://amanda.sourceforge.net/fom-serve/cache/310.html, because my index file looks corrupted: 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_ISO.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_ISOW.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_OOEX.gif 07544045020/./abaverh/public_html/WDBRY/wdbry_img_Logo_OOEX2.gif 07544045020/./abaverh/public_html/WDBRY/wdbry_img_News_CA.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_News_FAQ.jpg 07544045020/./abaverh/public_html/WDBRY/wdbry_img_News_OP.jpg But please note that all hosts are using tar 1.13.25, which is later than the suspected 1.13.19 bug. The corrupted indexing is only happening on *one* of my client machines, running gnu tar 1.13.25. I think I'd do a locate on both tar, and gnutar on the machine, and make sure that ALL of them are either 1.13-25, or are links to it. There may e an old one laying around thats being found first in the $PATH. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.16% setiathome rank, not too shabby for a WV hillbilly
Checking for missing files.
Hello all. Is there a way of checking what is on the tape against what is on the disk, to show missing or renamed files on a large scale? Thanks, Trevor. = Stussy said:Knowledge is King! =
Re: Checking for missing files.
On Tue, Aug 27, 2002 at 02:55:02PM +0200, Trevor Fraser wrote: Hello all. Is there a way of checking what is on the tape against what is on the disk, to show missing or renamed files on a large scale? Not clear on the objective. Do you mean determine that tape-x has the dumps of /a and /b and /c done on date y, i.e. a toc of the tape files? Or do you mean the dump of /a on tape-x contains the files /a/foo/, /a/bar, /a/foo/xyz, i.e. a toc of the individual dumps? And do you further mean what is actually on the tape, or what amanda believes she put there. I think there are positive, though different replies to each. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Checking for missing files.
Hi Jon. Thanks for the reply. My objective is when someone accidentally deletes files and doesn't know what file they were, to compare what Amanda has on tape and what is on the file system to see what is different, so I don't have to manually search the tape and the file system to see what is missing and what to restore. Thanks, Trevor. = Stussy said:Knowledge is King! = - Original Message - From: Jon LaBadie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 27, 2002 3:58 PM Subject: Re: Checking for missing files. On Tue, Aug 27, 2002 at 02:55:02PM +0200, Trevor Fraser wrote: Hello all. Is there a way of checking what is on the tape against what is on the disk, to show missing or renamed files on a large scale? Not clear on the objective. Do you mean determine that tape-x has the dumps of /a and /b and /c done on date y, i.e. a toc of the tape files? Or do you mean the dump of /a on tape-x contains the files /a/foo/, /a/bar, /a/foo/xyz, i.e. a toc of the individual dumps? And do you further mean what is actually on the tape, or what amanda believes she put there. I think there are positive, though different replies to each. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Checking for missing files.
On Tue, Aug 27, 2002 at 05:30:58PM +0200, Trevor Fraser wrote: Hi Jon. Thanks for the reply. My objective is when someone accidentally deletes files and doesn't know what file they were, to compare what Amanda has on tape and what is on the file system to see what is different, so I don't have to manually search the tape and the file system to see what is missing and what to restore. Thanks, Trevor. Ahh, then probably the regular indexes will be sufficient. I presume you are recording, then you have an indexdir defined. In that indexdir will be subdirs for each host. Under the host dir will be subdirs with names based on the disklist entries. In these names the / are replaced with _. My approach would be to make a list of everything the user currently has and compare it to what the index shows is on tape. Assume the user is shmo As root: cd ~shmo/.. # one level above shmo find shmo /tmp/shmo-current # or two levels and do a find home/shmo sort -o /tmp/shmo-current /tmp/shmo-current cd amanda-index-dir-for-shmo's-filesystem # note all the backups since the last level 0. # in my case that would be 20020823_0.gz # 20020824_1.gz 20020826_1.gz 20020827_2.gz for f in 20020823_0.gz 20020824_1.gz 20020826_1.gz 20020827_2.gz do gzip -dc $f | grep /shmo/ | sed 's,/$,,' done | sort | uniq /tmp/shmo-tape # or the command might look for /home/shmo if appropriate # the sed is to remove any trailing /s on dir names that my indexes # have, but the find does not. # now you may have to edit one or the other file to make the leading # part of each line the same For example, the find may not have a / # at the start or might need /home/ added to one file or deleted # from the other. Now you have two sorted lists, what is in shmo's directory tree currently and what is on tape in at least one of the most recent backup set. Of course the for f in ... loop could have been done on all index files to go further back. To compare them use the comm command: # files on tape but not in current dir tree comm -13 /tmp/shmo-current /tmp/shmo-tape # files in current dir tree, not on tape comm -23 /tmp/shmo-current /tmp/shmo-tape # files in both comm -12 /tmp/shmo-current /tmp/shmo-tape Another approach is to amrecover the entire /home/shmo tree in some tmp dir. Then do a dircmp of shmos' current tree with the tmp tree. Then you already have the files on disk and can simply copy them. Hope these make sense and help. Maybe someone else has alternative approaches. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Checking for missing files.
Thanks again Jon. To be honest, I'm going to leave the attempting 'till tomorrow, its late this side of the earth. I do see the solutions, will try them and see what works best for me. The main thing is I now know the approach isn't some thing I've been tripping over all the time, like so many other battles...no re-inventing the wheel either...whew! Chow, Trevor. = Stussy said:Knowledge is King! = - Original Message - From: Jon LaBadie [EMAIL PROTECTED] To: Trevor Fraser [EMAIL PROTECTED] Cc: Jon LaBadie [EMAIL PROTECTED] Sent: Tuesday, August 27, 2002 6:25 PM Subject: Re: Checking for missing files. On Tue, Aug 27, 2002 at 05:30:58PM +0200, Trevor Fraser wrote: Hi Jon. Thanks for the reply. My objective is when someone accidentally deletes files and doesn't know what file they were, to compare what Amanda has on tape and what is on the file system to see what is different, so I don't have to manually search the tape and the file system to see what is missing and what to restore. Thanks, Trevor. Ahh, then probably the regular indexes will be sufficient. I presume you are recording, then you have an indexdir defined. In that indexdir will be subdirs for each host. Under the host dir will be subdirs with names based on the disklist entries. In these names the / are replaced with _. My approach would be to make a list of everything the user currently has and compare it to what the index shows is on tape. Assume the user is shmo As root: cd ~shmo/.. # one level above shmo find shmo /tmp/shmo-current # or two levels and do a find home/shmo sort -o /tmp/shmo-current /tmp/shmo-current cd amanda-index-dir-for-shmo's-filesystem # note all the backups since the last level 0. # in my case that would be 20020823_0.gz # 20020824_1.gz 20020826_1.gz 20020827_2.gz for f in 20020823_0.gz 20020824_1.gz 20020826_1.gz 20020827_2.gz do gzip -dc $f | grep /shmo/ | sed 's,/$,,' done | sort | uniq /tmp/shmo-tape # or the command might look for /home/shmo if appropriate # the sed is to remove any trailing /s on dir names that my indexes # have, but the find does not. # now you may have to edit one or the other file to make the leading # part of each line the same For example, the find may not have a / # at the start or might need /home/ added to one file or deleted # from the other. Now you have two sorted lists, what is in shmo's directory tree currently and what is on tape in at least one of the most recent backup set. Of course the for f in ... loop could have been done on all index files to go further back. To compare them use the comm command: # files on tape but not in current dir tree comm -13 /tmp/shmo-current /tmp/shmo-tape # files in current dir tree, not on tape comm -23 /tmp/shmo-current /tmp/shmo-tape # files in both comm -12 /tmp/shmo-current /tmp/shmo-tape Another approach is to amrecover the entire /home/shmo tree in some tmp dir. Then do a dircmp of shmos' current tree with the tmp tree. Then you already have the files on disk and can simply copy them. Hope these make sense and help. Maybe someone else has alternative approaches. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
cruft missing files
Hi, last week one of the holding disks of our backup server (running amanda) crashed; unfortunately containing some dumps of file systems. after replacement of the disk (and using some other disks as holding disks) and some more backups made to disk (in degraded mode), an amflush now always reports: NOTES: amflush: /bak/amanda/coco/20020812: could not open working dir: No such file or directory amflush: fav._usr_openwin.1: disk fav:/usr/openwin not in database, skipping it. amflush: fav._.1: disk fav:/ not in database, skipping it. amflush: fav.c1t5d0s5.1: disk fav:c1t5d0s5 not in database, skipping it. amflush: fav._usr.1: disk fav:/usr not in database, skipping it. amflush: fav._var.1: disk fav:/var not in database, skipping it. amflush: fav._opt.1: disk fav:/opt not in database, skipping it. amflush: fav.c1t5d0s6.1: disk fav:c1t5d0s6 not in database, skipping it. amflush: Could not rmdir /big2/amanda/coco/20020812. Check for cruft. amflush: /big1/amanda/coco/20020812: could not open working dir: No such file or directory amflush: /bak/amanda/coco/20020816: could not open working dir: No such file or directory amflush: /big1/amanda/coco/20020816: could not open working dir: No such file or directory amflush: /bak/amanda/coco/20020819: could not open working dir: No such file or directory amflush: sheena.sdb2.0.1: ignoring cruft file. amflush: /big1/amanda/coco/20020819: could not open working dir: No such file or directory amflush: /bak/amanda/coco/20020820: could not open working dir: No such file or directory amflush: sheena.sdc1.0.1: ignoring cruft file. amflush: sheena.sdc1.0.2: ignoring cruft file. amflush: sheena.sdc1.0.3: ignoring cruft file. amflush: info.hdc2.0.1: ignoring cruft file. amflush: info.hdc2.0.2: ignoring cruft file. [...] directories above reported as missing really don't exist. does anybody know how to get rid of these messages ? I already tried to run amcheckdb, but it just reports Ready. tnx in advance.
Missing files
I'm running: build: VERSION=Amanda-2.4.2p2 BUILT_DATE=Tue Feb 12 11:03:03 EST 2002 BUILT_MACH=SunOS foo.bar.com 5.6 Generic_105181-17 sun4u sparc SUNW,U\ ltra-250 CC=gcc paths: bindir=/usr/local/bin sbindir=/usr/local/sbin libexecdir=/usr/local/libexec mandir=/usr/local/man AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda CONFIG_DIR=/usr/local/etc/amanda DEV_PREFIX=/dev/dsk/ RDEV_PREFIX=/dev/rdsk/ DUMP=/usr/sbin/ufsdump RESTORE=/usr/sbin/ufsrestore GNUTAR=/usr/local/alpha-tar/bin/tar COMPRESS_PATH=/usr/local/bin/gzip UNCOMPRESS_PATH=/usr/local/bin/gzip MAILER=/usr/ucb/Mail listed_incr_dir=/usr/local/var/amanda/gnutar-lists defs: DEFAULT_SERVER=foo.bar.com DEFAULT_CONFIG=Foo DEFAULT_TAPE_SERVER=foo.bar.com DEFAULT_TAPE_DEVICE=/dev/rmt/0bn HAVE_MMAP HAVE_SYSVSHM LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS CLIENT_LOGIN=backup FORCE_USERID HAVE_GZIP COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc Alpha-tar is usr/local/alpha-tar/bin/tar --version tar (GNU tar) 1.13.25 Here is my problem. I am trying to back up several directory, the directory structure is tarred but several subdirectories are empty or missing files. For example I am trying to backup the following directory: (from disklist) db1 /oracle/oracle1/app/oracle/adminuser-tar doing a df in that directory on the remote box, I get this: df /oracle/oracle1/app/oracle/admin/vault /oracle/oracle1(/dev/vx/dsk/oracle-1): 348244 blocks 514315 files These are the contents of the directory. bash-2.05a# ls -l total 10 drwxr-xr-x 2 oracle dba 512 Apr 30 2001 bdump drwxr-xr-x 2 oracle dba 512 Aug 8 2000 cdump drwxr-xr-x 2 oracle dba 512 Aug 8 2000 create drwxr-xr-x 2 oracle dba 512 Aug 8 2000 pfile drwxr-xr-x 2 oracle dba 1024 Jun 13 10:55 udump Amrecover from the remote machine is able to get this far, but when I ls using amrecover into say the directory bdump I get this: amrecover ls 2002-07-16 . 2002-07-16 alert_vault.log but when I do an ls on the actual directory I get this: bash-2.05a# cd bdump/ bash-2.05a# ls -l total 115728 -rw-r--r-- 1 oracle dba 58869186 Jul 16 12:11 alert_vault.log -rw-r- 1 oracle dba 319959 Apr 30 2001 vault_ora_16897.trc It never backs up the vault_ora_16897.trc file. I've added the backup user to the root, bin, and dba groups thinking it was a permission thing. I don't see any errors in the amanda debug files. I'm wondering why Amanda is just randomly missing files. Anyone else have this same problem? Any work arounds. Jose L. Rivas
Re: amrecover missing files
On Fri, Jun 07, 2002 at 01:52:39PM -0500, Ben Kochie wrote: I am using indexing, and gnutar to backup all of my filesystems, I keep the indexes in /etc/amanda/backupset/index/ according to my amanda.conf file. backups are working properly, no errors reported. I can run amrestore on a tape and see all of the files that are supposed to be backed up.. I can also gunzip the files in the index, and see them listed.. but when I run amrecover, set the host/disk, and do an ls, i only see a few of the directories/files that are supposed to be backed up. it seems like something in amindexd is not working properly, and I have no idea what. has any other amanda users run into this problem? One of my systems has similar problems. But because this system is a Windows 2000 system and I'm backing it up from an amanda client under Cygwin, I thought it might have been the unusual setup I'm using. However I'm coming to believe others are having similar problems so that it may not be my unique setup. A sample of my results. When I look at the D: partition, there are 2100 directories and files there. When I look at the amanda tape of a level 0 of that partition, it seems all the files are there. And the size of the dump is reasonable. But the index is certainly not. The index has 220 entries, 190 of them directories. Very few, if any, of those are more than 3 levels down. The 30 or so files are all in the top 2 directories. I originally did the cygwin client using gnutar 1.13.19. Now I'm using 1.13.25 and seeing the same results. Suggestions? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrecover missing files
interesting.. i havn't tried changing the gnutar used by my amanda.. now that I think about it.. I remember having to make changes on some old amanda setups.. I am about ready to try changing my compiler config.. I work on a very odd distribution (home grown) that has a slightly whack compiler setup.. and I'm going to try doing a build against our default libc5 compiler (don't ask.. it's not my fault, i'd be in debian bliss if I could) did you look at the index files manualy? what do they show.. that's thing that made me wonder.. the index files on disk are perfectly fine.. they show all the properly backed up data. but amindexd doesn't return all the listings. -ben On Fri, 7 Jun 2002, Jon LaBadie wrote: On Fri, Jun 07, 2002 at 01:52:39PM -0500, Ben Kochie wrote: I am using indexing, and gnutar to backup all of my filesystems, I keep the indexes in /etc/amanda/backupset/index/ according to my amanda.conf file. backups are working properly, no errors reported. I can run amrestore on a tape and see all of the files that are supposed to be backed up.. I can also gunzip the files in the index, and see them listed.. but when I run amrecover, set the host/disk, and do an ls, i only see a few of the directories/files that are supposed to be backed up. it seems like something in amindexd is not working properly, and I have no idea what. has any other amanda users run into this problem? One of my systems has similar problems. But because this system is a Windows 2000 system and I'm backing it up from an amanda client under Cygwin, I thought it might have been the unusual setup I'm using. However I'm coming to believe others are having similar problems so that it may not be my unique setup. A sample of my results. When I look at the D: partition, there are 2100 directories and files there. When I look at the amanda tape of a level 0 of that partition, it seems all the files are there. And the size of the dump is reasonable. But the index is certainly not. The index has 220 entries, 190 of them directories. Very few, if any, of those are more than 3 levels down. The 30 or so files are all in the top 2 directories. I originally did the cygwin client using gnutar 1.13.19. Now I'm using 1.13.25 and seeing the same results. Suggestions? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrecover: missing files and indexes
... I have examined the index files and they look okay. Does each line start with a big number, or do they look like this: / /lost+found/ /.dt/ /.dt/sessions/ /.dt/sessions/home/ /.dt/sessions/home/dt.session /.dt/sessions/home/dtqWaG0a /.dt/sessions/home/dt.settings ... If they start with a big number, that's a symptom of a bad version of GNU tar. You should be running either 1.12 plus the patches from the Amanda web page, or 1.13.19 from alpha.gnu.org. What does gtar --version say? Note that if you use gcc to build GNU tar, some versions are known to mis-compile it (sigh). It's probably best to use the latest (2.95.3). Chris O'Regan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amrecover: missing files and indexes
They start with a big number... *sigh* I have installed GNU tar version 1.13 built with Sun's Forte C compiler. I will try one of the version that you have suggested. Many thanks for the quick response! Chris O'Regan John R. Jackson [EMAIL PROTECTED]To: [EMAIL PROTECTED] urdue.edu cc: [EMAIL PROTECTED] Subject: Re: amrecover: missing files and indexes 07/07/2001 01:47 PM Please respond to jrj ... I have examined the index files and they look okay. Does each line start with a big number, or do they look like this: / /lost+found/ /.dt/ /.dt/sessions/ /.dt/sessions/home/ /.dt/sessions/home/dt.session /.dt/sessions/home/dtqWaG0a /.dt/sessions/home/dt.settings ... If they start with a big number, that's a symptom of a bad version of GNU tar. You should be running either 1.12 plus the patches from the Amanda web page, or 1.13.19 from alpha.gnu.org. What does gtar --version say? Note that if you use gcc to build GNU tar, some versions are known to mis-compile it (sigh). It's probably best to use the latest (2.95.3). Chris O'Regan John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
dump 0.4b16-1 on a debian potato system. Go get a newer version of Linux dump (0.4b22, http://dump.sourceforge.net/) as many bugfixes have been applied.
Re: missing files
On Mon, May 14, 2001 at 08:57:02AM +0200, Bernhard R. Erdmann wrote: dump 0.4b16-1 on a debian potato system. Go get a newer version of Linux dump (0.4b22, http://dump.sourceforge.net/) as many bugfixes have been applied. Probably the best way to do this is to temporarily change the potato to woody in your /etc/apt/sources file, apt-get update, install dump, then change it back. The new version of apt can keep track of things like this without having to shuffle config lines, but you wouldn't have the new version with potato :) Woody has 0.4b21-4 (likely with some of the later fixes backported). -- --Ray - Sotto la panca la capra crepa sopra la panca la capra campa
Re: missing files
amrestore said something about the files not found on tape. ... Huh? I doubt amrestore said anything like that. Maybe your recover program did? What, exactly, did you see? What was used to back things up, GNU tar or a system dump program? What version of GNU tar (if you used that)? What OS? Jason Thomas John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
On Sun, May 13, 2001 at 09:36:43PM -0500, John R. Jackson wrote: amrestore said something about the files not found on tape. ... Huh? I doubt amrestore said anything like that. Maybe your recover program did? What, exactly, did you see? ./CVSROOT/people/matthew/sysadmin/backup/backup-tsa,v: not found on tape ./CVSROOT/s97-nma/lib/.cvsignore,v: not found on tape ./CVSROOT/s97-nma/lib/cgi-lib.pl,v: not found on tape ./CVSROOT/s97-nma/lib/globals.pl,v: not found on tape ./CVSROOT/s97-nma/lib/http.pl,v: not found on tape ./CVSROOT/s97-nma/lib/spiderUrls,v: not found on tape ./CVSROOT/s97-nma/lib/util.pl,v: not found on tape What was used to back things up, GNU tar or a system dump program? What version of GNU tar (if you used that)? What OS? dump 0.4b16-1 on a debian potato system. Jason Thomas John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] -- Jason Thomas Phone: +61 2 6257 7111 System Administrator - UID 0 Fax:+61 2 6257 7311 tSA Consulting Group Pty. Ltd. Mobile: 0418 29 66 81 1 Hall Street Lyneham ACT 2602 http://www.topic.com.au/ PGP signature
Re: missing files
John R. Jackson wrote: What shows an error occurred? ... By error I meant you didn't see all the entries in amrecover that you expected to see. There isn't anything in the sendbackup*debug file to indicate what went wrong (or even that anything did go wrong). The more useful place to look is the index file (see below). Thanks for this complete response but you really should have said so in the first place, esp'ly before firing off a bunch of (testy) questions. Anyway, the answer to your quandary is that I didn't install indexing. The INSTALL instructions say If you are going to use the indexing capabilities of Amanda, then add these to your inetd.conf ... amandaidx stream amidxtape stream ... amidxtaped (Section 2.1.E.) which indicates its installation and use is optional. Unlike designers of a certain piece of software, i believe in the the KISS principle and was trying to get a little backup working before making an even more complicated mess. I'm pretty sure i won't be using Amanda now, so yes, i am just testing at this point, but after what is by all appearances a wasted 2 weeks, i thought it'd be reasonable to pursue finding out why Amanda/tar skipped 6 of 10 items (counting empty directories) in a small, single directory backup. For what its worth, my suspicion is still that Amanda has a problem correctly creating and saving the tar --listed-incremental file in some situations, eg w/.files when indexing is off. I'm not prepared to postulate an infinite worlds hypothesis and test for all possibilites (or study source code) though, so i'm hoping someone has a better clue. george I am not cleaning out everything between tests. I don't know how to do that or what that means. Since you're having amrecover/index problems, the important thing to remove is all the index files related to the test. Run amgetconf config indexdir to see where the top of the index directory is, then cd to the host directory within there and then cd to the disk directory within that. Remove all the *.gz files. Then when you run another test you can be sure amrecover (amindexd) isn't see old data by mistake. You can zcat the most recent file Amanda creates to see what amrecover will have to work with. If you see all the files you expect to, but amrecover doesn't show them, then that's one kind of problem (with the index file itself or amrecover). If you don't see the files you expect, then that's a problem with the backup itself.
Re: missing files
What shows an error occurred? ... By error I meant you didn't see all the entries in amrecover that you expected to see. There isn't anything in the sendbackup*debug file to indicate what went wrong (or even that anything did go wrong). The more useful place to look is the index file (see below). I am not cleaning out everything between tests. I don't know how to do that or what that means. Since you're having amrecover/index problems, the important thing to remove is all the index files related to the test. Run amgetconf config indexdir to see where the top of the index directory is, then cd to the host directory within there and then cd to the disk directory within that. Remove all the *.gz files. Then when you run another test you can be sure amrecover (amindexd) isn't see old data by mistake. You can zcat the most recent file Amanda creates to see what amrecover will have to work with. If you see all the files you expect to, but amrecover doesn't show them, then that's one kind of problem (with the index file itself or amrecover). If you don't see the files you expect, then that's a problem with the backup itself. george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
John R. Jackson wrote: I got all nine items of my /home/amanda directory archived, unlike when amdump ran it with option --listed-incremental /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0.new. What does this mean? I don't know what it means yet, except that tar is probably OK, it's just something about the way Amanda is calling it. What does amcheck have to say about your system? Amcheck has no complaints, including with the write test, though it was skipped below. (How do i put a tape back to inactive status? I tried re-labeling, but couldn't: tape is active.) # /usr/local/sbin/amcheck Dell-Full Amanda Tape Server Host Check - Holding disk /dumps/amanda: 2205816 KB disk space available, that's plenty ERROR: cannot overwrite active tape Dell-Full010503 (expecting a new tape) NOTE: skipping tape-writable test Server check took 12.971 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 2.345 seconds, 0 problems found (brought to you by Amanda 2.4.2p2) Does your Amanda user have sufficient permissions to create files in /usr/local/var/amanda/gnutar-lists? That dir is amanda owned and operated. What are the complete contents a typical /tmp/amanda/sendbackup*debug file for one of the failed runs? Don't have any from a failed run. Below is my only sendbackup*debug file, which is from the successful run. # cat /tmp/amanda/sendbackup*debug sendbackup: debug 1 pid 17143 ruid 507 euid 507 start time Fri May 4 20:45:05 2001 /usr/local/libexec/sendbackup: version 2.4.2p2 sendbackup: got input request: GNUTAR /home/amanda 0 1970:1:1:0:0:0 OPTIONS |;bsd-auth; parsed request as: program `GNUTAR' disk `/home/amanda' lev 0 since 1970:1:1:0:0:0 opt `|;bsd-auth;' sendbackup: try_socksize: send buffer size is 65536 sendbackup: stream_server: waiting for connection: 0.0.0.0.2865 sendbackup: stream_server: waiting for connection: 0.0.0.0.2866 waiting for connect on 2865, then 2866 sendbackup: stream_accept: connection from 192.168.1.100.2867 sendbackup: stream_accept: connection from 192.168.1.100.2868 got all connections sendbackup-gnutar: doing level 0 dump as listed-incremental to /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0.new sendbackup-gnutar: doing level 0 dump from date: 1970-01-01 0:00:00 GMT sendbackup: spawning /usr/local/libexec/runtar in pipeline sendbackup: argument list: gtar --create --file - --directory /home/amanda --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0.new --sparse --ignore-failed-read --totals . sendbackup-gnutar: /usr/local/libexec/runtar: pid 17144 sendbackup: pid 17143 finish time Fri May 4 20:45:05 2001 thx, george
Re: missing files
John R. Jackson wrote: ... (How do i put a tape back to inactive status? I tried re-labeling, but couldn't: tape is active.) Either use -f on amlabel, or use amrmtape. Worked, thx. Don't have any from a failed run. Below is my only sendbackup*debug file, which is from the successful run. Now I'm completely confused. This looks just like a failed run. I didn't think this ever worked for you. Are you saying sometimes it does and sometimes it doesn't? Are you just doing this for testing? Are you cleaning everything out between tests? Maybe one of them did fail but you're seeing old information even when it now works? What shows an error occurred? That sendbackup*debug doesn't mention an error or warning, the email afterwards looks friendly, and a backup did occur (just not a complete one), so i called it a successful run. If you see the format of the sendbackup*debug file as indicating an error, though, you of course know better. I haven't done anymore Amanda tests since that pseudo-successful run last Friday. Since then i've been trying, with your help, to figure out why it was not complete. I am not cleaning out everything between tests. I don't know how to do that or what that means. I know that that sendbackup*debug is my only one and is from the successful run, because of its file date. I was trying to get Amanda working before moving on but i don't need to. Let's drop it. thx anyway. george
Re: missing files
John R. Jackson wrote: In a test, i removed the --listed-incremental /usr/amanda_0.new option, and tar archived all my files, just how i like it. Why does Amanda put that option there? ... Ummm, because that's required to do incremental backups. :-) And is it feasible/desirable to make it go away for at least level 0 backups? Only if you don't want to do incrementals (in other words, no). For full dumps, as I recall, Amanda creates an empty file and gives that to gtar with --listed-incremental. You might try something like this: cp /dev/null /tmp/my-li-file gtar ... --listed-incremental /tmp/my-li-file ... and see what you get. I got all nine items of my /home/amanda directory archived, unlike when amdump ran it with option --listed-incremental /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0.new. What does this mean? Another question: Why doesn't that /usr/...amanda_0.new file exist? I have only a /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0 file, with contents 989184075 773 374412 ./.xauth). It probably did exist at the time Amanda ran. The .new in the name is a clue that Amanda is using that name and if everything goes right, it is renamed to the real name (without the .new). Good to know, thx. Based on what you've posted above, you were trying to back up something called /home/amanda, right? Is that an actual home directory? It looks like it is based on the listed incremental file which only lists one item, .xauth, and that's the kind of thing I'd expect to see inside a home directory. Yes, /home/amanda, whose contents are these files: drwx--3 amanda amanda 4096 May 4 13:13 . drwxr-xr-x 11 root root 4096 Apr 27 13:45 .. -rw-rw-r--1 amanda amanda 46 May 4 13:09 .amandahosts -rw-rw-r--1 amanda amanda 21 Apr 30 16:07 .amandahosts~ -rw---1 amanda amanda 6984 May 7 15:09 .bash_history -rw-r--r--1 amanda amanda 24 Apr 27 13:45 .bash_logout -rw-r--r--1 amanda amanda230 Apr 27 13:45 .bash_profile -rw-r--r--1 amanda amanda124 Apr 27 13:45 .bashrc -rwxr-xr-x1 amanda amanda333 Apr 27 13:45 .emacs -rw-r--r--1 amanda amanda 3394 Apr 27 13:45 .screenrc drwx--2 amanda root 4096 Apr 30 14:20 .xauth I still don't understand why files would be left out in my first successful amdump, a backup reported as level 0 by the email amdump sent afterwards. Level 0 is always supposed to mean all files, correct? The problem ppears to have something to do with the --listed-incremental /usr/amanda_0.new option, because all files are backed up when it is removed from the command. As i posted Friday, what appeared on the tape after the amdump was only four items: # tar tvv -rw-r--r-- amanda/amanda 230 2001-04-27 13:45 ./.bash_profile -rw-r--r-- amanda/amanda 124 2001-04-27 13:45 ./.bashrc -rwxr-xr-x amanda/amanda 333 2001-04-27 13:45 ./.emacs -rw-r--r-- amanda/amanda 3394 2001-04-27 13:45 ./.screenrc thanks alot, george
Re: missing files
I got all nine items of my /home/amanda directory archived, unlike when amdump ran it with option --listed-incremental /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0.new. What does this mean? I don't know what it means yet, except that tar is probably OK, it's just something about the way Amanda is calling it. What does amcheck have to say about your system? Does your Amanda user have sufficient permissions to create files in /usr/local/var/amanda/gnutar-lists? What are the complete contents a typical /tmp/amanda/sendbackup*debug file for one of the failed runs? george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
John R. Jackson wrote: Is the actual (eg, tar) command used by amdump recorded? Where? /tmp/amanda/sendsize*debug and /tmp/amanda/sendbackup*debug on the client. george Thanks. I didn't know that because the sendsize*debug files i looked inside didn't have the tar options because amdump wasn't getting that far. So here's the tar command amanda used: sendsize: argument list: /bin/gtar --create --file /dev/null --directory /home/amanda --one-file-system --listed-incremental /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0.new --sparse --ignore-failed-read --totals . In a test, i removed the --listed-incremental /usr/amanda_0.new option, and tar archived all my files, just how i like it. Why does Amanda put that option there? And is it feasible/desirable to make it go away for at least level 0 backups? Another question: Why doesn't that /usr/...amanda_0.new file exist? I have only a /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0 file, with contents 989184075 773 374412 ./.xauth). thank u, george
Re: missing files
In a test, i removed the --listed-incremental /usr/amanda_0.new option, and tar archived all my files, just how i like it. Why does Amanda put that option there? ... Ummm, because that's required to do incremental backups. :-) And is it feasible/desirable to make it go away for at least level 0 backups? Only if you don't want to do incrementals (in other words, no). For full dumps, as I recall, Amanda creates an empty file and gives that to gtar with --listed-incremental. You might try something like this: cp /dev/null /tmp/my-li-file gtar ... --listed-incremental /tmp/my-li-file ... and see what you get. Another question: Why doesn't that /usr/...amanda_0.new file exist? I have only a /usr/local/var/amanda/gnutar-lists/dellmachine_home_amanda_0 file, with contents 989184075 773 374412 ./.xauth). It probably did exist at the time Amanda ran. The .new in the name is a clue that Amanda is using that name and if everything goes right, it is renamed to the real name (without the .new). Based on what you've posted above, you were trying to back up something called /home/amanda, right? Is that an actual home directory? It looks like it is based on the listed incremental file which only lists one item, .xauth, and that's the kind of thing I'd expect to see inside a home directory. george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
John R. Jackson wrote: But i have a question as to why, according to a tar on the tape afterwards, only four out of the nine items in the directory to dump were actually backed up. ... What version of GNU tar are you using? If it's not at least 1.13.17 (and probably 1.13.19 would be better), you should upgrade. But I just archived that dir to disk using tar and it got all the files fine. I downgraded my (gnu) tar to v1.12 last week because http://www.amanda.org/patches.html says there are a couple of other problems in release 1.13 ... so its use is not recommended. Did Amanda do a full dump (level 0) or an incremental (level 0)? According to the email summary, L is 0. george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Also, is it safe to directly tar to an amanda-written tape w/o amanda or might that mess up later attempts to amrestore from that tape? thx, george
Re: missing files
But I just archived that dir to disk using tar and it got all the files fine. And did you do it the same way Amanda does, i.e. with all the listed incremental type flags it hands to GNU tar? That's where a lot of the problems are, not in just basic tar operations. I downgraded my (gnu) tar to v1.12 last week because http://www.amanda.org/patches.html says there are a couple of other problems in release 1.13 ... so its use is not recommended. As I understand it (I don't use GNU tar), the latest (.17 or .19) versions are probably OK. We should probably update the web page. But going back to 1.12 plus the Amanda patch (you did apply them, didn't you?) is also OK. Also, is it safe to directly tar to an amanda-written tape w/o amanda or might that mess up later attempts to amrestore from that tape? What do you mean? Amanda deliberately leaves the tape positioned at the end when it is done, i.e. it does not do a rewind. This is in case you want to append some more data in the same run, which should be reasonably safe (although I'd certainly do a couple of experiments before I committed to this). I don't know what amrestore will have to say about that if it bangs into your file(s). But by that time, it will have gone past all the Amanda data anyway and so you could ignore whatever whining it does. In my (very public :-) opinion, you should **NOT** rewind or reload an Amanda tape, fsf to the end and then write some information, unless you really, really know what you're doing and can verify at least 10 different ways that you're actually at the end of tape. george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
John R. Jackson wrote: But I just archived that dir to disk using tar and it got all the files fine. And did you do it the same way Amanda does, i.e. with all the listed incremental type flags it hands to GNU tar? That's where a lot of the problems are, not in just basic tar operations. Is the actual (eg, tar) command used by amdump recorded? Where? I downgraded my (gnu) tar to v1.12 last week because http://www.amanda.org/patches.html says there are a couple of other problems in release 1.13 ... so its use is not recommended. As I understand it (I don't use GNU tar), the latest (.17 or .19) versions are probably OK. We should probably update the web page. But going back to 1.12 plus the Amanda patch (you did apply them, didn't you?) is also OK. Yes, patch applied. In my (very public :-) opinion, you should **NOT** rewind or reload an Amanda tape, fsf to the end and then write some information, unless you really, really know what you're doing and can verify at least 10 different ways that you're actually at the end of tape. Good to know, thx. george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
Is the actual (eg, tar) command used by amdump recorded? Where? /tmp/amanda/sendsize*debug and /tmp/amanda/sendbackup*debug on the client. george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
missing files
It worked! I got a backup on tape and amdump sent me a success email! The last problem i found by looking at sendsize*debug as you suggested: it showed that it didn't expect /etc/amandates to be a directory so i deleted it and made a _file_ with that name instead. (amcheck didn't pick on this problem.) I also made a couple other small changes, for the record, not sure if they helped any. But i have a question as to why, according to a tar on the tape afterwards, only four out of the nine items in the directory to dump were actually backed up. Here's the nine items in the dir: # ls -l /home/amanda total 44 drwx--3 amanda amanda 4096 May 4 13:13 . drwxr-xr-x 11 root root 4096 Apr 27 13:45 .. -rw-rw-r--1 amanda amanda 46 May 4 13:09 .amandahosts -rw-rw-r--1 amanda amanda 21 Apr 30 16:07 .amandahosts~ -rw---1 amanda amanda 2388 May 2 18:26 .bash_history -rw-r--r--1 amanda amanda 24 Apr 27 13:45 .bash_logout -rw-r--r--1 amanda amanda230 Apr 27 13:45 .bash_profile -rw-r--r--1 amanda amanda124 Apr 27 13:45 .bashrc -rwxr-xr-x1 amanda amanda333 Apr 27 13:45 .emacs -rw-r--r--1 amanda amanda 3394 Apr 27 13:45 .screenrc drwx--2 amanda root 4096 Apr 30 14:20 .xauth What appears on the tape after the amdump: # tar tvv -rw-r--r-- amanda/amanda 230 2001-04-27 13:45 ./.bash_profile -rw-r--r-- amanda/amanda 124 2001-04-27 13:45 ./.bashrc -rwxr-xr-x amanda/amanda 333 2001-04-27 13:45 ./.emacs -rw-r--r-- amanda/amanda 3394 2001-04-27 13:45 ./.screenrc Also, am I supposed to create a info file and directory for every line in disklist? For example, creating /var/log/amanda/curinfo/dellmachine/ _home_amanda/info was necessary to make an amcheck complaint go away. thx again, george John R. Jackson wrote: What causes missing results? Usually a timeout. Take a look at /tmp/amanda/sendsize*debug on the client and figure out the total time (look at the first and last lines). Amanda allows five minutes per disk. If that's not enough, crank up the etimeout value in amanda.conf. george herson John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: missing files
The last problem i found by looking at sendsize*debug as you suggested: it showed that it didn't expect /etc/amandates to be a directory so i deleted it and made a _file_ with that name instead. (amcheck didn't pick on this problem.) ... It's on the TODO list to detect this. Now if I could just figure out how so many people manage to create it as a directory ... But i have a question as to why, according to a tar on the tape afterwards, only four out of the nine items in the directory to dump were actually backed up. ... What version of GNU tar are you using? If it's not at least 1.13.17 (and probably 1.13.19 would be better), you should upgrade. Did Amanda do a full dump (level 0) or an incremental (level 0)? Also, am I supposed to create a info file and directory for every line in disklist? ... No. Those are just informational messages from amcheck. Those directories will be automatically created for you by amdump (et al). george John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
