From: SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 11-APR-1994 17:26:00.86 To: EVERHART CC: Subj: Re: HELP! Hard drive reformatted accidentally! Date: Mon, 11 Apr 1994 12:53:04 -0700 (PDT) From: DEREK@U.WASHINGTON.EDU Subject: Re: HELP! Hard drive reformatted accidentally! Sender: "Derek S. Haining, Univ. of Washington, 206-685-2502" To: INFO-VAX@SRI.COM Cc: Jon.Wildstrom@LAUNCHPAD.UNC.EDU, wayne@TACHYON.COM Message-id: <01HB1RDULEYW9POMYJ@MAX.U.WASHINGTON.EDU.L> X-Envelope-to: INFO-VAX@SRI.COM X-VMS-To: IN%"INFO-VAX@SRI.COM" X-VMS-Cc: IN%"Jon.Wildstrom@LAUNCHPAD.UNC.EDU",IN%"wayne@TACHYON.COM",DEREK MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Jonathan Wildsrr trom pleads: >Help! Our Vax hard drive was reformatted accidentally last night! I'm not >entirely sure of the circumstances (I'm not the SysAdmin) but all our >accounts are on there. We can now log in (The system Disk is fine) but we >have no accounts to do things in, just telnet privileges. Is there some >_reliable_ unformat utility that I can get a hold of. Preferably cheap or >free (our SysAdmin doesn't want to spend a ton of money on this) Can >someone _Please_help me? Thanks in advance. Wayne Sewell responded: ... >Undeleting files is difficult/impossible enough, but >uninitializing a disk is yet another level of difficulty. The actual files may >be out there somewhere (unless init/erase was used), but all your file headers >are gone. You can't determine which logical blocks on the disk contain which >files. Even if you could, you've lost all your file attributes as well (file >type, blocksize; essentially everything that shows up in dir/full), because >those live in the file header. [NOT REALLY A PROBLEM -- IN SOME CASES] >Looking at the writeup for initialize in VMS File System Internals, I can't >determine if all the old file headers in the index file are overwritten (I >don't have source listings). If they are not, it might be possible to recover >some files by ignoring the file header allocation bit map and looking at all >file headers. It would be haphazard at best, because there is no way to >determine which file headers were valid at the time of the init. They would be >intermixed with file headers that had been valid at one time, but no longer. >Also, some of them would have been overwritten by headers for new files. [SEE BELOW] >Even if you could reconstruct the file headers, you would be back to the >traditional file undelete problem: the blocks belonging to the files have been >marked as free, so they may have been reallocated to new files and overwritten. [NOT A PROBLEM] >If your disk really was low-level formatted, or if init/erase was used, then >you are *really* out of luck, because all blocks on the disk have been >overwritten. [THIS *IS* A PROBLEM] I have had the pleasure of restoring three disks here at the University of Washington. In one instance the BITMAP.SYS developed a bad block. Recovery of this disk was declared impossible by CSC. I accomplished it by, as Wayne and other mentioned, mounting the disk /FOREIGN, finding unused blocks on the disk, modifying the retrieval pointers for BITMAP.SYS to use these other blocks, and, finally, using ANALYZE /DISK /REPAIR to "correct" the "new" BITMAP.SYS file. Worked like a charm. In another instance, which occurred a year before the BITMAP problem, a user was attempting to INITIALIZE a disk, but entered the wrong disk name in by mistake. Again, recovery was accomplished by mounting the disk /FOREIGN. (The third instance was similar, and involved recovering files on an INFOSERVER disk. Some of these file were unrecoverable as the upgrade to the INFOSERVER software overwrote some of the files.) The procedure took about 3 hours, as I had no pre-written programs around to accomplish the task. The solution gets into a topic which was recently discussed on this list -- the expansion of the INDEXF.SYS file. Basically, the INDEXF.SYS file has 4 extents on a newly initialized disk. The first extent contains the boot block (cluster). The next contains the home block (cluster). The next contains an alternate home block (cluster). The fourth extent contains the INDEXF BITMAP of file headers and the first 16 headers. Of these, the first 9 or so are reserved for the .SYS files and the MFD ([000000]). When the INDEXF.SYS has to be extended, the 1000 block "magic number" is used. I know, I saw Carl's posting about a 1500 block extent size. I tried years ago to set the disk default extend size to 5000 blocks, but the INDEXF.SYS file still only extended by ~1000 blocks at a time. (User files, however...) I don't recall if I tried setting the default extend size for the FILE itself... I am sure the algorithm has changed occasionally. Anyway, I started a procedure to troll the disk. I used dump to look at every 1000th block on the disk. E.g., $ DUMP /BLOCK=(START:lbn, COUNT:1) /OUT=dump.lbn ddcu: I then used SEARCH to search each output file for the "special longword" which occurred as the first longword of every file header. As I recall, it was FFFF6428 -- they weren't using ACLs. With an ACL present the number is different. For those blocks which contained a file header, I did a binary search around that block to find the starting and ending blocks of this extent. I also determined WHICH file ID range this extent contained. After I found all of the extents, I wrote a file header editor utility to patch the header for the INDEXF.SYS file. (This also had to recalculate the header checksum.) I constructed new retrieval pointers for each extent (by hand) and placed these into the header. When I had all of these entered, I dismounted the disk and mounted it "normally" -- but not /SYSTEM. I then used ANALYZE /DISK /NOREPAIR to check out my work. (I also logged all changes to the header in case I had to back anything out.) When I was convinced that it was OK, I let ANALYZE /DISK repair the alternate headers. This worked like a charm. Some caveats are: o You want to be sure that the volume was INITIALIZED THE SAME WAY IT WAS "BEFORE". If you PLACED the INDEXF.SYS file, or allocated MORE/LESS headers than before, the NEW INDEXF.SYS will NOT allocate the same blocks that the OLD file used. o The last few blocks of the INDEXF.SYS file MAY NOT BE INITIALIZED! When I have seen this before, the block was zero filled. NOTE: This also caused DFO V1.0 (and perhaps V1.1 and V1.1A) some headaches because it deems the INDEXF.SYS file corrupt. Anyway, as a result you may not find the last extent -- especially if only a few headers are in use. I started to write some programs to further automate this task, and have one which attempts to find all of the extents. It does this by first looking at every 1000th block. If it finds a range of the INDEXF.SYS missing, it rescans the disk at every 500th block, and then every 250th, etc... On the INFOSERVER disk I recovered, the INDEXF.SYS file was placed in a new location for the new software. In this case I found INDEXF.SYS fragments all over the place -- for THREE DIFFERENT INCARNATIONS OF THE DISK. (It was a field test machine which had sat on the desk of one of the developers before it shipped to me. I figured out which fragment belonged to which version based upon dates in the file headers. :)) Anyway, DEC used to offer a service through field service which used a SALVAGE (sp) utility. The cost was $200.00/hr with a 4 hour minimum and no guarantees. All of this info applies only to disks which were simply INITIALIZED -- not INIT/ERASEd. Your best bet is PROBABLY to simply restore from the BACKUP saveset which was just written before the damage was done. (Hoping you have one.) In the the cases I mentioned neither disk had had a backup done on it. Feel free to contact me, and good luck. -Derek S. Haining Division of Cardiothoracic Surgery University of Washington Seattle, Washington 98195 (206) 685-2502 DEREK@MAX.BITNET DEREK@MAX.U.WASHINGTON.EDU