Is this OK? Ignoring cruft file
Hi all,
I added a 'big' disk to my disklist yesterday. About 8G.
Flushing the files from the holding disk results in
NOTES:
amflush: beosrv-1._redhat.0.2: ignoring cruft file.
amflush: beosrv-1._redhat.0.3: ignoring cruft file.
taper: tape xic03 kb 13511296 fm 58 [OK]
Should I worry about this? Did only 2G of the backup actually make it to the tape?
The holding disk is empty after this, and it seems to happen only when a disk
is freshly added to the disklist. If it is due for a full backup lateron, there is no
such message.
I've set the chunksize of my holding disk to 2G.
I have to run amdump and amflush in separate runs. This is working fine.
I verify every tape written and that only gave errors once when the tape
was exhausted and completed on the next tape (expected error).
Thanks for any info!
Regards,
Edwin Hakkennes
--
From: Amanda user[SMTP:[EMAIL PROTECTED]]
Reply To: Admins
Sent: Thursday, August 15, 2002 10:45 AM
To: Multiple recipients of list admins
Subject:xic AMFLUSH MAIL REPORT FOR August 15, 2002
The dumps were flushed to tape xic03.
The next 2 tapes Amanda expects to used are: xic04, xic05.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 2:30
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)2:29 2:19 0:10
Tape Size (meg) 13194.612526.2 668.5
Tape Used (%) 62.7 59.53.2 (level:#disks ...)
Filesystems Taped58 29 29 (1:29)
Avg Tp Write Rate (k/s) 1506.3 1535.8 1107.9
NOTES:
amflush: beosrv-1._redhat.0.2: ignoring cruft file.
amflush: beosrv-1._redhat.0.3: ignoring cruft file.
taper: tape xic03 kb 13511296 fm 58 [OK]
DUMP SUMMARY:
DUMPER STATS
TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s
MMM:SS KB/s
--- --
beosrv-1 /0 645860 310720 48.1 N/A N/A
5:54 878.7
beosrv-1 /install NO FILE TO FLUSH
--
beosrv-1 /redhat 0 7980690 7649568 95.9 N/A N/A
66:081927.9
beosrv-1 /srv/apps1 143901056 7.3 N/A N/A
0:09 117.0
beosrv-1 /srv/data12030 256 12.6 N/A N/A
0:09 28.9
beosrv-1 /srv/libs1 14140 416 2.9 N/A N/A
0:12 34.2
beosrv-1 /srv/projects0 83650 63456 75.9 N/A N/A
0:411549.7
beosrv-1 /srv/scratch 0 10 64 640.0 N/A N/A
0:05 13.3
beosrv-1 /srv/users 0 4 22848 57.1 N/A N/A
0:211105.3
beosrv-1 /srv/xic 0 10 64 640.0 N/A N/A
0:11 6.1
beosrv-1 /var 1 391203872 9.9 N/A N/A
0:11 343.3
beosrv-2 /0 268150 121376 45.3 N/A N/A
2:38 768.0
beosrv-2 /var 0 107840 59520 55.2 N/A N/A
0:431372.2
dilbert /1 780 160 20.5 N/A N/A
0:10 16.5
dilbert /boot1 10 64 640.0 N/A N/A
0:10 6.2
dilbert /home1 340001472 4.3 N/A N/A
0:09 162.7
dilbert /usr 1 101601056 10.4 N/A N/A
0:09 117.4
dilbert /usr/local 1 270 64 23.7 N/A N/A
0:05 13.0
dilbert /var 1 239906752 28.1 N/A N/A
0:17 399.2
jansen_en_janssen/.kde1 10 64 640.0 N/A N/A
0:09 7.2
jansen_en_janssen/.kde2 1 20 64 320.0 N/A N/A
0:09 7.4
jansen_en_janssen/bin 1 10 64 640.0 N/A N/A
0:09 7.2
jansen_en_janssen/boot088307968 90.2 N/A N/A
0:13 616.1
jansen_en_janssen/dev 1 70 64 91.4 N/A N/A
0:09 7.2
jansen_en_janssen/etc 081301792 22.0 N/A N/A
0:09 194.8
Re: Is this OK? Ignoring cruft file
On Thu, Aug 15, 2002 at 11:47:24AM +0200, Edwin Hakkennes wrote: Hi all, I added a 'big' disk to my disklist yesterday. About 8G. Flushing the files from the holding disk results in NOTES: amflush: beosrv-1._redhat.0.2: ignoring cruft file. amflush: beosrv-1._redhat.0.3: ignoring cruft file. taper: tape xic03 kb 13511296 fm 58 [OK] Should I worry about this? Did only 2G of the backup actually make it to the tape? The holding disk is empty after this, and it seems to happen only when a disk is freshly added to the disklist. Why do you think only 2GB? Your chunksize? The above report says kb 13511296, i.e. 13.5GB. It also says fm 58, i.e. 58 file marks, about 56 disklist entries. If it is due for a full backup lateron, there is no such message. Don't know what message you might expect, but try amadmin xic due beosrv-1 /redhat to check when the next full dump is due. I don't know all the reason for cruft files, but occasionally I've seen empty directories or files that an amflush cleans up and reports as cruft. I've set the chunksize of my holding disk to 2G. If your file system has a 2GB file size limit, I believe the recommendation is to have the chucksize below, not at the limit. If it handles larger files, then 2GB is fine. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Is this OK? Ignoring cruft file
--On Thursday, August 15, 2002 11:47:24 +0200 Edwin Hakkennes [EMAIL PROTECTED]
wrote:
Hi all,
I added a 'big' disk to my disklist yesterday. About 8G.
Flushing the files from the holding disk results in
NOTES:
amflush: beosrv-1._redhat.0.2: ignoring cruft file.
amflush: beosrv-1._redhat.0.3: ignoring cruft file.
taper: tape xic03 kb 13511296 fm 58 [OK]
Should I worry about this? Did only 2G of the backup actually make it to the tape?
It wrote 13.5G to tape, and according to your output below, 7.6G of that was from
your beosrv-1 /redhat disklist entry. I think the cruft file messages are just
a result of the somewhat asynchronous nature of amanda. The chunk files are removed
after each set is written to tape but may not be all gone yet when Amanda scans
for other chunk sets to flush to tape. Anything that it doesn't know what to do
with is reported as 'cruft', whether it is some odd file put in the holding disk
or a chunk that isn't part of a complete set (the chunk files are named as
host.filesystem.level.chunknumber).
'Notes' are just informative, 'strange' needs to be examined, it may or may not
be a problem, and 'warning' you better pay attention to.
Frank
The holding disk is empty after this, and it seems to happen only when a disk
is freshly added to the disklist. If it is due for a full backup lateron, there is no
such message.
I've set the chunksize of my holding disk to 2G.
I have to run amdump and amflush in separate runs. This is working fine.
I verify every tape written and that only gave errors once when the tape
was exhausted and completed on the next tape (expected error).
Thanks for any info!
Regards,
Edwin Hakkennes
--
From: Amanda user[SMTP:[EMAIL PROTECTED]]
Reply To: Admins
Sent: Thursday, August 15, 2002 10:45 AM
To: Multiple recipients of list admins
Subject: xic AMFLUSH MAIL REPORT FOR August 15, 2002
The dumps were flushed to tape xic03.
The next 2 tapes Amanda expects to used are: xic04, xic05.
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 2:30
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)2:29 2:19 0:10
Tape Size (meg) 13194.612526.2 668.5
Tape Used (%) 62.7 59.53.2 (level:#disks ...)
Filesystems Taped58 29 29 (1:29)
Avg Tp Write Rate (k/s) 1506.3 1535.8 1107.9
NOTES:
amflush: beosrv-1._redhat.0.2: ignoring cruft file.
amflush: beosrv-1._redhat.0.3: ignoring cruft file.
taper: tape xic03 kb 13511296 fm 58 [OK]
DUMP SUMMARY:
DUMPER STATS
TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS
KB/s MMM:SS KB/s
---
--
beosrv-1 /0 645860 310720 48.1 N/A
N/A5:54 878.7
beosrv-1 /install NO FILE TO FLUSH
--
beosrv-1 /redhat 0 7980690 7649568 95.9 N/A
N/A 66:081927.9
beosrv-1 /srv/apps1 143901056 7.3 N/A
N/A0:09 117.0
beosrv-1 /srv/data12030 256 12.6 N/A
N/A0:09 28.9
beosrv-1 /srv/libs1 14140 416 2.9 N/A
N/A0:12 34.2
beosrv-1 /srv/projects0 83650 63456 75.9 N/A
N/A0:411549.7
beosrv-1 /srv/scratch 0 10 64 640.0 N/A
N/A0:05 13.3
beosrv-1 /srv/users 0 4 22848 57.1 N/A
N/A0:211105.3
beosrv-1 /srv/xic 0 10 64 640.0 N/A
N/A0:11 6.1
beosrv-1 /var 1 391203872 9.9 N/A
N/A0:11 343.3
beosrv-2 /0 268150 121376 45.3 N/A
N/A2:38 768.0
beosrv-2 /var 0 107840 59520 55.2 N/A
N/A0:431372.2
dilbert /1 780 160 20.5 N/A
N/A0:10 16.5
dilbert /boot1 10 64 640.0 N/A
N/A0:10 6.2
dilbert /home1 340001472 4.3 N/A
N/A0:09 162.7
dilbert
Re: Is this OK? Ignoring cruft file
On Thursday 15 August 2002 11:01, Frank Smith wrote: --On Thursday, August 15, 2002 11:47:24 +0200 Edwin Hakkennes [EMAIL PROTECTED] wrote: Hi all, I added a 'big' disk to my disklist yesterday. About 8G. Flushing the files from the holding disk results in NOTES: amflush: beosrv-1._redhat.0.2: ignoring cruft file. amflush: beosrv-1._redhat.0.3: ignoring cruft file. taper: tape xic03 kb 13511296 fm 58 [OK] Should I worry about this? Did only 2G of the backup actually make it to the tape? It wrote 13.5G to tape, and according to your output below, 7.6G of that was from your beosrv-1 /redhat disklist entry. I think the cruft file messages are just a result of the somewhat asynchronous nature of amanda. The chunk files are removed after each set is written to tape but may not be all gone yet when Amanda scans for other chunk sets to flush to tape. Anything that it doesn't know what to do with is reported as 'cruft', whether it is some odd file put in the holding disk or a chunk that isn't part of a complete set (the chunk files are named as host.filesystem.level.chunknumber). 'Notes' are just informative, 'strange' needs to be examined, it may or may not be a problem, and 'warning' you better pay attention to. Frank Hummm, this brings up an interesting thought, Frank. If amanda removed the chunk files as they were written, then how would amanda go about the case of hitting EOT in the middle of the last chunk file, finding that it has perms (via runtapes=2 for instance) to use the next tape in the magazine, at which point amanda supposedly restarts that disklist entries dump from the top. If there were 4 chunk files, 3 of which had been written and deleted when this occured, it seems to me that amanda would find herself between a rock and a hard place to be able to restart that particular disklist entries dump. It certainly wouldn't be very time efficient to redo the whole entry although that does seem to be the only way to recover. So how is this scenario resolved by amanda? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
Re: Is this OK? Ignoring cruft file
--On Thursday, August 15, 2002 11:45:52 -0400 Gene Heskett [EMAIL PROTECTED] wrote: On Thursday 15 August 2002 11:01, Frank Smith wrote: --On Thursday, August 15, 2002 11:47:24 +0200 Edwin Hakkennes [EMAIL PROTECTED] wrote: Hi all, I added a 'big' disk to my disklist yesterday. About 8G. Flushing the files from the holding disk results in NOTES: amflush: beosrv-1._redhat.0.2: ignoring cruft file. amflush: beosrv-1._redhat.0.3: ignoring cruft file. taper: tape xic03 kb 13511296 fm 58 [OK] Should I worry about this? Did only 2G of the backup actually make it to the tape? It wrote 13.5G to tape, and according to your output below, 7.6G of that was from your beosrv-1 /redhat disklist entry. I think the cruft file messages are just a result of the somewhat asynchronous nature of amanda. The chunk files are removed after each set is written to tape but may not be all gone yet when Amanda scans for other chunk sets to flush to tape. Anything that it doesn't know what to do with is reported as 'cruft', whether it is some odd file put in the holding disk or a chunk that isn't part of a complete set (the chunk files are named as host.filesystem.level.chunknumber). 'Notes' are just informative, 'strange' needs to be examined, it may or may not be a problem, and 'warning' you better pay attention to. Frank Hummm, this brings up an interesting thought, Frank. If amanda removed the chunk files as they were written, then how would amanda go about the case of hitting EOT in the middle of the last chunk file, finding that it has perms (via runtapes=2 for instance) to use the next tape in the magazine, at which point amanda supposedly restarts that disklist entries dump from the top. If there were 4 chunk files, 3 of which had been written and deleted when this occured, it seems to me that amanda would find herself between a rock and a hard place to be able to restart that particular disklist entries dump. It certainly wouldn't be very time efficient to redo the whole entry although that does seem to be the only way to recover. So how is this scenario resolved by amanda? I said that the chunks were removed after the set was written. I haven't looked at that part of the code, just observed my holding disk in various situations, so I may not be completely correct. It appears that after all of the set of chunks belonging to a single disklist entry are successfully flushed to tape, those chunks are deleted from the disk. If a tape error occurs anytime during the flush of a set of chunks all of that set remains on disk so a subsequent amflush can start over with the first chunk of the set. I believe Edwin's 'notes' was the result of Amanda successfully flushing all of the chunks of his 'redhat' directory, but after taper returned ok a command was given to remove those chunks while amflush went ahead and rescanned the holding disk looking for anything else that needed to be flushed. Since it can take a second or two to remove large files, a couple of the chunks were still there when the scan occurred, but since the first chunk was already gone Amanda saw the other two as cruft. Of course, when Edwin looked at the disk later it was all gone by then. Frank -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Is this OK? Ignoring cruft file
On Thursday 15 August 2002 12:55, Frank Smith wrote: I've been corrected Frank, seems I'd missed the key word 'set', my bad. Can I plead alzheimers, or failing that, just plain stupidity? Maybe thats what I get for trying to keep my reading speeds up as the years pile up. :-) -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 99.11% setiathome rank, not too shabby for a WV hillbilly
skipping cruft file
Hi all. I've installed amanda from the latest source after removing the SuSE 7.3 rpm version. When I run amcheck it passes server test and dies on client: WARNING: localhost: selfcheck request timed out. Host down? I've gone through the amanda chapter in the book recommended, the same with INSTALL file and cannot see anything I've missed. So I ran amoverview and it reported: bad date 20011205: in 20011205: found Amanda directory. bad date .bashrc: in .bashrc: skipping cruft file, perhaps you should delete it. date11 hostdisk30 localhoshda30 (Missing t is not a typo) I've search every file without finding any 'cruft' reference. What is going on? I got further than this on the rpm version... -- Steve Szmidt V.P. Information Video Group Distributors, Inc.
Re: cruft file ?
Stephen, On Fri, 7 Jun 2002, Stephen Carville wrote: |On Fri, 7 Jun 2002, Marcelo Souza wrote: | |- What those ignoring cruft file mean? | |The directory you have designated as holdingdisk probaly has some |files amanda does not recognize in it. But what it tell as cruft file are part of the backup. This volume is backed up to the holding disk, and later is flushed to tape. Amanda is spliting the volume in some files that amflush call cruft file. Can it mean that am I loosing data that is not flushed to tape? |- NOTES: |- amflush: host1.sd2a.0.1: ignoring cruft file. |- amflush: host1.sd2a.0.2: ignoring cruft file. |- amflush: host1.sd2a.0.3: ignoring cruft file. |- amflush: host1.sd2a.0.4: ignoring cruft file. |- amflush: host1.sd2a.0.5: ignoring cruft file. |- taper: tape host1_MAIL3 kb 11181824 fm 1 [OK] |- |- |- DUMP SUMMARY: |- DUMPER STATS TAPER STATS |- HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s |- -- -- -- |- host1 sd2a 0 11181824 11181824 -- N/AN/A 141:40 1315.5 |- |- (brought to you by Amanda version 2.4.1p1) - Marcelo
cruft file ?
Hi all,
What those ignoring cruft file mean?
TIA,
- Marcelo
(...)
STATISTICS:
Total Full Daily
Dump Time (hrs:min)2:23 2:22 0:00 (0:00 start, 0:01 idle)
Output Size (meg) 10919.810919.80.0
Original Size (meg) 10919.810919.80.0
Avg Compressed Size (%) -- -- --
Tape Used (%) 60.7 60.70.0
Filesystems Dumped1 1 0
Avg Dump Rate (k/s) -- -- --
Avg Tp Write Rate (k/s) 1315.5 1315.5--
NOTES:
amflush: host1.sd2a.0.1: ignoring cruft file.
amflush: host1.sd2a.0.2: ignoring cruft file.
amflush: host1.sd2a.0.3: ignoring cruft file.
amflush: host1.sd2a.0.4: ignoring cruft file.
amflush: host1.sd2a.0.5: ignoring cruft file.
taper: tape host1_MAIL3 kb 11181824 fm 1 [OK]
DUMP SUMMARY:
DUMPER STATS TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -- --
host1 sd2a 0 11181824 11181824 -- N/AN/A 141:40 1315.5
(brought to you by Amanda version 2.4.1p1)
Re: skipping cruft file
On Thu, 6 Dec 2001 at 8:40am, Steve wrote Hi all. I've installed amanda from the latest source after removing the SuSE 7.3 rpm version. When I run amcheck it passes server test and dies on client: WARNING: localhost: selfcheck request timed out. Host down? Did you go through the steps in FAQ-O-Matic to solve this? Is there any firewall (external, or ipchains/iptables) in the way? Did you make the appropriate changes to (x)inetd? Did you then restart (x)inetd? etc, etc. I've gone through the amanda chapter in the book recommended, the same with INSTALL file and cannot see anything I've missed. So I ran amoverview and it reported: amoverview is not going to help you debug this. You need to get your setup to pass amcheck. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
