dump-users

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b39 released.

[Kenneth P. <sh...@se...>]

Additionally, when verifying a backup where I don't have permission to read 
all files on the target filesystem, a permission error on a file stops with 
an offer to abort and dump core, but a permission error on a directory 
keeps going. I don't have a strong preference either way, but it seems like 
these two situations should have a consistent effect.

[Dump-users] Re: [Dump-announce] Dump/restore 0.4b39 released.

[Kenneth P. <sh...@se...>]

> 3.	Silenced the failure to call fgetflags() when comparing an
> 	entry which has no ext2 attributes (as in lsattr()).

I built this with the new EA/ACL patch. Not sure if this is related, but 
I'm getting a few compare errors in /dev:

[buildmeister@segw dump]$ ./dump 0 -b 64 -Mf /tmp/test2.dump -Q 
/tmp/test2.qfa -B 1000000 /dev

(Normal dump output)

./restore -C -l -L 1000 -b 64 -Mf /tmp/test2.dump

./restore: ./dev/pts: llistxattr failed: Operation not supported
./dev/shm: mode changed from 0755 to 01777.
./dev/shm: EA count changed from 0 to 1

I put the test dump file in the same location as before.

Re: [Dump-users] dump on CD (Linux only)

[Stelian P. <st...@po...>]

On Mon, Jan 17, 2005 at 09:55:22AM +0100, Joerg Schilling wrote:

> Stelian Pop <st...@po...> wrote:
> 
> > On Sun, Jan 16, 2005 at 08:57:08PM +0100, Joerg Schilling wrote:
> >
> > > jar...@be... wrote:
> > [...]
> > > 
> > > I don't know why this is crossposted to cdrwite@
> >
> > I think something has gone wrong with Joerg's mailbox, this mail

Sorry, I meant to day Helmut's (jar...@be...) mailbox of
course, not yours...

> > (and a few others I received from him in the last few days) are 
> > copies of 3-4 year old messages of him.
> >
> > Either he switched to Outlook or he is testing some bogus mail
> > scripts :)
> 
> If you don't understand how mail works, it would help
> it you try to avoid writing such useless comments.

I think you need to calm down. You do understand how smileys work,
don't you ?

> I definitely did not send mail to you except for the one asking
> why this mail has been sent.....
> 
> Meanwhile find someone who is able to explain mail headers to you.

Take a look at Helmut's mail headers and read them.

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] dump on CD (Linux only)

[Joerg S. <sch...@fo...>]

Stelian Pop <st...@po...> wrote:

> On Sun, Jan 16, 2005 at 08:57:08PM +0100, Joerg Schilling wrote:
>
> > jar...@be... wrote:
> [...]
> >=20
> > I don't know why this is crossposted to cdrwite@
>
> I think something has gone wrong with Joerg's mailbox, this mail
> (and a few others I received from him in the last few days) are=20
> copies of 3-4 year old messages of him.
>
> Either he switched to Outlook or he is testing some bogus mail
> scripts :)

If you don't understand how mail works, it would help
it you try to avoid writing such useless comments.

I definitely did not send mail to you except for the one asking
why this mail has been sent.....

Meanwhile find someone who is able to explain mail headers to you.


It may be that debian is on dope.....

J=F6rg

--=20
 EMail:jo...@sc... (home) J=F6rg Schilling D-13353 =
Berlin
       js...@cs...		(uni)  If you don't have iso-8859-1
       sch...@fo...	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/=
pub/schily

Re: [Dump-users] dump on CD (Linux only)

[Stelian P. <st...@po...>]

On Sun, Jan 16, 2005 at 08:57:08PM +0100, Joerg Schilling wrote:

> jar...@be... wrote:
[...]
> 
> I don't know why this is crossposted to cdrwite@

I think something has gone wrong with Joerg's mailbox, this mail
(and a few others I received from him in the last few days) are 
copies of 3-4 year old messages of him.

Either he switched to Outlook or he is testing some bogus mail
scripts :)

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] dump on CD (Linux only)

[Bill D. <dav...@tm...>]

Joerg Schilling wrote:

