> I have a 100GB database that I am trying to run a restore on after a
> successful backup. This is on a new virtual Windows Server 2008 box
> running FB 2.1.5 Classic 32-bit (due to some UDFs that have not been
> ported).
>
> After 26 hours of restore, the process quits with this error:
>
> gbak: activating and creating deferred index VOC_UNQ
>
> gbak:cannot commit index VOC_UNQ
>
> gbak: ERROR:operating system directive CreateFile failed
>
> gbak: ERROR: The system cannot find the path specified.
>
> gbak: activating and creating deferred index PK_VOC
>
> gbak:cannot commit index PK_VOC
>
> gbak: ERROR:operating system directive CreateFile failed
>
> gbak: ERROR: The system cannot find the path specified.
>
> gbak: ERROR:action cancelled by trigger (3) to preserve data integrity
>
> gbak: ERROR: Cannot deactivate index used by a PRIMARY/UNIQUE constraint
>
> gbak:Exiting before completion due to errors
>
> This is a box with a C: drive with 80GB free, and an E: drive 350GB
> free. The backup file and the restore file are both located on the E:
> drive right now, which is actually a SAN logical drive. This is an
> initial test to see if there are any issues running Firebird on it.
>
> The restore log indicates that approximately 30 other indices were
> successfully created prior to this error. The “CreateFile failed”
> message has me concerned. I checked Firebird.conf for temp directories,
> and I see that we did not have the temp directory created on this box
> (C:\TempFirebird). I’m not sure this is the issue, as some of the
> tables from the 30 successful indexes have many times more records than
> the table indicated in the error message.
>
> Does anyone have any thoughts?

Might be temp file related. Temp files being tried to be created in a
non-existing directory or exhausted disk space.

Beside making sure that enough temp space is available, you might also
consider:

* Running th restore through the Services API/Manager
* Provide a larger page cache upon restore, because especially the index
creation step loves RAM. Don't forget to set the page buffers value back
again at database-level after the restore via e.g. gstat. I've seen
restore improvements of > 300% for largish indexes this way.


--
With regards,
Thomas Steinmaurer
http://www.upscene.com/

Professional Tools and Services for Firebird
FB TraceManager, IB LogManager, Database Health Check, Tuning etc.