Orphaned file on repository

[ejenner]

Hi guys,

What is the correct way to establish whether or not a file on a repository is required for backup?

I've got a file I suspect has become detached from backup and not sure if it is safe to delete it.

These are the checks I've made, but I wondered what the official correct way is to solve this:

1. Checked the date, it is 04/03/2020 (UK date format DD/MM/YYYY) but the retention is 35 days (daily backups)
2. Another .VBK full file exists but it is from a few days ago 26/05/2020
3. If you attempt a restore it shows one full file and all the other increments to support 35 days of retention
4. When you check files on disk through the Veeam B&R console using 'properties' for the backup on disk the rogue .VBK file isn't listed

I'm worried about deleting the file in case there is some ongoing operation that requires it.

The repository has filled up, which is what caught my attention and caused me to look for possible files to delete. Could it have failed to continue to process due to full repository and left a merge job half completed causing a large .VBK to remain on the disk?

[Shestakov]

Hi EJ,
What setting of full backups do you have set?
If the suspicious VBK has ~30 dependent increments, no wonder the VBK is still there as retention of the latest VIBs is not over yet.
Thanks

[ejenner]

Where would I get that information for you? Are you talking about forward / reverse incremental? It's a Windows Agent job so I don't think I can configure that.

[Shestakov]

You can check it in the policy/job settings.
You cannot set reverse incremental backup method in agent jobs, however active and synthetic full backups are supported.

[ejenner]

So does a 'synthetic full' reforumlate the files on the repository and potentially leave an old file behind? Maybe if the process was interrupted perhaps?

[Shestakov]

Synthetic full creates full backup from increments and leaves the oldest chain to remain until it's removed in accordance with the retention policy.
If you share your settings I can tell better, but for now my guess is the older chain is not removed as not all increments are outdated yet.

[ejenner]

Here are the screenshots of the settings:












Here are the files on the repository. It has split the files across two SOBR extents:

Folder 1:




Folder 2:




It looks to me like the 16TB file is unnecessary. Is there any chance it is still being used? That's what I'm trying to work out.

[Shestakov]

Thanks for the details.
Do you have any restore points between March, 4th and April, 29th?
If no, you have 35 restore points (1 full + 34 increments) in the chain from the mentioned 16 TB full backup and June, 1st. And new chain starting from .vbk (full backup) made on June 1st 18:15.
The 16 TB full backup will be automatically removed when you have 35 restore points in the new chain, i.e. in the beginning of July in a case you backup once a day.
If you remove the file, you will not be able to restore from any backup of the first backup chain.

[ejenner]

Maybe... bear in mind this screenshot taken today is a day or two later than the screenshots above so 29th of April could be the same as 30th April today?

[Shestakov]

If full backup used to be 29th April and now 30th, your chain is used forever forward incremental method. And 42 TB file from June, 1st is from another chain.
Thus, the 16 TB is used in the active backup chain and cannot be removed.
Does it answer your question?
Thanks

[ejenner]

Hmm... only issue with that is the disparity in full-backup file sizes. During that time the size of the data will be relatively static, not much change. So it does not make sense for an older restore to be 16TB and 30~days later it is 42TB.

[Shestakov]

Are you sure these 16TB and 42TB backup files were created by the same job?
Based on your posts 42TB file could be created by another job.

[ejenner]

The source volume is a 40TB volume. It's all video files so already compressed.

[ejenner]

This file is still on the disk with the same size and date.

Additionally, I've checked the backup properties in the 'Disk' area where the backup files are listed and that file is NOT shown in the list of files for that backup.

I wish there was an official way of checking for orphan files as some of them can be quite large. I'd really like to delete this file but I don't know if it has to be retained for the backup to function.

I can think of ways around this issue like testing restorations with the file renamed (and so missing from the repository) but that hasn't been suggested as a solution so I'd be reluctant to try that in case it breaks the backup chain.

[Dima P.]

EJ,

Can you open backup file properties via Home > Backups > Disk node? It should list all the restore points from the backup chain. Cheers!

[ejenner]

yes, if you open that location the file isn't shown there.

[Dima P.]

Then it's safe to delete it. I usually suggest to rename or move backup and give job a day or two prior deleting it. Cheers!