I have set Snapshot Management to "Smart", Schedule "Daily" for most of my shares.
I have not changed shares settings in years.
Today I noticed snapshot count has dropped to "3 (2 day(s) protection)" for each share. Why is this? I would have expected lots of monthly snapshots, plus weekly and daily ones.
Volume Size
data 2.38 TB
Snapshots: 199.08
Free: 2.88 TB
There is not much traffic on this device. Maximum utilization was 46 % during 1 year.
Firmware: 6.10.1, Device uptime 140 days.
There are no signifcant errors or warnings in logs.
Best regards, frantic
Model: RN31200|ReadyNAS 300 Series 2- Bay (Diskless)
I have set Snapshot Management to "Smart", Schedule "Daily" for most of my shares.
I have not changed shares settings in years.
Today I noticed snapshot count has dropped to "3 (2 day(s) protection)" for each share. Why is this? I would have expected lots of monthly snapshots, plus weekly and daily ones.
It's impossible to know exactly what happened without looking at the full log zip file. So perhaps download the zip now (hopefully before details are lost). You can send one of the mods ( @JohnCM_S or @Marc_V ) a private message (PM) with a downloadable link to the logs (google drive, dropbox, etc), and ask them to analyze them. Don't post the logs publicly. A PM is sent using the envelope icon on the upper right of the forum page.
One problem with the "smart" snapshots is that the monthly ones are never deleted. Eventually they will fill up the volume, and when that happens the system will delete snapshots in order to protect the file system integrity (very bad things can happen if you run out of space). So that is the most likely explanation (even though you didn't notice the volume getting full). The mods should be able to sort that out if the details are still in the log zip file.
Personally I use the custom snapshots, and check the box to only make them when something changes in the share. That gives you explicit control over the retention - letting you better manage the total snapshot space. I use 3 month retention on most shares.
Note that snapshots aren't backups - they just give you some ability to roll back to older versions of files or folders. Only differences between the main folder and the snapshot(s) are stored on the disk.
On the System/Volumes tab in the GUI, use the gear icon for the volume the share resides in to select Settings, then Snapshot Pruning. You will likely see that you exceeded the threshold set for pruning, so the deletion @StephenB described took place. You can increase that, but anything above 90% can lead to problems with the file system.
If you use RSYNC backup and have the "delete files removed on source" option selected, you may not think you exceeded the limit when you actually did. It could happen when rsync is copying a large file and has a temporary updated one and the original both present until the copy is complete and the temporary replaces the orignal.
Snapshot Pruning is set (and has always been) to 90 %.
I started to browse downloaded logs from yesterday and form 2 years old.
status.log looks interesting. In 2017, there were a few warnings regarding free space below 30%, 20%, ... and this:
[17/01/06 01:03:36 CET] info:snapshot:LOGMSG_SNAPSHOT_MONITOR_INFO Snapshot 2016_12_30__00_00_03 was successfully deleted from share or LUN *** due to low free space on the volume. [17/01/06 01:03:36 CET] warning:snapshot:LOGMSG_C_SNAPSHOT_WARN Continuous protection snapshot count dropped to 60 in volume data. [17/01/06 01:04:41 CET] info:snapshot:LOGMSG_SNAPSHOT_MONITOR_INFO Snapshot 2016_12_30__00_00_03 was successfully deleted from share or LUN *** due to low free space on the volume.
Later in 2017 the volume has been increased online from 3 TB to 6 TB.
I have a suspicion: maybe the pruner didn't notice. Of course, that's complete speculation. I do not know the mechanisms, I have no idea where the pruner takes the limit from.
I have created a new share with hourly snapshots for testing purposes. Let's see what happens.
In my other message, I told you where in the GUI the pruner gets the limit, which you also can change. It's actualy stored in /data/._share/.snapshot_prune (assuming your volume is "data"), and it contains the minimum percentage of free space before pruning is triggered rather than the allowed max space shown in the GUI (so, 100 minus the allowed space percentage). Since it's a percentage,it's hard to see how a change in volume size would cause it to delete snapshots too soon because it didn't recognize a new size limit.
If I remember correctly, the value displayed by the GUI at some earlier point in development was also the allowed minimum amount remaining, so the same as the value in the file. I guess Netgear found that to be too confusing and changed it in the GUI but not in the configuration file and whatever does the work.
In my other message, I told you where in the GUI the pruner gets the limit, which you also can change. It's actualy stored in /data/._share/.snapshot_prune (assuming your volume is "data"),
In the GUI, the setting is 90 %. There is a 10 in the file. The files last change date is 2017-10-02. On this device, there were only minor fluctuations in the amount of storage space used during this year. Utilization raised from 42 % to 46 %, according to the GUI graph in System / Performance / Utilization. With my old hard drives (half the size), these values would have been near the limit of 90 % usage. Hence my suspicion, what might have gone wrong in the software.
However, I added another share. Since that, the pruner seems to be behaving normally again. I will keep an eye on that.
