Earlier today Pierre asked: > Roll Foward recovery : > Does someone use this way to mirror Turbo Image database? Well; yeah; "sort of" we do that: Roll Forward recovery allows you to put the log files on a different volume set from the volume set the database resides on. Every night during the five-or-so hours when production database does not need to be online for our users we copy database from our USER volume set to the BACKUP volume set. After successful completion of copy we restart logging with a new set of log files (after saving previous set of log files to another group to go with previous STORE to tape of BACKUP volume set (we are fairly paranoid about our mission-critical data) ). A code snippet from our job stream that runs on the BACKUP volume set is (edited to protect actual database names). The variable LOGGROUP gets set according to the day of the week. the "PAUSE 30" between RELLOG and GETLOG is in there because RELLOG is one of those commands that "comes back" to the prompt right away; *BUT* It might take a few seconds to complete. If RELLOG is not completely done before do the GETLOG thing, GETLOG will fail: ! IF JCW >= FATAL THEN ! comment copy of xxxxxx.xxxx.xxxxxxxx FAILED. Restart ! comment logging on CURRENT file set; + PRINT WARN ! JDWARN.PUB ! LOG LGxx, RESTART ! ELSE ! PURGE [log in to unmask]; NOCONFIRM ! DSCOPY LGxx@ TO @.!LOGGROUP; MOVE; QUIET ! RELLOG LGxx ! PAUSE 30 ! BUILD LGxx001; DISC=2048; CODE=LOG ! GETLOG LGxx; LOG=LGxx001.xxxx.xxxxxxxx,DISC; AUTO ! LOG LGxx,START ! ENDIF This way if by some *real* bad stroke of luck our Mirrored USER volume should get hosed up / broke to the point where neither spindle in the same mirrored pair is useable, we have all info on the BACKUP volume set necessary to Roll Forward with last night's copy of the production database.... of course we will be down for some amount of time until we get the USER volume going again, bring last night's database copy back, and Roll Forward... but we will (at least in theory) not lose a single record from our database. ... and with the USER volume being mirrored, hopefully odds of having to do the above for real are slim... > What do you think about this? Lot cheaper that NetBase Shadowing.... simpler, too... AS LONG AS you can afford the time to fix USER volume and Roll Forward.. and: Sort of SIDEBAR for another day: Be advised that over a period of many months working with the HP RC, we have discovered a few "interesting" details that effect the above, if you are running Image/SQL and have your TurboIMAGE databases ATTACHed to an ALLBASE DBE: It turns out that that the file names in the TurboConnect file (TurboIMAGE database name + "TC") and the ALLBASE DBE are fully qualified.... by itself that is probably not a surprise.... *BUT*: It turns out that STORE / VSTORE is not smart enough to realize it is being asked to STORE / VSTORE *copies* of the IMAGE database and ALLBASE DBE; when it looks inside the TC file and the DBE that have been copied to the BACKUP volume set: STORE completes without error, but it writes something really screwy at the front of the tape, and depending on several factors at the time the tape is cut (not all completely understood (long, *LONG* story) ), if you are "unlucky" (we were "unlucky" maybe 40-50 percent of the time), all subsequent VSTORE attempts on that tape will FAIL.. :-((( Failure mode is TurboIMAGE dataset counter on VSTORE listing goes nuts and counts IMAGE datasets in NEGATIVE direction up to a thousand datasets or more; and then VSTORE ABORTs in the first few seconds of trying to read the tape.... arrggghhhh..... If I get time and others are interested, I can give a more complete history and description of our "VSTORE failure" saga.... Ken Sletten