You can subscribe to this list here.
2000 |
Jan
(2) |
Feb
(15) |
Mar
(1) |
Apr
(11) |
May
(9) |
Jun
(22) |
Jul
(23) |
Aug
(21) |
Sep
(21) |
Oct
(7) |
Nov
(13) |
Dec
(58) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(20) |
Feb
(33) |
Mar
(24) |
Apr
(27) |
May
(48) |
Jun
(12) |
Jul
(35) |
Aug
(37) |
Sep
(41) |
Oct
(37) |
Nov
(29) |
Dec
(4) |
2002 |
Jan
(35) |
Feb
(17) |
Mar
(33) |
Apr
(65) |
May
(53) |
Jun
(43) |
Jul
(38) |
Aug
(37) |
Sep
(11) |
Oct
(25) |
Nov
(26) |
Dec
(38) |
2003 |
Jan
(44) |
Feb
(58) |
Mar
(16) |
Apr
(15) |
May
(11) |
Jun
(5) |
Jul
(70) |
Aug
(3) |
Sep
(25) |
Oct
(8) |
Nov
(16) |
Dec
(15) |
2004 |
Jan
(16) |
Feb
(27) |
Mar
(21) |
Apr
(23) |
May
(14) |
Jun
(16) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(17) |
Nov
(15) |
Dec
(44) |
2005 |
Jan
(37) |
Feb
(3) |
Mar
(7) |
Apr
(13) |
May
(14) |
Jun
(23) |
Jul
(7) |
Aug
(7) |
Sep
(12) |
Oct
(11) |
Nov
(11) |
Dec
(9) |
2006 |
Jan
(17) |
Feb
(8) |
Mar
(6) |
Apr
(14) |
May
(18) |
Jun
(16) |
Jul
(6) |
Aug
(1) |
Sep
(5) |
Oct
(12) |
Nov
(1) |
Dec
(1) |
2007 |
Jan
(3) |
Feb
(6) |
Mar
(6) |
Apr
|
May
|
Jun
(7) |
Jul
(8) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(8) |
Dec
(14) |
2008 |
Jan
(31) |
Feb
(3) |
Mar
(9) |
Apr
|
May
(15) |
Jun
(9) |
Jul
|
Aug
(13) |
Sep
(10) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
(11) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(9) |
Jul
(23) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(10) |
2011 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(5) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
From: ToddAndMargo <Tod...@zo...> - 2022-12-18 23:40:26
|
On 12/11/22 14:41, ToddAndMargo via Dump-users wrote: > Hi All, > > Fedora 36 and 37 > dump-0.4-0.49.b47.fc36.x86_64 > qemu-kvm-7.1.0-3.fc36.x86_64 > ext4 file system > > I have an absolute disaster on my hands. Dump does not properly > restoring my sparse qemu-kvm qcows2 drives. I frequently restored my > qcows2 drive after goofing my Windows Virtual Machines' (VM's) with > updates (have to simulate what my customers see). All VM's were off > during the dump backup. > > gparted sees (booting the VM off a live iso) the restored drive as a > blank drive. > > In the following, the qcows2 file whit the date on the end is the good > file. The one without the date is the restored file: > > ls -al KVM-W11.qcow2 KVM-W11.qcow2_2022-12-11 > -rw-r--r--. 1 qemu qemu 33615708160 Dec 8 02:28 KVM-W11.qcow2 > -rw-r--r--. 1 qemu qemu 33615708160 Dec 8 02:28 KVM-W11.qcow2_2022-12-11 > > sha256sum KVM-W11.qcow2 KVM-W11.qcow2_2022-12-11 > 2ed61cdbb654c5a6c69200d5531a5147653561c13f75944fb1086d9c80fcd96b > KVM-W11.qcow2 > 05c48a0994a8c6f748e218104c7a6fd9117b4de357a97c51704ed74082c26f04 > KVM-W11.qcow2_2022-12-11 > > As you can see, they are the same size but not the same contents! > > This was the restore command: > restore -if /lin-bak/2022-12-10_rootExt4Dump.gz > > Any words of wisdom? > > Many thanks, > -T I eventually converted all my qcows drives over to raw drives and that cured the problem. But I'd still like to know is there is any way to get dump to backup a qcows sparse file. |
From: ToddAndMargo <Tod...@zo...> - 2022-12-11 22:41:53
|
Hi All, Fedora 36 and 37 dump-0.4-0.49.b47.fc36.x86_64 qemu-kvm-7.1.0-3.fc36.x86_64 ext4 file system I have an absolute disaster on my hands. Dump does not properly restoring my sparse qemu-kvm qcows2 drives. I frequently restored my qcows2 drive after goofing my Windows Virtual Machines' (VM's) with updates (have to simulate what my customers see). All VM's were off during the dump backup. gparted sees (booting the VM off a live iso) the restored drive as a blank drive. In the following, the qcows2 file whit the date on the end is the good file. The one without the date is the restored file: ls -al KVM-W11.qcow2 KVM-W11.qcow2_2022-12-11 -rw-r--r--. 1 qemu qemu 33615708160 Dec 8 02:28 KVM-W11.qcow2 -rw-r--r--. 1 qemu qemu 33615708160 Dec 8 02:28 KVM-W11.qcow2_2022-12-11 sha256sum KVM-W11.qcow2 KVM-W11.qcow2_2022-12-11 2ed61cdbb654c5a6c69200d5531a5147653561c13f75944fb1086d9c80fcd96b KVM-W11.qcow2 05c48a0994a8c6f748e218104c7a6fd9117b4de357a97c51704ed74082c26f04 KVM-W11.qcow2_2022-12-11 As you can see, they are the same size but not the same contents! This was the restore command: restore -if /lin-bak/2022-12-10_rootExt4Dump.gz Any words of wisdom? Many thanks, -T -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computers are like air conditioners. They malfunction when you open windows ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
From: SZYMCZAK J. - E. Val./D. S. et Développement/P. i. <Jer...@de...> - 2020-06-17 09:56:11
|
Good morning We're looking for some help on dump/restore commands on our Ubuntu server references : Ubuntu 18.04 LTS x64, kernel 4.15.0-106-generic dump:amd64/bionic 0.4b46-3 We can perform dump and restore commands on parts of our filesystem. Files, directories, Linux rights are correctly restored. We've noticed a problem with Access Control Lists : files' ACLs are correctly restored, but not for directories. Example of ACLs on a directory before dump : /# owner: root// //# group: ENTE-ENS/domain admins// //user::rwx// //user:20000:rwx// //user:ENTE-ENS/jeremy.szymczak-smb:rwx// //group::r-x// //group:20000:rwx// //group:ENTE-ENS/admins-xp-ens:rwx// //mask::rwx// //other::r-x// //default:user::rwx// //default:user:20000:rwx// //default:user:ENTE-ENS/jeremy.szymczak-smb:rwx// //default:group::r-x// //default:group:20000:rwx// //default:group:ENTE-ENS/admins-xp-ens:rwx// //default:mask::rwx// //default:other::r-x// / Example of ACLs after restore : /# owner: root// //# group: ENTE-ENS/domain admins// //user::rwx// //group::r-x// //mask::rwx// //other::r-x/ Command used to dump : /dump -0 -A $PATH_ARCH/$BAK_NAME.arc -L "$BAK_NAME" -f /dev/st0 $SAV1 / (the variables are correctly defined at the beginning of the script) Command used to restore : /restore -io -A $PATH_ARCH/$BAK_NAME.arc -f /dev/st0/ The same command without the -o option gives the same result. Have we missed something in the dump/restore behavior ? Or in the parameters to use ? Thanks a lot -- *Jérémy SZYMCZAK** *École nationale des techniciens de l’équipement Direction de la stratégie et du développement Politique informatique et systèmes d'informations Site de Valenciennes Tél : 03 27 23 73 95 <tel:03%2027%2023%2073%2095> |
From: Abner G. <67...@gm...> - 2016-05-02 01:16:09
|
I am a relatively recent user of dump and am looking for some confirmation that I understand this application correctly as some of it seems a bit unusual. I have spent some time studying on blocks vs records with regards to such programs as tar, dd, and more recently dump. There are several features of dump that are a bit confusing in this regard. I should say that I am using version 0.4b44 under Debian linux. Here is a portion of the dump output: DUMP: Label: xyz DUMP: Writing 512 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 91547938 blocks. DUMP: Volume 1 started with block 1 at: Sun May 1 12:29:52 2016 DUMP: 0.00% done, finished in 0:00 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 21.45% done at 65448 kB/s, finished in 0:18 DUMP: 42.84% done at 65372 kB/s, finished in 0:13 DUMP: 69.20% done at 70388 kB/s, finished in 0:06 DUMP: Closing /dev/nst0 DUMP: Volume 1 completed at: Sun May 1 12:49:20 2016 DUMP: Volume 1 91489792 blocks (89345.50MB) DUMP: Volume 1 took 0:19:28 DUMP: Volume 1 transfer rate: 78330 kB/s 1. Dump announces that it is using 512 K record size but then gives completion information in number of 1 K blocks. Dump writes 512 one kilobyte blocks to each record. Why not just announce result as "91489792 kB" rather than "91489792 blocks" or better yet provide number of records written to tape? Was this of some historic significance? 2. Is it possible to alter the block size to something larger than 1 K? Does not appear to be the case or at least not documented in man page. 3. Option -b is referred to in man page as "blocksize" but it really sets the record size. This does however directly relate to bs= option of dd command. 4. Option -B is referred to as "records" but it is really asking to specify the number of 1 K blocks that can fit on the tape. 5. There might be value in recording the number of records in the dump for verification or data recovery purposes but dump does not provide this info directly. The size of the dump is output in kB and MB. From these numbers the number of records can be calculated assuming there are no extra records created for headers or at end of the dump file. Does anyone bother tracking number of records per dump? I usually just record the MB. Lastly, I want to say thank you to the authors, maintainers, and other contributors as I am greatly appreciative for this useful application. Regards, Abner |
From: Abner G. <67...@gm...> - 2016-04-20 00:00:20
|
I am a relatively new user of dump. Previously I had been using tar to back up data to tape. I keep a small database where I manually record some basic info about each backup such as a brief description of the content of the archive, file number on tape, tape number, size in MB, and transfer rate. I also note the backup in my paper planner just in case. I am wondering if there would be significant value in recording the number of blocks written to tape as reported by dump? I could see this possibly being of value in the case of a corrupt tape, maybe? Maybe of use to verify the integrity of the archive? Has anyone found this information useful in any regard? |
From: Nazarov S. <s-n...@ya...> - 2015-07-15 19:27:08
|
Hello! I've a problem with dump/restore extended attributes on ext3/4 filesystems with inode size more than 128b: xattr's of regular files restored correctly, but directories lose some of it's xattr's (I guess - xattr's located inside of inode itself). Thanks. |
From: Al F. <al...@af...> - 2015-03-26 21:53:24
|
Hello: I've been trying to run restore against a 500GB dump file which eventually fails with the following message: /sbin/restore: cannot write to file /tmp//rstmode1404204895-fhRwaN No space left on device I'm using restore version 0.4b44 off a CentOS 7.01406 livecd and libext2fs 1.42.9 Has anymore come across something similiar and were you able to workaround it? Many thanks. |
From: Aaron S. H. <aar...@gm...> - 2014-07-09 19:36:32
|
Didn't you ask this last year? http://sourceforge.net/p/dump/mailman/search/?q=xfs On Wed, Jul 9, 2014 at 3:30 PM, MargoAndTodd <mar...@gm...> wrote: > Hi All, > > "Supposedly" Red Hat Enterprise Linux 7 is supporting XFS by > default. Will this cause any problems for Dump and > Restore? > > -T > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > Dump-users mailing list > Dum...@li... > https://lists.sourceforge.net/lists/listinfo/dump-users -- In general, we reserve the right to have a poor memory--the computer, however, is supposed to remember! Poor computer. -- Guy Lewis Steele Jr. |
From: MargoAndTodd <mar...@gm...> - 2014-07-09 19:30:03
|
Hi All, "Supposedly" Red Hat Enterprise Linux 7 is supporting XFS by default. Will this cause any problems for Dump and Restore? -T |
From: Petr H. <ph...@re...> - 2013-08-08 14:34:54
|
Hi, I have just a question whether btrfs file system is supported or not? If not will dump support it? -- Best regards / S pozdravem Petr Hracek |
From: Aaron S. H. <aar...@gm...> - 2013-07-27 21:31:32
|
> Does it have a mailing list? Seems xfsdump is discussed on the XFS mailing list: http://oss.sgi.com/archives/xfs/ And is maintained in its own Git repo: http://xfs.org/index.php/Getting_the_latest_source_code |
From: MargoAndTodd <mar...@gm...> - 2013-07-26 20:36:17
|
>> On Fri, Jul 26, 2013 at 1:17 PM, MargoAndTodd <mar...@gm... >> <mailto:mar...@gm...>> wrote: >> >> On 07/25/2013 01:23 PM, Berend de Boer wrote: >> >>>>>> "MargoAndTodd" == MargoAndTodd <mar...@gm... >> <mailto:mar...@gm...>> writes: >> > >> > MargoAndTodd> Hi, I just learned that Red Hat Enterprise >> Linux 7.x >> > MargoAndTodd> is going to use the xfs file system by default. >> > MargoAndTodd> Will dump support it? >> > >> > No. You need to use xfsdump. >> > >> > -- >> > All the best, >> > >> > Berend de Boer >> >> Hi Berend, >> >> Will xfsdump be supported by this mailing list? >> >> And, will all the command line parameters be the same? >> >> Many thanks, >> -T On 07/26/2013 12:03 PM, Bruce Hyatt wrote:> xfsdump man page <http://linux.die.net/man/8/xfsdump> > > Bruce Hyatt > > Thank you! Does it have a mailing list? |
From: MargoAndTodd <mar...@gm...> - 2013-07-26 17:17:41
|
On 07/25/2013 01:23 PM, Berend de Boer wrote: >>>>>> "MargoAndTodd" == MargoAndTodd <mar...@gm...> writes: > > MargoAndTodd> Hi, I just learned that Red Hat Enterprise Linux 7.x > MargoAndTodd> is going to use the xfs file system by default. > MargoAndTodd> Will dump support it? > > No. You need to use xfsdump. > > -- > All the best, > > Berend de Boer Hi Berend, Will xfsdump be supported by this mailing list? And, will all the command line parameters be the same? Many thanks, -T |
From: Berend de B. <be...@po...> - 2013-07-25 20:23:57
|
>>>>> "MargoAndTodd" == MargoAndTodd <mar...@gm...> writes: MargoAndTodd> Hi, I just learned that Red Hat Enterprise Linux 7.x MargoAndTodd> is going to use the xfs file system by default. MargoAndTodd> Will dump support it? No. You need to use xfsdump. -- All the best, Berend de Boer ------------------------------------------------------ Awesome Drupal hosting: https://www.xplainhosting.com/ |
From: MargoAndTodd <mar...@gm...> - 2013-07-25 16:03:39
|
Hi, I just learned that Red Hat Enterprise Linux 7.x is going to use the xfs file system by default. Will dump support it? Many thanks, -T |
From: Marc T. <ma...@dr...> - 2013-03-06 17:44:22
|
Thanks- I'll pass that on to the Slackware devs. Kind Regards, Marc On 04/03/13 21:11, Phillip Susi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 3/4/2013 3:42 PM, Marc Thomas wrote: >> I finally figured this out. On Slackware64 14.0 (and 13.37 most >> likely), in order to compile dump-0.4b44, one must: export >> EXT2FS_LIBS="-lext2fs -lcom_err" >> >> before building. It seems that configure now relies on the output >> of "pkg-config --libs <package>" to get some of the flags, and in >> my case the com_err library is never specified. FWIW, "pkg-config >> --libs ext2fs" returns: "-L/lib64 -lext2fs" on this system. > Then slackware's e2fsprogs-dev package is broken. Specifically it's > pkg-config file is missing that flag. > > This is probably due to the still somewhat recent changes in gcc. You > used to be able to get away with just linking to ext2fs, and gcc would > see that it imports com_err, and link that as well. This was a bug > and gcc no longer does this so you have to explicitly link the other lib. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJRNQ4cAAoJEJrBOlT6nu75pQIIAMvq0WPHbpeRAKgCmUIBEGMh > gAU5tjGsyVh2ABYWQp8H628C7f5eXyVnSn7gnEXSrAnBx79RdocHXGNieMVuAQ90 > VHLlQF4ZcRPQHY3etVKUUg6rxHZVmp+AaNMBaNzTPlt2iOY0jgx/kw8BcWQJ/HH8 > hnpVR3A5nunF+MtfPYWdxxEnfOm+D/SEbW29p6zSUJGwe/yXuMJ4l9PUB+/T9Xdf > JvXhlAH60UJgjFAh+4xU/s8lAN2PJegPRMwGJBgngLkUKSK4TvwZ2+qoMpTPAU2/ > TvYInKI8y5/v8vGlDObEp7ntnPBMGUa2aaZcD9qrVdQsI3L0WDenenw1S/+EWbY= > =7wrs > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Dump-devel mailing list > Dum...@li... > https://lists.sourceforge.net/lists/listinfo/dump-devel > |
From: Marc T. <ma...@dr...> - 2013-03-04 20:57:09
|
I finally figured this out. On Slackware64 14.0 (and 13.37 most likely), in order to compile dump-0.4b44, one must: export EXT2FS_LIBS="-lext2fs -lcom_err" before building. It seems that configure now relies on the output of "pkg-config --libs <package>" to get some of the flags, and in my case the com_err library is never specified. FWIW, "pkg-config --libs ext2fs" returns: "-L/lib64 -lext2fs" on this system. Kind Regards, Marc On 30/07/12 19:06, Marc Thomas wrote: > Hi All, > > I've never had a problem building dump before, but 0.4b44 doesn't > compile for me. 0.4b43 builds fine - I just rebuilt it for a sanity check. > > Distribution: > Slackware Linux 13.37.0 > > Platform: > Linux anvil 2.6.37.6 #2 SMP Sat Apr 9 13:24:51 CDT 2011 x86_64 AMD > Phenom(tm) 9850 Quad-Core Processor AuthenticAMD GNU/Linux > > GCC version: > gcc (GCC) 4.5.2 > > Configure command: > ./configure --with-binowner=root --with-bingrp=root --with-manowner=root > --with-mangrp=root --mandir=/usr/local/man --disable-transselinux > > Failure log: > marc@anvil:~/xxBuildxx/dump/dump-0.4b44$ make > for i in compat/lib compat/include common dump restore rmt; do \ > (cd $i && make all) || exit 1; \ > done > make[1]: Entering directory > `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/lib' > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. > -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et > -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" compaterr.c -o compaterr.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. > -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et > -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" compatglob.c -o compatglob.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. > -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et > -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" bylabel.c -o bylabel.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. > -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et > -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" system.c -o system.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. > -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et > -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" rmtflags.c -o rmtflags.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. > -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et > -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" minilzo.c -o minilzo.o > ar r libcompat.a compaterr.o compatglob.o bylabel.o system.o rmtflags.o > minilzo.o > ar: creating libcompat.a > ranlib libcompat.a > make[1]: Leaving directory > `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/lib' > make[1]: Entering directory > `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/include' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory > `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/include' > make[1]: Entering directory `/home/marc/xxBuildxx/dump/dump-0.4b44/common' > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" dumprmt.c -o dumprmt.o > make[1]: Leaving directory `/home/marc/xxBuildxx/dump/dump-0.4b44/common' > make[1]: Entering directory `/home/marc/xxBuildxx/dump/dump-0.4b44/dump' > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" itime.c -o itime.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" main.c -o main.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" optr.c -o optr.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" tape.c -o tape.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" traverse.c -o traverse.o > gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. > -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump > -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO > -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" > -D_DUMP_VERSION=\"0.4b44\" unctime.c -o unctime.o > gcc -o dump itime.o main.o optr.o tape.o traverse.o unctime.o > ../common/dumprmt.o -L../compat/lib -lcompat -L/lib64 -lext2fs -lz > -lbz2 -lblkid -luuid > main.o: In function `main': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/main.c:726: undefined > reference to `com_err' > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/main.c:719: undefined > reference to `com_err' > tape.o: In function `doslave': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/tape.c:1197: undefined > reference to `error_message' > traverse.o: In function `dump_xattr': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:813: undefined > reference to `com_err' > traverse.o: In function `dumpdirino': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:1143: undefined > reference to `com_err' > traverse.o: In function `getino': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:1371: undefined > reference to `com_err' > traverse.o: In function `mapfilesfromdir': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:501: undefined > reference to `com_err' > traverse.o: In function `maponefile': > /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:411: undefined > reference to `com_err' > traverse.o:/home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:340: > more undefined references to `com_err' follow > /lib64/libext2fs.a(ext2_err.o): In function `initialize_ext2_error_table': > ext2_err.c:(.text+0x83): undefined reference to `_et_list' > /lib64/libext2fs.a(alloc_stats.o): In function `ext2fs_inode_alloc_stats2': > alloc_stats.c:(.text+0x121): undefined reference to `com_err' > /lib64/libext2fs.a(alloc_stats.o): In function `ext2fs_block_alloc_stats': > alloc_stats.c:(.text+0x231): undefined reference to `com_err' > /lib64/libext2fs.a(gen_bitmap.o): In function `ext2fs_warn_bitmap2': > gen_bitmap.c:(.text+0x19f): undefined reference to `com_err' > gen_bitmap.c:(.text+0x1be): undefined reference to `com_err' > /lib64/libext2fs.a(bitops.o): In function `ext2fs_warn_bitmap': > bitops.c:(.text+0x9a): undefined reference to `com_err' > /lib64/libext2fs.a(bitops.o):bitops.c:(.text+0xb2): more undefined > references to `com_err' follow > collect2: ld returned 1 exit status > make[1]: *** [dump] Error 1 > make[1]: Leaving directory `/home/marc/xxBuildxx/dump/dump-0.4b44/dump' > make: *** [all] Error 1 > marc@anvil:~/xxBuildxx/dump/dump-0.4b44$ > > > Any ideas? > > TIA, > Marc > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Dump-users mailing list > Dum...@li... > https://lists.sourceforge.net/lists/listinfo/dump-users > |
From: gnafou <fmg...@ya...> - 2012-11-19 13:29:04
|
Hello We are having some problems with dump : dump outputs numerous ' DUMP: bread: lseek fails ' We have been unable to figure why some dump work properly and why some output the previous message ( hundred of times ) . Context : debian squeeze i386 e2fsprogs 1.41.12-4stable1 libc6 2.11.3-4 We have LVM ext3 filesystems mounted on '/mnt/repos' on this filesystem we have files which are kvm raw images these raw images contain a ext3 partition that we want to backup process: we 'snapshot' the /mnt/repos logical volume we mount the snapshotted logical volume to access ( frozen) kvm raw-files we access the ext3 filesystem from the kvm raw-files with losetup and kpartx we dump the /dev/mapper/loop0p1 device , writing the dumpfile to a disk I do not really know what to look for to understand what is causing the DUMP: bread: lseek fails message ( tested with debian 0.4b43 as well as copiled 0.4b44 ) LOG DUMP: Date of this level 0 dump: Mon Nov 19 02:51:46 2012 DUMP: Date of last level ? dump: Fri Nov 16 14:17:00 2012 DUMP: Dumping /dev/mapper/loop0p1 (an unlisted file system) to /mnt/backup/KVM017-2012.11.19-02.51.dump3 DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: Compressing output at compression level 2 (bzlib) DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 275086 blocks. DUMP: Volume 1 started with block 1 at: Mon Nov 19 02:51:51 2012 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: bread: lseek fails ( about 1300 times) DUMP: bread: lseek fails DUMP: Closing /mnt/backup/KVM017-2012.11.19-02.51.dump3 DUMP: Volume 1 completed at: Mon Nov 19 02:52:44 2012 DUMP: Volume 1 took 0:00:53 DUMP: Volume 1 transfer rate: 2188 kB/s DUMP: Volume 1 276210kB uncompressed, 115991kB compressed, 2.382:1 DUMP: 276210 blocks (269.74MB) on 1 volume(s) DUMP: finished in 53 seconds, throughput 5211 kBytes/sec DUMP: Date of this level 0 dump: Mon Nov 19 02:51:46 2012 DUMP: Date this dump completed: Mon Nov 19 02:52:44 2012 DUMP: Average transfer rate: 2188 kB/s DUMP: Wrote 276210kB uncompressed, 115991kB compressed, 2.382:1 DUMP: DUMP IS DONE |
From: Marc T. <ma...@dr...> - 2012-07-30 18:21:18
|
Hi All, I've never had a problem building dump before, but 0.4b44 doesn't compile for me. 0.4b43 builds fine - I just rebuilt it for a sanity check. Distribution: Slackware Linux 13.37.0 Platform: Linux anvil 2.6.37.6 #2 SMP Sat Apr 9 13:24:51 CDT 2011 x86_64 AMD Phenom(tm) 9850 Quad-Core Processor AuthenticAMD GNU/Linux GCC version: gcc (GCC) 4.5.2 Configure command: ./configure --with-binowner=root --with-bingrp=root --with-manowner=root --with-mangrp=root --mandir=/usr/local/man --disable-transselinux Failure log: marc@anvil:~/xxBuildxx/dump/dump-0.4b44$ make for i in compat/lib compat/include common dump restore rmt; do \ (cd $i && make all) || exit 1; \ done make[1]: Entering directory `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/lib' gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" compaterr.c -o compaterr.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" compatglob.c -o compatglob.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" bylabel.c -o bylabel.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" system.c -o system.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" rmtflags.c -o rmtflags.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I../.. -I../../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../../compat/include -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" minilzo.c -o minilzo.o ar r libcompat.a compaterr.o compatglob.o bylabel.o system.o rmtflags.o minilzo.o ar: creating libcompat.a ranlib libcompat.a make[1]: Leaving directory `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/lib' make[1]: Entering directory `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/marc/xxBuildxx/dump/dump-0.4b44/compat/include' make[1]: Entering directory `/home/marc/xxBuildxx/dump/dump-0.4b44/common' gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" dumprmt.c -o dumprmt.o make[1]: Leaving directory `/home/marc/xxBuildxx/dump/dump-0.4b44/common' make[1]: Entering directory `/home/marc/xxBuildxx/dump/dump-0.4b44/dump' gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" itime.c -o itime.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" main.c -o main.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" optr.c -o optr.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" tape.c -o tape.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" traverse.c -o traverse.o gcc -c -D_BSD_SOURCE -D_USE_BSD_SIGNAL -g -O2 -pipe -I.. -I../compat/include -I/usr/include/ext2fs -I/usr/include/et -I../dump -DRDUMP -DRRESTORE -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/usr/local/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b44\" unctime.c -o unctime.o gcc -o dump itime.o main.o optr.o tape.o traverse.o unctime.o ../common/dumprmt.o -L../compat/lib -lcompat -L/lib64 -lext2fs -lz -lbz2 -lblkid -luuid main.o: In function `main': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/main.c:726: undefined reference to `com_err' /home/marc/xxBuildxx/dump/dump-0.4b44/dump/main.c:719: undefined reference to `com_err' tape.o: In function `doslave': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/tape.c:1197: undefined reference to `error_message' traverse.o: In function `dump_xattr': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:813: undefined reference to `com_err' traverse.o: In function `dumpdirino': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:1143: undefined reference to `com_err' traverse.o: In function `getino': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:1371: undefined reference to `com_err' traverse.o: In function `mapfilesfromdir': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:501: undefined reference to `com_err' traverse.o: In function `maponefile': /home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:411: undefined reference to `com_err' traverse.o:/home/marc/xxBuildxx/dump/dump-0.4b44/dump/traverse.c:340: more undefined references to `com_err' follow /lib64/libext2fs.a(ext2_err.o): In function `initialize_ext2_error_table': ext2_err.c:(.text+0x83): undefined reference to `_et_list' /lib64/libext2fs.a(alloc_stats.o): In function `ext2fs_inode_alloc_stats2': alloc_stats.c:(.text+0x121): undefined reference to `com_err' /lib64/libext2fs.a(alloc_stats.o): In function `ext2fs_block_alloc_stats': alloc_stats.c:(.text+0x231): undefined reference to `com_err' /lib64/libext2fs.a(gen_bitmap.o): In function `ext2fs_warn_bitmap2': gen_bitmap.c:(.text+0x19f): undefined reference to `com_err' gen_bitmap.c:(.text+0x1be): undefined reference to `com_err' /lib64/libext2fs.a(bitops.o): In function `ext2fs_warn_bitmap': bitops.c:(.text+0x9a): undefined reference to `com_err' /lib64/libext2fs.a(bitops.o):bitops.c:(.text+0xb2): more undefined references to `com_err' follow collect2: ld returned 1 exit status make[1]: *** [dump] Error 1 make[1]: Leaving directory `/home/marc/xxBuildxx/dump/dump-0.4b44/dump' make: *** [all] Error 1 marc@anvil:~/xxBuildxx/dump/dump-0.4b44$ Any ideas? TIA, Marc |
From: Steve B. <fb7...@sn...> - 2012-06-01 16:32:06
|
I've been wrestling with some data corruption from my cheap LSI Logic RAID5 controller (Dell PERC 5/i). Using "restore -C" has been a great way to identify which files are mangled so I don't need to run a full restore, possibly overwriting files that were intentionally changed. However, it was fairly difficult to tell from the existing output of "restore" which files were intentionally changed and which files had been unintentionally changed. I was working on a script to review all the changed files and look for mtime/ctime discrepancies when I realized that there was an even better way-- the restore program itself could do what I wanted with only a little tweaking. (Thank you, Open Source!) If any of you are interested in this new feature, I've uploaded the patch to Sourceforge here: https://sourceforge.net/tracker/?func=detail&aid=3531220&group_id=1306&atid=301306 The only change to default operation is this warning when the file on disk has changed but has the same mtime as the dump: fprintf(stderr,"%s: file contents differ but mtime does not. File may be corrupted.\n", name); I added a couple other changes that are only visible when using "-v", these are: 1) Print an informational description if the file contents differ and so does the mtime: Vprintf(stdout, "%s: file contents and mtime both differ. This was probably an intentional change. (file: %ld, dump: %ld)\n", name, sb.st_mtime, timep[1].tv_sec ); 2) Change the "comparing %s" line to also print atime/ctime/mtime in case I want to run an external analysis of the times. Since this is only printed when the user has specifically requested verbose output, I didn't see the harm in making it truly verbose. Vprintf(stdout, "comparing %s (size: %lld, mode: 0%o, atime: %ld, ctime: %ld, mtime: %ld)\n", name, (long long)sb.st_size, mode, sb.st_atime, sb.st_ctime, sb.st_mtime ); I don't see any harm in adding these features to the mainstream "restore", but I'd also like for someone to review the patch for bonehead C programming errors first. :-) -- Steve Bonds |
From: Christoph H. <ch...@ra...> - 2012-03-14 17:39:25
|
I found out that this does not happen with dump-0.4b42. Regards, Christoph |
From: Christoph H. <ch...@ra...> - 2012-03-14 17:37:12
|
Hi, I have the same problem as Hendrik Hoeth mentioned in his mail from august 23, 2011. When a directory is removed and an incremental backup is then done, restoring the incremental backup fails. From his mail: ---------- cut here ---------- ## /tmp/testing is a fresh ext3 or ext4 file system mkdir /tmp/testing/foobar dump -u -f /tmp/level0.dump /tmp/testing/ rmdir /tmp/testing/foobar dump -1 -u -f /tmp/level1.dump /tmp/testing/ restore -rf /tmp/level0.dump restore -rf /tmp/level1.dump The second restore fails with "deleteino: out of range 0" and asks me if I want to abort. If I say no, I'm asked again, and after saying "n" again restore starts using 100% CPU forever. If I abort, the foobar directory is gone, but I have a directory called something like RSTTMP01977. ---------- cut here ---------- Same thing happens here. I created a loopback ext3 file system and mounted (readonly for the dumps) at /tmp/testing. My system is x86_64 ubuntu oneiric. Regards, Christoph |
From: Bob B. Jr. <bl...@da...> - 2012-02-23 14:04:56
|
Thanks for the suggestion.. using buffer, our larger file systems maintain an average throughput of around 31 MB/s. Just using dump direct to tape, the same file system was averaging only 16 MB/s. dump -0uf - $FS_NAME | buffer | dd obs=1M of=/dev/nst0 DUMP: Date of this level 0 dump: Tue Feb 21 23:12:00 2012 DUMP: Dumping /dev/sda1 (/home) to standard output DUMP: Label: none DUMP: Writing 10 Kilobyte records DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 175538832 blocks. DUMP: Volume 1 started with block 1 at: Tue Feb 21 23:12:08 2012 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 4.58% done at 26821 kB/s, finished in 1:44 DUMP: 10.51% done at 30750 kB/s, finished in 1:25 DUMP: 15.37% done at 29982 kB/s, finished in 1:22 DUMP: 21.89% done at 31963 kB/s, finished in 1:11 DUMP: 30.82% done at 36013 kB/s, finished in 0:56 DUMP: 35.73% done at 34804 kB/s, finished in 0:54 DUMP: 41.75% done at 34865 kB/s, finished in 0:48 DUMP: 46.14% done at 33719 kB/s, finished in 0:46 DUMP: 50.72% done at 32948 kB/s, finished in 0:43 DUMP: 56.23% done at 32878 kB/s, finished in 0:38 DUMP: 62.16% done at 33044 kB/s, finished in 0:33 DUMP: 67.11% done at 32703 kB/s, finished in 0:29 DUMP: 71.28% done at 32068 kB/s, finished in 0:26 DUMP: 76.26% done at 31859 kB/s, finished in 0:21 DUMP: 80.57% done at 31415 kB/s, finished in 0:18 DUMP: 84.47% done at 30878 kB/s, finished in 0:14 DUMP: 89.15% done at 30672 kB/s, finished in 0:10 DUMP: 94.93% done at 30848 kB/s, finished in 0:04 DUMP: 99.12% done at 30514 kB/s, finished in 0:00 DUMP: Volume 1 completed at: Wed Feb 22 00:48:12 2012 DUMP: Volume 1 175145930 blocks (171040.95MB) DUMP: Volume 1 took 1:36:04 DUMP: Volume 1 transfer rate: 30386 kB/s DUMP: 175145930 blocks (171040.95MB) DUMP: finished in 5764 seconds, throughput 30386 kBytes/sec DUMP: Date of this level 0 dump: Tue Feb 21 23:12:00 2012 DUMP: Date this dump completed: Wed Feb 22 00:48:12 2012 DUMP: Average transfer rate: 30386 kB/s DUMP: DUMP IS DONE 350291860+0 records in 171040+1 records out 179349432320 bytes (179 GB) copied, 5760.42 s, 31.1 MB/s On Tue, 2012-02-14 at 21:15 +0000, dk...@ly... wrote: > > All interfaces are SAS, I can do dd reads from tape at 150 MB/s from > both > > systems. > > > > Trying to determine if this is kernel related (st module) or dump > related > > or ext3/4 related. > > Have you tried using some buffering between the dump program and the > tape? > Something like > > <dump'n'all> | dd ibs=512 obs=1M of=$TAPE > > so dump doesn't need to wait for the tape to confirm that the block > had been > written, dd does that and less often. Tapes should acknowledge > the block as > soon as it's been received in the cache, before really committing it > to tape, > but even that "as soon as" may be stalling the process for some > reason. > > There is a utility called "buffer" which is supposed to do the > buffering with > more options. Try it and and let us know if it speeds up the dump > backup in > your case. > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ Dump-users mailing list Dum...@li... https://lists.sourceforge.net/lists/listinfo/dump-users |
From: <dk...@ly...> - 2012-02-14 21:15:37
|
<html><HEAD><LINK rel=stylesheet type=text/css href="/webmail/static/deg/css/wysiwyg-3451203449.css" media=all> <META name=GENERATOR content="MSHTML 9.00.8112.16440"></HEAD> <BODY> <DIV>> All interfaces are SAS, I can do dd reads from tape at 150 MB/s from both<BR>> systems.<BR>><BR>> Trying to determine if this is kernel related (st module) or dump related<BR>> or ext3/4 related.<BR></DIV> <DIV>Have you tried using some buffering between the dump program and the tape? </DIV> <DIV>Something like </DIV> <DIV> </DIV> <DIV> <dump'n'all> | dd ibs=512 obs=1M of=$TAPE</DIV> <DIV> </DIV> <DIV>so dump doesn't need to wait for the tape to confirm that the block had been </DIV> <DIV>written, dd does that and less often. Tapes should acknowledge the block as </DIV> <DIV>soon as it's been received in the cache, before really committing it to tape, </DIV> <DIV>but even that "as soon as" may be stalling the process for some reason.</DIV> <DIV> </DIV> <DIV>There is a utility called "buffer" which is supposed to do the buffering with </DIV> <DIV>more options. Try it and and let us know if it speeds up the dump backup in </DIV> <DIV>your case. </DIV></BODY></html> |
From: resoli - s. <re...@us...> - 2012-02-14 16:08:51
|
Il giorno gio, 18/08/2011 alle 17.52 +0200, resoli - sourceforge ha scritto: > .. > > Incorrect block for <file1 path> at 1588999555 blocks > > Incorrect block for <file1 path> at 1588999556 blocks > > *** so on for same file1 on many consecutive blocks *** > > Incorrect block for <file1 path> at 1589000042 blocks > > Missing blocks at the end of <file1 path>, assuming hole > > <file2 path>: (inode 122169539) not found on tape > > <file3 path>: (inode 122169540) not found on tape > > ... > > ======== > > > > To my surprise, "restore -x -a -Q" , using the genereted QFA file, > > correctly restores these three files without problems from third volume, > > swapping directly from first to third volume. > > > > I post here also the relevant fragment of QFA file, near the boundary > > between second and third volume: > > > > ======== > > ... > > 122169536 2 775829 > > 122169537 2 775831 > > 122169537 3 1 > > 122169539 3 3 > > 122169540 3 5 > > 122169541 3 7 > > 122169543 3 8 > > ... > > ======== > > I forgot to add the log fragment from dump: > > ========== > ... > DUMP: Volume 3 started with block 1588986880 at: Tue Aug 16 10:07:05 > 2011 > DUMP: Volume 3 begins with blocks from inode 122169536 > ... > ========== > > It seems that informations from dump log are not congruent with QFA > ones: dump log says that part of inode 122169536 is on volume 3, QFA > records his position only on volume 2. Only to revamp the question ... Any hint? bye, rob |