Stand-alone slices
<[email protected]> Sun, 1 Feb 2009 0:47:17 -0500
| Newsgroups | gmane.comp.sysutils.backup.dar.general |
|---|---|
| Message-ID | <20090201004717.SQ6IF.694280.imail@eastrmwml48> |
My hard drive just crashed, but luckily I didn't lose any important data as it was on another hard drive. So I'm trying to use dar and par2 to create backups that will span multiple dvds. This is not a support question, however. Basically, I see that individual slices are pretty much worthless without the catalogue. So from what I understand, the catalogue holds a list of all the files in the archive and their offsets in the large virtual file. Then when you go to actually restore a file, the virtual offset is translated into a slice number and slice offset. Furthermore, I see that you can isolate the catalogue and encode no data. Finally, I read that you can extract files individually, and you will only require the slice(s) where the file actually resides in the archive. You do, however, appear to need the catalogue from the first slice to determine what files are in the archive and where they fall in the virtual file (and hence the slices). So I am wondering if a semi-acceptable solution to the stand-alone slice issue could be to provide a means of isolating the catalogue so that the user could optionally write it as a separate file to each piece of media. Then, when a certain file was called for, the virtual address would translate into a slice offset. The program would prompt the user to provide the correct slice. That way, if I lost all my backup dvd's except for 1, then I would still be able to extract any files from that single slice, and I would just be out of luck for the rest. I'm sure I'm missing something here, but I don't see the problem with this. (of course it wouldn't be as space efficient, but then again neither is using par2). Bill ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword