Issue and Best Practices with Storage snapshot (NetApp)

[LaurentS]

Hello,

I have issue when i use Storage Snapshot with VBR 9.0.0.1715 and NetApp (1x FAS2552 2x FAS254) : ONTAP OS: 'NetApp Release 8.3.2P8 (No Flexclone license).

By intermitence we got this errors in the Backup Job Logs (Job.<MyBackupJobName>.Backup.log):
- Error Attempt to create snapshot when clone in progress
- Error Snapshot operation not allowed due to clones backed by snapshots. Try again after sometime

There is a NetApp KB talking about that :
https://kb.netapp.com/support/index?pag ... id=2023724 (you need to login)
The solution of this KB helped me to understand what's happened :
SOLUTION To resolve the issue, ensure that no other backup programs are running at the same time as a VSC backup.

We only have VBR to Backup VMs, but we have 2 Backup Job each one have some VMs of the same LUN/datastore.
I think the issue is caused when i create a snapshot+clone for the First Job and when the second Job start it can't create another clone, because another one is already created by the First Job.

If this is true, we need to change our Backup Job Policy and maybe a best practices is to :
- Backup Job n°1 with all VMs of LUN1
- Backup job n°2 with all VMs of LUN2
- etc...

So we can launch all backup Job simultaneous and won't have this "Storage Snapshot" Issue.
Maybe we will have to use "per-VM Backup files" if we have too many VMs on a single LUN but it's another subject.

What do you think about this Backup Policy change (One Backup Job by LUN/Datstore) when using Storage Snapshot ?

Thank you.
Regards

Laurent.S

[widmerkarl]

Hi Laurent

First, did you already open a support case at Veeam? If not i would recommend to do this. You you'll get the best support you can have (second reason is that posts without support ID could be deleted here in the forums).

Second, per VM backup chain is, as far as my experience tells me, always a good option. So it's one backup file per VM, and not a huge backup file for all VMs, which probably can cause certain problems.

Third, is there a possibility that a job is running directly on your NetApp? Like Snapvault or Snapmirror? Could that probably cause an issue when a Veeam job starts?

At one of my customers we've got also a NetApp. I do storage snapshot every half hour through Veeam, and backups twice per day (night and lunch time), which will be replicated with Veeam to another site. During the backup windows (which take about half an hour) i set the storage snapshot jobs to not do a storage snapshot.

I created the storage snapshot like this, that it does only the VMs on one LUN, that means per LUN one storage snapshot job. I also enabled storage latency control to not overload the NetApp.

[LaurentS]

Hello Karl,

Thanks for your quick reply.

There is no other job running directly in the 2 NetApp array, no snapvault or snapmirror.

I did not have open a case yet, because when using storage snapshot (NetApp w/o flexclone license), i would like to know if it is a best practices to change my Backup Policy to :
- Backup Job n°1 with all VMs of LUN1
- Backup job n°2 with all VMs of LUN2
Because if it is, i will change the Backup Policy and i think my issue will just disappear :]

With what i understand and what i read from you, i can say that, make a Backup Job by LUN, make sense !

Regards.
Laurent.S

[foggy]

Hi Laurent, yes, switching to job per LUN is the right step to address this behavior.

[LaurentS]

Thanks for this confirmation foggy,

I didn't notice before, but if a VM change from one LUN to another (Storage vMotion or Storage DRS) i will have a Backup Repository space increase
The VM will be process by another Job and, a Full Backup of the VM in a new Backup Chain will be create instead of an increment in the first Backup Chain.

I will check this information in a test environnement and see what i can do to deal with it.
Maybe a single Job with All LUN (with"per-VM backup files"), what do you think about it?

Regards.
Laurent.S

[foggy]

Single job with all LUNs will also work.