Menu
▾
▴
dump-users
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: Bernhard R. E. <be...@be...> - 2000-09-14 12:20:43
|
Peter Biechele wrote: > > Is there an easy way of excluding Files or directories from a Level 0 > Dump on a filesystem ?? > > As I understood, the chattr with the +d Option does only exclude the > files from incremental dumps. Use dump -h0, see man dump. > PS: I am using Suse 6.4 with dump 0.4b16 ! Lots of bugs have been fixed, use at least 0.4b18. The SRPM of 0.4b19 won't compile with your rpm 3.0.4. AFAIK SuSE hasn't released yet rpm 3.0.5, which is required for dump's 0.4b19 SRPM. |
|
From: Peter B. <Pet...@be...> - 2000-09-14 09:18:35
|
Is there an easy way of excluding Files or directories from a Level 0 Dump on a filesystem ?? As I understood, the chattr with the +d Option does only exclude the files from incremental dumps. Thank You for any help ! PS: I am using Suse 6.4 with dump 0.4b16 ! Peter Biechele -- Dr. Peter Biechele Tel.: +49 7641 920869 41 beXtec GmbH Fax: +49 7641 920869 49 Kaiserstuhlstr. 3, 79312 Emmendingen E-Mail: Pet...@be... |
|
From: Eros A. <er...@la...> - 2000-09-09 07:29:44
|
Stelian Pop wrote: > > dump doesn't truncate the file upon opening. > > I'd say that you already had a file of that size before starting the dump. > > Is this true ? You're absolutly right.... sorry but I was not aware of that, I'll add a remove to my script.. Thanks and Regards. -- Eros Albertazzi CNR-LAMEL, Via P.Gobetti 101, 40129 Bologna, Italy Tel: (+39)-051-639 9179 Fax: (+39)-051-639 9216 E-mail: er...@la... |
|
From: Stelian P. <po...@cy...> - 2000-09-08 18:39:43
|
On Thu, Sep 07, 2000 at 05:17:02PM -0600, gabriel somlo wrote:
> Can you please check the source code for some variable that overflows and
> causes large dumps done with the above method to fail ?
>
> I still can't tell wether the problem is with dump (makes a corrupt dump
> if too many files are dumped), restore (incapable of restoring a valid
> dump if it's too large or contains too many files), or both...
Ok, give me the pointer to your 350M dump (try a bzip2 -9 on it
before), and I'll take a look.
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: po...@cy...
\____/
|
|
From: Stelian P. <po...@cy...> - 2000-09-08 18:37:32
|
On Thu, Sep 07, 2000 at 09:34:02AM +0200, Bernhard R. Erdmann wrote:
> found a bug in dump 0.4b19: it doesn't dump a filesystem mounted as a
> subdir of /tmp.
I think it's more general than that: it doesn't dump a filesystem
which mountpoint is not given as an absolute path (as specified
in the fstab).
example:
if the /tmp/hp is in fstab
# /sbin/dump 0af /dev/null hp <- will not work
# /sbin/dump 0af /dev/null /tmp/hp <- will work
if /tmp/hp is not listed in the fstab, there is no way you
can dump the filesystem.
This is a bug present since the first version of dump, not
a regression in 0.4b19 (as your mail seemed to imply), isn't it ?
> [now listed in in /etc/fstab, see bugs fixed in 0.4b7]
Well, unless I'm completly wrong, the change in 0.4b7 allowed
to do a dump of something like /dev/sda5 without putting /dev/sda5
in the fstab file. But this did not allowed dumping a filesystem
not listed in the fstab by giving only the mountpoint... Am I wrong
here ?
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: po...@cy...
\____/
|
|
From: Stelian P. <po...@cy...> - 2000-09-08 17:54:52
|
On Thu, Sep 07, 2000 at 10:43:24AM +0200, Eros Albertazzi wrote:
> I have dump-0.4b19-1 on my pc. I am aware that dump report the total number of
> MB written to
> tape at the end of run and I am wandering if the figure is correct or how should
> be interpreted.
> Here the log
> [...]
>
> DUMP: 14895 tape blocks (14.55MB) on 1 volume(s)
>
> [...]
>
> while on host inti I have:
>
> ls -l /bck/psyche_root_8
> -rw-r--r-- 1 gufo whimsy 217804800 Sep 6 01:03 /bck/psyche_root_8
>
dump doesn't truncate the file upon opening.
I'd say that you already had a /bck/psyche_root_8 file of that
size before starting the dump.
Is this true ?
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: po...@cy...
\____/
|
|
From: gabriel s. <so...@CS...> - 2000-09-07 23:17:11
|
Stelian, I did some more research on dump/restore v. 0.4b19 ,using the statically linked binaries. It appears that if you do dump -a0f /tmp/mounted_filesystem/image.dump /dev/sda2 where /dev/sda2 is my Linux root partition, you can't restore if the size of the dump exceeds a certain limit (in my experiments, it's somewhere between 60 and 300 MBytes). I used the "a" flag to get around the repeated prompts to mount and prepare the next volume. Whenever I removed enogh stuff from /dev/sda2, the dump and restore worked flawlessly. It does not matter which files I remove, and it's not a problem with the contents of the /dev/ directory. Can you please check the source code for some variable that overflows and causes large dumps done with the above method to fail ? I still can't tell wether the problem is with dump (makes a corrupt dump if too many files are dumped), restore (incapable of restoring a valid dump if it's too large or contains too many files), or both... Thanks for your time, Gabriel On Mon, 4 Sep 2000, Stelian Pop wrote: > On Sat, Sep 02, 2000 at 10:19:33AM -0600, gabriel somlo wrote: > > > And yes, the statically linked programes were called dump.static and > > restore.static, but I renamed them for my typing convenience... > > Ok, sorry to insist, but just to be sure, > could you confirm that the restore > you are using is also the latest version (running dump > or restore without arguments will print the version number). > > And, are you able to reproduce this behaviour on a small > partition, and give me access to the result (ftp, http, > etc) ? Please don't include any sensitive data. > > Stelian. > -- > /\ > / \ Stelian Pop > / DS \ Email: po...@cy... > \____/ > |
|
From: Eros A. <er...@la...> - 2000-09-07 08:43:28
|
I have dump-0.4b19-1 on my pc. I am aware that dump report the total number of MB written to tape at the end of run and I am wandering if the figure is correct or how should be interpreted. Here the log DUMP: Connection to inti established. DUMP: Date of this level 8 dump: Wed Sep 6 01:02:00 2000 DUMP: Date of last level 6 dump: Mon Sep 4 01:02:01 2000 DUMP: Dumping /dev/hda2 (/) to /bck/psyche_root_8 on host gufo@inti DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 14198 tape blocks. DUMP: Volume 1 started at: Wed Sep 6 01:02:55 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /bck/psyche_root_8 DUMP: Volume 1 completed at: Wed Sep 6 01:03:32 2000 DUMP: Volume 1 took 0:00:37 DUMP: Volume 1 transfer rate: 402 KB/s DUMP: 14895 tape blocks (14.55MB) on 1 volume(s) DUMP: finished in 37 seconds, throughput 402 KBytes/sec DUMP: level 8 dump on Wed Sep 6 01:02:00 2000 DUMP: Date of this level 8 dump: Wed Sep 6 01:02:00 2000 DUMP: Date this dump completed: Wed Sep 6 01:03:32 2000 DUMP: Average transfer rate: 402 KB/s DUMP: DUMP IS DONE while on host inti I have: ls -l /bck/psyche_root_8 -rw-r--r-- 1 gufo whimsy 217804800 Sep 6 01:03 /bck/psyche_root_8 Regards.. -- Eros Albertazzi CNR-LAMEL, Via P.Gobetti 101, 40129 Bologna, Italy Tel: (+39)-051-639 9179 Fax: (+39)-051-639 9216 E-mail: er...@la... |
|
From: Bernhard R. E. <be...@be...> - 2000-09-07 07:34:23
|
Hi, found a bug in dump 0.4b19: it doesn't dump a filesystem mounted as a subdir of /tmp. # mkdir hp # mount /dev/sdb1 hp # /sbin/dump 0af /dev/null hp DUMP: Date of this level 0 dump: Thu Sep 7 09:16:14 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hdb11 (/tmp (dir /hp)) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 33 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:16:14 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:16:14 2000 DUMP: 31 tape blocks (0.03MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Thu Sep 7 09:16:14 2000 DUMP: Date this dump completed: Thu Sep 7 09:16:14 2000 DUMP: Average transfer rate: 0 KB/s DUMP: DUMP IS DONE # emacs /etc/fstab [now listed in in /etc/fstab, see bugs fixed in 0.4b7] # umount hp/ # mount hp # /sbin/dump 0af /dev/null hp DUMP: Date of this level 0 dump: Thu Sep 7 09:20:25 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hdb11 (/tmp (dir /hp)) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 33 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:20:25 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:20:25 2000 DUMP: 31 tape blocks (0.03MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Thu Sep 7 09:20:25 2000 DUMP: Date this dump completed: Thu Sep 7 09:20:25 2000 DUMP: Average transfer rate: 0 KB/s DUMP: DUMP IS DONE # mkdir blah # umount hp/ # mount /dev/sdb1 blah # /sbin/dump 0af /dev/null blah DUMP: Date of this level 0 dump: Thu Sep 7 09:20:59 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hdb11 (/tmp (dir /blah)) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 33 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:20:59 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:20:59 2000 DUMP: 31 tape blocks (0.03MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Thu Sep 7 09:20:59 2000 DUMP: Date this dump completed: Thu Sep 7 09:20:59 2000 DUMP: Average transfer rate: 0 KB/s DUMP: DUMP IS DONE # df /tmp Filesystem 1k-blocks Used Available Use% Mounted on /dev/hdb11 202220 1187 190593 1% /tmp # /sbin/dump 0af /dev/null /tmp/blah DUMP: Date of this level 0 dump: Thu Sep 7 09:23:45 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hdb11 (/tmp (dir /blah)) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 33 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:23:45 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:23:45 2000 DUMP: 31 tape blocks (0.03MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Thu Sep 7 09:23:45 2000 DUMP: Date this dump completed: Thu Sep 7 09:23:45 2000 DUMP: Average transfer rate: 0 KB/s DUMP: DUMP IS DONE # /sbin/dump 0af /dev/null /dev/sdb1 DUMP: Date of this level 0 dump: Thu Sep 7 09:26:19 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/sdb1 (/tmp/hp) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 100414 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:26:23 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:26:53 2000 DUMP: Volume 1 took 0:00:30 DUMP: Volume 1 transfer rate: 1908 KB/s DUMP: 57243 tape blocks (55.90MB) on 1 volume(s) DUMP: finished in 30 seconds, throughput 1908 KBytes/sec DUMP: Date of this level 0 dump: Thu Sep 7 09:26:19 2000 DUMP: Date this dump completed: Thu Sep 7 09:26:53 2000 DUMP: Average transfer rate: 1908 KB/s DUMP: DUMP IS DONE # umount blah/ # mkdir -p /tmp1/hp # mount /dev/sdb1 /tmp1/hp # /sbin/dump 0af /dev/null /tmp1/hp DUMP: Date of this level 0 dump: Thu Sep 7 09:28:57 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hdc1 (/ (dir tmp1/hp)) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 33 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:28:57 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:28:57 2000 DUMP: 33 tape blocks (0.03MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Thu Sep 7 09:28:57 2000 DUMP: Date this dump completed: Thu Sep 7 09:28:57 2000 DUMP: Average transfer rate: 0 KB/s DUMP: DUMP IS DONE # umount /tmp1/hp # mkdir /tmp2 # mount /dev/sdb1 /tmp2 # /sbin/dump 0af /dev/null /tmp2 DUMP: Date of this level 0 dump: Thu Sep 7 09:29:49 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/hdc1 (/ (dir tmp2)) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 31 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:29:49 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:29:49 2000 DUMP: 31 tape blocks (0.03MB) on 1 volume(s) DUMP: finished in less than a second DUMP: Date of this level 0 dump: Thu Sep 7 09:29:49 2000 DUMP: Date this dump completed: Thu Sep 7 09:29:49 2000 DUMP: Average transfer rate: 0 KB/s DUMP: DUMP IS DONE # umount /tmp2 # mkdir /var/spool/cyrus # emacs /etc/fstab # mount /var/spool/cyrus/ # /sbin/dump 0af /dev/null /var/spool/cyrus DUMP: Date of this level 0 dump: Thu Sep 7 09:32:08 2000 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/sdb1 (/var/spool/cyrus) to /dev/null DUMP: Label: none DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 100414 tape blocks. DUMP: Volume 1 started at: Thu Sep 7 09:32:11 2000 DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: Closing /dev/null DUMP: Volume 1 completed at: Thu Sep 7 09:32:38 2000 DUMP: Volume 1 took 0:00:27 DUMP: Volume 1 transfer rate: 2120 KB/s DUMP: 57243 tape blocks (55.90MB) on 1 volume(s) DUMP: finished in 27 seconds, throughput 2120 KBytes/sec DUMP: Date of this level 0 dump: Thu Sep 7 09:32:08 2000 DUMP: Date this dump completed: Thu Sep 7 09:32:38 2000 DUMP: Average transfer rate: 2120 KB/s DUMP: DUMP IS DONE |
|
From: Stelian P. <po...@cy...> - 2000-09-04 08:43:59
|
On Sat, Sep 02, 2000 at 10:19:33AM -0600, gabriel somlo wrote:
> And yes, the statically linked programes were called dump.static and
> restore.static, but I renamed them for my typing convenience...
Ok, sorry to insist, but just to be sure,
could you confirm that the restore
you are using is also the latest version (running dump
or restore without arguments will print the version number).
And, are you able to reproduce this behaviour on a small
partition, and give me access to the result (ftp, http,
etc) ? Please don't include any sensitive data.
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: po...@cy...
\____/
|
|
From: gabriel s. <so...@CS...> - 2000-09-02 16:19:41
|
First off, thanks for your quick reply. Secondly, sorry for throwing too much information at you and possibly leading you down the wrong path. The simple version of my story is that eventually I gave up on NFS and just attached a second SCSI disk to my computer and directed the output of dump to it. So what I did was as follows: mke2fs /dev/sdb1 mount /dev/sdb1 /tmp/blah dump 0f /tmp/blah/clone-this.root /dev/sda2 to get an image of the filesystem on /dev/sda2. Then, on the target machine, I did mke2fs /dev/sda2 mount /dev/sda2 /tmp/root mount /dev/sdb1 /tmp/blah cd /tmp/root restore rf /tmp/blah/clone-this.root It still gave me the same errors. And yes, the statically linked programes were called dump.static and restore.static, but I renamed them for my typing convenience... Thanks for your patience, :) Gabriel On Sat, 2 Sep 2000, Stelian Pop wrote: > On Fri, Sep 01, 2000 at 10:44:32AM -0600, gabriel somlo wrote: > > > > > restore rf - < /nfs-mount-point/clone-this.root > > Do you get the same errors if doing just > restore rf /nfs-mount-point/clone-this.root > > > The dumps were error free in each instance. I used the statically linked > > binaries from > > > > dump-static-0.4b19-1.i386.rpm > > In this case the dump is called dump.static and the > restore is restore.static... > > Is it possible that you used some other (much older) > version of dump and/or restore ? > > Stelian. > -- > /\ > / \ Stelian Pop > / DS \ Email: po...@cy... > \____/ > |
|
From: Stelian P. <po...@cy...> - 2000-09-02 15:25:30
|
On Fri, Sep 01, 2000 at 10:44:32AM -0600, gabriel somlo wrote:
>
> restore rf - < /nfs-mount-point/clone-this.root
Do you get the same errors if doing just
restore rf /nfs-mount-point/clone-this.root
> The dumps were error free in each instance. I used the statically linked
> binaries from
>
> dump-static-0.4b19-1.i386.rpm
In this case the dump is called dump.static and the
restore is restore.static...
Is it possible that you used some other (much older)
version of dump and/or restore ?
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: po...@cy...
\____/
|
|
From: gabriel s. <so...@CS...> - 2000-09-01 16:44:35
|
Hi ! I recently tried to clone several Linux boxes using dump and restore, over NFS. It didn't work, and I'm wondering if anyone knows what the problem is. At first, I just did a dump 0f - / > /nfs-mount-point/clone-this.root The output looked normal, there were no complaints, and I ended up with my clone-this.root file. Then I booted my target machine from CDROM, added NFS support, and mounted the /nfs-mount-point/. I used mke2fs on /dev/sda2, then mounted /dev/sda2 to /tmp/out. I changed to /tmp/out and did restore rf - < /nfs-mount-point/clone-this.root At this point I started getting tons of error messages of the form "expected next file XXXX, got YYYYY" The man page sais this is because I dumped from an active file system. The next thing I tried was to boot my SOURCE machine off the CDROM, start NFS support, mount the /nfs-mount-point/ and then did a dump 0f - /dev/sda2 > /nfs-mount-point/clone-this.root This dump was DEFINITELY not done from an active filesystem. Then I repeated the restore process on the target machine, with the same error: "expected next file XXXX, got YYYYY". The dumps were error free in each instance. I used the statically linked binaries from dump-static-0.4b19-1.i386.rpm Does anyone have a guess what might be wrong ? Please let me know if you need any more info about what I did... Thanks much, Gabriel Somlo |
|
From: Stelian P. <ste...@al...> - 2000-09-01 14:02:04
|
On Fri, Sep 01, 2000 at 09:52:09AM -0400, Neil Berthier wrote: > I'm trying to back up a remote disk using dump and openssh. I have no > problem ssh'ing > between the machines as root without a passphrase, or doing ssh allegro > ls, for instance. > But if I try dump--- > > remotehost # dump 0ucBf 2000000 allegro:/dev/nst0 /dev/hda7 > DUMP: allegro.sbs.umass.edu: Connection refused > DUMP: login to allegro as root failed. Did you use the RSH environment variable ? Seems to me that you are trying to use the internal rsh here, non ssh ... > >From allegro, where my tape drive is located, I can > > ssh remotehost dump 0ucBf 2000000 - /dev/hda7 > /dev/nst0 > > Which connects and writes the dump fine, except that it is a multiple > tape dump and when the tape fills, it crashes, but dump doesn't > ask for a second volume. You cannot have several tapes using such a syntax, because the one which writes to the tape is not the dump process but your shell which redirect the output to the tape... Stelian. -- Stelian Pop <ste...@al...> |
|
From: Neil B. <ber...@ps...> - 2000-09-01 13:55:23
|
Hi, I'm trying to back up a remote disk using dump and openssh. I have no problem ssh'ing between the machines as root without a passphrase, or doing ssh allegro ls, for instance. But if I try dump--- remotehost # dump 0ucBf 2000000 allegro:/dev/nst0 /dev/hda7 DUMP: allegro.sbs.umass.edu: Connection refused DUMP: login to allegro as root failed. From allegro, where my tape drive is located, I can ssh remotehost dump 0ucBf 2000000 - /dev/hda7 > /dev/nst0 Which connects and writes the dump fine, except that it is a multiple tape dump and when the tape fills, it crashes, but dump doesn't ask for a second volume. Can anyone help? -- Neil Berthier ber...@ps... http://allegro.sbs.umass.edu/berthier |
|
From: Stelian P. <ste...@al...> - 2000-08-23 10:32:44
|
On Mon, Aug 21, 2000 at 06:20:09PM -0400, Eric J. Gerney wrote:
> /sbin/dump: ACLs in inode #12108 won't be dumped: Success
Do you really have ACLs in your inodes ? If yes, the message
is normal, dump doesn't save the ACLs. If not, see below...
> DUMP: Warning: undefined file type 050000
This is strange: the filetype is the same field as in the stat
structure, and you seem to have files that are not regular files,
neither directories, devices etc...
I think that you may:
- have a corrupted filesystem (does fsck report something
wrong on this filesystem ?)
- or, more probably, it's again the same old story about
running dump on a (very) active filesystem. Try to dump
this filesystem while it is not mounted and see if the
errors persist.
Stelian.
--
Stelian Pop <ste...@al...>
|
|
From: Bernhard E. <be...@be...> - 2000-08-22 07:38:15
|
Stelian Pop wrote: [...] > Well, RedHat updated their spec file (using some new macros, > FHS compliance etc), and I wanted to keep in sync. Anyway, > my interest in maintaining RPM files is rather limited, and > I will even maybe drop that support in the future, doing only > tar.gz releases. I encourage you not to drop SRPM support. |
|
From: Gunther S. <sch...@ri...> - 2000-08-22 06:44:28
|
Hi Stelian, > Ok, I've put it on: > ftp://dump.sourceforge.net/pub/dump/dump-0.4b19a.tar.gz I just compiled it on a 5.2 with kernel 2.2.16. I have to encourage you to continue SRPM support. (But I'll hack my own one out of 0.4b19a). ;) thanks, Gunther -- Gunther Schlegel Riege Software International GmbH Manager System Administration Mollsfeld 10 40670 Meerbusch, Germany Email: sch...@ri... Phone: +49-2159-9148-0 Fax: +49-2159-9148-11 ------------------------------------------------------------------------- |
|
From: Eric J. G. <eg...@gr...> - 2000-08-21 22:20:15
|
Dump-users,
I'm hoping someone can help me with this....
I get the following errors when I perform a dump of my filesystems.
Actually, it's a script that calls dump for each filesystem. When it gets
to /var, the follow errors are displayed.
Has anyone seen this before?
I've only included the portion of the output that contains errors, and
that has been edited for length.
DUMP: Date of this level 0 dump: Thu Jul 27 01:55:41 2000
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/sda7 (/var) to /dev/nst0
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 14110 tape blocks on 0.00 tape(s).
DUMP: Volume 1 started at: Thu Jul 27 01:55:44 2000
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
/sbin/dump: ACLs in inode #12108 won't be dumped: Success
DUMP: Warning: undefined file type 050000
/sbin/dump: ACLs in inode #12111 won't be dumped: Success
/sbin/dump: ACLs in inode #12115 won't be dumped: Success
/sbin/dump: ACLs in inode #12137 won't be dumped: Success
DUMP: Warning: undefined file type 0170000
/sbin/dump: ACLs in inode #12142 won't be dumped: Success
/sbin/dump: ACLs in inode #12151 won't be dumped: Success
/sbin/dump: ACLs in inode #12158 won't be dumped: Success
DUMP: Warning: undefined file type 0150000
/sbin/dump: ACLs in inode #12160 won't be dumped: Success
/sbin/dump: ACLs in inode #12162 won't be dumped: Success
.
.
.
DUMP: Warning: undefined file type 030000
DUMP: DUMP: 14028 tape blocks on 1 volumes(s)
DUMP: finished in 11 seconds, throughput 1275 KBytes/sec
DUMP: Volume 1 completed at: Thu Jul 27 01:55:55 2000
DUMP: Volume 1 took 0:00:11
DUMP: Volume 1 transfer rate: 1275 KB/s
DUMP: level 0 dump on Thu Jul 27 01:55:41 2000
DUMP: DUMP: Date of this level 0 dump: Thu Jul 27 01:55:41 2000
DUMP: DUMP: Date this dump completed: Thu Jul 27 01:55:55 2000
DUMP: DUMP: Average transfer rate: 1275 KB/s
DUMP: Closing /dev/nst0
DUMP: DUMP IS DONE
Thanks in advance,
Eric Gerney, RHCE, CCNA.
Network Manager
GRC International
eg...@gr...
-----------------
The author is GPG empowered. Public key at: finger eg...@gr...
The opinions expressed herein are strictly those of the author
and do not necessarily reflect those of GRCI.
|
|
From: Kenneth P. <sh...@we...> - 2000-08-21 21:35:58
|
On Mon, 21 Aug 2000 23:01:59 +0200, Stelian Pop wrote: >On Mon, Aug 21, 2000 at 09:36:00PM +0200, Bernhard Erdmann wrote: >> But anyway, I'm not very happy about your move to rpm-3.0.5 with >> dump-0.4b19. What are the advantages using it's features rpm<=3.0.3 >> doesn't provide? Lots of traffic on the RPM mailing list right now about how the new 3.0.5 (a "bridge" version to RPM 4) must be used on all new packages at Red Hat. A lot of grumbling going on. >Well, RedHat updated their spec file (using some new macros, >FHS compliance etc), and I wanted to keep in sync. Anyway, >my interest in maintaining RPM files is rather limited, and >I will even maybe drop that support in the future, doing only >tar.gz releases. > >So I try to keep that as simple as possible (I'm not willing >to understand all the RPM features etc). I just suppose the RedHat >spec is the good one, package with that and distribute the intel >and source rpms as a convenience download for many people. Please don't stop. I really appreciate having the release in SRPM format to simplify building and updating. Ken mailto:sh...@we... http://www.sewingwitch.com/ken/ http://www.harrybrowne2000.org/ |
|
From: Stelian P. <po...@cy...> - 2000-08-21 21:02:06
|
On Mon, Aug 21, 2000 at 09:36:00PM +0200, Bernhard Erdmann wrote: > Thanks for the explanation. The .tar.gz compiles properly, Ok, that's good. > but putting > it in an RPM fails due to an old rpm version (3.0.2) on that old RHL 5.2 > machine. I'll have a look to ftp.redhat.com/updates/5.2 if they provide > rpm-3.0.5 for RHL 5.2. They do (rpm-3.0.5-9.5x.i386.rpm). In order to install future updates for RedHat 5.2, you will even be forced to upgrade rpm, since the new packages won't be undestand by the old rpm... So it is RedHat that forces you actually to update rpm to 3.0.5... :) > But anyway, I'm not very happy about your move to rpm-3.0.5 with > dump-0.4b19. What are the advantages using it's features rpm<=3.0.3 > doesn't provide? Well, RedHat updated their spec file (using some new macros, FHS compliance etc), and I wanted to keep in sync. Anyway, my interest in maintaining RPM files is rather limited, and I will even maybe drop that support in the future, doing only tar.gz releases. So I try to keep that as simple as possible (I'm not willing to understand all the RPM features etc). I just suppose the RedHat spec is the good one, package with that and distribute the intel and source rpms as a convenience download for many people. Stelian. -- /\ / \ Stelian Pop / DS \ Email: po...@cy... \____/ |
|
From: Bernhard E. <be...@be...> - 2000-08-21 19:36:12
|
Stelian Pop wrote: [...] > I've put the tar.gz on the ftp site (see my mail on dump-users), > but I'm unable to build a src.rpm at the moment. > > But it should be rather easily to do that yourself: > just drop the tar.gz in /usr/src/redhat/SOURCES > copy the dump.spec (contained into the tar.gz) in /usr/src/redhat/SPEC > modify the dump.spec, to define the version as 0.4b19a instead of 0.4b19. > rpm -ba dump.spec Thanks for the explanation. The .tar.gz compiles properly, but putting it in an RPM fails due to an old rpm version (3.0.2) on that old RHL 5.2 machine. I'll have a look to ftp.redhat.com/updates/5.2 if they provide rpm-3.0.5 for RHL 5.2. But anyway, I'm not very happy about your move to rpm-3.0.5 with dump-0.4b19. What are the advantages using it's features rpm<=3.0.3 doesn't provide? |
|
From: Bernhard E. <be...@be...> - 2000-08-21 19:16:37
|
Stelian Pop wrote: > > On Mon, Aug 21, 2000 at 12:56:50PM +0200, Stelian Pop wrote: > > > PS: if it's inconvenient for you to get the CVS version, I could > > put a snapshot somewhere. > > Ok, I've put it on: > ftp://dump.sourceforge.net/pub/dump/dump-0.4b19a.tar.gz It compiles properly on Red Hat 5.2 (with kernel 2.0.38). |
|
From: Stelian P. <ste...@al...> - 2000-08-21 11:10:17
|
On Mon, Aug 21, 2000 at 12:56:50PM +0200, Stelian Pop wrote:
> PS: if it's inconvenient for you to get the CVS version, I could
> put a snapshot somewhere.
Ok, I've put it on:
ftp://dump.sourceforge.net/pub/dump/dump-0.4b19a.tar.gz
Stelian.
--
Stelian Pop <ste...@al...>
|
|
From: Stelian P. <ste...@al...> - 2000-08-21 10:57:05
|
I fixed in CVS the two compilation problems:
- struct sigaction has no sa_sigaction field.
- struct ext2_super_block has no s_uuid or s_volume_name field.
Could you (Gunther and Bernhard) please test that it compiles
nicely now on your system(s) ?
Thanks (and sorry for all that)...
PS: if it's inconvenient for you to get the CVS version, I could
put a snapshot somewhere.
Stelian.
--
Stelian Pop <ste...@al...>
|
50 messages has been excluded from this view by a project administrator.
