GFE after Arcserve restore (AREV Specific)
At 08 FEB 1998 10:24:08AM Dave Harmacek wrote:
In my 15 years of working with ARev I just had the most disastrous event! The hard drive on the server failed and backups from the night before restore with errors. The Arcserve tape Compare showed no errors so we had no idea that the tape copy would be unusable. The LinkHash tables were in use up to the disk failure and showed no errors. I restored the tape to a difference server and had exactly the same errors.
So, does anyone know of a problem with LinkHash files and ArcServe 6.0? And of course, a fix?
We have ARev 3.12, NLM, and Novell 3.12 environment.
Dave
At 09 FEB 1998 12:25AM Mark Martin wrote:
Hi Dave,
If you were using Arcserve with the 'Backup Open Files' option, and the system was in use, then it is quite possible that the LK and OV portions are out of synch.
If this is the case, you may lose the record that was in use durring the backup but that should be all.
What type/types of GFE's are being reported? This may help with diagnosing the problem and helping you fix it.
Mark Martin
At 09 FEB 1998 11:06AM Victor wrote:
Is the restore process itself reporting errors, or are you getting errors in Arev after performing the restore? If it's just the latter, you probably made good backups without ensuring that the .LK and .OV portions of the files were backed up in tandem (in synch with each other). This is required to ensure against GFEs.
If you are only getting GFE's, you should be able to fix them with minimal data loss. The potential data loss will be all records involved in any resize operation that occurred between saving the .LK and .OV files, plus any new records saved between those two backups.
If your errors were with the restore operation itself, I can't help you there. It serves to illustrate, however, the importance of not just doing backups, but testing them. I've had clients that faithfully did backups but never tested them. When it came time to do a restore, they found out they weren't actually getting useable backups.
Victor
At 09 FEB 1998 01:17PM Dave Harmacek wrote:
Both Backup and Restore processes in Arcserve did NOT report any errors. All Arev-based machines are logged out before backup starts. The ENTIRE directories are backup up to keep them in sync.
You are right, we didn't test the backup by doing a full or partial restore. However, the backup from the other physical volume of the same server test OK. It appears that the combination of the drive and the backup software didn't make useable backups. Also, not all Arev files were showing damage!
These are several files with over 1.5 million records. The VERIFYLH program couldn't even report all of the errors!
At 09 FEB 1998 01:23PM Dave Harmacek wrote:
Hi Martin. We log out all ARev machines every evening long before the start of the backup! We backup all files in the ARev directories to keep them in sync.
When VERIFYLH had few enough errors to correct (some tables are over 1.5 million rows) they were of various types: (5) Overflow frame header type 98 is incorrect, (7) Row is in the wrong group, (3) Primary frame header type (14, 4294967220,4294967168) is incorrect, Group 15630 in overflow frame header (frame 4432) is not consistent with the current…, (8) Offset 1024 frame 4434 in OV table; row terminator (char(255)) is missing. So, these are in both the LK and OV portions of the tables.
These error types were found in other tapes from other nights. It appears that Arcserve compare was not reporting the errors that were happening.
Dave
At 10 FEB 1998 09:16AM Aaron Kaplan wrote:
Well, there are two issues going on. One is is the backup and restore accurate. The other is are the LH files correct.
I'd be willing to bet good money (heck, I'd bet English money as well) that the files were backed up and restored complete and error free.
The problem, most likely, is that LK portion and the OV portion were backed up far enough apart that the one changed placing them out of synch.
It would be the same as if you went to last years backup and restored just the LK portion. Basically, this is what you've done.
If you must have 24/7 access, then the best thing to do is have a mirrored server, disconnect the mirror, back up the backup, then let the servers re-mirror.
At 11 FEB 1998 09:12AM Dave Harmacek wrote:
Hi Aaron, thanks for your reponse. However, as you may see in my response to MM I have all machines logged out overnight and full backups are done in order to keep the files in sync. Also, you will see that errors reported vea VERIFYLH are in both the LK and OV. Restores done from the same tape but a difference physical drive showed no errors on LH files.