> >But then I don't understand this, from the OP's question:
> >
> >> The manufacturer of my buckup software
> >> http://www.acronis.com/backup-recovery/
> >> <http://www.acronis.com/backup-recovery/> told me, it is important,
> >> that Firebird works with / supports the Microsoft VSS service
> >
> >This suggests that Firebird ought to recognize and/or cooperate with the
> VSS service, "or else".
> >
> >I don't know anything about VSS, but given the choice I'd definitely go for
> gbak or nbackup. They were designed to do exactly that job. They know
> what's going on *inside* a Firebird database - something that VSS probably
> isn't aware of.
>
> Volume shadowing, that came in with WinXP/Server2003, *was* suspected
> to cause problems for Firebird, although different kinds of problems than its
> older alter ego, SystemRestore.

SystemRestore <> VSS

The WinXP SystemRestore was an attempt by MS to "protect" key system structures from corruption during the installation of software packages/MS patches/updates, by making physical copies of files which OS detected as being changed. The problem was that MS had used "gdb" as a private extension for some internal structures, which needed protection -- unfortunately, MS didn't make SystemRestore smart enough to only care about files in selected folders. Starting with Win2003, however, SystemRestore has been based on the use of VSS, which doesn't copy the files but tracks HDD block changes and creates restore points, which changes can be rolled-back from.
http://en.wikipedia.org/wiki/System_Restore


VSS is a completely different beast. VSS operates at the block level of the file system and tracks block changes, with the end result being similar to a versioning file system, allowing any file to be retrieved as it existed at the time any of the snapshots was made.
http://en.wikipedia.org/wiki/Shadow_Copy

> Quoting the subject of the original posting - "incremental backups, wenn
> the SQL Firebird is running", it sounds as though the OP thinks VSS provides
> an incremental backup capability. It doesn't.

Correct, but it does allow for *backup software* to create an incremental backup! (Which is what the OP was asking)

> snapshot of the entire volume, at block level. Thus, if Something Nasty
> should happen to the volume, the *entire volume* would need to be
> restored and the image would be that taken at the last snapshot.

That is a little exaggerated!

As with any HDD failure, an appropriate restore process would need to be followed in order to restore a system to an appropriate point in time.

The restore/backup strategy has nothing to do with VSS usage.

> As far as I understand it, third-party backup software like Acronis (along
> with a heap of others) makes use of the snapshot volume copy by taking its
> own copy of the copy, extracting out blocks pertaining to a file and
> regrouping them readt for a restore operation to stitch them together in a
> manner analogous to disk defrag.

Backup software read the contents of files using standard file access APIs (*they do not read specific disk blocks*) and stream the contents to a backup file/destination. When a restore is required they reverse the process. In each case, the software expects the OS to manage the physical sector/block location of the files.

It is no different than how Firebird deals with HDDs. The engine open the database, it asks the OS to reads sections (pages) of the file, the OS determines where on disk (the block/sector) those sections are found.

A disk defragmenter is a *completely* piece of software -- which does care about the physical location of each block within a file.

> If that *is* as I understand it to be, then I cannot see how Firebird could be
> said to support the VSS, let alone "work with it". One would need to be at
> least *suspicious* that a Firebird database file restored that way would be
> thoroughly corrupted, since its inventory of block addresses is stored and
> mapped by indirection, within the database itself.

This shows a complete misunderstanding of how backup software has worked in decades.

There was a time when backup software operated at a disk block level but that was long before there was even operating systems like DOS 1.0.

All OS (since at least 1985) have abstracted the disk block/sector management from basic file operations. It is only very specialized software (disk defragmenter or undelete) which have ever needed to worry about disk allocation tables and/or disk sector/block management.

> I was interested to see Sean commenting so definitively that it was safe.
> Sean, are you using it with your own Windows-based database volumes?
> Have you tried a restore?

Before I posted my reply, I performed the following test:

1 - connected to a database on my local HDD
2 - setup an INSERT statement to have the ID for each row of an existing table written to another empty table.
3 - setup a backup job using my VSS enabled backup software (Farstone Advanced Workstation v7, I could have used the basic Win7 Backup software) to backup the database file to another local HDD
4 - executed the INSERT statement
5 - started the backup job
6 - backup job completed within 2 minutes, without error
7 - INSERT statement added 3 million rows and completed within 4 minutes, without error
8 - disconnected from the database
9 - renamed the database
10 - restored the database
11 - connected to the database
12 - Counted the rows in the target table -- no rows found -- and no errors
13 - executed GFIX on database -- no errors


Sean