[9fans] Disk backup?

[9fans] Disk backup?

[trebol]

Hi everyone,

What is the more efficient backup procedure in Plan 9 do you recommend?

I'm using cwfs and I think "9fs dump" is incredible - I can recover
that thing I dropped a month ago and now I am regret for doing that -
but the disk failure nightmare is always present.

thanks in advance,
trebol.

Re: [9fans] Disk backup?

[erik quanstrom]

On Sun Mar 24 18:12:34 EDT 2013, trebol55555@yahoo.es wrote:
> Hi everyone,
>
> What is the more efficient backup procedure in Plan 9 do you recommend?
>
> I'm using cwfs and I think "9fs dump" is incredible - I can recover
> that thing I dropped a month ago and now I am regret for doing that -
> but the disk failure nightmare is always present.

if you can afford it, i'd make a periodic copy of the dump device to
another disk in the same machine.  i might even consider just copying
the whole disk.

since cwfs (and venti) have a worm structure, you can also (or additionally)
back up incrementally to optical media.  backup(8) has some details on some
excellent work geoff did, but it might be a tad venti-specific.

since i am used to having rather large worms, and i don't have a blu-ray,
i usually use vblade(8), or a hardware aoe target to present a disk, partition,
or file as a target for backup images.

- erik

[9fans] Disk backup?

[trebol]

> if you can afford it, i'd make a periodic copy of the dump device to
> another disk in the same machine.  i might even consider just copying
> the whole disk.

I've had bad experiences with CDs and DVDs, so I'm going to follow
your advise and just copy the whole dump device; and keep reading the
documentation, but I think in the future I'll ask the list about the
correct restoration of the dump.

Thanks a lot!

trebol.

Re: [9fans] Disk backup?

[arisawa]

that takes so long time.

it is better to have efficient backup tool. (but not exists yet though)
cwfs is not so easy to backup compared to venti.
venti is easy to backup because filled areas are shielded and guaranteed not to be modified.
but cwfs is not. unwritten blocks exist in deep dumped area. 
these blocks might be written in future.

On 2013/03/25, at 11:04, trebol <trebol55555@yahoo.es> wrote:

>> if you can afford it, i'd make a periodic copy of the dump device to
>> another disk in the same machine.  i might even consider just copying
>> the whole disk.
> 
> I've had bad experiences with CDs and DVDs, so I'm going to follow
> your advise and just copy the whole dump device; and keep reading the
> documentation, but I think in the future I'll ask the list about the
> correct restoration of the dump.
> 
> Thanks a lot!
> 
> trebol.
> 

Re: [9fans] Disk backup?

[cinap_lenrek]

i was thinking about this some time ago... theres the fakeworm
device "f<subdevice>" that will maintain a block bitmap of
the blocks that have already been written. one could write
a program that also backups the block bitmap and on backup,
compares the bitmaps prior copying blocks so only newly
written blocks get backed up.

--
cinap

Re: [9fans] Disk backup?

[arisawa]

thanks cinap,

I believed you are interested on this topic.

assuming we don't modify current cwfs code,
the only way to solve the problem is to have list of unwritten blocks up to last superblock 
(or bitmap of written blocks)
cwfs might manage the list, but I don't know where it is.

inspecting block tags of fsworm gives us information for having the list.
but my fsworm is old one that have been used elsewhere, and full of garbage data.
then block tag of fsworm is unreliable. 
we have small probability to misunderstand that some of unwritten blocks is as written blocks.
to avoid this problem, we must format fsworm putting some special tag on each block.
this will take long time, but only once.
do you have any alternative solution?


On 2013/03/25, at 13:36, cinap_lenrek@gmx.de wrote:

> i was thinking about this some time ago... theres the fakeworm
> device "f<subdevice>" that will maintain a block bitmap of
> the blocks that have already been written. one could write
> a program that also backups the block bitmap and on backup,
> compares the bitmaps prior copying blocks so only newly
> written blocks get backed up.
> 
> --
> cinap
> 

Re: [9fans] Disk backup?

[cinap_lenrek]

the block bitmap on a fakeworm is at the end of the sub
device/partition. see fworm.c:

int
fwormread(Device *d, Off b, void *c)
{
	Iobuf *p;
	Device *fdev;
	Devsize l;

	if(chatty > 1)
		fprint(2, "fworm read  %lld\n", (Wideoff)b);
	fdev = FDEV(d);
	l = devsize(fdev);
	l -= l/(BUFSIZE*8) + 1;
	if(b >= l)
		panic("fworm: rbounds %lld", (Wideoff)b);
	l += b/(BUFSIZE*8);

	p = getbuf(fdev, l, Brd|Bres);
	if(!p || checktag(p, Tvirgo, l))
		panic("fworm: checktag %lld", (Wideoff)l);
	l = b % (BUFSIZE*8);
	if(!(p->iobuf[l/8] & (1<<(l%8)))) {
		putbuf(p);
		fprint(2, "fworm: read %lld\n", (Wideoff)b);
		return 1;
	}
	putbuf(p);
	return devread(fdev, b, c);
}