>jar...@be... wrote:
>
>  
>
>>On 26 Jul, Stelian Pop wrote:
>>    
>>
>>>On Thu, Jul 26, 2001 at 02:45:26PM +0200, jar...@ig... wrote:
>>>
>>>      
>>>
>>>>ftp://ftp.igpm.rwth-aachen.de/pub/jarausch/Dump_On_CD/dump-04b23CD.diff
>>>>        
>>>>
>>>This patch modifies dump.h, reminiscent from a previous patch but
>>>unused now. Please remove it.
>>>
>>>      
>>>
>>I don't think so. Currently in (04b23) restore is linked against 
>>../common/dumprmt.o
>>and all global flags like Mflag are allocated THERE. So I have put
>>the new MultiFlag in dump.h so that it gets allocated there to.
>>Unfortunately the restore/Makefile doesn't check the dependeny of
>>../common/dumprmt.o on dump.h
>>    
>>
>
>I don't know why this is crossposted to cdrwite@
>
>
>but incremental backups and restores in a OS and filesystem independent 
>way should be possible with star.
>  
>

I don't believe this discussion was about any backup methods but dump 
and restore. Different problem, different solution.

-- 
bill davidsen <dav...@tm...>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: [Dump-users] dump on CD (Linux only)

[Joerg S. <sch...@fo...>]

jar...@be... wrote:

> On 26 Jul, Stelian Pop wrote:
> > On Thu, Jul 26, 2001 at 02:45:26PM +0200, jar...@ig...th-aachen.d=
e wrote:
> >=20
> >> ftp://ftp.igpm.rwth-aachen.de/pub/jarausch/Dump_On_CD/dump-04b23CD.d=
iff
> >=20
> > This patch modifies dump.h, reminiscent from a previous patch but
> > unused now. Please remove it.
> >=20
>
> I don't think so. Currently in (04b23) restore is linked against=20
> ../common/dumprmt.o
> and all global flags like Mflag are allocated THERE. So I have put
> the new MultiFlag in dump.h so that it gets allocated there to.
> Unfortunately the restore/Makefile doesn't check the dependeny of
> ../common/dumprmt.o on dump.h

I don't know why this is crossposted to cdrwite@


but incremental backups and restores in a OS and filesystem independent=20
way should be possible with star.

J=F6rg

--=20
 EMail:jo...@sc... (home) J=F6rg Schilling D-13353 =
