New bckp cpy job option full only,what to do with vib files

[tntteam]

Hi there,

I was wondering what to do with the remaining vib files that don't seem to be deleted with GFS retention ?

I upgraded from v8 to v9 and activated the new option "copy only full", but there is remaining vib files from v8.
What you guys think? Did you do the same ? vib files got removed ?

Here is some pictures to make this post fancy

[veremin]

These points are the ones created by simple retention policy and they seem to be in-line with the specified value - 2. In other words, there is nothing for a backup copy job to delete.



Thanks.

[tntteam]

Sorry I don't get it ?
2 is the minimum right ?

There is already 2 more recent restore points than these no ?

Anyway, do you plan to allow us to manually remove restore points of our choice with no side effects ? That would be awesome

[foggy]

There's only one VIB file (increment) on the screenshot, which, with its corresponding VBK (full), comprises regular backup copy chain (simple retention). All other files are GFS fulls.

You can safely remove any GFS restore points, however removing increments is not recommended, since having the entire chain is essential for restore.

[alanbolte]

The existence of the VIB file is normal, but the VIB file hasn't been updated in over a month, and he's got two 'R' points.

What is your copy interval set to?

[tntteam]

Hi,

Copy interval is 7 days and allowed transfert window is tuesday from 08:00 to 22:59.

What are R points btw ?

The vib hasn't updated since I checked copy only full points new feature.

What's making me unsure about all this is all points have retention policy (letter, Week or Month) but not the last vbk and vib that were the last backup copies before veeam upgrade and copy only full option activated.

[foggy]

'R' stands for 'Regular', meaning the simple retention chain. Your settings explain why they are not updated. They'd be deleted according to retention once the new regular chain reaches the specified number of restore points (2), however this will not occur, since every time the new full is generated. You can delete the 01/03 full and VIB manually.

[tntteam]

Yay thanks !

Just delete the regular files and rescan repo will do it ?

[foggy]

Should do, however, don't touch the most recent regular full (the one from 14/03).

[tntteam]

Looks like I was, as always, not patient enough.

12/04/2016 10:23:33 :: Starting GFS retention policy processing cycle
12/04/2016 10:23:45 :: Deleting incremental backup 08/03/2016 08:15:00 per retention policy
12/04/2016 10:36:54 :: Deleting full backup 01/03/2016 08:15:00 per retention policy

I'll wait for other copy jobs to clean things too

Thanks for your help all

[foggy]

Looks like the new VIB file was created during this job cycle, do you see it in the backup repository?

[tntteam]

No vib files, only vbk with retentions :

[foggy]

Ok, seems the current behavior is caused by the fact that you switched to using active fulls while at the same time you had a simple retention chain in place. There're some issues with how retention works for the remaining part of the forever forward chain, they are scheduled to be fixed in the next update. In your particular case, the fulls marked with "R" will most likely stay forever in the repository, so to reclaim space, you can rename them temporarily, rescan the repository, and remove them from UI. If the job will continue to work fine, remove the files completely.