* [9fans] Disk backup? @ 2013-03-24 22:10 trebol 2013-03-25 0:33 ` erik quanstrom 0 siblings, 1 reply; 23+ messages in thread From: trebol @ 2013-03-24 22:10 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-24 22:10 [9fans] Disk backup? trebol @ 2013-03-25 0:33 ` erik quanstrom 2013-03-25 2:04 ` trebol 0 siblings, 1 reply; 23+ messages in thread From: erik quanstrom @ 2013-03-25 0:33 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* [9fans] Disk backup? 2013-03-25 0:33 ` erik quanstrom @ 2013-03-25 2:04 ` trebol 2013-03-25 3:14 ` arisawa ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: trebol @ 2013-03-25 2:04 UTC (permalink / raw) To: 9fans > 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 2:04 ` trebol @ 2013-03-25 3:14 ` arisawa 2013-03-25 4:36 ` cinap_lenrek 2013-03-25 15:03 ` erik quanstrom 2013-03-26 7:07 ` arisawa 2013-03-26 23:22 ` trebol 2 siblings, 2 replies; 23+ messages in thread From: arisawa @ 2013-03-25 3:14 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 3:14 ` arisawa @ 2013-03-25 4:36 ` cinap_lenrek 2013-03-25 5:46 ` arisawa 2013-03-25 13:43 ` erik quanstrom 2013-03-25 15:03 ` erik quanstrom 1 sibling, 2 replies; 23+ messages in thread From: cinap_lenrek @ 2013-03-25 4:36 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 4:36 ` cinap_lenrek @ 2013-03-25 5:46 ` arisawa 2013-03-25 7:19 ` cinap_lenrek 2013-03-25 13:43 ` erik quanstrom 1 sibling, 1 reply; 23+ messages in thread From: arisawa @ 2013-03-25 5:46 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 5:46 ` arisawa @ 2013-03-25 7:19 ` cinap_lenrek 2013-03-25 7:32 ` arisawa 0 siblings, 1 reply; 23+ messages in thread From: cinap_lenrek @ 2013-03-25 7:19 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 7:19 ` cinap_lenrek @ 2013-03-25 7:32 ` arisawa 0 siblings, 0 replies; 23+ messages in thread From: arisawa @ 2013-03-25 7:32 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 4:36 ` cinap_lenrek 2013-03-25 5:46 ` arisawa @ 2013-03-25 13:43 ` erik quanstrom 1 sibling, 0 replies; 23+ messages in thread From: erik quanstrom @ 2013-03-25 13:43 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 3:14 ` arisawa 2013-03-25 4:36 ` cinap_lenrek @ 2013-03-25 15:03 ` erik quanstrom 2013-03-26 7:27 ` arisawa 1 sibling, 1 reply; 23+ messages in thread From: erik quanstrom @ 2013-03-25 15:03 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 15:03 ` erik quanstrom @ 2013-03-26 7:27 ` arisawa 2013-03-26 13:19 ` erik quanstrom 0 siblings, 1 reply; 23+ messages in thread From: arisawa @ 2013-03-26 7:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 7:27 ` arisawa @ 2013-03-26 13:19 ` erik quanstrom 2013-03-26 18:34 ` cinap_lenrek 0 siblings, 1 reply; 23+ messages in thread From: erik quanstrom @ 2013-03-26 13:19 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 13:19 ` erik quanstrom @ 2013-03-26 18:34 ` cinap_lenrek 2013-03-26 18:56 ` erik quanstrom 0 siblings, 1 reply; 23+ messages in thread From: cinap_lenrek @ 2013-03-26 18:34 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 18:34 ` cinap_lenrek @ 2013-03-26 18:56 ` erik quanstrom 2013-03-26 19:07 ` cinap_lenrek 0 siblings, 1 reply; 23+ messages in thread From: erik quanstrom @ 2013-03-26 18:56 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 18:56 ` erik quanstrom @ 2013-03-26 19:07 ` cinap_lenrek 2013-03-26 19:10 ` erik quanstrom 2013-03-26 19:15 ` erik quanstrom 0 siblings, 2 replies; 23+ messages in thread From: cinap_lenrek @ 2013-03-26 19:07 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 19:07 ` cinap_lenrek @ 2013-03-26 19:10 ` erik quanstrom 2013-03-26 19:15 ` erik quanstrom 1 sibling, 0 replies; 23+ messages in thread From: erik quanstrom @ 2013-03-26 19:10 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 19:07 ` cinap_lenrek 2013-03-26 19:10 ` erik quanstrom @ 2013-03-26 19:15 ` erik quanstrom 2013-03-26 19:23 ` cinap_lenrek 1 sibling, 1 reply; 23+ messages in thread From: erik quanstrom @ 2013-03-26 19:15 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 19:15 ` erik quanstrom @ 2013-03-26 19:23 ` cinap_lenrek 0 siblings, 0 replies; 23+ messages in thread From: cinap_lenrek @ 2013-03-26 19:23 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-25 2:04 ` trebol 2013-03-25 3:14 ` arisawa @ 2013-03-26 7:07 ` arisawa 2013-03-26 12:52 ` erik quanstrom 2013-03-26 23:22 ` trebol 2 siblings, 1 reply; 23+ messages in thread From: arisawa @ 2013-03-26 7:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 7:07 ` arisawa @ 2013-03-26 12:52 ` erik quanstrom 0 siblings, 0 replies; 23+ messages in thread From: erik quanstrom @ 2013-03-26 12:52 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* [9fans] Disk backup? 2013-03-25 2:04 ` trebol 2013-03-25 3:14 ` arisawa 2013-03-26 7:07 ` arisawa @ 2013-03-26 23:22 ` trebol 2013-03-28 7:51 ` arisawa 2 siblings, 1 reply; 23+ messages in thread From: trebol @ 2013-03-26 23:22 UTC (permalink / raw) To: 9fans 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. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-26 23:22 ` trebol @ 2013-03-28 7:51 ` arisawa 2013-03-28 13:17 ` erik quanstrom 0 siblings, 1 reply; 23+ messages in thread From: arisawa @ 2013-03-28 7:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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. > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Disk backup? 2013-03-28 7:51 ` arisawa @ 2013-03-28 13:17 ` erik quanstrom 0 siblings, 0 replies; 23+ messages in thread From: erik quanstrom @ 2013-03-28 13:17 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2013-03-28 13:17 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-03-24 22:10 [9fans] Disk backup? trebol 2013-03-25 0:33 ` erik quanstrom 2013-03-25 2:04 ` trebol 2013-03-25 3:14 ` arisawa 2013-03-25 4:36 ` cinap_lenrek 2013-03-25 5:46 ` arisawa 2013-03-25 7:19 ` cinap_lenrek 2013-03-25 7:32 ` arisawa 2013-03-25 13:43 ` erik quanstrom 2013-03-25 15:03 ` erik quanstrom 2013-03-26 7:27 ` arisawa 2013-03-26 13:19 ` erik quanstrom 2013-03-26 18:34 ` cinap_lenrek 2013-03-26 18:56 ` erik quanstrom 2013-03-26 19:07 ` cinap_lenrek 2013-03-26 19:10 ` erik quanstrom 2013-03-26 19:15 ` erik quanstrom 2013-03-26 19:23 ` cinap_lenrek 2013-03-26 7:07 ` arisawa 2013-03-26 12:52 ` erik quanstrom 2013-03-26 23:22 ` trebol 2013-03-28 7:51 ` arisawa 2013-03-28 13:17 ` erik quanstrom
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).