I’m not exactly sure why this is happening but a DS1821+ running the latest DSM version will sometimes fail to execute the retention policy at the specified time in Active Backup for Business unless I initiate a system restart. I’m looking at NTP synchronization with my domain controller (Active Directory on Windows Server 2016) as a possible issue but haven’t confirmed the root cause just yet.
My volume size balloons quickly if the retention policy execution is missed in 2 or 3 days so I need to figure this out eventually. Any ideas or suggestions would be appreciated.
Hi,
how do you notice the retention policy fail to execute ?
Thanks
Ben
Hi Ben. I go to Active Backup for Business–Activities–Log and look for entries showing “version deletion task” at the time set in the retention policy execution in the Setting section. If there are no logs showing older versions being deleted as expected, there’s a problem.
Of course, if your retention polices are such that no versions are eligible for deletion, you won’t find anything in the log entries.
Be the way, I had to restart my domain controller yesterday for other reason but still could not get NTP synch so there’s clearly a problem… I just don’t know if that’s preventing the Execution Policy from starting.
Hi,
I left the default Advance Retention policy and from the log, I could tell that after the first 10 backup (one per day), ABB start to delete one backup every day at midnight, and the backup is programmed at 3am.
But it skip a delete every 7 days, but simetimes every 4 days. I have only 6 weeks of data with some extra manual backup so it is difficulte to extract the exact pattern.
So it seems to follow a certain retention policy but without a lot of data, it is hard to conclude if it is exact.
You could export the log from the Task Summary TAB in a csv file and it become easyer to analyse.
Regards
Ben
Update: Retention Policy Execution continues to fail and I’m completely stumped. NTP is successfully synching with the domain controller and all other timed tasks (Hyperbackup, Snapshots, Replication, etc.) are executing perfectly as scheduled. The only successful work-around I’ve found is manually stopping the AB4B package and restarting it. Being desperate, I may have to open a Synology trouble ticket… more to follow.
Update: Retention policy continues to fail to execute without stopping AB4B package and restarting daily. DSM and AB4B updates from 2 days ago did not solve the problem so I finally opened a support ticket yesterday. I had a pleasant message exchange with an analyst and granted her SSH authorization today to access the Synology. She indicated it was very strange and nothing they’ve ever heard in the past. Stay tuned for future updates.
Update: After opening a ticket with Synology, I’m somewhat underwhelmed. They are not exactly speedy but I know they probably have a huge caseload. Howerver, it’s clear they are not fully reading (or comprehending) my message exchanges. I think the support analyst is in Taiwan so maybe there’s a language translation issue but she was borderline rude in her latest communication to me. I’ll continue to keep everyone updated.
Final update- the problem seems cured. However, Synology support claims they did nothing other than scour the activity logs looking for clues. Therefore, they consider it a fluke that somehow fixed itself. I won’t be surprised if this issue occurs again.
Candidly, the support team did not impress me. In a couple of exchanges, I thought they were inventing explanations for specific observations I pointed out. In other cases, I felt as if I was educating them on the behavior of ABfB processes. I’m far from being a Synology prima donna but won’t leverage them again unless I have no other option.