Storage Snapshots or Streaming backups - Or Both?

[stephen.cilesio]

I'm finding it hard to go down either the pure storage Snapshot path or the pure Streaming backup path. I know that each have their own limitations, for example, storage based snapshots can do Instant VM recovery, guest file and app level items but can't do any restores through enterprise manager. Also another big thing is the fact that for Veeam to communicate to the storage device it needs to connect directly to the cluster (NetApp) instead of the individual SVM unless i am mistaken. Also with Snapshot based backups you can only restore from VM disks which are on the same datastore as the VMX file. But Damn! They are so fast and efficient!

With streaming backups the functionality is there (especially for self service portal to do restores through Enterprise manager) but when it comes to large environments and servers (specifically File Servers, DB servers etc) the jobs could take a long time on full backups to a lower tier of storage (SATA) begging the question about having a caching tier (SAS).

I've heard alot of different views and what i can gather is that having combination of both is a good idea. Reason being is that snapshot jobs allow you to get more frequent recovery points during the day for recovery, and then at the end of the day it’s recommended to backup from the snap so you’re writing a Veeam backup file to say a storage device for streaming backups then giving you multiple copies for data protection.

Just wanted to see if there is anyone who are using both streaming and snapshot based backups and how it's being implemented?

[Andreas Neufert]

You can compare those 2 methods like the following:
Snapshots and Snapshot Replicas (SnapVault/SnapMirror) are exact same copies. There is are no checks if the applications/Software what writes to it, did it in a way that it can read the data again. For example if VMware VMFS. So if VMFS is broken and you detect it not in a timely manner (because it only affects some data that are not used in a long time) you will end up in a long chain of Snapshots that all have the same problem.
Backups read the data again over the way that VMware had written it. If there are some read errors, you detect it at next backup run.

Then there is the human factor and I saw people deleting stuff by mistake.

We recommend to apply a 3-2-1 rule + air gapped backups.

3 copies of the data (original, backup/snapshot and a second copy of the backup/snapshot).
2 different media logics... store your data in a different way then you hold your production data and read it at least once over the way it was written to know that you have valid backups (see above).
1 additional site (Fire and other disaster could happen).

Air gapped backup to cloud or offline tape (just in case a virus delete or encrypt your backups).

On the other side NetApp really help you to optimize RTO and RPO...
A good concept is:
Run daily Application Aware backups to a system out of your storage system... best to do this from a SnapVault or SnapMirror.
Use Hourly or 2 hourly Application Aware backups and replicate them to SnapVault/SnapMirror destination and hold them for some days.
Create every 10 minutes a crash consistent snapshot and hold it for 1-2 days. Potentially only on your primary storage (or replicate to SV/SM if you have good connections)

[MichaelCade]

I actually was speaking to someone that had the same queries as you yesterday, and as you say Storage Snapshots are so fast and great for recovery time and point objectives. But to emphasise what Andreas has said if its on the same ONTAP (WAFL) system being moved from A to B then all good data but also bad data will also be stored and replicated. I always suggest using Storage Snapshots and a backup to that different media type with also a copy offsite. here were my quick notes back to the query.

1st line of backup - Storage Snapshots orchestrated by Veeam, this may or may not include replication to secondary array, these can be application or for an even faster RPO crash consistent could be used depending on Application. (Scenario - VM, File etc failure, really fast RPO/RTO requirement)

2nd line of backup - Backup from Storage Snapshots to a secondary media type, some spinning disk next to the production rack this will hold short term retention for fast recovery. (Scenario - Production storage failure, restore requirement outside snapshot retention)

3rd line of backup - Backup Copy / Backup from Secondary Storage Snapshot, getting that primary backup data over to a secondary or offsite location this could be a similar retention to 2nd line or this offsite copy could be for longer term retention. (Scenario - Production site failure and long term retention restore if requirement outside primary backup retention)