Veeam and Netgear NAS

[m.novelli]

Hi guys, I would like to share a couple of odd issues with Veeam Backup and Netgear NAS (low end models). Maybe you experienced something similar in your environment.

I have some SMB customers with Netgear NAS (like ReadyNAS NV+ v2 or ReadyNAS Pro) configured as SMB repository for Veeam Backup

With two different customers running Veeam Backup 6.5 patch 2 I had an odd issue. Veeam Backup Job was set to incremental with full active backup every week. Vmware is 4.1 U3 for both customers.

It happened that at one customers site Veeam was only performing incrementals backup but never the full active. Email report was always success, but looking deeper we just found one full active backup at the very beginning and then dozens of small incremental backups.

At another customer site happened that Veeam after a couple of years of perfect work didn't delete the old backups and the NAS got full. Looking at the files located on the NAS I've found that the most recent timestamp was 2 weeks ago. Again email report by Veeam was successful and last timestamp was the night before the NAS got full

Marco

[chrisdearden]

I dont think the NAS has anything to do with it. Is the job actually scheduled to run on the days you have set for the active full ?

[m.novelli]

I dont think the NAS has anything to do with it. Is the job actually scheduled to run on the days you have set for the active full ?

Yes, is set to run every day

Marco

[homerjnick]

I use similiar Netgear NAS' and have not had any issues...just naturally poor performance compared to other NAS'

[Dima P.]

Hello Marco,

Could you please clarify does Netgrear Ready NAS is used as NFS storage in both mentioned cases? From the way you described it may sound like the issue with the security permissions with access to the NFS storage?

Thank you.

[m.novelli]

Hello Marco,

Could you please clarify does Netgrear Ready NAS is used as NFS storage in both mentioned cases? From the way you described it may sound like the issue with the security permissions with access to the NFS storage?

Thank you.

It's used as simple CIFS share, \\ip_address\shared_backup_folder

Just wanted to share my experience with the forum guys

Marco

[Dima P.]

Ok, thank you for the update.

Definitely not the security permissions
It might be the retention settings then - as it handles the deletion of the outdated backup files? Could you please put a little bit light on the job retention set up. Thank you.

[foggy]

It happened that at one customers site Veeam was only performing incrementals backup but never the full active. Email report was always success, but looking deeper we just found one full active backup at the very beginning and then dozens of small incremental backups.

Definitely not related to the NAS itself. Does this customer probably chain his backup jobs to run one after another? If that's the case, then chained jobs are started on the next day (not the one the active full is scheduled to be performed at), due to the time required to run earlier jobs.

At another customer site happened that Veeam after a couple of years of perfect work didn't delete the old backups and the NAS got full. Looking at the files located on the NAS I've found that the most recent timestamp was 2 weeks ago. Again email report by Veeam was successful and last timestamp was the night before the NAS got full

And no default low backup repository disk space notification warnings? Looks strange. Btw, this could be caused by the same issue (active fulls are not running, previous backups cannot be deleted according to retention settings).

[m.novelli]

Definitely not related to the NAS itself. Does this customer probably chain his backup jobs to run one after another? If that's the case, then chained jobs are started on the next day (not the one the active full is scheduled to be performed at), due to the time required to run earlier jobs.

Good catch! This is the issue with this customer, the backup job was chained!

Marco

[foggy]

Good catch! This is the issue with this customer, the backup job was chained!

Not the best practice actually. The better approach to limit the number of concurrent tasks (if that is the goal of chaining jobs) would be setting the number of parallel tasks running on the proxy or repository server to 1 and starting all of the jobs one by one with some short intervals.