On 2006-03-10 12:07, . wrote:
Hi,
somehow it seems that the amount dumped to tape differs from what's on
the partition:
NOTES:
[...]
taper: tape condor-04 kb 2509536 fm 11 [OK]
DUMP SUMMARY:
DUMPER STATS TAPER
STATS HOSTNAME DISK L ORIG-kB OUT-kB COMP% MMM:SS KB/s
MMM:SS KB/s
-------------------------- --------------------------------- ------------
prometheus / 0 49700 40934 82.4 1:00 679.7 0:261590.4
prometheus /home 1 10179801017980 -- 6:552454.5 2:466117.0
prometheus /share 1 228790 145301 63.5 9:49 246.8 0:354170.8
prometheus /tmp 0 5830 688 11.8 0:02 294.9 0:09 75.4
prometheus /usr 0 393495 237920 60.5 3:511031.8 0:524586.7
prometheus /var 0 204380 159242 77.9 1:162094.3 0:295549.1
[...]
(brought to you by Amanda version 2.4.5)
Sidenote...
Have a look at the "columnspec" parameter for amanda.conf and add
some whitespace between the columns.
prometheus:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 228M 93M 124M 43% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sda7 4.6G 33M 4.4G 1% /ahodi
/dev/sda8 353G 97G 239G 29% /home
/dev/sda9 542G 53G 462G 11% /share
/dev/sda3 3.7G 34M 3.5G 1% /tmp
/dev/sda6 3.7G 758M 2.8G 22% /usr
/dev/sda5 5.5G 425M 4.9G 8% /var
[...]
How can a _full_ dump of a 93 MB partition (/) make for an uncompressed
size of 40 MB? The dump of the /home partition is likewise weird.
When I sum up what has been dumped to tape, it adds up to 2.39 GB. How
can a full dump of more than 150 GB come down to 2.39 GB on tape?
Different possibilities.
- Do you use gnutar with an exclude list? What is excluded?
- When you remove a file that is still open by some process, the
filename is gone, but the file-without-name and diskspace it takes
is still there, until the last process having the file open is
finished. This can easily happen with programs that create large
log or debugging files, and you removed them, but the program itself
is still keeping the files open (and can even still write to them!).
- A file having one byte, occupies one diskblock. Many small files,
and possibly large diskblocks (noting the size of your partitions
that is probably the case!) results in much wasted diskspace.
Backing up with gnutar uses a fixed amount for each filename (with
stats, etc.) plus the content of the file itself, possibly only one
byte. Some filesystems behave better in these extreme cases, if
tuned properly.
But it is still weird...
Any files missing in the backup?
Any files having a weird small (0?) size in the backup that is
not zero in the filesystem?
What version of gnutar are you using? There are known bugs in 1.14.x
and 1.15.0 having to do with sparse files (although nothing I've
seen would result in this behaviour -- the backup itself would be
find, only restoring sparse files with that version would be a problem.)
Or are you using dump?
Dumps are promoted most of the time. Am I making a bad mistake somewhere?
That is weird indeed.
What is the output "amadmin config balance"?
--
Paul Bijnens, xplanation Technology Services Tel +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax +32 16 397.512
http://www.xplanation.com/ email: Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ... "Are you sure?" ... YES ... Phew ... I'm out *
***********************************************************************
|
