Continuing from my previous post on SnapMirror, SnapVault also uses NetApp Snapshot technology. I will use "SV" instead of SnapVault.
SV can be done from multiple primary storage systems to one secondary storage system, it also reduces storage requirements by using thin-replication technology and by inter-operating with deduplication. SV can be scheduled at multiple intervals to improve RPO.
One can provide read-only access that is stored on SV secondary storage by exporting the SV secondary volume to or sharing with UNIX or windows clients. Users can be allowed to copy-and-paste procedures to restore data.
License:
1.Install license for each primary (sv_ontap_pri) and secondary (sv_ontap_sec) storage system.
2. SnapMirror license required for failover to a SV secondary qtree or volume.
Qtrees are the basic unit for SV. Primary qtrees, non-qtree data and even volumes are backed up to qtrees on the SV secondary system.
Initial Backup (baseline): The first time SV backs up a qtree or volume, it backs up all of the data blocks on primary storage, writes the data to the secondary volume, and then creates a Snapshot on the secondary volume.
Scheduled Updates: After the initial backup, SV performs updates, transferring and storing only the data blocks that have changed since the last backup. For every update, SV creates a snapshot copy of the relevant volume.
Archive: One uses SV mainly for archival purposes, as we take multiple snapshot copies, you can archive all those multiple backups that were performed multiple times.
Ports:
1. For SV backup and restore operations, port 10566 must be open in both directions.
2. For NDMP management, port 10000 must be open on both primary and secondary systems.
Log file: One can locate the SV logs in the /etc/log/snapmirror
Throttling: One can enable throttling by setting "options replication.throttle.enable on|off"
Deduplication:
1. By enabling dedup on SV secondary storage system and secondary volume, it automatically starts the process automatically after the completion of a SV transfer.
2. The deduplication of blocks is initiated when the number of changed blocks represents at least 20% of the number of blocks in volume.
3. As dedup synchronizes with SV schedule, you cannot schedule the dedup of a SV secondary volume. One can start this process manually from GUI or CLI with a maximum of eight concurrent dedup operations.
Scenario:1
To setup SV by adding license, enabling access, creating volume, schedule, start and update.
Step:1 Add license
filerA> license add <sv_ontap_pri>
filerB> license add <sv_ontap_sec>
Step:2 Enable SV access
filerA> options sanpvault.enable on
filerA> options snapvault.access all
filerB> options sanpvault.enable on
filerB> options snapvault.access all
Step:3 Create thin primary and secondary volume by setting several options which I generally use
filerA> vol create vol_primary -s none aggr1 500g
filerA> vol options vol_primary fractional_reserve 0
filerA> snap reserve vol_primary 0
filerA> snap sched vol_primary 000
filerA> snap autodelete vol_primary on
filerA> snap autodelete vol_primary target_free_space 5
filerA> sis on /vol/vol_primary
filerB> vol create vol_secondary -s none aggr1 500g
filerB> vol options vol_secondary fractional_reserve 0
filerB> vol options vol_secondary nosnap on
filerB> snap reserve vol_secondary 0
filerB> snap sched vol_secondary 000
filerB> sis on /vol/vol_secondary
filerA> qtree create /vol/vol_primary/qt
Step:5 Schedule Snapvault
filerA> snapvault snap sched vol_primary sv_hourly 6@0-23
filerB> snapvault snap sched -x vol_secondary sv_hourly 24@0-23
Step:6 Initialize baseline transfer
filerB> snapvault start -S filerA:/vol/vol_primary/qt /vol/vol_secondary/qt
When you run the above command, qtree "qt" will be created on the secondary volume automatically.
Step:7 Check the status of transfer on primary or secondary storage system
snapvault status -l filerA:/vol/vol_primary/qt
or
snapvault status
Step:8 Update SV secondary
filerB> snapvault update /vol/vol_secondary/qt
Scenario:2
Restore data to original qtree on the primary storage system
filerA> snapvault restore -S filerB:/vol/vol_secondary/qt /vol/vol_primary/qt
Scenario:3
To clean up the obsolete SV relationships
Step:1 Identify the relationships that needs to be cleaned up
filerA> snapvault destinations
Step:2 Release secondary destinations.
filerA> snapvault release /vol/vol_primary/qt filerB:/vol/vol_secondary/qt
Step:3 Stop the snapvault services
filerB> snapvault stop -f filerB:/vol/vol_secondary/qt
Step:4 Unschedule updates
filerA> snapvault snap unsched -f vol_primary sv_hourly
filerB> snapvault snap unsched -f vol_secondary sv_hourly
Step:5 Delete SV snapshot copies
filerA> snap list vo_primary
filerA> snap delete vol_primary <snapshot name>
filerB> snap list vol_secondary
filerB> snap delete vol_secondary <snapshot name>
Scenario:4
To restart SV by resynchronizing relationships between primary and secondary.
filerB> snapvault start -r -S filerA:/vol/vol_primary/qt filerB:/vol/vol_secondary/qt
No comments:
Post a Comment