Date: Thu, 16 Mar 2006 11:20:37 +0000 From: Alex Zbyslaw <xfb52@dial.pipex.com> To: Paolo Tealdi <paolo.tealdi@polito.it> Cc: freebsd-questions@freebsd.org Subject: Re: dump level 9 Message-ID: <44194A05.4010600@dial.pipex.com> In-Reply-To: <7.0.1.0.0.20060316091138.01fa4ae8@polito.it> References: <7.0.1.0.0.20060315131135.0327a978@polito.it> <441821AD.1080605@dial.pipex.com> <7.0.1.0.0.20060315153306.02165290@polito.it> <4418344D.8080003@dial.pipex.com> <7.0.1.0.0.20060316091138.01fa4ae8@polito.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Paolo Tealdi wrote: > At 15.35 15/03/2006 +0000, Alex Zbyslaw wrote: > >> Paolo Tealdi wrote: >> >> >>> >>> /dev/da0s1g 91399912 57543202 32028712 64% /home >> >> >> Well, that does look like the whole disk, and the dates and levels of >> the dumps look right... >> >> What happens if you leave off the -L (but still doing just an >> estimate)? (You shouldn't need > > > # dump 9SuBf 1000000000 - /home > DUMP: WARNING: should use -L when dumping live read-write filesystems! > DUMP: Date of this level 9 dump: Thu Mar 16 09:13:53 2006 > DUMP: Date of last level 0 dump: Sat Mar 11 19:40:24 2006 > DUMP: Dumping /dev/da0s1g (/home) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 57703445 tape blocks. > > Little differences because the it's in production > >> the redirection as nothing is actually dumped with -S). What does ls >> -lsak /home show? If that's just a small number of users, then "ls >> -lsak /home/*". > > >> Is it conceivable that you have some process running which is >> actually touching all the files in /home? > > > No. > > This is an extract of the ls for a user directory > > /home/BCI/avantag: > total 12098 > 2 drwx------ 8 bci bci 1024 Apr 27 2005 ./ > 2 drwxr-xr-x 20 bci bci 512 Mar 14 2005 ../ > 2 -rw------- 1 bci bci 30 Jan 16 2003 .qmail > 22 -rw------- 1 bci bci 22528 Mar 21 2001 archivio_lib.doc > 20 -rw------- 1 bci bci 19456 Mar 21 2001 archivio_per.doc > 20 -rw------- 1 bci bci 19456 Mar 21 2001 archivio_tes.doc > 2 drwx------ 4 bci bci 512 Apr 27 2005 biblioteca/ > 2 drwx------ 2 bci bci 512 Dec 28 2004 bookmark importati/ > 20 -rw------- 1 bci bci 19456 Mar 21 2001 > classificazioni_lib.doc > 2 drwx------ 2 bci bci 512 Dec 28 2004 doc.tealdi/ > 2 drwx------ 3 bci bci 512 Dec 28 2004 documenti/ > 2400 -rw------- 1 bci bci 2435127 Mar 21 2001 doppi_per_chiave.zip > 5424 -rw------- 1 bci bci 5526904 Mar 21 2001 > doppi_per_chiave_e_anno.zip > 2 drwx------ 17 bci bci 1536 Mar 16 09:16 eudora/ > 400 -rw------- 1 bci bci 378880 Mar 21 2001 > guida_configurazione_aleph500.doc > 288 -rw------- 1 bci bci 271622 Mar 21 2001 > lista_classificazioni_singole.zip > 54 -rw------- 1 bci bci 53849 Mar 21 2001 > lista_edizioni_singole.zip > 3168 -rw------- 1 bci bci 3224349 Mar 21 2001 > lista_intestazioni.zip > 224 -rw------- 1 bci bci 201646 Mar 21 2001 > lista_soggetti_singoli.zip > 0 -rw------- 1 bci bci 0 Jan 16 2003 mailbox > 2 drwx------ 2 bci bci 512 Dec 28 2004 maildir/ > > This is the output of restore -if <filename> for this directory. > > restore > cd BCI/avantag > restore > ls > ./BCI/avantag: > .qmail eudora/ > archivio_lib.doc guida_configurazione_aleph500.doc > archivio_per.doc lista_classificazioni_singole.zip > archivio_tes.doc lista_edizioni_singole.zip > biblioteca/ lista_intestazioni.zip > bookmark importati/ lista_soggetti_singoli.zip > classificazioni_lib.doc mailbox > doc.tealdi/ maildir/ > documenti/ > numero_dei_volumi_esistenti_su_lib.doc > doppi_per_chiave.zip videoregistrazioni_cd.doc > doppi_per_chiave_e_anno.zip > Sorry, at this point I have no clue what's going on. Assuming everything really is OK with the base system, then this looks like a bug. Clutching at straws, here are some things I might try: 1) "which dump" - just to be absolutely sure 2) Remake dump from /usr/src. 3) Make sure base system is OK. Cvsup, buildworld, buildkernel etc. This would bring you up to -p12 and require reboot. If behaviour still the same, file a PR. 4) Depending on your C prowess, instrument dump with some debugging info - at the point where it decides to back up a file, print out the relevant variables (the dates on the file and the date that it is being compared against). This will generate a lot of output but you can just hit ^C after a few seconds of printing. I don't think gdb would be an option as dump forks to 5) Do a level 0 of / home. Check that the restore actually works by actually restoring at least some of it, not just using ls. Then newfs /home being very careful and then restore it! (Being paranoid, I would make more than one dump, including one to tape, and would restore one of the backups to some spare disk). --Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44194A05.4010600>