Berlin
       js...@cs...		(uni)  If you don't have iso-8859-1
       sch...@fo...	(work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/=
pub/schily

[Dump-users] Re: Brown paper bag bug (and fix) for 'restore -C' (0.4b38)

[Kenneth P. <sh...@se...>]

--On Friday, January 14, 2005 2:11 PM +0100 Stelian Pop 
<st...@po...> wrote:

> Please test this patch (or the CVS version which contains it), I will
> release 0.4b39 early next week.

Thanks! I've built and installed a new RPM and will test it later today.

[Dump-users] Brown paper bag bug (and fix) for 'restore -C' (0.4b38)

[Stelian P. <st...@po...>]

On Tue, Jan 11, 2005 at 03:21:13PM -0800, Kenneth Porter wrote:

> Tried a full backup with verify and I think -C is broken. I'm seeing this, 
> which looks like it's trying to restore the files instead of compare them:
> 
> abort? [yn] /usr/sbin/restore: cannot rename ./var/lib/mysql/mysql/db.MYI 
> to RSTTMP02: No such file or directory
> 
> I found my mysql directory clobbered. With what appeared to be the original 
> under another name, /var/lib/RSTTMP06373651. Fortunately I was able to 
> recover by renaming it into place.

Got it. In fact it was a bug in restore, when using the -C mode,
which was affecting directories containing a file with the same name
as the directory (such as /var/lib/mysql/mysql, or
/lib/modules/2.6.9-1.667/build/scripts/genksyms/genksyms)

The attached patch should solve the problem. The patch also forces
the -N option (do not write on the disk) of restore when doing a
comparision, this should in the future prevent other bugs like this
one.

Please test this patch (or the CVS version which contains it), I will
release 0.4b39 early next week.

Thanks Kenneth for all the help you gave on this bug.

Stelian.

Index: restore/symtab.c
===================================================================
RCS file: /cvsroot/dump/dump/restore/symtab.c,v
retrieving revision 1.23
diff -u -r1.23 symtab.c
--- restore/symtab.c	14 Dec 2004 14:07:58 -0000	1.23
+++ restore/symtab.c	14 Jan 2005 12:55:14 -0000
@@ -189,9 +189,16 @@
 	char *np, *cp;
 	char buf[MAXPATHLEN];
 
+	ep = lookupino(ROOTINO);
+
 	cp = name;
+	if (*cp == '.')
+		++cp;
+	if (*cp == '/')
+		++cp;
+	if (*cp == '\0')
+		return ep;
 
-	ep = lookupino(ROOTINO);
 	while (ep != NULL) {
 		for (np = buf; *cp != '/' && *cp != '\0' &&
 				np < &buf[sizeof(buf)]; )
@@ -202,8 +209,7 @@
 
 		oldep = ep;
 
-		if (strcmp(ep->e_name, buf) != 0 &&
-		    ep->e_entries != NULL) {
+		if (ep->e_entries != NULL) {
 
 			ep = ep->e_entries[dir_hash(buf)];
 			for ( ; ep != NULL; ep = ep->e_sibling)
Index: restore/main.c
===================================================================
RCS file: /cvsroot/dump/dump/restore/main.c,v
retrieving revision 1.48
diff -u -r1.48 main.c
--- restore/main.c	13 Jan 2005 15:41:06 -0000	1.48
+++ restore/main.c	14 Jan 2005 12:55:14 -0000
@@ -424,6 +424,7 @@
 		Vprintf(stdout, "Begin compare restore\n");
 		compare_ignore_not_found = 0;
 		compare_errors = 0;
+		Nflag = 1;
 		setup();
 		printf("filesys = %s\n", filesys);
 		if (STAT(filesys, &stbuf) < 0)
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] dump on CD (Linux only)

[<jar...@be...>]

On 26 Jul, Stelian Pop wrote:
> On Thu, Jul 26, 2001 at 02:45:26PM +0200, jar...@ig... wrote:
> 
>> ftp://ftp.igpm.rwth-aachen.de/pub/jarausch/Dump_On_CD/dump-04b23CD.diff
> 
> This patch modifies dump.h, reminiscent from a previous patch but
> unused now. Please remove it.
> 

I don't think so. Currently in (04b23) restore is linked against 
../common/dumprmt.o
and all global flags like Mflag are allocated THERE. So I have put
the new MultiFlag in dump.h so that it gets allocated there to.
Unfortunately the restore/Makefile doesn't check the dependeny of
../common/dumprmt.o on dump.h

I, too, would prefer the global flags in a different object file,
but currently it's that way.



Helmut.

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Stelian P. <st...@po...>]

On Wed, Jan 12, 2005 at 11:17:59PM +0100, Stelian Pop wrote:

> > While checking this as a mortal I realized that restore can't dump core 
> > when it can't write to the root of the target filesystem. It might be 
> > desirable to have panic() chdir to /tmp or to the directory the program 
> > started from before aborting.
> 
> chdir() back to the original directory seems to be indeed the right way.

Done in CVS.

Stelian.
-- 
Stelian Pop <st...@po...>    

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Stelian P. <st...@po...>]

On Wed, Jan 12, 2005 at 01:40:47PM -0800, Kenneth Porter wrote:

> --On Tuesday, January 11, 2005 3:33 PM -0800 Kenneth Porter 
> <sh...@se...> wrote:
> 
> >restore: cannot rename ./var/lib/mysql to ./var/lib/RSTTMP06373651:
> >Permission denied
> 
> Looks like this code also exists in 0.4b37, so perhaps it's not getting 
> triggered when I run that version of restore. In any case, when doing a 
> compare, nodeupdates() shouldn't be making filesystem changes no matter 
> what input it gets from the dump file. It looks like renameit() needs to 
> check for command == 'C'. I'm not sure if this breaks mktempname() and if 
> that needs attention as well.

I think you got it. I believe this could be related to some changes I made
in 0.4b38 to improve the comparision (before 0.4b38, only files were
compared, directory weren't, so a change in the ownership of a directory
was not reported by restore -C). While implementing this, I reused some
code and it appears that this code requires some sort of write access.

I'll look at this more in detail tomorrow.

> While checking this as a mortal I realized that restore can't dump core 
> when it can't write to the root of the target filesystem. It might be 
> desirable to have panic() chdir to /tmp or to the directory the program 
> started from before aborting.

chdir() back to the original directory seems to be indeed the right way.

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

--On Wednesday, January 12, 2005 10:23 PM +0100 Stelian Pop 
<st...@po...> wrote:

> - can you reproduce this with the unpatched dump ?

It fails the same way using both patched and unpatched dump with the 
unpatched restore. So all 4 combinations fail.

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

--On Tuesday, January 11, 2005 3:33 PM -0800 Kenneth Porter 
<sh...@se...> wrote:

> restore: cannot rename ./var/lib/mysql to ./var/lib/RSTTMP06373651:
> Permission denied

Looks like this code also exists in 0.4b37, so perhaps it's not getting 
triggered when I run that version of restore. In any case, when doing a 
compare, nodeupdates() shouldn't be making filesystem changes no matter 
what input it gets from the dump file. It looks like renameit() needs to 
check for command == 'C'. I'm not sure if this breaks mktempname() and if 
that needs attention as well.

While checking this as a mortal I realized that restore can't dump core 
when it can't write to the root of the target filesystem. It might be 
desirable to have panic() chdir to /tmp or to the directory the program 
started from before aborting.

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Stelian P. <st...@po...>]

