On Mon, 2008-11-24 at 06:14 -0800, Steve Haley wrote: > Not sure if it is related, but we've had the same error appear if we > try to restore a 3.4 jbackup made on a aix server to a windows server > if the hash files have any triggers. I've never figured a direct way > around it - we either redo the backup without the triggers or restore > the file on an aix box, remove the triggers, resave, and then restore > the windows server. >
It's certainly a possibility, but my feeling is that the the save was bad in the first place. I don't know if this has changed in later releases (I think it was) but jbackup used to just print "corrupt file" and carry on, so you never realized that the save was no good. If you have triggers ont hat file then I suppose that indicates the error Steve is referring to. Recovery, if jrestore does not already recover from the error point would be quote involved. First you have to determine the offset in the file where it goes wrong (this is really a job for *nix), then determine the fault (which means you would have to know something about the save structure, though it is pretty easy to infer as this is, ironically, one way backups are more reliable (make them simple). The thing you then have to do is fix that piece of the file with a hex editor, which basically means hacking it into some structure that jrestore can deal with (even if the data you get is screwed) such that it can move past that point. That assumes of course that there is in fact any data past that point (does the offset look like it might be the end of the backup image?) Other thigsn to check: 1) How did you get this image - ftp? dvd? Did you copy it in binary mode? 2) Was it > 2GB and caused some transfer mechanism in the process to screw up? 3) Can you restore it in AIX? If so then you can look for things like triggers and take them off and jbackup again. However, if AIX won't restore the image, then you may be screwed. On backups: 1) Always verify the backup image; 2) Keep the output of the backup with the image so you can refer to it later; 3) Restore one backup once a week or so to make sure you are backing up what you think you are; 4) Review horror stories of what went wrong with peoples backups (never changing tapes, not realizing they were backing up nothing, not realizing they were backing up the wrong stuff, etc). Almost all problems stem from not verifying the backups that are there, rather than not actually making any backups. Jim > Steve > CMI > > On Nov 21, 11:31 am, "Simon Verona" <[EMAIL PROTECTED]> wrote: > > I’m looking to restore some data from an AIX 4.3 server running jbase > > 3.3.9. > > > > The backup was made using jBackup. > > > > When I restore onto my Windows 2003 server running jbase.3.4.10 , I get > > about 400mb of data and then the following : > > > > Hash file \adp\data\MODEMS\LEX-TMP-27 > > > > ERROR! Unknown record segment type '0' found > > > > Buffer - c0000000130þ/adp/data/MODEMS/PARTS > > > > þ0þ88 > > > > Scanned Files : 2017 > > > > Blocks : 30839 > > > > Reels : 1 > > > > Restored Directories : 99 > > > > Regular files : 929 > > > > Linked files : 0 > > > > Other files : 0 > > > > Hash files : 949 > > > > Hash records : 3169181 > > > > 481.8594 MB processed > > > > > --~--~---------~--~----~------------~-------~--~----~ Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en -~----------~----~----~----~------~----~------~--~---
