Ferro Backup System - The best Backup Software
Network Backup & Restore Software Solution for SMBs
 
  EN    PL    ES   


Article ref. no : FS-FBS-20060427-I01
Last revised : 22 April 2006
Version: 1.0


Backup of open and locked files

The article discusses the issues involved in open file backup. It explains what open files are, gives the reasons why some files are locked and shows how locking is done. Finally, two mechanisms to solve the open file backup problem are suggested.




Introduction

File locking mechanisms are used in all multiprocessing operating systems. In some, file locking is mandatory (e.g. Microsoft Windows) and in some it’s optional (e.g. UNIX).

Below, we will only discuss cases of mandatory locking, since only in such cases do we have to face the problem of open file backup.

Anyone who has ever had to back up important data has faced the following situation: the file to be backed up is skipped when making the backup copy, or there’s an error message which says that the system cannot access the file as it is being used by another process.

Fig 1 Locked (in use) file copying error

Fig. 1 Locked (in use) system file copying error


If you have also encountered a similar problem or are going to back up database or system files or other files used by another application to which access is locked by the operating system, you need to read the following text. The short time you spend on reading it will surely pay off and sooner or later you will be able to use the information contained here in practice.



Access rights and sharing modes

Each file-opening process must indicate the access mode and the sharing mode it needs. By indicating the access mode, the process informs the operating system what the file is being opened for. Three access modes are available: read, write, read-and-write. If a given process opens the file only to read its content, it will open a read-only file. If it wants to make some changes, it must open the file as write-only or as read-and-write.

Access modeDescription
Open ReadIt’s only allowed to read the file
Open WriteIt’s only allowed to write in the file
Open Read WriteBoth reading and writing allowed

Table 1. File access modes


Another parameter to be defined by the process that wants to access the file is the sharing mode. This informs the operating system whether the next application (process) trying to open the file should be allowed to do so or whether it should be denied access. Four sharing modes are available: access denied, allow read, allow write, no limitations. These sharing modes enable processes to lock (using the operating system) access to files which they accessed first.

Sharing modeDescription
Share ExclusiveOther applications cannot access the file
Share Deny ReadOther applications can open the file as write-only
Share Deny WriteOther applications can open the file as read-only
Share Deny NoneOther applications can open the file without limitations

Table 2. File sharing modes


Don’t confuse file locking mechanisms with protection rules and user rights granted by the system administrator or with file attributes.

In this article, we only focus on the case where the process opens the file using the exclusive lock, which completely denies access to it to other processes, and makes it impossible to read or make a backup copy. We will not discuss the situation where it’s impossible to write or delete file as these are issues not related to the data backup process.



Who locks files and why?

File locking mechanisms service to protect data and its structure. Access to a file can be locked (through the operating system) by a process which is already accessing or has created the file. File locking mechanisms allow atomic reading or writing operations. In such operations there is a requirement that the resource (the file or its part) should be unshareable for some time. This means that at a given moment only one process can have a given type of access.

Let us imagine a situation like this: Process A saves calculation results in several locations in the file or changes several records in the database, meanwhile process B is reading the file. Data read by process B may be incoherent and most likely will not be usable.

To avoid the possibility of reading data that are incoherent (e.g. to make a backup) from the point of view of a given application ( e.g. the database system), files are exclusively locked without the right to be read by other processes.

Atomic operations such as writing or reading a given portion of data (transactions), usually take very little time; however, the lock on the file that prevents its being read is, in very many cases, active not only when atomic operations are in process, but from the moment the file is opened by the process until it’s closed.
Fig. 2 File open and locked by system process

Fig. 2 File open and locked

Such a procedure is used in most cases by database applications, which, pursuant to the assumptions adopted in their design, will be the only “owners” of a database file and will have exclusive access to it. From the point of view of a given database system, it is not necessary for other applications to read such a database file at the same time, even to ensure simultaneous multi-user access to the database. Likewise, another process opening the file could disturb the operation of the database engine, for example, making it impossible to complete transactions in the right time. For these reasons, and to simplify implementation, often the file locks used are active almost all the time, preventing a backup application from making backup copies.

It is system files (e.g. system registry files in Windows NT family systems) that are locked most often, as well as databases (Lotus Notes, Oracle, Microsoft SQL Server, Microsoft Access, MySQL, PostgreSQL), mailing system files and graphic program files.



Backup of locked files using Ferro Backup System

Ferro Backup System from version 2.4 upwards makes it possible to back up locked files or files used by other applications. The Open File Manager option is available in the standard version (also in the demo version).