On Wed, Jan 12, 2005 at 07:54:06AM -0800, Kenneth Porter wrote:

> --On Wednesday, January 12, 2005 10:02 AM +0100 Stelian Pop 
> <st...@po...> wrote:
> 
> >Reverting to restore-0.4b37 or reverting to both older dump and older
> >restore ?
> 
> The initial backup/verify used 0.4b38-ea (with EA/ACL patch). This is the 
> restore that gives the error. I then checked the resulting dump file with 
> restore from 0.4b37 and it performs the comparison properly. So I don't 
> think there's a problem with dump. It's something in restore that seems to 
> be ignoring the -C flag.
> 
> I put the scripts I use here:
> 
> <http://microprecisionautomation.com/DumpScripts/>

Well, it works for me (with both the official 0.4b38, and with the
patched version):

[root@deep-space-9 tmp]# dump
dump 0.4b38 (using libext2fs 1.35 of 28-Feb-2004)
[...]
[root@deep-space-9 tmp]# dump 0f DMP /etc
  DUMP: Date of this level 0 dump: Wed Jan 12 22:12:44 2005
  DUMP: Dumping /dev/hdb1 (/ (dir etc)) to DMP
  DUMP: Label: none
  DUMP: Writing 10 Kilobyte records
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 60572 blocks.
  DUMP: Volume 1 started with block 1 at: Wed Jan 12 22:12:46 2005
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: Closing DMP
  DUMP: Volume 1 completed at: Wed Jan 12 22:12:49 2005
  DUMP: Volume 1 62020 blocks (60.57MB)
  DUMP: Volume 1 took 0:00:03
  DUMP: Volume 1 transfer rate: 20673 kB/s
  DUMP: 62020 blocks (60.57MB) on 1 volume(s)
  DUMP: finished in 3 seconds, throughput 20673 kBytes/sec
  DUMP: Date of this level 0 dump: Wed Jan 12 22:12:44 2005
  DUMP: Date this dump completed:  Wed Jan 12 22:12:49 2005
  DUMP: Average transfer rate: 20673 kB/s
  DUMP: DUMP IS DONE
[root@deep-space-9 tmp]# restore Cf DMP 
Dump   date: Wed Jan 12 22:12:44 2005
Dumped from: the epoch
Level 0 dump of / (dir etc) on deep-space-9.dsnet:/dev/hdb1
Label: none
filesys = /
root@deep-space-9 tmp]#

> I normally run backup-smb-full from a weekly crontab entry.

Don't see anything obviously wrong there, except maybe that
you look for dump and restore in /sbin, while my rpm installs
them in /usr/sbin.

