Partager via

Best practices for Remote Storage

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Best practices

The following list represents some best practices for Remote Storage. You should implement this list whenever possible.

  • Backup files on managed volumes as well as the Remote Storage database files. Remote Storage relies on backups to protect applicable files cached on your local volumes, in addition to the Remote Storage database and other program data files in the System32\RemoteStorage folder. You should keep track of when data backups occur and which tapes are used. For information on Backup, see Backup overview.

    For more information on protecting data managed by Remote Storage, see Protecting and recovering data from loss.

  • Backup files as an administrator when backing up Remote Storage database files. Remote Storage requires that you run system state backups as a member of the Administrators group in order to backup the Remote Storage database files. If you run a system state backup as a member of the Backup Operators group, it will not include the Remote Storage database files.

  • Make copies of your remote storage data. You should make multiple copies of the tapes or disks that Remote Storage uses and regularly update them. In this way, if you later encounter a problem with your original tape or optical disk (the master media), you can recreate it using a copy you have made. Doing this ensures no loss of data.

  • Keep full media copies off site. If possible, keep full media copies off site or rotate media copies between your business sites for safekeeping. (Non-full media copies are required on site for synchronization.)

  • Do not use the Remote Storage command-line utility before you configure Remote Storage. You must configure Remote Storage using the Remote Storage Setup wizard before you use the rss.exe command-line utility, or you will not be able to use the utility to successfully manage Remote Storage.

  • Do not create File Replication service (FRS) replica sets on a volume that is managed by Remote Storage. In addition, do not add a volume that contains directories that are part of an FRS replica set to Remote Storage. Otherwise, you might severely impact system performance and possibly cause data loss within your media library.

    FRS might need to periodically read every file in the replica set to send the file contents to another computer. This causes FRS to recall all files that Remote Storage has sent to secondary storage, which might take a long time (hours or days). If you use tape for your secondary storage, remember FRS recalls files in directory order rather than media order, so the excessive number of tape seeks performed by FRS will likely ruin the tapes and cause data loss.

  • Validate your managed volumes regularly. You should schedule validation of your managed volumes on a regular basis. Validation ensures that all files on managed volumes point to the correct data in remote storage.

  • Discontinue managing all volumes before uninstalling Remote Storage. Before you uninstall Remote Storage, you should discontinue managing all volumes by selecting Recall copied data from storage in the Remove Volume Management wizard. Otherwise, you may lose your file data.

  • Think before you delete a file from a managed volume. If you delete a file from a managed volume, the associated data can no longer be recalled from remote storage. Be careful not to delete such files if you might want to recall the data at a later time.

  • Do not use Remote Storage to manage excessively full volumes. Remote Storage requires free space on each volume to store the metadata for each file it manages. If there is not enough space on the volume, Remote Storage will behave unpredictably or fail to work. There is no way to predict how much space you'll need for the metadata, so use your best judgment and clear space on excessively full volumes before attempting to manage them.

  • Do not format a managed volume. When a managed volume is formatted, Remote Storage cannot locate the volume anymore, and does not know if the volume is temporarily unavailable or was permanently removed (which is the case when a volume is being formatted).

  • Load balance your scheduled tasks. When managing several large-capacity volumes, you should schedule tasks to run on different days and at different times to spread out the workload on your server. For example, all tasks for volume A could be scheduled to run on Tuesdays and Thursdays at 2:00 am; all tasks for volume B could be scheduled to run on Mondays, Wednesdays, and Fridays at 2:00 am.

  • Avoid scheduling tasks at system restart. To prevent excess workload on your server, you should not schedule any tasks to start at system restart.

  • Do not change the drive letter assigned to a managed volume. If you must change a volume's drive letter, stop managing it with Remote Storage first.

  • Log in as a domain user when managing volumes. Remote Storage only notifies you of file recalls when you are logged in as a domain user. If you log onto your local computer only, you will not receive these recall notifications.

  • Avoid deleting the USN journal, if it has been created. If someone has created an update sequence number (USN) journal on the computer using the fsutil utility, deleting it will degrade the performance of Remote Storage.