File-level snapshot is an attribute of an NSS volume that allows a temporary copy of an open file to be made at the time of a volume backup so that the last-known good copy of the file is available for backup while the file is in use.
The file snapshot attribute is not the same as the pool snapshot feature. Pool snapshot is an NSS feature that makes block-level snapshots of a pool that persist until intentionally deleted. For information, see Managing NSS Pool Snapshots.
Normally, if a file is open when backup services begin, that open file cannot be backed up. With the file snapshot attribute set for a volume, NSS creates and maintains a virtual volume where it writes a partial or full copy of a file’s original data whenever a file on the source volume is open for write. This temporary copy of the file’s original data is made available to the backup software instead of the current contents of the open file. Consequently, open files can be copied to the backup media, even though changes in progress for the files are not backed up.
All file snapshot activity happens transparently to the user and to non-backup applications. The user and applications always read the current content of the file. The copy of the file is temporary. When the user or API closes the file, NSS deletes the file-snapshot copy.
IMPORTANT:Not all third-party backup software can take advantage of the file snapshot attribute, even if you set it.
The file snapshot attribute uses block-level copy-on-write technology, which is a technique of capturing images of data before it is modified by applications. The primary purpose of these images is to enable point-in-time backups of file systems while they are in use.
Before the file is open, the physical volume contains a file with data that fills multiple storage blocks on the device. The virtual volume contains only metadata about the file. Metadata includes owner, created date/time, other information about the file, and an empty Blocks Changed list.
Whenever the file opens for a Write call, NSS makes a copy of the block’s contents before writing. NSS identifies writes at the block level. The NSS file snapshot attribute updates the metadata for the file, then monitors for writes to the file. When it intercepts a write command, NSS does not immediately write to the physical location. Instead, NSS reads the data in the target block and copies the existing data in that block to the virtual volume. It adds the addresses of the changed blocks to the Blocks Changed list. At this point in the process, the old data exists in two places: the target block and a block in the virtual volume.
Next, NSS allows the new data to overwrite the old data in the target block. Now, the target block contains new data. The file on the physical volume has some blocks that contain old data, and some blocks that contain new data, just as it would after any normal write process. All that is stored in the virtual volume is the metadata about the file and the blocks of data that represent what the file looked like at the moment it was opened (the blocks of data that NSS copied to the virtual volume).
With the file snapshot attribute disabled, your backup software normally cannot capture a file to backup media, if the file is open and changes are in progress. The backup passes over the file and does not copy it to the backup media. The state of the file is not captured to the backup media.
When the file snapshot attribute is enabled and your backup software takes advantage of the feature, the backup knows to read blocks from the virtual volume and from the physical volume for the open file. From the physical volume, the backup software reads the blocks that are as yet unchanged by any block writes. From the virtual volume, the backup software reads the blocks that contain the file’s data as it was when the file opened. The total information saved to the backup media represents the state of the file when the file was opened.
The virtual volume and its contents are not directly accessible to users or non-backup APIs. It is only accessible to Novell Storage Management Services or third-party backup software that takes advantage of the file-snapshot flag. All other applications ignore the virtual volume. If it is accessing an open file, the backup software reads original data from the virtual volume, but any other application reads the file’s current contents.
When the open file closes, NSS updates the file’s metadata and erases the blocks of original data stored in the virtual volume.
This is how the last-known-good version of the file is saved to the backup media when it would have been passed over previously. The backup media contains real data; it does not back up the virtual volume per se. It only copies data from the virtual volume to re-create the complete last-known-good copy of the open file.
The copy-on-write technology used in file-level snapshots is designed for most files that spend their lifetimes in a closed state or read-only state. However, copy-on-write is neither desirable nor useful for database backups, which are perpetually held in an open state for writing. Because the copy occurs when the write call is issued for a block, the copy is not updated if subsequent writes are made to the same block before the file is closed. The longer the database is open, the more out of date the copied block becomes.
For example, in a Novell GroupWise® system, the longer the database is open, the more chronologically disjointed the contents of the copied blocks are from the actual contents in them. If you make a backup of the database without first closing the file, you get a backup image, but it is not useful.
Initially, the virtual volume occupies very little storage space. It contains only an empty blocks changed list. As an application opens a file to update its data, NSS dynamically allocates space in the virtual volume where it can copy blocks of the original data. As blocks of data change, NSS copies the original data to the virtual volume and updates the blocks changed list to indicate which blocks have changed.
The size of the virtual volume depends on several factors:
The size of the original file when it is opened
How the files are used (such as how often they change, when they change, and who changes them)
How many blocks of data that a single change affects (up to the number of blocks in the original file)
How the application saves changes (such as by blocks or by the entire file)
You should set the physical volume’s size to grow dynamically to the size of the pool. Otherwise, you must periodically monitor the volume size to make sure it can accommodate the peak size of the virtual volume as the volume contents fluctuate at peak productivity times. Make sure your volume’s size can also accommodate any seasonal productivity peaks.
The amount of I/O overhead related to the dynamic file snapshots depends on the usage of the volume. Every time a file opens for write (not read), NSS makes a copy of the metadata about the file, but not the data itself. NSS makes a copy of only that part of the data in the file that a write changes. The algorithm is optimized in such a way that NSS does not make copies of data too often, given the behavior of most applications such as word processors.
Applications write data in different ways. Some close the file after each write, while others close the file intermittently and on demand. As soon as the application closes the file, even if the file is still open for read or for another write, NSS erases any related blocks for that file that are saved in the virtual volume. On executing the next open for write, the process begins again for the file, working with the last closed copy of the file.
Other applications write only differential data at the (logical) end of the file, leaving the existing data blocks intact. In this case, no existing data blocks are overwritten by the application, and there is no writing of data (only metadata) to the virtual volume.
However, in all cases, the backup software can still back up the last closed version of the file.
When assessing overhead, it is important to remember that every time a file is closed, NSS erases the file’s metadata and the original data blocks that were copied to the virtual volume. The data in the virtual volume is not a perpetual copy that is constantly updated.
To assess overhead related to the File Snapshot attribute of an NSS volume, consider the following questions:
What types of applications are in use? How do those applications write to files? How are closes executed?
How many files are there in the volume, categorized by application?
How frequently are files changed? Does the frequency change by user or user group? Time of year? Type of application?
How much data in the file changes typically with each use? How often are files opened for Read versus for Write?
File snapshots apply only to NSS volumes on Netware. After the attribute is set, the file-snapshot process is automatic.
You can enable the File Snapshot attribute when you create the volume by selecting the check box on the page. Whenever the volume is first activated, NSS creates the virtual volume and the file snapshot process occurs automatically.
To set up the file snapshot attribute after a volume is in use requires some pre-planning. You must deactivate and activate the volume to enable NSS to set up the virtual volume area where file snapshots are stored. Initiate the file snapshot attribute at a time when no I/O operations are in progress and all cached data is also reflected in the storage media. For example, to make sure no transactions are lost:
Allow in-progress transactions to complete gracefully.
Temporarily block any new transactions.
Flush any file changes that are cached in memory to the volume.
To enable the file snapshot attribute on a given volume:
In iManager, select the server for the volume you want to manage.
In , select .
Select a volume in the list.
If the volume is not active and mounted, click .
The option activates and mounts the volume in one step. The volume should still be selected when the page reloads. If it is not, select the volume again.
Click .
Select the check box, click , then click to confirm the change.
On the page, select .
Select the volume, then click .
Select the volume, then click .
NSS creates the metadata about files in the virtual volume during the activation process. When the page reloads, the volume is in the activated state and the virtual volume is ready for file-snapshot process.
For information, see Section A.13, File-Level Snapshot Commands.
NSS sets a flag that Novell Storage Management Services™ (SMS) and some third-party backup software can read to determine if there are copies of open files available to be backed up.
IMPORTANT:Even if you set this flag, not all third-party backup software takes advantage of the service.
Novell SMS automatically checks for the File Snapshot attribute when it backs up a volume. If the attribute is set, it takes advantage of the feature.
To open a snapshot file for backup, set a bit in the requested rights parameter and set the READ_ACCESS_BIT. This bit is 0x04000000. It is defined in the NSS header files as zPR_READ_ACCESS_TO_SNAPSHOT.
The default setting for File Snapshot is whenever your file system receives an open for write request, it waits for the backup open to close the file. To return an error, the backup open should also set the deny-the-write bit.
To get information on a snapshot file, use the getInfo command. NSS supports any getInfo call that returns packed information with the RNewStyle bit set in the information mask. You need to set an additional bit 0x20000000 in the information mask. This bit is defined at RNSSInfoOnSnapshot in NSS header files. Both open and getInfo calls require the bit for requested rights and the bit for additional information mask.
The following calls also return information about File Snapshot:
GetFileSize
GetFileHoles
Whenever backup software tries to read an open file, it reads data from the virtual volume and the volume. The virtual volume contains a list of changed blocks for the file. It reads the original data for those blocks from the virtual volume. Then it reads the other blocks of data from the volume itself. The data saved to backup media is the file’s original content before it was open.
When you restore the volume from its backup media, it restores just as it does normally. It requires no special action.