Once again:
- please verify that /sbin/dump and /sbin/restore are the correct versions
- can you reproduce this with the unpatched dump ?
- can you provide me a small dump exhibiting the problem ?

Thanks.

Stelian.
-- 
Stelian Pop <st...@po...>

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

--On Tuesday, January 11, 2005 3:33 PM -0800 Kenneth Porter 
<sh...@se...> wrote:

> bad name to addentry ./var/lib/mysql/mysql

It looks like this is reported near the new directory hash logic. Could 
that be trying to write to the original partition?

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

--On Wednesday, January 12, 2005 10:02 AM +0100 Stelian Pop 
<st...@po...> wrote:

> Reverting to restore-0.4b37 or reverting to both older dump and older
> restore ?

The initial backup/verify used 0.4b38-ea (with EA/ACL patch). This is the 
restore that gives the error. I then checked the resulting dump file with 
restore from 0.4b37 and it performs the comparison properly. So I don't 
think there's a problem with dump. It's something in restore that seems to 
be ignoring the -C flag.

I put the scripts I use here:

<http://microprecisionautomation.com/DumpScripts/>

I normally run backup-smb-full from a weekly crontab entry.

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Stelian P. <st...@po...>]

On Tue, Jan 11, 2005 at 03:33:02PM -0800, Kenneth Porter wrote:

> An attempt with the unpatched 0.4b38 to verify the full backup while not 
> root:

Is this the same bug report as the one in the previous mail or a
new one ?

You say it fails "while non root". Should I understand that restoring
as root works ok ?

> [ken@segw boot]$ restore -C -l -Mf /mnt/Backup/Sauron/0/root/dump
> Dump   date: Tue Jan 11 13:40:59 2005
> Dumped from: the epoch
> Level 0 dump of / on segw:/dev/hda6
> Label: /
> filesys = /
> restore: cannot rename ./var/lib/mysql to ./var/lib/RSTTMP06373651: 
> Permission denied
> bad name to addentry ./var/lib/mysql/mysql
> abort? [yn]
> 
> Reverting to b37 and it doesn't exhibit this.

Reverting to restore-0.4b37 or reverting to both older dump and older
restore ?

Are you able to reproduce this on a small set of files and mail me
the dump file ?

I'll try to take a look at this ASAP.

Stelian.
-- 
Stelian Pop <st...@po...>    

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Stelian P. <st...@po...>]

On Tue, Jan 11, 2005 at 03:21:13PM -0800, Kenneth Porter wrote:

> --On Tuesday, January 11, 2005 11:19 AM -0800 Kenneth Porter 
> <sh...@se...> wrote:
> 
> >--On Friday, January 07, 2005 3:09 PM +0100 Stelian Pop
> ><st...@po...> wrote:
> >
> >>The next version of dump/restore will feature EA/ACL support, and
> >>there is already a beta patch implementing this. If you use EA/ACLs,
> >>please do test this patch and report back (get the patch from dump's
> >>homepage).
> >
> >For those wishing to build RPM's, I've attached a patch to the spec file
> >that applies the EA/ACL patch.
> 
> Tried a full backup with verify and I think -C is broken. I'm seeing this, 
> which looks like it's trying to restore the files instead of compare them:
> 
> abort? [yn] /usr/sbin/restore: cannot rename ./var/lib/mysql/mysql/db.MYI 
> to RSTTMP02: No such file or directory
> 
> I found my mysql directory clobbered. With what appeared to be the original 
> under another name, /var/lib/RSTTMP06373651. Fortunately I was able to 
> recover by renaming it into place.

Is this using *both* dump and restore 0.4b38 ? Or dump 0.4b38 and 
and older restore ?

Stelian.
-- 
Stelian Pop <st...@po...>    

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

An attempt with the unpatched 0.4b38 to verify the full backup while not 
root:


[ken@segw boot]$ restore -C -l -Mf /mnt/Backup/Sauron/0/root/dump
Dump   date: Tue Jan 11 13:40:59 2005
Dumped from: the epoch
Level 0 dump of / on segw:/dev/hda6
Label: /
filesys = /
restore: cannot rename ./var/lib/mysql to ./var/lib/RSTTMP06373651: 
Permission denied
bad name to addentry ./var/lib/mysql/mysql
abort? [yn]

