NetApp Snapvault Guide

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 configuration

filer1 : 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

Initial configuration

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

Schedule

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.