Two scenarios are possible during the backup process when Open File Manager is run by the FBS Worker process module:
  • the entire file is locked and cannot open as read-only
  • the file can open as read-only but part of the file is locked

In the first case, Open File Manager will be activated if the standard file opening (using system functions) fails in n/2 attempts. The n parameter stands for the number of file opening attempts and is defined in the FBS Server central management module.

The other situation occurs sometimes for database files and spreadsheets. The database program or spreadsheet may exclusively lock part of a file when writing it. Each backup program may freely open such a read-only file. The problem starts, however, when trying to read a locked fragment – the operation will be interrupted and the system will generate an exception notifying that a given part of the file is locked by another process. In this case FBS Worker reopens the file, this time using Open File Manager, and freely copies the whole file content.

So we already know how and when OFM is activated. Later in the article we will discuss the operation diagram of the open file manager.



Open File Manager – open file backup

When a locked file is encountered, data back-up bypasses the operating system. Open File Manager gains direct access to the hard drive, thus bypassing operating system file locks. This way it can read all information stored on the disc independently of other applications and of the operating system itself.

A cluster is the smallest single data portion available from the file system. Each file occupies a given number of clusters on the disc, which number depends on the file size and on the size of clusters. The cluster size is fixed and determined when formatting the partition (FAT) or volume (NTFS). A file can be saved in consecutive clusters or it can be fragmented, with its respective parts stored in different disc locations. Information on which clusters are allocated to a given file is stored in the allocation table. For FAT it’s the File Allocation Table, and for NTFS, the Master File Table. To read the file, then, first you need to read the file data from the allocation table, whose structure is completely different for FAT and NTFS. Open File Manager supports both file systems, which can likewise come in different versions: FAT 12, FAT 16, FAT 32, NTFS 4.0, NTFS 5.0, NTFS 5.1.


Fig. 3 Disc divided into NTFS and FAT volumes

Fig. 3 Disc divided into NTFS and FAT volumes

Therefore, the low-level disc access delivered by Open File Manager consists in loading the allocation table, reading the virtual and logical location of clusters that show fragments of a given file, and reading data stored in those clusters. OFM uses additional techniques to prevent incoherent data from being read. If a file is read by OFM, it means that it’s coherent. For databases, this will be a post-transaction status.



Comparison of Volume Shadow Copy Service (VSS) and Ferro Backup System OFM

In Windows XP and Windows 2003, a volume shadow copy service has been introduced. This service offers, among other things, backup of locked files. It enables any file to be opened and copied at any time. Unfortunately, the VSS application is very limited, so it cannot be used in many situations.
Fig. 4 Operation diagram of Volume Shadow Copy Service (VSS)

Fig. 4 Operation diagram of Volume Shadow Copy Service (VSS)



As we have already mentioned, this service allows backup of locked files, but both the back-up program and the program that locked the file must be VSS-compliant. This means that the application (e.g. the database application) whose files we want to back up must be dedicated for the Windows XP/2003 platform and use shadow copy mechanisms. At present, few application of brands other than Microsoft are compatible with this technology. Besides, the backup application must also be VSS-compliant. The backup program attached to Windows XP and Windows Server does not offer such capability.

Another VSS limitation is that the backup application, the application that has locked the file and the file itself all have to be on the same computer. If the file is locked by an application remotely run on a different computer, then the backup process will not be successful. If the file and the application that has exclusive access to it are on the same computer, but the backup application attempts to read the file over the network, then the backup will not be effective, either.

Another inconvenience is that volume shadow copying requires adequate free disc space. This space is used to make volume snapshots. If there’s not enough free space on the disc, then backup of locked files will not be possible, either.

There are, however, applications where VSS will work better than FBS OFM. If we have a server operating under MS Windows Server 2003, running programs such as Microsoft Exchange Server 2003 and Microsoft SQL Server 2000 operating on large databases, then it’s better to use the volume shadow copy service and an adequate backup program compatible with this technology.

However, the aforementioned limitations make the applicability of the volume shadow copy mechanisms for open file backup quite limited:
  • The service is only available in Windows XP and Windows Server 2003
  • The backup software and business software must be VSS-compliant
  • The backup software, business software and the locked file must be on the same computer.
  • Additional disc space is required
The open file backup process embedded in Ferro Backup System does not have those limitations. OFM operates under all systems from the Windows NT family (NT, 2000, XP, 2003). It offers backup of files locked by applications operating on remote computers and requires no free disc space.
Home   Help   Where to Buy    Download    Contact Us   Partners   |  Printable version  |  Language: EN EN   PL PL

Backup of open files, backup of locked files, backup in use files
All rights reserved.
Copyright © 2000-2022 FERRO Software