Reverting to b37 and it doesn't exhibit this.

Re: [Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

--On Tuesday, January 11, 2005 11:19 AM -0800 Kenneth Porter 
<sh...@se...> wrote:

> --On Friday, January 07, 2005 3:09 PM +0100 Stelian Pop
> <st...@po...> wrote:
>
>> The next version of dump/restore will feature EA/ACL support, and
>> there is already a beta patch implementing this. If you use EA/ACLs,
>> please do test this patch and report back (get the patch from dump's
>> homepage).
>
> For those wishing to build RPM's, I've attached a patch to the spec file
> that applies the EA/ACL patch.

Tried a full backup with verify and I think -C is broken. I'm seeing this, 
which looks like it's trying to restore the files instead of compare them:

abort? [yn] /usr/sbin/restore: cannot rename ./var/lib/mysql/mysql/db.MYI 
to RSTTMP02: No such file or directory

I found my mysql directory clobbered. With what appeared to be the original 
under another name, /var/lib/RSTTMP06373651. Fortunately I was able to 
recover by renaming it into place.

[Dump-users] Re: [Dump-announce] Dump/restore 0.4b38 released.

[Kenneth P. <sh...@se...>]

--On Friday, January 07, 2005 3:09 PM +0100 Stelian Pop 
<st...@po...> wrote:

> The next version of dump/restore will feature EA/ACL support, and
> there is already a beta patch implementing this. If you use EA/ACLs,
> please do test this patch and report back (get the patch from dump's
> homepage).

For those wishing to build RPM's, I've attached a patch to the spec file 
that applies the EA/ACL patch.

Re: [Dump-users] dump & cdrecord

[Stelian P. <st...@po...>]

On Mon, Dec 20, 2004 at 09:20:12PM -0500, David Gesswein wrote:

> > That's what the restore -V option is there for. 
> > 
> > Correction: looking at the source I see that -V is used only when 
> > reading multi-volume *compressed* dumps (and indeed, this is what I
> > use myself). I wonder whether uncompressed dumps need a special treatement
> > or not...
> > 
> Works fine if I compress with -z1. Since the data wasn't too compressable I
> had decided to not compress. With compression does a read error make
> the rest of the backup unreadable or does the decompression resync?

Each block is compressed individually so it should resync.

> Might be good to document the interaction of -V and compression if not
> done already.

I'll do.

Did you try to burn with -dao as someone suggested ?

Stelian.
-- 
Stelian Pop <st...@po...>    

Re: [Dump-users] dump & cdrecord

[Helmut J. <jar...@ig...>]

On 20 Dec, David Gesswein wrote:
>> That's what the restore -V option is there for. 
>> 
>> Correction: looking at the source I see that -V is used only when 
>> reading multi-volume *compressed* dumps (and indeed, this is what I
>> use myself). I wonder whether uncompressed dumps need a special treatement
>> or not...
>> 
> Works fine if I compress with -z1. Since the data wasn't too compressable I
> had decided to not compress. With compression does a read error make
> the rest of the backup unreadable or does the decompression resync?
> 
> Might be good to document the interaction of -V and compression if not
> done already.

1st) you can take -y  (lzo compression) which is really fast
2nd) with -y each block is compressed individually, i.e.
     if some block has a read error cdrecord might continue,
     but the compressed block contains a length field.
     I am not sure what will happen if this is completely
     unreasonable.
     
-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Re: [Dump-users] dump & cdrecord

[David G. <dj...@dr...>]

> That's what the restore -V option is there for. 
> 
> Correction: looking at the source I see that -V is used only when 
> reading multi-volume *compressed* dumps (and indeed, this is what I
> use myself). I wonder whether uncompressed dumps need a special treatement
> or not...
> 
Works fine if I compress with -z1. Since the data wasn't too compressable I
had decided to not compress. With compression does a read error make
the rest of the backup unreadable or does the decompression resync?

Might be good to document the interaction of -V and compression if not
done already.