the block tags do not really matter for the backup. you use the
fakeworm only as a backend for the cw device so you can just
copy all the blocks that got ther bit set in the bitmap compared
to the backup.

--
cinap

Re: [9fans] Disk backup?

[arisawa]

oh! nice!
that resolves all.
thanks a lot
i will try

On 2013/03/25, at 16:19, cinap_lenrek@gmx.de wrote:

> the block bitmap on a fakeworm is at the end of the sub
> device/partition. see fworm.c:
>
> int
> fwormread(Device *d, Off b, void *c)
> {
> 	Iobuf *p;
> 	Device *fdev;
> 	Devsize l;
>
> 	if(chatty > 1)
> 		fprint(2, "fworm read  %lld\n", (Wideoff)b);
> 	fdev = FDEV(d);
> 	l = devsize(fdev);
> 	l -= l/(BUFSIZE*8) + 1;
> 	if(b >= l)
> 		panic("fworm: rbounds %lld", (Wideoff)b);
> 	l += b/(BUFSIZE*8);
>
> 	p = getbuf(fdev, l, Brd|Bres);
> 	if(!p || checktag(p, Tvirgo, l))
> 		panic("fworm: checktag %lld", (Wideoff)l);
> 	l = b % (BUFSIZE*8);
> 	if(!(p->iobuf[l/8] & (1<<(l%8)))) {
> 		putbuf(p);
> 		fprint(2, "fworm: read %lld\n", (Wideoff)b);
> 		return 1;
> 	}
> 	putbuf(p);
> 	return devread(fdev, b, c);
> }
>
> the block tags do not really matter for the backup. you use the
> fakeworm only as a backend for the cw device so you can just
> copy all the blocks that got ther bit set in the bitmap compared
> to the backup.
>
> --
> cinap
>

Re: [9fans] Disk backup?

[erik quanstrom]

On Mon Mar 25 00:37:51 EDT 2013, cinap_lenrek@gmx.de wrote:
> i was thinking about this some time ago... theres the fakeworm
> device "f<subdevice>" that will maintain a block bitmap of
> the blocks that have already been written. one could write
> a program that also backups the block bitmap and on backup,
> compares the bitmaps prior copying blocks so only newly
> written blocks get backed up.

the fakeworm device causes more trouble than it's worth.  and
there's no reason other than tradition to use it.  if you simply
drop the "f" from an existing configuration that uses it, you'll
be free of the little nanny that will break things if you device
size changes by a little, say from running from a backup, or
you need to recover a botched dump.

it's much simplier just to do a bit copy and know that the same
configuration will run as long as the existing worm will fit.

- erik

Re: [9fans] Disk backup?

[erik quanstrom]

> it is better to have efficient backup tool. (but not exists yet though)
> cwfs is not so easy to backup compared to venti.
> venti is easy to backup because filled areas are shielded and guaranteed not to be modified.
> but cwfs is not. unwritten blocks exist in deep dumped area.
> these blocks might be written in future.

untrue.  these unwritten blocks are never used.  the dump
consists of only blocks with a waddr greater than the last
superblock's waddr.  /sys/src/fs/dev/cw.c:/^dumpblock is a good
reference.

- erik

Re: [9fans] Disk backup?

[arisawa]

Hello erik,

look free block list in superblocks, and observe their changes.
then you will find some of these free blocks are consumed for new file contents.
if not, your system and mine is different.

On 2013/03/26, at 0:03, erik quanstrom <quanstro@quanstro.net> wrote:

>> it is better to have efficient backup tool. (but not exists yet though)
>> cwfs is not so easy to backup compared to venti.
>> venti is easy to backup because filled areas are shielded and guaranteed not to be modified.
>> but cwfs is not. unwritten blocks exist in deep dumped area. 
>> these blocks might be written in future.
> 
> untrue.  these unwritten blocks are never used.  the dump
> consists of only blocks with a waddr greater than the last
> superblock's waddr.  /sys/src/fs/dev/cw.c:/^dumpblock is a good
> reference.
> 
> - erik
> 

Re: [9fans] Disk backup?

[erik quanstrom]

On Tue Mar 26 03:28:07 EDT 2013, arisawa@ar.aichi-u.ac.jp wrote:
> Hello erik,
>
> look free block list in superblocks, and observe their changes.
> then you will find some of these free blocks are consumed for new file contents.
> if not, your system and mine is different.

