Veeam v8 Install With NetApp Config

Veeam has released v8 of it’s Backup and Replication software. As a long time Veeam user this is a release I have been waiting for. Previously, Veeam had released support for storage snapshots on HP storage arrays, but with my environments being primarily NetApp over the last few years I wasn’t able to take advantage. Now in v8, we can restore and backup directly from snapshot. This speeds up the process and limits the impact on the Virtual Machines in the environment.

This guide walks you through a brand new installation of Veeam Backup & Replication v8 on Server 2012 and how to add your NetApp storage array as an object to browse existing snapshots. This is a high-level guide and in the future I’ll do a more in-depth backup/restore from Storage. For my guide on installing Veeam v7 with Windows 2012 R2 Data Deduplication, click here.

If you’re not interested in a custom SQL Express installation as well, pick up the guide at step 15. Steps 1-15 show how to install SQL Express to the secondary drive to prevent growing databases from affecting the main OS partition.


1. Dedicated server for installing Veeam
2. License file for Veeam (copied out to the server)
3. Latest version of Veeam v8 downloaded and mounted on the server (the installer is in an .ISO)
4. A service account for running the Veeam services (Optional, but my preferred method)
5. Username/password with admin rights to vCenter
6. Username/password for NetApp array (for this post I’ll be using the ‘root’ account)


