A backup system can be block level, which backs up bits on the actual hard drive or file level which backs up actual files.
Block level is great for the hard drives of virtual machines. It can also be used on physical machines but restore is much more tricky than file level backup
File level backup checks which files have changed and backs up copies of those files – with or without versioning.
One problem with file-level backup can be open files. These are files currently being used by the operating system which may stop the backup process from accessing them. A very common example of this is for database files. Many backup softwares have an “open file” option. What this does is to tell the operating system to take a snapshot of the hard drive and then the file is copied from the snapshot. Once the backup is complete the snapshot is merged back into the hard drive. This uses a feature of windows known as the volume shadow service (VSS)
One issue with all of this can be database files. The main medical accounting and clinical system is usually a database file such as a firebird fdb file. In determining which files have changed since the last backup, the backup software may check the file size and the time attributes on the file to determine whether it has actually changed.
Because the file is open, the dates will not have changed and the size may not change frequently despite a large number of writes. This is because a database file works in blocks of pages and the size of the file will only change with each new page creation. This may be slower than first thought, even with a large number of writes. Close inspection of the backup logs may revea l that the main database is only being infrequently backed up. One solution to this is to maintain a local (non open) copy of the database file the dates of which are flushed prior to the backup operation. ie copy file, flush dates, run backup The flush operation can be done with copy /b myfile.txt ,,