i have seen the superblock[n-1] gets modified as superblock[n] gets
written, but superblock[n-1] stays in the cache.  i assumed this was
because the new superblock was deleted from the free list, but didn't
look into it.  "recover main" drops this info.

this is a slight annoyance, but not a bug.  if new files are put below
waddr, that's a bug.

i use ken's file server, not cwfs.

- erik

Re: [9fans] Disk backup?

[cinap_lenrek]

i looked at kenfs's dumpblock() from /n/sources/extra/fs/fs/dev/cw.c
but i do not see what you mean. the code just goes thru the cache
looking for a block to dump while trying to get one as close to
the previous dumped block address as possible in both directions.
(trying to avoid seeks?)

can you point to the specific code that makes sure that blocks
get only written to the worm after the previous superblock?

what makes me think (i could be wrong here) that the assumption
does *not* hold is this (using kenfs here from /n/sources/extra/fs):

blocks have the following states:

	/* states -- beware these are recorded on the cache */
				/*    cache    worm	*/
	Cnone = 0,		/*	0	?	*/
	Cdirty,			/*	1	0	*/
	Cdump,			/*	1	0->1	*/
	Cread,			/*	1	1	*/
	Cwrite,			/*	2	1	*/
	Cdump1,			/* inactive form of dump */
	Cerror,

the blocks maintained in the freelist should be blocks not already written
to the worm. like, when we delete a file that was already written to the
worm (states Cread, Cwrite), it is not put into the freelist and we'll
just forget about it. however, if the block was just in the cache (Cdirty)
it *is* put on the freelist:

int
cwfree(Device *dev, Off addr)
{
	int state;

	if(dev->type == Devcw) {
		state = cwio(dev, addr, 0, Ofree);
		if(state != Cdirty)
			return 1;	/* do not put in freelist */
	}
	return 0;			/* put in freelist */
}

now, such a Cdirty block could just sit in the freelist for a while no?
while the filesystem does many dump generations. if that Cdirty block
becomes part of the filesystem again because it is allocated, then
the next cwrecur() should pick it up and call split() on it.

Off
split(Cw *cw, Iobuf *p, Off addr)
{
	Off na;
	int state;

	na = 0;
	if(p && (p->flags & Bmod)) {
		p->flags |= Bimm;
		putbuf(p);
		p = 0;
	}
	state = cwio(cw->dev, addr, 0, Onone);	/* read the state (twice?) */
	switch(state)
	{
	default:
		panic("split: unknown state %s", cwnames[state]);

	case Cerror:
	case Cnone:
	case Cdump:
	case Cread:
		break;

	case Cdump1:
	case Cwrite:
		/*
		 * botch.. could be done by relabeling
		 */
		if(!p) {
			p = getbuf(cw->dev, addr, Bread);
			if(!p) {
				print("split: null getbuf\n");
				break;
			}
		}
		na = cw->fsize;
		cw->fsize = na+1;
		cwio(cw->dev, na, 0, Ogrow);
		cwio(cw->dev, na, p->iobuf, Owrite);
		cwio(cw->dev, na, 0, Odump);
		cwio(cw->dev, addr, 0, Orele);
		break;

	case Cdirty:
		cwio(cw->dev, addr, 0, Odump); // <- *here*
		break;
	}
	if(p)
		putbuf(p);
	return na;
}

we see in this case, that we wont make a new address for the block, but
we'll just mark it for dumping at its original address which i think
is not limited to after the last dumps superblock address.

in the other case, when that block already had a version in the worm
(Cdump1, Cwrite) it is indeed copied to the end of the filesystem like
i think you ment by saying it will fill the worm only after the previous
dumped superblock.

does this make any sense?

--
cinap

Re: [9fans] Disk backup?

[erik quanstrom]

> int
> cwfree(Device *dev, Off addr)
> {
> 	int state;
>
> 	if(dev->type == Devcw) {
> 		state = cwio(dev, addr, 0, Ofree);
> 		if(state != Cdirty)
> 			return 1;	/* do not put in freelist */
> 	}
> 	return 0;			/* put in freelist */
> }
>
> now, such a Cdirty block could just sit in the freelist for a while no?
> while the filesystem does many dump generations. if that Cdirty block
> becomes part of the filesystem again because it is allocated, then
> the next cwrecur() should pick it up and call split() on it.

why wouldn't it be marked for dump on the very
first dump?

- erik

Re: [9fans] Disk backup?

[cinap_lenrek]

because it is never visited by cwrecur(). the block isnt part of the
active filesystem. its just sitting in the freelist. cwrecur() just
walks from the root directory down following the trail of dirty
modified blocks but it is not walking the freelist.

--
cinap

Re: [9fans] Disk backup?

[erik quanstrom]

