Estimating Snapshot Pool Requirements
Snapshot data grows dynamically for as long as a snapshot is active and as long as there is enough space available in the snapshot pool to store them. When the snapshot pool approaches its capacity (at about 95 percent), the Snap Server deletes the oldest snapshot’s data to create space for more recent snapshot data.
The default configuration allocates 80 percent of RAID capacity to the volume and 20 percent to the snapshot pool. You can adjust the size of the pool up (assuming unallocated space exists) or down according to your needs. If you find that your snapshot strategy does not require all of the space allocated to the snapshot pool by default, consider decreasing snapshot pool capacity and re-allocating the capacity to the file system. To adjust the size of the snapshot pool, navigate to the Storage >
Snapshots screen, and click the Adjust Snapshot Space link in the introductory text.
The number of snapshots that a RAID can support is a function of these factors: (1) the space reserved for the snapshot data; (2) the duration of the snapshots you create; and (3) the amount and type of write activity to the volume(s) since the snapshot was created. The following table describes minimum and maximum allocation cases.
Adjusting Snapshot Pool Size
The current size of the snapshot pool for each RAID (or RAID group) can be viewed by navigating to the Storage > Snapshots screen and clicking the adjust snapshot space link in the introductory text. On the screen that opens, you can adjust the pool up or down as necessary at any time. In addition, there are two other processes that may affect the size of the snapshot pool.
• Creating a Volume — In the course of creating a new volume, a pull-down menu allows you to add a percentage of the capacity being allocated to the new volume to the snapshot pool. This feature defaults to 20%, the recommended amount of space to reserve for snapshots. If you do not plan to use snapshots with this volume, maximize volume capacity by reducing this percentage to zero; if you do plan to use snapshots, adjust this percentage in accordance with the guidelines discussed in previous section.
Guidelines for Estimating Snapshot Pool Requirements
Allocate about 10% of RAID if Allocate about 25% of RAID if
• Activity is write-light
• Write access patterns are concentrated in a few places
• A small number of Snapshots must be available at any point in time
• Activity is write-heavy
• Write access patterns are randomized across the volume
• A large number of Snapshots must be available at any point in time
Accessing Snapshots
• Creating a RAID Group — When two RAIDS are grouped, their snapshot pools are added together. For example, if RAID A with a snapshot pool of 50 MB is grouped with RAID B with a snapshot pool of 25 MB, the resulting RAID Group will have a snapshot pool or 75 MB. Depending on the purpose you had in mind when grouping the RAIDs, the result of combining the two snapshot pools may or may not be desirable, and you will need to readjust the size as described above.
Accessing Snapshots
Snapshots are accessed via a snapshot share. Just as a share provides access to a portion of a live volume (or file system), a snapshot share provides access to the same portion of the file system on all current snapshots of the volume. The snapshot share’s path into snapshots mimics the original share’s path into the live volume.
Creating a Snapshot Share
You create a snapshot share by selecting the Create Snapshot Share option in the course of creating a live-volume share. For example, assume you create a share to a directory called “sales,” and you select the Create Snapshot Share option. When you connect to the server via Internet Explorer or other file browser, two shares display:
SALES SALES_SNAP
The first share provides access to the live volume, and the second share provides access to any archived snapshots. Other than read-write settings (snapshots are read-only), a snapshot share inherits access privileges from its associated live-volume share.
Tip The same folders appear on the Web View screen when you connect to Snap Server using a Web browser; however, the snapshot share folder does not provide access to the snapshot; it will always appear to be empty. You can prevent the snapshot share from displaying on this Web View screen by selecting the Hide Snapshot Share option when creating or editing a share.
Coordinating Snapshot and Backup Operations
Chapter 7 Snapshots 59
Accessing Snapshots Within the Snapshot Share
A snapshot share contains a series of directories. Each directory inside the snapshot share represents a different snapshot. The directory names reflect the date and time the snapshot was created. For example, assume the snapshot share named
Sales_SNAP contains the following four directories:
latest
2003-12-25.120000 2004-01-01.000100 2004-01-07.020100
The latest directory always points to the most recent snapshot (in this case, 2003-01-07.020100, or January 7th, 2003, at 2:01 a.m.). A user may view an individual file as it existed at a previous point in time or even roll back to a previous version of the file by creating a file copy to the current live volume.
Tip The “latest” subdirectory is very useful for setting up backup jobs as the name of the directory is always the same and always points to the latest available snapshot.
Coordinating Snapshot and Backup Operations
Like backups, snapshots can be scheduled to recur at a designated time and interval. In addition to synchronizing the backup and snapshot schedules, you must create a share (and snapshot share) to the appropriate directory so that the backup software can access the snapshot. For most backup purposes, the directory specified should be one that points to the root of the volume so that all of the volume’s data is backed up and available from the snapshot share.
1 Create a snapshot for each volume you want to back up.
In the Administration Tool, navigate to the Storage > Snapshots screen, and click Create Snapshot. When defining and scheduling the snapshot, consider the following:
• In the Create Recovery File pull-down menu, select Yes to ensure that the ACL, extended attributes, and quota information is captured and appended to the snapshot. This step is needed because many backup packages do not back up native ACLs and quotas. Placing this information in a recovery file allows all backup packages to include this information. If the volume needs to be restored from tape, or the entire system needs to be recreated from scratch on a different server, this information may be required to restore all rights and quota information.
• Offset the snapshot and backup schedules such that the backup does not occur until you are sure the snapshot has been created. (The snapshot itself does not require much time, but creating the recovery file may take up to 30 minutes,
Coordinating Snapshot and Backup Operations
depending on the number of files in the volume.) For example, assuming you schedule nightly backups for a heavily used volume at 3:00 a.m., you might schedule the snapshot of the volume to run every day at 2:30 a.m., allowing half an hour for the snapshot to run to completion.
2 If necessary, create a share for each volume with snapshot share enabled.
In the Administration Tool, begin by navigating to the Security > Shares screen, and then click Create Share. Select the volume and click Continue. Then, to create a share to the volume itself (on the root), simply accept the default path by clicking Use Current Path. Finally, be sure to select Create Snapshot Share.
3 Set the backup software to archive the latest version of the snapshot.
The Snap Server makes it easy to configure your backup software to
automatically archive the most recent snapshot. Simply configure your backup software to copy the contents of the latest directory within the snapshot share you created at the root of the volume. For example, assume the snapshot share named SHARE1_SNAP contains the following four directories:
latest
2003-12-25.120000 2004-01-01.000100 2004-01-07.020100
Each directory inside the snapshot share represents a different snapshot. The directory names reflect the date and time the snapshot was created. However, the latest directory always points to the latest snapshot (in this case, 2003-01-07.020100, or January 7th, 2003, at 2:01 a.m.). In this case, configuring the backup software to copy from
\SHARE1_SNAP\latest
ensures that the most recently created snapshot is always archived.
Snap Server Administrator Guide 61 Snap Server Administrator Guide 61
Chapter 8
Disaster Recovery
This chapter explains how to create the files you need to recover a Snap Server’s configuration information, such as network and RAID
configurations, as well as volume-specific information, such as ACLs and quota settings.
It also discusses what to do if all access to the data on a Snap Server is cut off due to a hardware or software failure. Focus is placed on the procedures for (1) reinstalling the Snap Server operating system; and (2) restoring the server to its original configuration with data intact. The final section describes how to use these files to restore any Snap Server to its original state.
Topics in Disaster Recovery Management:
• Backing Up Server and Volume Settings
• Backing Up the NetVault for GuardianOS NVDB Directory
• Recovering the NetVault Database
• Disaster Recovery Procedural Overview
Backing Up Server and Volume Settings
In addition to backing up the data stored on the Snap Server, you may also back up its system and volume settings. The Maintenance > Disaster Recovery screen allows you to create the files you need to restore these settings: (1) server-specific settings such as server name, network, RAID, volume and share configurations, local user and group lists, and snapshot schedules; and (2) volume-specific settings such as ACLs, extended attributes, and quota settings.
The SnapDRImage File and the Volume Files
Details on the Snap Server disaster recovery files and the information they contain are as follows:
Backing Up Server and Volume Settings
• SnapDRImage — The Snap Server disaster recovery image saves server-specific settings such as server name, network, RAID, volume and share configuration, local user and group lists, and snapshot schedules. There is one SnapDRImage file per server, residing on the root directory of the first volume at the following path: \\server_name\volume_name.
Tip The SnapDRImage file is in binary form and can be safely used only with the Snap Server Disaster Recovery tool. Other tools will not work and may
compromise the integrity of the file.
• Volume-specific files — These files, named backup.acl, backup.qta.groups, and backup.qta.users, preserve volume-specific settings such as ACLs, extended attributes, and quota settings. One set of these files exists per volume, residing at the following path: \\server_name\volume_name\.os_private.
Caution The Create Recovery Files option in the snapshot feature automatically updates the volume-specific files when the snapshot is taken. If you do not use snapshots to back up a volume to tape, you must manually regenerate these files whenever you change ACL or quota information to ensure that you are backing up the most current volume settings.
Creating the SnapDRImage and Volume Files
Before you create the disaster recovery files, make sure you have completed the following activities:
• You have completely configured the Snap Server. If you subsequently make any major changes to the configuration, you must repeat the procedures described in this section.
• You have recorded, in an off-server location, the following information about the configuration: (1) the server name; (2) the number of RAIDs; (3) the number of volumes; and (4) the size of each volume. You may need to enter this information later as part of a disaster recovery operation.
• You have devised and implemented a data backup strategy.
Use the following procedure to create and secure the disaster recovery files:
1 Create the disaster recovery files.
Navigate to the Maintenance > Disaster Recovery screen. Click Create Recovery Images to create the SnapDRImage file and the volume files in a single operation.
2 Copy the filesto a safe place off the server.
Copy the SnapDRImage file to a safe location on another server or backup medium. (See the previous section for file names and paths.) This strategy ensures that if the file system on the Snap Server is corrupted, the image file will be available to restore server settings.
Backing Up the NetVault for GuardianOS NVDB Directory
Chapter 8 Disaster Recovery 63