Skip site navigation (1)Skip section navigation (2)
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>