NetApp Snapvault is a disk-to-disk backup solution for NetApp filers. Basically, snapvault use the NetApp snapshots to store them as a backup on a secondary filer.
How Snapvault works
In first, a snapvault relationship is created between two filers, the first transfer is the baseline transfer and it's like a full backup. Then, every time a snapvault update is run, or scheduled, a new snapshot, which is locked, is done on the primary filer. The delta between the baseline snapshot and the new snapshot on the primary filer is transferred to the secondary filer. The new snapshot is now as the baseline snapshot, and the old one maybe deleted depending retention policy.
Be careful, almost all snapvault configuration is made from the secondary filer, and not the primary.
How configure Snapvault
Global configurationfiler1 : primary filer, with active files filer1:/vol/source_volume1 : primary volume where qtree is located
filer1:/vol/source_volume1/ds : qtree which will be backuped filer2 : secondary filer, where the data will be backuped filer2:/vol/snapvault_volume : secondary volume where snapvault will create the qtree
filer2:/vol/snapvault_volume/source_volume1 : qtree which will be created where data will transfered. It has to don't exist.
First of all, we have to enter the snapvault license, allow the snapvault communication between both filers :
filer1> license add XXXXX filer1> options snapvault.enable on filer1> options snapvault.access host=filer2 ---------- filer2> license add XXXXX filer2> options snapvault.enable on filer2> options snapvault.access host=filer1
We need to modify the snap sched on the secondary filer. We will configure the schedule later with snapvault snap sched. Because it isn't interesting to take snapshot if no new snapvault transfer are done.
filer2> snap sched snapvault_volume1 0 0 0
The initial transfer can be very long depending of the size used on the primary volume, because all data on the primary volume will transferred to the secondary during the initial transfer. We create the initial transfer before setup the snapvault schedule.
filer2> snapvault start -S filer1:/vol/source_volume1/ds filer2:/vol/snapvault_volume/qtree
The snapvault schedule must be configure on both filers.The snapshot copies on the source enables administrators to recover directly from source filer without accessing any copies on the destination. This enables more rapid restores. However, it is not necessary to retain a large number of copies on the primary; higher retention levels are configured on the secondary. The commands below shows how to create hourly, daily & weekly snapvault snapshots.
filer1> snapvault snap sched source_volume1 sv_hourly 24@0-22 filer1> snapvault snap sched source_volume1 sv_daily 7@23 filer1> snapvault snap sched source_volume1 sv_weekly 56@21@sun
On the secondary filer, the schedule is a bit different. The command is quiet the same, but works differently. The schedule indicate when the snapvault has to update the relation.
filer2> snapvault snap sched -x snapvault_volume sv_hourly 6@0-22 filer2> snapvault snap sched -x snapvault_volume sv_daily 14@23@sun-fri filer2> snapvault snap sched -x snapvault_volume sv_weekly 6@23@sun
That's it. The base configuration is done.
Check the snapvault status
Once the configuration is done, we don't have to do anything. Everything should works fine. But it could be interesting to check if the snapvault relation still working, when was the last snapvault update, etc... Here is the two main commands useful :
snapvault status (-l) : Show the snapvault status, the lag (which indicate when was the last snapvault transfer). The -l option permit to have more information like the quantity of data transfered during the last update
snap list : permit to see on each volume how many snapshots are available, when they have been created, and the usage.