Gee, I guessed correctly this time :))
On Sat, Oct 18, 2003 at 11:24:05PM +0530, Rohit Peyyeti wrote:
>
> Elaborating on my earlier post:
>
> Here is the amreport email which I got (I did write few DLEs to the
> tape)
>
> These dumps were to tape TLS-Set-1-10.
> *** A TAPE ERROR OCCURRED: [[writing file: No space left on device]].
> Some dumps may have been left in the holding disk.
Note the "may" here. Don't know if you are set up correctly to
write large level 0's to the holding disk or whether they go
directly to tape.
> Run amflush to flush them to tape.
> The next tape Amanda expects to use is: TLS-Set-2-01.
>
> FAILURE AND STRANGE DUMP SUMMARY:
> localhost /h lev 0 FAILED [dumps too big, but cannot incremental dump new
> disk]
> machine2 /h3 lev 0 FAILED [dumps too big, but cannot incremental dump
> new disk]
> machine2 /h lev 0 FAILED [dumps too big, but cannot incremental dump
> new disk]
> machine2 /h2 lev 0 FAILED [dumps too big, but cannot incremental dump
> new disk]
This suggests to me that the DLE's are each larger than your tape.
If so, it will NEVER be possible to back them up as currently configured.
They will have to be split (see lots of descriptions in the archive and
in the example disklist file) into multiple, smaller DLE's
> machine2 //windows/UsersG3 lev 0 STRANGE
> machine2 //windows/UsersG2 lev 1 STRANGE
> machine2 //windows/users lev 0 STRANGE
> machine2 //windows/users lev 0 FAILED [out of tape]
>
>
> STATISTICS:
> Total Full Daily
> -------- -------- --------
> Estimate Time (hrs:min) 0:26
> Run Time (hrs:min) 9:34
> Dump Time (hrs:min) 8:02 5:40 2:22
> Output Size (meg) 12275.1 8396.3 3878.8
> Original Size (meg) 23046.4 15172.3 7874.1
> Avg Compressed Size (%) 53.3 55.3 49.3 (level:#disks ...)
> Filesystems Dumped 12 2 10 (1:8 2:2)
Note, 12 DLE's dumped.
> Avg Dump Rate (k/s) 434.7 420.9 467.8
>
> Tape Time (hrs:min) 2:10 1:03 1:07
> Tape Size (meg) 7577.8 3698.5 3879.3
> Tape Used (%) 64.2 31.4 32.9 (level:#disks ...)
> Filesystems Taped 11 1 10 (1:8 2:2)
But 11 DLE's taped.
Note also, 7.5GB "successfully" taped.
> Avg Tp Write Rate (k/s) 993.4 995.2 991.8
>
>
> FAILED AND STRANGE DUMP DETAILS:
>
> /-- machine2 //windows/UsersG3 lev 0 STRANGE
> sendbackup: start [machine2://windows/UsersG3 level 0]
> sendbackup: info BACKUP=/usr/bin/smbclient
> sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... -
> sendbackup: info end
> --> some NT_STATUS_OBJECT_NAME_NOT_FOUND errors <--
> | tar: dumped 55299 files and directories
> | Total bytes written: 6503511552
> sendbackup: size 6351086
> sendbackup: end
> \--------
Samba backups always generate some "strange" results.
For me it is mostly files that windows will not let
me backup for some reason.
>
> /-- machine2 //windows/UsersG2 lev 1 STRANGE
> sendbackup: start [machine2://windows/UsersG2 level 1]
> sendbackup: info BACKUP=/usr/bin/smbclient
> sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... -
> sendbackup: info end
> --> some NT_STATUS_OBJECT_NAME_NOT_FOUND errors <--
> | tar: dumped 44048 files and directories
> | Total bytes written: 6387213824
> sendbackup: size 6237514
> sendbackup: end
> \--------
ditto
>
> /-- machine2 //windows/users lev 0 STRANGE
> sendbackup: start [machine2://windows/users level 0]
> sendbackup: info BACKUP=/usr/bin/smbclient
> sendbackup: info RECOVER_CMD=/usr/bin/smbclient -f... -
> sendbackup: info end
> --> some NT_STATUS_OBJECT_NAME_NOT_FOUND errors <--
> | tar: dumped 119083 files and directories
> | Total bytes written: 9405756416
> sendbackup: size 9185309
> sendbackup: end
> \--------
>
>
> NOTES:
> planner: Adding new disk localhost:/h.
> planner: Adding new disk machine2:/h.
> planner: Adding new disk machine2:/h2.
> planner: Adding new disk machine2:/h3.
> planner: Adding new disk machine2://windows/users.
Strongly suggest you do not add everything at once. Introduce them
a little at a time. Otherwise you try to backup 4000GB in one run
rather than 40GB each run. Remember any new DLE (disk) MUST BE GIVEN
a level 0 the first time it is seen.
> planner: Incremental of machine2:/vl bumped to level 2.
> taper: tape TLS-Set-1-10 kb 11981568 fm 12 writing file: No space left on
> device
> driver: going into degraded mode because of tape error.
Now here is the bad news. Amanda wrote 12 files to the tape (i.e. fm 12,
aka file marks). This is the initial amanda 32KB header (saying it is
tape TLS-Set-1-10 and other data) and 11 successful DLE dumps. Remember
above, the report said it dumped 12 DLE's, but only taped 11 DLE's
successfully, for 7.5GB. Note this line also says that at 11.981568GB
it reached the end of the tape. This was obviously during the taping of
that 12th DLE.
>
>
> DUMP SUMMARY:
> DUMPER STATS TAPER STATS
> HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
> -------------------------- --------------------------------- ------------
> machine1 /h 2 64160 58912 91.8 1:16 778.4 0:581019.8
> machine1 /vl 1 1449150 103744 7.2 5:12 332.0 1:421016.6
> machine1 /vm 1 44820 11360 25.3 0:15 780.1 0:12 911.2
> machine1 /vw 1 1280 448 35.0 0:01 452.9 0:22 20.8
> machine2 -is/UsersG2 1 62375143682880 59.0 131:26 467.0 61:32 997.4
> machine2 -is/UsersG3 0 63510863787296 59.6 135:14 466.7 63:26 995.2
> machine2 -osis/users 0 91853094810515 52.4 205:11 390.8 FAILED ----
And here we see the DLE that was the 12 to be taped and failed. It dumped
successfully ('probably' is on the holding disk) but failed taping. Why,
because it was a 9.18GB DLE that compressed to 4.81GB. But 7.5GB taped
plus 4.8GB trying to tape (12.3GB) does not fit into your 11.8GB tape
(as you reported earlier today).
> machine2 /h 0 FAILED ---------------------------------------
> machine2 /h2 0 FAILED ---------------------------------------
> machine2 /h3 0 FAILED ---------------------------------------
> machine2 /vl 2 61570 5472 8.9 0:18 301.9 0:07 775.6
> machine2 /vw 1 178790 106368 59.5 2:56 605.1 1:451017.6
> localhost /h 0 FAILED ---------------------------------------
We already guessed that these failed because they were bigger than 11.8GB
so amanda did not even try.
> localhost /rp 1 21770 2752 12.6 0:021267.3 0:04 694.1
> localhost /vl 1 1790 160 8.9 0:01 172.7 0:02 77.9
> localhost /vw 1 2280 320 14.0 0:05 52.9 0:02 186.0
It is generally recommended that you NOT use localhost, but a hostname.
You and I know we will "never" do it, but what if you move your amanda
installation, or the tapedrive to another system. It will be the wrong
"localhost", but the correct "hostname".
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
