Re: dump level 9
At 13.23 16/03/2006 +, Alex Zbyslaw wrote: Good luck. If you try the newfs, please let us know how it turns out. Hurra ! I resolved! Obviously newfs did not resolve. :-( But... i studied the problem from another point of view reading dump sources, as you suggested. dump thinks that file has changed if : a) modification date has changed b) cdate has changed : cdate is the date of inode modification throught stat utility (very nice) i noticed that every file under /home had a cdate very recent. comparing dates i got solution : sophos antivirus, that starts every night with a complete /home scan, modifies cdate. Unfortunately i installed sophos antivirus more or less in the same days of the power cut ... I think that sophos support will receive a question in the next few days ... :-) Thank for the support, Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Paolo Tealdi wrote: Hurra ! I resolved! Excellent! Obviously newfs did not resolve. :-( But... i studied the problem from another point of view reading dump sources, as you suggested. dump thinks that file has changed if : a) modification date has changed b) cdate has changed : cdate is the date of inode modification throught stat utility (very nice) i noticed that every file under /home had a cdate very recent. comparing dates i got solution : sophos antivirus, that starts every night with a complete /home scan, modifies cdate. Unfortunately i installed sophos antivirus more or less in the same days of the power cut ... Damn. Kicking myself for not asking you about cdate. I think that sophos support will receive a question in the next few days ... :-) Shame your email can't include a big kick in the pants for whoever a) thought this was a good idea in the first place b) didn't pick up such dumb behaviour in testing. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
At 15.35 15/03/2006 +, Alex Zbyslaw wrote: Paolo Tealdi wrote: /dev/da0s1g 91399912 57543202 3202871264%/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 10 - /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 bci22528 Mar 21 2001 archivio_lib.doc 20 -rw--- 1 bci bci19456 Mar 21 2001 archivio_per.doc 20 -rw--- 1 bci bci19456 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 bci19456 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 bci53849 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 bci0 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.docguida_configurazione_aleph500.doc archivio_per.doclista_classificazioni_singole.zip archivio_tes.doclista_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.zipvideoregistrazioni_cd.doc doppi_per_chiave_e_anno.zip restore Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Paolo Tealdi wrote: At 15.35 15/03/2006 +, Alex Zbyslaw wrote: Paolo Tealdi wrote: /dev/da0s1g 91399912 57543202 3202871264%/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 10 - /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 bci22528 Mar 21 2001 archivio_lib.doc 20 -rw--- 1 bci bci19456 Mar 21 2001 archivio_per.doc 20 -rw--- 1 bci bci19456 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 bci19456 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 bci53849 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 bci0 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.docguida_configurazione_aleph500.doc archivio_per.doclista_classificazioni_singole.zip archivio_tes.doclista_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.zipvideoregistrazioni_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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
At 11.20 16/03/2006 +, Alex Zbyslaw wrote: Clutching at straws, here are some things I might try: 1) which dump - just to be absolutely sure /sbin/dump 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). I will do a newfs on saturday afternoon, after doing some backups (also on tape). After this, if the problem persists, i'll do the pass 2, 3 and 4. In my opinion something gets damaged at filesystem level after an energy block (date are similar). I did an fsck (more times) but the problem persists : probably fsck doesn't recognise the problem. It could be important to do debugging for this problem, but it's a production disk (big) and i can't play with it too much. Thanks a lot for your support. Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Paolo Tealdi wrote: I will do a newfs on saturday afternoon, after doing some backups (also on tape). After this, if the problem persists, i'll do the pass 2, 3 and 4. In my opinion something gets damaged at filesystem level after an energy block (date are similar). I did an fsck (more times) but the problem persists : probably fsck doesn't recognise the problem. By energy block I assume you mean a power cut? It's certainly suspicious but without actually understanding what is causing the problem, hard to be sure if there is a relation. I'm struggling to understand how ls can show a date in 2003 for a file, while dump thinks that the inode has changed since your level 0 a few days ago. I'm no expert on the filesystem, but that's just weird. I don't see how a power cut could have done that or what problem fsck could fix It could be important to do debugging for this problem, but it's a production disk (big) and i can't play with it too much. Thanks a lot for your support. One more thought off the top of my head. What does ls -lsak /home/.snap show? I know there can be issues with snapshots in the 5 series and having more than one snapshot can be a bad idea. I don't think that's it because your dump -S without -L showed pretty much the same as with -L, but just in case. If you do find any snapshots (I believe dump would leave one called dump_snapshot or .dump_snapshot or something obvious if it gets interrupted (by a power failure, for example) then you can delete with rm. I don't hold out much hope but it's easier than a dump/restore). If no-one else replies here with bright ideas, you could also try posting to maybe freebsd-hackers or freebsd-fs; http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL Good luck. If you try the newfs, please let us know how it turns out. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Dear all, i've a problem with a dump on level 9 for a filesystem. Scenario : a) System with 2 filesystem ( /home and /backup ). b) every night a batch process makes a dump of /home on a file living on /backup. On saturday it makes a dump on level 0 and the other nights it makes a dump on level 9. c) this procedure has worked for 1.5 years without any problem. d) This procedure is working well for all the other filesystems of this server. It's working also for other servers without problem. e) the batch execute dump with these parameters : # dump leveluLBf 10 - mount-point f) The server is a Freebsd 5.4-p6 vanilla. g) /etc/dumpdates seems to be ok (/home is /dev/da0s1g. /dev/da0s1a 0 Sat Mar 11 19:28:32 2006 /dev/da0s1d 0 Sat Mar 11 19:29:07 2006 /dev/da0s1e 0 Sat Mar 11 19:29:22 2006 /dev/da0s1f 0 Sat Mar 11 19:29:24 2006 /dev/da0s1g 0 Sat Mar 11 19:40:24 2006 /dev/da0s1a 9 Wed Mar 15 03:00:01 2006 /dev/da0s1d 9 Wed Mar 15 03:00:03 2006 /dev/da0s1e 9 Wed Mar 15 03:00:08 2006 /dev/da0s1f 9 Wed Mar 15 03:00:11 2006 /dev/da0s1g 9 Wed Mar 15 03:02:43 2006 h) filesystem is fsck ok. The problem : Level 9 backup does a complete backup as it does level 0. I did a random control and everything seems to be copied, also if the file date is VERY OLD comparing with backup date. There isn't enought space in /backup to make 6 complete backup of /home : i am in continous disk-full risk ... Did you use the -u switch on your dump command. It looks like you must have if dumpdates is written OK. I haven't tried this and, if lacking a -u isn't the problem, unfortunately I do not have an answer to your main question. But, I wonder why you chose level 9 for your change dumps. It sort of defeats the system. It would be more normal to use level 1. I know that [some much] earlier versions of BSD dump only took levels up to 5, but I presume that since they include up to 9 in the documentation it should work. jerry Anybody has any idea ? Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Paolo Tealdi wrote: i've a problem with a dump on level 9 for a filesystem. Scenario : a) System with 2 filesystem ( /home and /backup ). b) every night a batch process makes a dump of /home on a file living on /backup. On saturday it makes a dump on level 0 and the other nights it makes a dump on level 9. c) this procedure has worked for 1.5 years without any problem. d) This procedure is working well for all the other filesystems of this server. It's working also for other servers without problem. e) the batch execute dump with these parameters : # dump leveluLBf 10 - mount-point f) The server is a Freebsd 5.4-p6 vanilla. g) /etc/dumpdates seems to be ok (/home is /dev/da0s1g. /dev/da0s1a 0 Sat Mar 11 19:28:32 2006 /dev/da0s1d 0 Sat Mar 11 19:29:07 2006 /dev/da0s1e 0 Sat Mar 11 19:29:22 2006 /dev/da0s1f 0 Sat Mar 11 19:29:24 2006 /dev/da0s1g 0 Sat Mar 11 19:40:24 2006 /dev/da0s1a 9 Wed Mar 15 03:00:01 2006 /dev/da0s1d 9 Wed Mar 15 03:00:03 2006 /dev/da0s1e 9 Wed Mar 15 03:00:08 2006 /dev/da0s1f 9 Wed Mar 15 03:00:11 2006 /dev/da0s1g 9 Wed Mar 15 03:02:43 2006 h) filesystem is fsck ok. The problem : Level 9 backup does a complete backup as it does level 0. I did a random control and everything seems to be copied, also if the file date is VERY OLD comparing with backup date. There isn't enought space in /backup to make 6 complete backup of /home : i am in continous disk-full risk ... Anybody has any idea ? Show us the output of the dump command which didn't work as you expected. Right when it starts it tells you what level of dump it is doing and when it thinks the last relevant dump was. This may not be the problem, but it's the best place to start! Btw, I think your -B 10 is not the best way to go. Just use -a instead. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
At 08.45 15/03/2006 -0500, Jerry McAllister wrote: But, I wonder why you chose level 9 for your change dumps. It sort of defeats the system. It would be more normal to use level 1. I know that [some much] earlier versions of BSD dump only took levels up to 5, but I presume that since they include up to 9 in the documentation it should work. Only for historical reason. I'll try to change 9 to 1 ... but i don't think the problem will resolve. Thank you for the answer. Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Jerry McAllister wrote: But, I wonder why you chose level 9 for your change dumps. It sort of defeats the system. It would be more normal to use level 1. I know that [some much] earlier versions of BSD dump only took levels up to 5, but I presume that since they include up to 9 in the documentation it should work. If you only use one level other than 0, then it makes no difference what that level is: 1, 9, 5 anything but 0. A level N dumps everything since the last dump N, which in this case is always the last level 0. Using modified tower of hanoi (so the man page says :-)) can decrease the amount of data per dump at the cost of having to do more dumps: e.g. I do 0: 1 3 2 1 3 2 ... 0 ... But if I have to restore everything and the last dump was a 2, I have to restore the 0 1 and 2. Similarly if it crashed after 3, I would do 0 1 3. That cuts down the amount of data dumped, but is slightly more complex than just having to restore the 0 and last 9 (in the OPs case). I could use 1 7 9, or 4 6 8 instead of 1 2 3 and the data dumped would be the same in each case. I was pretty sure that BSD 4.2 had 9 incremental dump levels, but that was long, long ago in a universe of 1600bi tapes far, far away :-) --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
At 08.45 15/03/2006 -0500, Jerry McAllister wrote: But, I wonder why you chose level 9 for your change dumps. It sort of defeats the system. It would be more normal to use level 1. I know that [some much] earlier versions of BSD dump only took levels up to 5, but I presume that since they include up to 9 in the documentation it should work. Only for historical reason. I'll try to change 9 to 1 ... but i don't think the problem will resolve. Thank you for the answer. Yes, I do not think that is causing the problem either. But, it makes sense to check. Do check the preliminary dump output as it starts as someone else has suggested. It might have a clue. jerry Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Jerry McAllister wrote: But, I wonder why you chose level 9 for your change dumps. It sort of defeats the system. It would be more normal to use level 1. I know that [some much] earlier versions of BSD dump only took levels up to 5, but I presume that since they include up to 9 in the documentation it should work. If you only use one level other than 0, then it makes no difference what that level is: 1, 9, 5 anything but 0. A level N dumps everything since the last dump N, which in this case is always the last level 0. Of course, but then you limit yourself from moving to a level 2 or higher to accomodate an especially large change dump the day before. Using modified tower of hanoi (so the man page says :-)) can decrease the amount of data per dump at the cost of having to do more dumps: e.g. I do 0: 1 3 2 1 3 2 ... 0 ... But if I have to restore everything and the last dump was a 2, I have to restore the 0 1 and 2. Similarly if it crashed after 3, I would do 0 1 3. That cuts down the amount of data dumped, but is slightly more complex than just having to restore the 0 and last 9 (in the OPs case). I could use 1 7 9, or 4 6 8 instead of 1 2 3 and the data dumped would be the same in each case. The simplest, if you do a weekly full dump and daily change dumps is 0, 1, 2, 3, 4, 5, 6 but of course, that mean doing the most restores, though possibly smaller ones, of all the schemes. It doesn't work, of course, if you only do a monthly full dump and daily change dumps. I was pretty sure that BSD 4.2 had 9 incremental dump levels, but that was long, long ago in a universe of 1600bi tapes far, far away :-) I don't know just when it was, but back then I was working on vendor's proprietary flavors of BSD, so it could have been their particular flavor, although I am pretty sure they just took utilities like dump and simply recompiled and used them as is. jerry --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
At 14.16 15/03/2006 +, you wrote: Paolo Tealdi wrote: Anybody has any idea ? Show us the output of the dump command which didn't work as you expected. Right when it starts it tells you what level of dump it is doing and when it thinks the last relevant dump was. This may not be the problem, but it's the best place to start! anfitrione# dump 9SuLBf 10 - /home /backup/anfitrione/test.bck DUMP: Date of this level 9 dump: Wed Mar 15 15:34:41 2006 DUMP: Date of last level 0 dump: Sat Mar 11 19:40:24 2006 DUMP: Dumping snapshot of /dev/da0s1g (/home) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 57364771 tape blocks. S : does only an estimation of the tape blocks. This is the df output /dev/da0s1a 2536781589967438868%/ devfs 1 10 100%/dev /dev/da0s1h 38095704 26227564 1110622670%/dati /dev/da0s1g 91399912 57543202 3202871264%/home /dev/da0s1e 507630 298 466722 0%/tmp /dev/da0s1f 5077038 2866754 210874458%/usr /dev/da0s1d 507630 95858 37116221%/var /dev/gvinum/vinum0 276640510 179205196 9190250466%/backup Btw, I think your -B 10 is not the best way to go. Just use -a instead. When i created the script (LONG time ago), if remember well, i had problems with -a, resolved with -B 10 . Thanks for the help, Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dump level 9
Paolo Tealdi wrote: At 14.16 15/03/2006 +, you wrote: Paolo Tealdi wrote: Anybody has any idea ? Show us the output of the dump command which didn't work as you expected. Right when it starts it tells you what level of dump it is doing and when it thinks the last relevant dump was. This may not be the problem, but it's the best place to start! anfitrione# dump 9SuLBf 10 - /home /backup/anfitrione/test.bck DUMP: Date of this level 9 dump: Wed Mar 15 15:34:41 2006 DUMP: Date of last level 0 dump: Sat Mar 11 19:40:24 2006 DUMP: Dumping snapshot of /dev/da0s1g (/home) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 57364771 tape blocks. S : does only an estimation of the tape blocks. /dev/da0s1g 91399912 57543202 3202871264%/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 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? --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