On Tue Mar 26 15:08:13 EDT 2013, cinap_lenrek@gmx.de wrote:
> because it is never visited by cwrecur(). the block isnt part of the
> active filesystem. its just sitting in the freelist. cwrecur() just
> walks from the root directory down following the trail of dirty
> modified blocks but it is not walking the freelist.

if it's not part of the active file system, then how could it be allocated
as part of a new file?

- erik

Re: [9fans] Disk backup?

[erik quanstrom]

On Tue Mar 26 15:08:13 EDT 2013, cinap_lenrek@gmx.de wrote:
> because it is never visited by cwrecur(). the block isnt part of the
> active filesystem. its just sitting in the freelist. cwrecur() just
> walks from the root directory down following the trail of dirty
> modified blocks but it is not walking the freelist.

sorry.  i see now.  why the exception for dirty blocks?
that's hard to understand.

- erik

Re: [9fans] Disk backup?

[cinap_lenrek]

because that worm address is still perfectly usable for storage. i
dont know how common this case is tho. maybe you could live with
abandoning these worm blocks on dump and get an append only worm
structure in return and not waste too much space.

--
cinap

Re: [9fans] Disk backup?

[arisawa]

Hello,

Now I think,
pseudo-RAID1 configuration
c(/dev/sdC0/fscache){(/dev/sdC0/fsworm)(/dev/sdD0/fsworm)}
might be a best solution.
I have no experience this configuration.
anyone tried it?


On 2013/03/25, at 11:04, trebol <trebol55555@yahoo.es> wrote:

>> if you can afford it, i'd make a periodic copy of the dump device to
>> another disk in the same machine.  i might even consider just copying
>> the whole disk.
>
> I've had bad experiences with CDs and DVDs, so I'm going to follow
> your advise and just copy the whole dump device; and keep reading the
> documentation, but I think in the future I'll ask the list about the
> correct restoration of the dump.
>
> Thanks a lot!
>
> trebol.
>

Re: [9fans] Disk backup?

[erik quanstrom]

> Hello,
>
> Now I think,
> pseudo-RAID1 configuration
> c(/dev/sdC0/fscache){(/dev/sdC0/fsworm)(/dev/sdD0/fsworm)}
> might be a best solution.
> I have no experience this configuration.
> anyone tried it?

from iwp9 2e, http://www.quanstro.net/plan9/disklessfs.pdf
we take advantage of the mirror (don't confuse it with raid1)
by putting the second copy in another building.  there is
never a performance impact to doing this.

- erik

[9fans] Disk backup?

[trebol]

I see a lot of interesting things on this thread, but all of those are
beyond my knowledge.  I'm just starting to learn programming (K&R),
the internal structure of the file system is too much for me now. I'm
thinking about mount dump, and copy the /n/dump directory to other system
(linux). So my questions are:

- Is there a way to simulate the incremental backup feature of gnu tar?
- Is possible to restore the system in a new disk with this copy of dump?
- What do you recommend me for send the tar file, ssh, nfs or other thing?

thanks,
trebol.

Re: [9fans] Disk backup?

[arisawa]

hmm...

did you compared incremental backup of gnu tar with pdumpfs?
i guess pdumpfs is much reliable and convenient.

pdumpfs(pseudo dumpfs, i guess) runs on UNIX, the same mechanism is applied to TimeMachine of Mac.


On 2013/03/27, at 8:22, trebol <trebol55555@yahoo.es> wrote:

> I see a lot of interesting things on this thread, but all of those are
> beyond my knowledge.  I'm just starting to learn programming (K&R),
> the internal structure of the file system is too much for me now. I'm
> thinking about mount dump, and copy the /n/dump directory to other system
> (linux). So my questions are:
> 
> - Is there a way to simulate the incremental backup feature of gnu tar?
> - Is possible to restore the system in a new disk with this copy of dump?
> - What do you recommend me for send the tar file, ssh, nfs or other thing?
> 
> thanks,
> trebol.
> 

Re: [9fans] Disk backup?

[erik quanstrom]

On 2013/03/27, at 8:22, trebol <trebol55555@yahoo.es> wrote:

> I see a lot of interesting things on this thread, but all of those are
> beyond my knowledge.  I'm just starting to learn programming (K&R),
> the internal structure of the file system is too much for me now. I'm
> thinking about mount dump, and copy the /n/dump directory to other system
> (linux). So my questions are:
>
> - Is there a way to simulate the incremental backup feature of gnu tar?
> - Is possible to restore the system in a new disk with this copy of dump?
> - What do you recommend me for send the tar file, ssh, nfs or other thing?

here's how i copied one ken file server to another preserving
the history.  this is equivalent to making an incremental backup
each day at the file, not the block level.  the only difference is
a file system was made, rather than a a mkfs archive of changes
for each day of the dump.

http://www.quanstro.net/plan9/history.pdf

- erik