A little story for you administrators… one with a good ending (I think…)
I had a user approach me last week. He’d been saving an archive for years in the hopes that he could access it. Since we’d moved to R7 “recently” (darn near a year!) he thought it was that time.
He didn’t have any details, just a 1 GB file that was inaccessible to him. I had him drop that out on a share and pulled it down locally.
When opening it up locally it failed with an “Invalid or Nonexistant document” error. Servers can be quite useful for cleaning up corruption so I moved the file on over to one of our test boxes. This time it threw out the dreaded RRV Bucket Corrupt error message.
It’s been some time since I’d tangled with that one and past experience was always one of failure to recover, but 7 was out, maybe someone had luck… searched all over, even got our other admin to help plug through the hits in google.
Nothing. Everyone had pretty much the same conclusion… forget about it, restore from backup.
Well, users don’t back these local archives up often and as it were, he’d copied this archive around with him for the past 8 or 9 years apparently (I swear he said 4 or 5… but it dated back to 98!) just hoping it would be salvageable some day.
So we started to run through the usual tricks…
loading compacts, using -M, -c -i to try to copy it, loading fixup, anything we could think of. Most of these failed because of the need for a consistency check.
We moved the file to another server… disabled the consistency checks (SKIP_FIXUP=1 in the notes.ini and restart) and started getting a little further…
Fixup with any switches just started up and shut down… no good.
compact -M returned: Error compacting database.nsf: One or more of the source document’s attachment are missing. Run Fixup to delete the document in the source database.
Not helpful when fixup does no good.
load convert to try replacing design failed with: Mail Convert Failed on database.nsf: Design Replacement Error: Database (.nsf) has grown too large; use compact to reduce the file size or use use File New Replica to recreate your file with larger capacity.
Did I mention it was about 1 GB? Yeah, compact -M helps with this… but wait, I can’t do that until fixup runs… and well, fixup… yeah, you see.
Copy style compact, set to ignore errors (compact -c -i) failed too: Error compacting database.nsf: This database cannot be read due to an invalid on disk structure
It seemed like a failure with a little bit of progress because we no longer got hung on the need to consistency check.
As a last resort I tried to open it up with my client, just wondering what that would error out with. It gave me an error and suggested that creating a new replica would help. No good when you have no option to create a new replica, however the option to create a database COPY existed…
Being stubborn I tried… as it started to copy design I got hopeful. but then an error popped. I had the option to INGORE the error… so I did… again and again and again… about 50 times at least … and it finished the desing portion and moved to the documents. It copied about 3000 documents as well… at the end it hit me with another slew of errors that I ignored, but the end result (after replacing design on this copy!) was an archive of about 3000 docs that I could access.
Interesting twist… and worth a shot if you run into the dreaded RRV Bucket error. Just thought I’d share one success with the doom and gloom of this error. (Many thanks to Keith for his help on this one!)