1. Right click the DVD drive and click “Open”
2. Navigate to Redistr -> x64. Locate SQLEXPRx64.exe, right click and choose “Run as administrator”
3. Click “Yes” to run the installer if prompted
4. Under the “Installation” section, click “New SQL Server stand-alone installation”
5. Click the check box for “I accept the license terms” and decide if you want to send feature usage data to Microsoft then click “Next”
6. Ensure the check box for “Include SQL Server product updates” is checked and click “Next”
7. Updates and setup files will install…
8. Choose the features to install (Database Engine Services is the only thing required). Choose the install directory (I always choose the secondary drive of the machine and click “Next”
9. Choose a name for the instance or leave as default (SQLExpress), choose the instance root directory (secondary drive again) and click “Next”
10. Enter a service account for running the SQL DB engine (or leave it as local system) and click “Next”
11. Choose “Mixed mode” for the authentication type then enter a password for the “sa” account (Immediately save this password somewhere). Choose the groups/users that will be SQL Server administrators

a. Be default, only users/groups added here will have access to the Veeam console. If you don’t want to grant permissions to the SQL instance, you can grant access to these users/groups for the Veeam database after it has been created

12. Click on the “Data Directories” tab and ensure all the directories are pointing to the secondary drive and click “Next”
13. Choose whether to send error reports and click “Next” and the installation will begin
14. Once the installation completes, click “Close”
15. Close the “SQL Server Installation Center” window. Navigate back to the root of the DVD drive. Right click on “Setup.exe” and choose “Run as administrator”
16. Click “Yes” to run the installer if prompted
17. Click “install” for “Veeam Backup & Replication”
18. Click “Next”
19. Read and accept the license terms and click “Next”
20. Click “Browse” and locate your license file then click “Next”
21. Choose the features to install and the install directory then click “Next”

a. To install to a different location (like a secondary drive), the folders need to be created ahead of time

22. If any features are missing, click “Install”
23. Once the system configuration check passes, click “Next”
24. Review the default configuration and if no changes need to be made, click “Install”
25. Once the install completes, click “Finish”
26. Close the setup window and restart the server
27. After the server finishes rebooting, login and view the services to ensure the Veeam and SQL services that are “Automatic” have started
28. Open “Veeam Backup & Replication”
29. Click “Managed servers” on the left side and then click “VMware vSphere”
30. Enter the name or IP of the vCenter Server and click “Next”
31. Click the “Add” button and then enter the username/password of an account with permissions on the vCenter server. Click “OK” then click “Next”
32. Click “Finish”
33. To add your NetApp storage systems to Veeam, click on “Storage Infrastructure” and then click the “Add Storage” button
34. Click “NetApp Data ONTAP”
35. Enter the Name or IP of the storage system and click “Next”
36. Click “Add” to add credentials to connect to the NetApp then choose the protocol and port. Click “Next”
37. If the name/IP and credentials work, click finish and discovery of VMs and LUNs/Volumes will begin.
38. Once storage and VMs have been discovered, click “Close”
39. In the “Storage Infrastructure” view, expand “NetApp”, then the storage system. Choose a volume with virtual machines and current volume snapshots. Expand the volume, choose a snapshot and see what VMs are inside.

a. From this view you can delete existing snapshots, create new storage snapshots, and rescan the volume for new snapshots. At the VM-level, you can instantly recover the VM from snapshot, restore guest-OS files, and even restore objects from Active Directory, Exchange, SQL or SharePoint.

40. Click on “Backup & Replication” then expand “Backups” and click on “Storage snapshots.” You’ll see a list of all the volumes that have snapshots, what VM’s are in those snapshots, and how many restore points are available.

This is the basics of installing Veeam v8 and connecting to your vCenter Server and NetApp Storage. The process is incredibly simple and like every else from Veeam it just works. In the future I intend to add more restore scenarios such as application item recovery and VM recovery from storage snapshots.

Veeam v8 Install With NetApp Config

Tegile Array Replication and Restore

These days most of my replication is handled at the VM-level by software design for virtualization. While that is the case for most of my evironment, I still have a few non-virtualized workloads that run on shared storage that need to be replicated in the event of a disaster at my primary location. This process has never been too complex from my days of working with NetApp and now as I continue exploring the Tegile I’m happy to say that it’s just as easy through the GUI.

Documenting this process for my non-virtual workloads would be a little difficult so I’ve decided to document this process using an NFS datastore containing a few virtual machines. The first half of this guide is setting up the replication relationship and replicating the data. The second-half is the process to actually restore that data and make it usable at your DR site.


1. Login to the web interface of the Tegile that is the replication source
2. Click on “Settings” then “App-Aware”
3. Click on “Zebi Replication” on the left column
4. Under the tab “Replication Target” click the “Add” button (This is adding the DR Tegile as the target array)
5. Enter the name or IP of the array (the shared Management IP address) and the username/password (Optionally you can specify a port range for replication which we won’t be doing for this documentation) and click “Add”
6. Once it has been successfully added it will appear in the “Replication Target” list
7. Login to the web interface of the DR target Tegile, click on “Settings” then “App-Aware”, choose “Zebi Replication” on the left column and then click on “Replication Source” tab. You should see your other array listed here (The IP address will be the “management” IPs of each controller, not the shared management IP for both arrays)
8. Back on the Primary Tegile (Replication source) click on “Data”
9. Click on the disk pool then then project that will be replicated
10. For this documentation I’ve created a Project named “NFS_Replication” with a volume named DR_Windows with 4 VMs inside. Click on the project that will be replicated and click on the “Edit” button
11. Click on “Replication” on the left column
12. Click the “Add Replication” button

a. Select the Target System and click “Next”
b. Select the “Target Pool” and enter a name for the “Replication Project”. Click “Next”
c. Choose what options are required and which volumes will be replicated (This test only has one volume, DR_Windows, but you can include or exclude any volumes that exist in this project. We’ll choose quiesce which will perform a VMware snapshot to put the OS in a consistent state. Click “Next”
d. Choose your schedule (manual or automatic), frequency, and how many additional snapshots (restore points) will be saved on the target array. For this example we’ll do daily replication that happens at 10:49 am and we’ll keep 14 snapshots. Click “Finish”
e. Once it’s all setup, you’ll see your target array, the target pool, and the target project

13. I have 4 VMs in that datastore (DR-Test01-04). Once the time hits, we can see that snapshots are taken, then removed, for each of the VMs in that datastore.
14. On the DR target array, we can see we now have snapshots available for this project. (The reason there are 2 is because I initiated a manual replication sync for testing first)

a. To manually kick off a replica snapshot, on the source array, find the project, click on “Replication” and then click the “Play” button that says “Replicate”


That is how simple it is to setup replication. Now let’s imagine we need to spin up those replicated VMs in this volume. Here is how we do that.


1. On the DR target array, click on Data, select the pool, then click on “Replica (1)” to view the replica project
2. Click the “Edit” button for the NFS volume
3. Click on “Snapshots” and find the snapshot you want to bring live (We’ll choose the latest version). Click the “Clone” button

a. Cloning the snapshot will allow us to create a new project and NFS Volume from this snapshot and spin up these VMs in DR. By doing a clone, we’re able to continue to replicate data in the event you are testing replication instead of having an actual DR event.

4. Enter a name for the new Project (DR_NFS_Replication for this writing) and a name for the mount point (/export/DR_NFS_Replication for this writing) and click “Clone”
5. If successful, you’ll receive this message about the new project being created. Click “OK”
6. Close the window for “Share Configuration” and click on “Local (1)” under “Projects”
7. Click on the “DR_NFS_Replication” project then view the Mountpoint of the Share (/export/DR_NFS_Replication/DR_Windows). Note the “c” before the share name which denotes it was a clone from another projects
8. Click the “Edit” button for the project and then click on “Sharing”
9. This is where you will add the IP addresses or range of IPs that need read/write and root access to the shares in this project. The IP addresses/ranges will carry over from the source array. Our IP range is the same in DR as our lab so we’ll leave this alone.
10. Connect to your DR vCenter server or ESXi hosts. Click on the host, then “Configuration”, then “Storage”
11. Click “Add Storage” towards the top right
12. Choose “Network File System” and click “Next”
13. Enter the NFS IP address of the DR Tegile, enter the folder path (/export/DR_NFS_Replication/DR_Windows) and then enter the name of the Datastore (DR_Windows). Click “Next”
14. Review the summary info and click “Finish”
15. Repeat for each host that needs access to this datastore. Afterwards, right click the datastore and click “Browse Datastore”
16. Inside you’ll see the 4 VMs we that were located in here before. Open each folder, right click the VM name.vmx file and choose “Add to inventory”
17. Enter the name and location for the VM and click “Next”
18. Choose the Cluster or host and click “Next”
19. Review the settings and click “Finish.” Repeat for each VM that needs to be added.
20. Power on all the VMs and now you can run any validation tests or bring these VMs live in a DR event


Obviously, the process of mounting the datastore in your DR vCenter Server and re-adding the VMs one by one would be time consuming and tedious. When developing your DR plans, having this process scripted (easy enough in something like PowerCLI) ahead of time on the vCenter side of things would ease that burden. From the standpoint of the Tegile, this process is fairly intuitive and simple to setup. One of the things I love is that by default the data you are bringing live on the DR site is a clone and replication continues running without being affected.

Tegile Array Replication and Restore

Performing Tegile System Upgrade

One of the more nerve-racking tasks as a storage admin is performing upgrades to your storage arrays. Through the years I’ve done a few upgrades to my NetApps and even when following directions on how to do it, I still worry that something isn’t going to go right and I’ll be left restoring a lot of data. I don’t exactly love working in the CLI either which adds to the nerves.

While working with this Tegile HA2400 we had a software update available ( to and it seemed like a great time to document this process. Software updates are done through the web interface and are done in just a few clicks on each controller. With failovers that allow for minimal interruption, I was able to perform this upgrade towards the end of the working day and we never had any application interruptions.

Below are the steps to peform this system upgrade.

1. If running in Active/Passive, login to the web interface of the passive Zebi node (default credentials are admin/tegile)
2. Verify that it’s the passive node by viewing the available pools. If there are no pools running on this node, you will only see “Zebi System” as the pool name
3. Click on “Settings” then “Administration”
4. On the left side, click “System Upgrade”
5. Click the link for “Check for Upgrades”
6. If there are any available updates, they will appear next to “Update Available”
7. Click the “Upgrade” button, click “Upgrade Local” and then click “OK” to confirm upgrading to the latest version
8. The installation will begin and show the status of the tasks it is performing followed by a notification that the node is rebooting.
9. After the node has rebooted, log back in to the web interface
10. Click on the Node name in the top right corner to verify the new version is running
11. Click the Flag icon in the top right and then the “ACK” button for the upgrade events that are generated.
12. Click on the Node name again and then click “Go to peer node” (this will open a new tab to connect to the other node in the cluster)
13. Click on “Settings” and then “HA”
14. Click “Switch Over All Resources” and click “OK” to confirm
15. Once you receive this message on controller A, all resources have been migrated
16. Click on “Settings” then “Administration”
17. Click on “System Upgrade” and then ensure that the “Update Available” version matches the version applied to the partner node
18. Click the “Upgrade” button, then click “Upgrade Local” (not that it recognizes the peer has already been upgraded) and click “OK”
19. The current task status will display just as before and then you’ll be notified once the node is rebooting just as before
20. After the reboot, log back in to the web interface and click the node in the top right corner to verify the version
21. Click on “Settings” and then “HA”
22. After the last upgrade, all the resources sitting on Controller B moved back to Controller A and now Controller B shows standby

That is all there is to it. The whole process from start to finish was under 15 minutes (I think closer to 10 if I didn’t screenshot the whole process). The steps for an active/active setup would be essentially the same, but you would move all the resources off one controller and on to the other prior to performing the first upgrade. Interestingly, despite not having auto failback enabled (Settings -> HA -> Advanced Options) after the upgrade completed all the resources that were on controller B moved back to controller A. During the next upgrade I will see if that happens again or was just a fluke this time around. I might even do that upgrade with a heavier load on the box just to see what happens.


Performing Tegile System Upgrade