we have a FAS8020 (NetApp Release 8.2.2P1 7-Mode) and Catalogix DPX Backup Software.
The problem is that our NAGIOS shows the following:
CRIT - 868.6% used (10.86 of 1.25 TB), (warn/crit at 80.00/90.00%), trend: 0.00 B / 24 hours
Looking at the NetApp OnCommand Manager: It is true!
This volume is thin provisioned and has 5% snapshot reserve configured.
Enable scheduled snapshots is NOT set.
Under DataProtection -> SnapVault -> Relationships and Schedules i found entries (Schedule Type=Backup, Schedule Details=Basic) and under Snapshot Copies i have a looooot of Files.
Can please someone explain to me why i have so much snapshot copies in that .snapshot folder? As this folder is only used for Backup Data coming from Catalogic DPX i think it is not nessesary to also snapshot them. Backup Data should be in Filesystem /vol/vol_block_bu_exchange instead of Filesystem /vol/vol_block_bu_exchange/.snapshot.
Next question is how could it be that we have 5% configured and now we have 868,6%?
I have absolutely no idea about this topic and i hope someone can explain it to me 🙂
So what I think you are seeing is that the snapshots have "spilled" over into the volume space used by the data i.e. the remaining 95%.
Your volume was set with a 5% snap reserve, its purpose is a dedicated space to hold all the snapshot copies. However, if the size of the snapshots exceeds that 5% reserve then they will start to consume the remaining space available in the volume, thereby actually reducing the space available to the data. The 5% snapshot reserve is too small to hold all the snapshots, however, neither the volume nor the snapshot reserve size will change.
Therefore your 868.6% refers to the snapshots consuming more than 8x the space allocated in the snapshot reserve. The SnapVaults will not fail until there is no more space left in the volume. If you were to increase the snapshot reserve to c.60% you should get back to a managable figure. However, this will mean that the data now only has 40% of the volume size available, you may need to resize the volume to account for growth/retention etc.
Regarding the many snapshots you have in the volume, this is most likely to be due to the retention you have set on the SnapVault relaitonship, e.g. to hold 30 days of nightly backups you will have 30 snapshots - one for each night, allowing you to recover to any night over the last 30 days. Once the 30 days have elapsed, during the next SnapVault update the oldest snapshot will expire and so keeping the 30 days retention.This is seperate from the volume scheduled snapshots that you have disabled.
Finally, the backup data as at the last SnapVault update will be in held the volume (as read only) with only the SnapVault snapshots in the .snapshot folder available for point in time restores.
thx a lot. Can you explain this part to me please:
As this folder is only used for Backup Data coming from Catalogic DPX i think it is not nessesary to also snapshot them. Backup Data should be in Filesystem /vol/vol_block_bu_exchange instead of Filesystem /vol/vol_block_bu_exchange/.snapshot.
Sorry but not sure I can be of anymore assistance. I am not familiar with yourenvironment and howDPXis utilising the snapshots, therefore I'm afraid I cannot comment whether you need to snapshot the backup data. There must have been a reason whySnapVaultwas chosen for the method of backup, are the original design documents of no use? IsDPXcataloguing only the primary snapshots to facilitate your point-in-time restores? Is the retention on you primary datasufficient for your requirements?
To clarify how SnapVault works...a copy of the data is held in the volume\qtree. This data represents the state of the source data as at the last SnapVault update. All snapshots are held in .snapshot and only the changed blocks since the previous update are stored in this area. The only backup data being held in .snapshot are previous versions of the data necessary for your recovery requirements - assuming DPX is configured to use them.