Normally, SnapVault uses the count field of the SnapVault schedule on the secondary storage system to determine the number of Snapshot copies that are retained. Once the count has been reached, the oldest retained Snapshot copies are deleted when new Snapshot copies are added. For SnapLock volumes, older WORM Snapshot copies cannot be deleted until their retention period has expired. WORM Snapshot copies are not deleted automatically. It is your responsibility to delete WORM Snapshot copies once they expire.
Snapshot copies created by SnapVault on SnapLock Compliance volumes use a different naming scheme from that used by Snapshot copies for regular volumes. Snapshot names for SnapLock volumes use the time and date of the Snapshot copy creation as a suffix. The time and date are generated by the compliance clock. The following is the format of the Snapshot copy name:
snapname.yyyymmdd_hhmmss_zzz
snapname is the Snapshot copy name specified in the schedule
yyyymmdd is the year, month, and day
hhmmss is the hour, minute, and second
zzz is the current time zone setting
%/used %/total date name
---------- ---------- ------------ --------
2% ( 2%) 0% ( 0%) Feb 04 02:20 svhourly.20040104_120502_GMT
9% ( 3%) 1% ( 0%) Feb 04 02:15 svhourly.20040104_180601_GMT
You can configure the schedules on the SnapVault secondary storage system to create WORM Snapshot copies with a retention period that you specify. For WORM Snapshot copy creation to occur, the volume must exist on the secondary storage system and it must be a SnapLock volume.
Note
If you change the retention period in the schedule, WORM Snapshot copies created under the previous schedule retain their retention periods and WORM Snapshot copies created under the changed schedule use the new retention period.
When you configure a SnapVault Snapshot schedule for a SnapLock volume on the secondary storage system, the Snapshot copies created for that volume are WORM Snapshot copies. By default, SnapVault uses the retention period set by the snaplock_default_period vol option as the retention period for the WORM Snapshot copies. You should ensure that the retention periods you configured when creating a SnapLock Compliance volume are correct.
Caution
The default retention period for SnapVault Compliance volumes is 30 years. Be sure to reset the default retention period unless you want all of the created SnapVault WORM Snapshot copies to have a 30-year retention period.
You can specify retention periods for different WORM volume Snapshot copies. To specify the retention period for WORM volume Snapshot copies, complete the following step.
WORM Snapshot copies created on the secondary storage system in the sv_proj SnapLock volume have retention periods of 360 days from the time of their creation. Snapshot copies are created at noon and 8 p.m. every day.
snapvault snap sched -x -o retention_period=360d sv_proj sv_hourly 1@12,20
To extend the retention period of a WORM Snapshot copy, complete the following step.
The following command extends the hourly Snapshot copy on the wormvol volume to 2 years:
snapvault snap retain wormvol sv_hourly.20050513_195442_GMT 2y
***WARNING: YOU ARE REQUESTING SNAPLOCK RETENTION OF A SNAPSHOT***
This operation will enforce the retention of the snapshot by SnapLock for the specified retention period. You will NOT be able to delete the retained snapshot until this retention period has been satisfied. The relevant information for confirmation of this operation is as follows:
Volume: wormvol
Snapshot: sv_hourly.20050513_195442_GMT
Retain until: Fri Feb 17 00:00:27 GMT 2006
Are you REALLY sure you want to retain this snapshot? Y
WORM Snapshot copies are identified by the word snaplock at the end of each Snapshot copy entry. To list all Snapshot copies, including WORM Snapshot copies, complete the following step.
To list Snapshot copies with their retention dates, complete the following step.
Snapshot copies with a dash (-) in the retention date column are not WORM Snapshot copies; therefore, they do not have retention periods.
WORM Snapshot copies that have been retained beyond their retention periods can be deleted. To delete an expired WORM Snapshot copy, complete the following step.
| 1 |
snap delete volume snapshot |
Trying to delete unexpired WORM Snapshot copies will fail.
system> snap delete wormvol slminutely.20040104_122040_GMT
Illegal operation on snapshot locked by SnapLock.
You might need to retain more than the 255 Snapshot copies, which is the limit imposed on volumes by Data ONTAP. Actually, the practical limit for WORM Snapshot copies is about 250 because of a few non-WORM base Snapshot copies and temporary Snapshot copies that are used by SnapVault, and Snapshot copies that are needed for managing SnapMirror relationships if you have the SnapVault secondary volumes protected by SnapMirror.
If you need to retain more than 250 Snapshot copies, you can do so by creating a new volume. As subsequent volumes reach the limit, you create newer volumes. In this manner, you can use multiple volumes to retain a larger number of Snapshot copies.
Two approaches to creating a new volume to retain more Snapshot copies are as follows:
Note
You cannot retain more than 255 SnapVault Snapshot copies without a new baseline using Open Systems SnapVault because Open Systems SnaVault does not support the snapvault start -r command, a command that is needed to restart SnapVault relationships on the new volume.
The following are advantages of the cloning approach:
Note
At the time of the split, additional disk space will likely be used.
The following are advantages of the copy approach:
The following process lists tasks for creating a new volume for Snapshot retention.
Details of each task are listed in the following sections.
Note
Free Snapshot copies might be required to complete some operations. If you get an error message stating that the system has reached the Snapshot copy limit per volume, you will need to find unnecessary Snapshot copies and delete them.
To ensure everything on the old volume is in an appropriate state, complete the following steps.
| 1 |
Check that all relationships for the volume that you will clone or copy are Idle and in the SnapVaulted state by entering the following command: snapvault status |
|
|
Go to Step 3. | ||
|
They are not in this state, but transfers are proceeding normally | ||
|
Go to Step 2 | ||
| 2 |
Occasionally, the snapvault status command might show a relationship for which there is no permanent configuration information. To check and correct the configuration information, complete the following steps.
|
|
| 3 |
Ensure that all qtrees with SnapVault relationships are at the same base Snapshot copy by entering the following command: snapvault status -l Check the Base Snapshot copy listed for each qtree in the destination volume, to ensure they refer to the same Snapshot copy. |
|
|
Go to Step 4 | ||
| 4 |
Enter the following command to create a new base Snapshot copy for all qtrees in the volume: snapvault snap create -w sec_vol "" sec_vol is the current secondary volume. " " specifies that no snapvault snap sched Snapshot copy is created, such as sv_hourly.20050513_195442_GMT. Note |
|
| 5 |
Go back to Step 1 and ensure everything is in an appropriate state. |
|
Before you unconfigure the schedules, make note of the schedule configuration, including retention periods. Doing so enables you to set up the schedule the same way on the new secondary volume.
To unconfigure the SnapVault schedules, complete the following steps.
| 1 |
View the existing schedules by entering the following command: snapvault snap sched sec_vol |
| 2 |
Unconfigure the schedules by entering the following command: snapvault snap unsched sec_vol Note |
| 3 |
Ensure that everything is in an appropriate state by repeating the steps in the section Ensure everything on the old volume is in an appropriate state. |
To create a volume clone, complete the following steps.
| 1 |
Ensure that you licensed the volume cloning feature (flex_clone license) by entering the following command: license |
| 2 |
Create the clone by entering the following command: vol clone create altvol -b sec_vol base_snapshot altvol is the new secondary volume. sec_vol is the old secondary volume. base_snapshot is the Snapshot copy that you found in Step 3 of Ensure everything on the old volume is in an appropriate state. Note When you create the volume clone, you might see several messages that appear to be errors, but they are not. Examples of possible messages are: Reverting volume altvol to a previous snapshot. Breaking snapmirrored qtree 1 in volume altvol: base snapshot no longer exists. Use snapmirror resync or initialize to re-establish the snapmirror. Breaking snapmirrored qtree 2 in volume altvol: WAFL_check broke all snapmirrors in volume wormclone1. Use snapmirror resync or initialize to re-establish the snapmirror. |
When creating a copy of a volume, the copy must be the same type as the old volume (flexible or traditional) and it must be the same compliance type as the old volume (SnapLock Compliance or SnapLock Enterprise).
Note
If the volume you are copying is a flexible volume, the copy does not have to be in the same aggregate as the old volume, nor does it have to be on the same storage system as the old volume.
To create a copy of the old volume, complete the following steps.
Clone volumes and volume copies automatically inherit the retention periods from their parent volumes. For this reason, this step is usually a check. You can change the retention periods for the volume if you want.
To check the retention periods on the new volume, complete the following steps.
As was the case with retention periods, clone volumes and volume copies automatically inherit all options from their parent volumes. Before starting any SnapVault activity on the new volume, ensure that this is the case.
To check volume options on the new volume against volume options on the old volume, complete the following steps.
The qtrees on the new volume will all be in the normal state, not the snapvaulted state (as shown using the qtree status command). You must restart the SnapVault relationships in the new volume.
Note
To support data integrity in a restrictive SnapLock Compliance environment, the snapvault start -r operation saves all data that was written after the common Snapshot copy to a directory on the volume. For details see SnapVault resynchronization for SnapLock Compliance volumes.
To restart SnapVault relationships in the new volume, complete the following steps.
Assuming you are not changing the SnapVault Snapshot schedule on the primary, use the same names and schedule for Snapshot copies.
To reconfigure the SnapVault schedules, complete the following step.
After the first scheduled Snapshot copy and transfer have occurred, look at the entries in the new volume.
To view the entries, complete the following steps.
| 1 |
snapvault status snapvault status -c |
| 2 |
Look at all the entries for the new volume and ensure that everything is working correctly. |
When everything is working correctly, you can delete the old relationships. To delete the old relationships, complete the following steps.
The snapvault stop command deletes the qtree from the active file system on the old volume. Backup copies of the qtree are in the Snapshot copies on the old volume and you can access them if you want to browse the old backups or restore from the old backups. The active image of the backup data is moved to the new volume when you restart the SnapVault relationship using the snapvault start -r command.
Copyright © 1994-2005, Network Appliance, Inc. All rights
reserved.
Part No. 210-01081_B0
File: snapva31.htm
Last updated: 01-Dec-2005 16:36:13