Make one of the transaction log LUNs the volume mount point root because it will be backed up on a regular basis. This makes certain that your volume mount points are preserved in a backup set and can be restored if necessary.
Also note that if databases reside on a LUN, do not add mount points to that LUN. If you must complete a restore of a database residing on a LUN with volume mount points, the restore operation removes any mount points that were created after the backup, disrupting access to the data on the mounted volumes referenced by these volume mount points. This is true only of mount points that exist on volumes that hold database files.
BEST PRACTICE: ALWAYS PLACE SYSTEM DATABASES ON A DEDICATED LUN AND FLEXVOL VOLUME.
We can take a backup when the user database is present in a LUN in which system databases are also present. This is because we can restore the Snapshot copy for a user database, and SnapManager reverts to the conventional stream-based backup, dumping all data, ―block for block,‖ to the snapinfo LUN.
Keeping system databases on a dedicated LUN and FlexVol volume separated from your user databases has the benefit of keeping deltas between Snapshot copies smaller since they do not hold changes to tempdb. Tempdb is recreated every time SQL Server is restarted and provides a scratch pad space in which SQL Server manages the creation of indexes and various sorting activities. The data in tempdb is thus transient and does not require backup support. Since the size and data associated with tempdb can become very large and volatile in some instances, it should be located on a dedicated FlexVol volume with other system databases on which Snapshot copies do not occur. This also helps preserve bandwidth and space when SnapMirror is used.
BEST PRACTICE: BACKUP POLICY
followed, you might end up with mismatching backup sets on different volumes. This can cause a backup set to be rendered useless and unable to be restored.
BEST PRACTICE: FRACTIONAL SPACE POLICY
The threshold value for the policy ―deletion of backup sets‖ should always be less than that of ―dismount databases.‖
BEST PRACTICE: FRACTIONAL SPACE RESERVATION
When a LUN is fully space reserved (fractional space reservation set to 100%), write operations to that LUN are protected against failure caused by an out-of space condition due to Snapshot copy disk space consumption. If you do require a fractional space reservation policy, work with your NetApp Support representative. The representative can help implement a fractional space reservation policy that fits your environment.
The fractional space reservation policy is set to 100% (disabled) by default. In order to leverage fractional space reservation policies, you must set the fractional reserve parameter to less than 100%.
BEST PRACTICE: GUIDELINES FOR ESTIMATING THE SIZE OF THE VOLUME
When you create a volume and you want to reserve a percentage of the space for overwrites, use the following calculation to determine the size of the volume:
(1 + fractional reserve)
*
LUN size + amount of data in Snapshot copies BEST PRACTICE: MINIMUM BACKUP FREQUENCYAll backup and recovery processes should be created according to each environment's unique
requirements. When in doubt, the general recommendation is to back up the database every hour and the transaction log every 30 minutes during production time and possibly less often during off-peak hours. BEST PRACTICE: ALWAYS ARCHIVE OR MIRROR SNAPSHOT COPIES
NetApp strongly recommends archiving or mirroring backup sets as soon as possible. Disasters do occur, and if the storage device containing the databases and backup Snapshot images is adversely affected, it will not be possible to restore the databases from the primary storage system. Archive media can be tape, another FAS system, a NearStore device, or even local SATA drives available in the FAS3000 series. The archive process is described in further detail in SnapManager for Microsoft SQL Server (SMSQL) Installation and Administration Guide.
BEST PRACTICE: TIPS FOR CREATING LUNS
1. When specifying a UNC path to a share of a volume to create a LUN, use IP addresses instead of host names. This is particularly important with iSCSI, because host-to-IP name resolution issues can interfere with the locating and mounting of iSCSI LUNs during the boot process.
2. Use SnapDrive to create LUNs for use with Windows to avoid complexity.
3. Calculate disk space requirements to accommodate data growth, Snapshot copies, and space reservations.
4. Leave automatic Snapshot copy scheduling off as configured by SnapDrive.
BEST PRACTICE: RUN DATABASE CONSISTENCY CHECKER (DBCC CHECKDB) TO VALIDATE DATABASE BEFORE AND AFTER MIGRATION
For usual operations, also try to execute the verification process during off-peak hours to prevent excessive load on the production system. If possible, off-load the entire verification process to another SQL Server instance running on another server.
BEST PRACTICE: AVOID CREATING SNAPSHOT COPIES ON VOLUMES WITH ACTIVE SNAPSHOT-WRITABLE LUNS
NetApp does not recommend creating a Snapshot copy of a volume that contains an active Snapshot copy because this creates a ―busy Snapshot‖ issue.
Avoid scheduling SMSQL Snapshot copies when: Database verifications are running
Archiving a Snapshot-backed LUN to tape or other media
BEST PRACTICE: WHEN USING SUPPLEMENTAL ROLLING SNAPSHOT COPIES
Thoroughly read the ―SMSQL Installation and Configuration Guide‖ section ―Minimizing your exposure to loss of data.‖
Configure rolling Snapshot copies to occur only between SMSQL backup and SnapMirror processes. This prevents overlapping Snapshot schedules.
BEST PRACTICE: USE ALTERNATIVE METHODS FOR REMOTE MANAGEMENT
NetApp recommends avoiding Terminal Server for server management when possible. When using Terminal Server with Windows 2003 (not Windows 2000), you may use a remote desktop to connect if you use a command line parameter/console, shown here:
%SystemRoot%\System32\mstsc.exe /console
If you are using Windows 2000, NetApp advises using either NetMeeting remote control or RealVNC (available at www.realvnc.com/download.html).