Choose from the following topics:
Plan your backup jobs for this agent by reviewing the following information:
This agent supports the following backup types:
This agent has the following unique functionality:
The system state is comprised of many components that are critical to recovery of the Windows 2000, XP and Server 2003 operating systems. See System State Backups for more information on System State backups.
Distributed File Systems (DFS) consist of both data and configuration information. The data is stored in the file system of several machines participating in the DFS tree, while the configuration is stored in the registry of each machine and/or the Active Directory databases.
The best way to back up DFS is to install the Windows File System iDataAgent on each machine and back up the default subclient with the default settings, which include the system state. This will back up both the data and the configuration.
You can back up DFS data mapped to a UNC path, but this is not recommended. Subclients containing UNC paths to the data on remote machine will back up the DFS data; however, the configuration of the remote machine(s) will not be backed up. The DFS structure would have to be recreated manually and the data restored from the UNC subclients.
You can back up Microsoft Virtual Server virtual machines by configuring pre-snapshot and post-snapshot scripts that use the VSBackupUtil utility. The snapshot scripts enable the system to quiesce and snap the virtual machines. See Back Up Virtual Machines on Microsoft Virtual Server for step-by-step procedures.
When using Windows Server 2003, you can enable VSS for backup jobs, see VSS for the Windows File System iDataAgent for more information.
When using Windows 2000, XP, or Server 2003, you can install and enable Open File Handler (OFH) or QSnap to back up locked files. See QSnap/Open File Handler for the Windows File System iDataAgent for more information.
NOTE:
Simultaneous OFH/QSnap backups cannot be run for two Windows File System subclients with contents on the same volume. Because of this, you must define subclients as entire volumes or schedule backups so that they do not overlap.
There are some instances in which the Classic File Scan is always used, including but not limited to:
If the backup set contains both NTFS drives and FAT volumes, and the change journal is the selected method of scanning, then the change journal will be used for NTFS volumes and the classic file scan will be used for FAT volumes (because the Windows Change Journal does not support FAT volumes). If classic file scan is the selected method of scanning then both NTFS and FAT volumes will use the classic file scan.
The options you set for classic file scan will be used whenever classic file scan is called (these appear grayed out unless classic file scan is selected). For example, you can select classic file scan, pick your options, and then select change journal. In this case the change journal will be used, but your selected options for classic file scan will be saved and used whenever the classic file scan is called.
See Use Change Journal or Classic File Scan for Backups for step-by-step instructions on changing your selection.
For Windows File System iDataAgent, it is recommended to use the Change Journal for the purpose of determining which files have changed and/or have been backed up. For situations in which you are using this system with other software to manage your data or if you are backing up volumes that do not use the Change Journal (such as a FAT partition) the Check archive bit during backups option is useful. These options effect only the Classic File Scan.
Each file in an NTFS or NWFS file system has a set of attributes managed by the operating system. The archive bit is one of these attributes. When set, the archive bit indicates that either the content or name of a file has changed.
If you select the Check archive bit during backups option, then all incremental or differential backups conducted on the selected backup set and its subclients include not only those files whose content has changed, but also any files that have been renamed. This option does not affect the behavior of full backups and the corresponding incremental and differential backups tend to be more comprehensive. In addition, the system resets the archive bit of every file that it backs up.
When this option is cleared, files are considered modified based only on the file modification time. In addition, the system does not change the state of the archive bit of the files it backs up.
If you are using an external application to move data backed up by this system based on file access times and file modified status, it is important to understand how the Use Change Journal and Check archive bit during backups options affect those file attributes. For example, if you select the Use Change Journal option the file access times will not be preserved and the file is marked as modified. If the Check archive bit during backups option is selected, in conjunction with the Preserve File Access Time option, the file access times will be preserved and the file will not be marked as modified. See Set the Archive Bit Attribute for step-by-step instructions.
This option allows you to prevent the file access time from being changed for Windows/Unix/Macintosh File System iDataAgents as a result of running data protection operations on the client. When this option is selected, the file access time will be preserved. See Preserve the File Access Time for step-by-step instructions.
Before performing any backup procedures for this agent, review the following information:
The CV_MAGNETIC folder (which is created when a mount path is configured) will by default be excluded from data protection operations if a MediaAgent and the Windows File System iDataAgent is installed in a computer. (The CV_MAGNETIC folder must be associated with the MediaAgent that is installed in the computer.) To include the folder in data protection operations, the nDoNotFilterGalaxyMagneticMountPaths registry key must be created in the computer.
Filters can be used in conjunction with the "Items That Failed" list on the data protection Job History Report to eliminate backup or migration failures by excluding items which consistently fail that are not integral to the operation of the system or applications. Some items fail because they are locked by the operating system or application and cannot be opened at the time of the data protection operation. This often occurs with certain system-related files and database application files.
Also, keep in mind that you will need to run a full backup after adding failed files to the filter in order to remove them.
If you have a File System DataMigrator Agent on the same client as your File System iDataAgent, and you want to include DataMigrator stubs in the file system incremental backups, see Including DataMigrator Stubs in Backups for more information.
If you plan to do a full iDataAgent restore on a Windows 2003 Server x64 platform, use an x64 iDataAgent for backup. You cannot do a full iDataAgent restore on an x64 platform if you are using a 32-bit iDataAgent.
Full iDataAgent backups of quotas that were created using File Server Resource Manager (FRSM) and backups of a created ADAM instance cannot be restored using Full iDataAgent restore.
Backup jobs may take more time if anti-virus software is set for “on access” scanning. To address this issue, it is recommended that all files under the Galaxy/Base folder be excluded from anti-virus scanning software.