Retention policy: Rotated discs

[adlois]

Hi,

Support case ID: 03336155.

The policy for holding rotating discs is not applied correctly.

There is an advanced option checkbox in the repositories "This repository is backed by hard drives rotated". Maintain a coherence between the clubs. But regret this does not seem to be the right one.

• What would happen in case of holidays?
  Forget about rotating the discs for a day?

Thanks,

[Dima P.]

Hello and welcome to Veeam community!

Here is a good KB article which explains How to configure Veeam for rotated media, worth checking.

advanced option checkbox in the repositories "This repository is backed by hard drives rotated"

This option is required to instruct backup job that underneath the backup repository rotated drives are used. In such case specific logic is used to make sure that the backup chain created on these drives is not broken.

What would happen in case of holidays? Forget about rotating the discs for a day?

Device should be accessible by the time backup job starts and if it's not - backup job will be completed with error as there is no target available.

[veremin]

I cannot currently check the case, so do you mind answering a few questions:

- What type of job are you using? Backup or backup copy one?
- What backup mode are those jobs using? Forward incremental with periodic full, Forward Forever incremental, Reverse incremental, Synthetic Full GFS or Active Full GFS, etc.?
- And what retention period is specified?
- And type of repository are you using?

Retention policy for backups stored on rotated media works differently for different types of jobs, different backup modes and different repository types. Thus, the questions.

Thanks!

[adlois]

Hi @v.Eremin,

It consists of 2 jobs included as backup tasks (no backup copy).

- The first job makes a copy on a NAS incrementally with a full copy a week.

- The second work is a complete daily copy from Monday to Friday (without weekends) for each rotating disk, to carry out the order of the days of the week for each disk, for which it is the chain of the retention is broken without knowing by What. And in the case of forgetting to change a nightclub one day to another person treated for holidays then the sequence of the retention becomes a Mamluk and a correct vacuum of the disc is not made, leaving no space and in the task failing the copy work of security.

I have already tried to apply the comments in this knowledge base https://www.veeam.com/kb1154. Successless, it once forced the removal of the content of the repository only, but at other times it was ignored... it is not 100% reliable.

Thanks,

[veremin]

Is the repository added as a shared folder? If so, then, the described behaviour is expected (kindly, see the referenced document, specifically Linux and Shared Folder Backup Repository section). Thanks!

[adlois]

If it is the expected compartment, then there are no more possibilities and different possible uses, as in this case, for the clients that use Veeam as software for backups of the virtualized infrastructures.

With respect to Linux and Shared Folder Backup Repository

As soon as Veeam Backup & Replication starts a new backup chain on the drive, it removes information about restore points from previous backup chains from the configuration database. Backup files corresponding to these previous restore points are not deleted, they remain on disk. This happens because Veeam Backup & Replication applies the retention policy only to the current backup chain, not to previous backup chains.

According to this, one can not contemplate a human error of forgetting the rotation of disks, or holidays in between. I insist again with this, I think it is a subject to see and better in Veeam, it is possible that there are more people with this problem and not report it enough.

Thanks,

[foggy]

Not sure what behavior do you expect in this case. If the disk hasn't been changed, the backup chain on it is consistent and Veeam B&R just adds a new restore point to the existing chain.