Jordan Desroches wrote:
Hello all,
I've been having a problem with incremental dumps on a NFS mounted
Netapp. AMANDA runs great until I reboot the client (or remount the NFS
shares on the client). At that point, while calcsize predicts what I
believe is the correct incremental dump size, tar proceeds to do a full
dump of all the NFS mounted files. I believe this has to due with
something changing between mounts that tar is translating as a change to
all files. Upon reading some of the documentation for tar, it indicated
that in the incremental dump gnutar-lists, there should be a "1"
preceding every entry to indicate that the file is NFS mounted because
(Quoting
http://www.gnu.org/software/automake/manual/tar/Incremental-Dumps.html";):
"Metadata stored in snapshot files include device numbers, which,
obviously is supposed to be a non-volatile value. However, it turns out
that NFS devices have undependable values when an automounter gets in
the picture. This can lead to a great deal of spurious redumping in
incremental dumps, so it is somewhat useless to compare two NFS devices
numbers over time. The solution implemented currently is to considers
all NFS devices as being equal when it comes to comparing directories;
this is fairly gross, but there does not seem to be a better way to go."
Here is an example from one of my gnutar-lists, showing what I believe
are preceding zeroes, indicating that tar thinks that the files are not
on NFS:
1201070794^@37216648^@0^@947801240^@0^@24^@8623377^@./unclaimed_afs/nmlhome/mcbride/.desktop-nauset.dartmouth.edu/0.0^@Y4Dwmdeskname^@Y4Dwmdesks^@Y4Dwmdesks.bak^@Y4Dwmsession^@^@^@0^@1180594753^@523384000^@24^@9457059^@./spacescience/web/wl/per/HenrysForkFishing^@YIMG_0103.jpg^@YIMG_0104.jpg^@YIMG_0105.jpg^@YIMG_0106.jpg^@YIMG_0107.jpg^@YIMG_0108.jpg^@YIMG_0109.jpg^@YIMG_0110.jpg^@YIMG_0111.jpg^@YIMG_0112.jpg^@YIMG_0113.jpg^@YIMG_0114.jpg^@YIMG_0115.jpg^@YIMG_0116.jpg^@YIMG_0117.jpg^@YIMG_0118.jpg^@YIMG_0119.jpg^@YIMG_0120.jpg^@YIMG_0121.jpg^@YIMG_0214.jpg^@^@^@0^@1170258810^@0^@24^@11505238^@./paulsen/MAC_Keith/Mac_NIH/Proposals/Breast
PPG/Original Proposal '98/Letters^@
Here's how the FS is mounted in /etc/fstab:
192.168.0.2:/vol/research /mnt/thayerfs/research nfs
hard,rsize=32768,wsize=32768 0 0
And here is an example disk list entry:
tardis /mnt/thayerfs/research_p-z /mnt/thayerfs/research {
nocomp-test
include "./[p-zP-Z]*"
}
Has anyone run into this problem, or know how to fix it?
Very related to this:
http://wiki.zmanda.com/index.php/Tar_dumps_every_file_in_a_level-1_backup_after_a_hardware_change
and fixing (each time you have the change!!) it with this script:
http://www.gnu.org/software/tar/utils/tar-snapshot-edit.html
This is actually a gnutar problem...
--
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 *
***********************************************************************
|
