Older backups not being deleted

[daystrom]

Case #04266849

I got a warning today: Backup location [E:\VeeamBackup\] is getting low on free disk space (316.3 GB free of 3.6 TB)
The backup target has files starting June 6, a month ago. This disk has been in place since June 6, so all of the backup files are still on disk.

But settings for this job are to keep backups for 9 days (excluding days with no backups). In addition, it creates a active full backup every Saturday

How do I end up with a full month of backups on here?

The volume restore dialog shows that restores are available only from June 24, 11 days ago. That seems to match the 9 day retention - because 9 days ago is the second of two incrementals after the full on June 24. I would expect that tomorrow it should delete the June 24, 25, 26 backups from the restore list, which is ok, but I also want the files on disk to be removed. Anyone know what the issue might be?

[daystrom]

Would sure appreciate some input on this, either via the ticket or here on the forum.

[Egor Yakovlev]

Greetings!

Having a quick glance in your submitted logs, it is hard to determine the root reason on the fly(let's wait for support to land a word), however I have few notes:
- version of agent you currently have is 3.0.2.170, so it is worth giving a shot for update to latest(v4) and run the backup again. I see last update was on 6\10\2019, so the issue most likely not related to the build of an agent, however it is a good idea to stay current.
- Detailed session logs only show job statuses from 6\28 to 7\5 - which, according to created restore points in the logs, gives us just 9 restore points so far. Hard to dig into earlier statuses without earlier data. Was job re-created(deleted, created new) on 6\27 by chance?
- I see Full backup on 6\27, then daily incremental to 7\3 as expected. On 7\4 another Full(Saturday scheduled one, expected) and 7\5 incremental. That makes us 9. So daily status for "cleanup task" is "[Transform] Transformation is not needed." which reads it "No retention will be applied" is 100% expected. Would be cool if you can upload entire C:\ProgramData\Veeam\Endpoint folder(.zip) with more recent logs for that job to the case(cp.veeam.com).

Not much, but hope that might help!
/Cheers!

[nielsengelen]

Keep in mind that for the incrementals to still work, we need the full backup file which is related to it. If you use the restore point simulator, you can do some testing and see how much disk space you require based on your needs (for example 1TB of disk with 9 restore points and active full weekly).

It may be interesting to change your backup target to a ReFS disk with synthetic full as it requires less space.

For the deletions, not happening (unless it is like described and they only get deleted once the first full is gone) - support should be able to clarify it what is exactly going on/wrong.

[daystrom]

Thanks to both of you for your replies. I didn't realize I'm a full version behind, so I'll upgrade both of my pcs to 4.x. Maybe that will solve this issue with backup file retention.

The job wasn't deleted and recreated on 6/27.

To nielsengelen, I am using the free version and I don't think synthentic full is available to me. Thanks for pointing me to that website that emulates backup patterns - very interesting!

[daystrom]

I updated to 4.x, and ran a backup. It performed an incremental, but didn't remove any older files. Earlier this week I had to manually remove older backup files from the target, it was out of space, so now I have backup files from June 20. But that's still way over the "keep for 9 days". Hopefully veeam support will comment at some point.

[Egor Yakovlev]

Manually removing files in the storage could lead to various chain corruptions, because Veeam would expect files to be there but cannot find them for service operations.
Can you please update the case with a fresh zip export from C:\ProgramData\Veeam\Endpoint?
/Thanks!

[daystrom]

I have uploaded endpoint.zip to a new case 04280475. The original case was closed automatically after x days.

I had understood that it was ok to manually remove older backup files (a full backup and it's related incr) but if that's not so, good to know. Because the older files are not being removed at this point, I have to create space manually. Would it be a worthwhile experiment to start the backup over from scratch? If so how would I do that? BTW, I both of my pcs that backup with agent have the same issue.

[Egor Yakovlev]

Thanks!

I have checked the logs - and it surely does seem like a corruption in meta. If you are ok to start a new chain, you can just delete existing backup job(not backup files) and create a new one with a different name - that will make sure no folders will overlap as each backup job generates it's own subfolder on the backup repository location. See if new job retention applies and cleanup old backup job folder afterwards.
Btw, if there is no strict business reason to have additional full backup weekly, you can just stick with the default Forever-Forward Incremental chain with 9 points - Full backup will be "refreshed" daily with each daily retention merge anyway.
/Cheers!

[daystrom]

Thank you Egor. I will start over. You said I could keep the backup files but that's elective, correct?

[daystrom]

I meant, they wouldn't be needed for the fresh start, a rather obvious fact.

[Egor Yakovlev]

Yeah, they are not needed for new chain.
We will keep them just in case, to keep existing points intact(say tomorrow you will need to restore from "older" backup)

[daystrom]

Thanks again. I'm almost certain that the issues I've had with agent are due to the atypical manner that I have been using it.

[daystrom]

After deleting the original job and creating a new one from scratch, I find the email notifications still carry the old name of the pc (or the backup job not sure which). It was like this before the new job was created, but I expected it to be corrected in the new job. The name of the pc appears in the Details section of the email, where the column headings are Name, Status, Start time etc. I don't find a control point for this name. Is it editable in the registry, or?

[Egor Yakovlev]

Subject of email is configurable under Settings->Notifications.
Default pattern is "[%JobResult%] %ComputerName% - %JobName% - %CompletionTime%"
Body of email is strict and cannot be altered.
/Cheers!

[daystrom]

Not the subject line. The body of the email, in the second section, Details, the listed name is the name that the pc had a year ago.
It's not important, but it does seems like a bug.

[Egor Yakovlev]

Just wondering, when that PC Rename happened a year ago, was Veeam Agent already installed on the machine?

[daystrom]

Yes it was.

[Egor Yakovlev]

Yes, it is a "by design" behavior.
Will check if we can alter it in future versions.
/Thanks!

[daystrom]

ok, no problem, it was just a detail, minor anomaly.