Retention¶
Retention defines how long copies created by a Backup Copy Job are stored in the target Cloud4You Cloud Repository.
The Backup Copy Job retention policy is independent of the retention of the primary backup job. This means that a local backup can have a different retention period than the copy stored in the Cloud Repository.
Example:
Info
Retention should be selected according to the required data retention period and the allocated Cloud Repository capacity.
Types of retention¶
For Backup Copy Jobs, Veeam Backup & Replication provides two basic mechanisms:
- Short-Term Retention — short-term retention of current restore points,
- GFS Retention — long-term retention of selected full backups.
Veeam also has a separate data retention policy for machines removed from the infrastructure or excluded from a job.
Short-Term Retention¶
Short-Term Retention defines how many days Veeam should keep restore points created by a Backup Copy Job.
The setting is available in the Backup Copy Job wizard under:
Example:
means that Veeam will retain restore points created within the period defined by the retention policy.
The minimum value for Backup Copy Job short-term retention is:
Veeam Backup & Replication 13
In the current Veeam Backup & Replication 13, Backup Copy Job retention is configured as a period in days.
How are old restore points removed?¶
During the first Backup Copy Job session, Veeam creates a full restore point.
Subsequent sessions create incremental restore points:
When the oldest restore point exceeds the configured retention period, Veeam automatically processes the backup chain.
In a standard Backup Copy Job chain, the oldest restore point is merged into the full backup and then removed from the chain.
Do not manually delete backup files from the repository.
Warning
Files stored in the Cloud Repository should be managed only by Veeam Backup & Replication mechanisms.
Retention is calculated independently of the source¶
A Backup Copy Job has its own retention policy.
For example, you can configure:
or the other way around:
Changing the retention of the local backup job does not automatically change the Backup Copy Job retention.
GFS Retention¶
If selected copies need to be stored for a longer period, you can use:
GFS allows full backups to be retained in:
- Weekly cycles,
- Monthly cycles,
- Yearly cycles.
Example:
This allows current restore points to be kept for a relatively short period while selected full backups are retained for months or years.
Enabling GFS¶
When editing a Backup Copy Job, go to:
and select:
Then click:
In the GFS configuration window, you can enable selected cycles.
Weekly¶
The:
option defines how many weeks weekly full backups should be retained.
Example:
means weekly GFS copies are retained for 4 weeks.
You can also specify the day of the week used to select the backup marked as the weekly GFS point.
Monthly¶
The:
option allows selected full backups to be retained for a specified number of months.
Example:
means monthly copies are retained for 12 months.
Yearly¶
The:
option allows yearly full backups to be retained for a specified number of years.
Example:
means yearly GFS copies are retained for 5 years.
Example retention variants¶
The values below are examples and should be adjusted to the organization's requirements.
Basic variant¶
A good solution for environments that primarily require a current off-site copy.
Extended variant¶
This retains both current history and monthly archival points.
Long-term variant¶
Suitable for environments that require selected copies to be retained for a long period.
Note
Enabling GFS may significantly increase Cloud Repository usage. Copies marked as GFS are not removed by the short-term retention policy until their corresponding GFS period expires.
GFS and the number of restore points¶
After GFS is enabled, the number of restore points stored in the repository may be higher than the short-term retention setting alone would suggest.
Example:
This does not mean that the repository will always contain only 14 restore points.
Backups marked as GFS are protected from short-term retention removal until their GFS retention period ends.
Synthetic Full and Active Full for GFS¶
When creating GFS full backups, Veeam can use two mechanisms.
Synthetic Full¶
This is the default method.
Veeam creates the GFS full backup using data already stored in the target repository.
This reduces the amount of data that must be transferred again from the source.
Active Full¶
When you select:
Veeam reads the complete restore point from the source repository and transfers it to the target repository.
This may increase:
- network transfer,
- job duration,
- load on the source repository.
In a typical Cloud Repository scenario, keeping the default Synthetic Full mechanism reduces the need to transfer the entire dataset again over the Internet.
Deleted machine retention¶
A Backup Copy Job also has a separate policy for machines that:
- have been removed from the infrastructure,
- have been excluded from the Backup Copy Job,
- are no longer protected by the source job.
You can find the setting in the advanced Backup Copy Job options:
The:
option determines after how many days Veeam may remove data for such machines from the regular backup chain.
The default value for a Backup Copy Job is:
Veeam recommends configuring at least:
to reduce the risk of accidental data removal when a machine was temporarily not processed correctly.
Warning
Do not configure a very short deleted-items retention period without careful analysis. Veeam may consider a machine deleted if it has not been able to create a valid restore point for it for a certain period.
Data protected by active GFS retention follows separate rules and is not removed by deleted-items retention in the same way as regular restore points.
Retention and Cloud Repository capacity¶
Longer retention means higher consumption of allocated storage.
Capacity requirements are affected by:
- amount of protected data,
- daily data change,
- backup frequency,
- Short-Term Retention period,
- number of GFS copies,
- compression,
- deduplication,
- structure of the protected data.
Example:
Do not assume that the required capacity will be equal only to the size of the source data.
You can use the:
to estimate the required space.
What happens when the repository becomes full?¶
If the Cloud Repository does not have sufficient free space, subsequent backup operations may fail.
We therefore recommend regularly monitoring:
and the use of the allocated quota.
If usage approaches the limit, possible solutions include:
- increasing Cloud Repository capacity,
- shortening retention,
- reducing the number of GFS copies,
- removing unnecessary backups using Veeam mechanisms,
- reviewing the amount of protected data.
Danger
Do not manually delete backup files directly from the repository. This may cause inconsistencies in the configuration and backup chain.
Which retention policy should I choose?¶
There is no single correct policy for every environment.
When selecting retention, consider:
- required RPO and RTO,
- risk of late ransomware detection,
- legal requirements,
- contractual requirements,
- time required to detect an incorrect or deleted file,
- available budget,
- allocated Cloud Repository capacity.
For business-critical data, consider combining:
with regular restore tests.
Example¶
A company performs a local backup every day.
It wants:
- one month of current history in Cloud4You,
- four weekly archival copies,
- twelve monthly copies,
- five yearly copies.
Configuration:
Backup Copy Job
Short-Term Retention:
30 days
GFS:
Weekly:
4 weeks
Monthly:
12 months
Yearly:
5 years
In this case, the Cloud Repository quota must be sized appropriately because GFS copies may be retained much longer than standard restore points.
Best practices¶
- do not select retention only according to available space,
- account for the possibility of late detection of data loss or encryption,
- consider GFS for important data,
- monitor quota usage,
- after changing retention, monitor how used space increases or decreases,
- do not manually delete backups outside Veeam,
- perform restore tests regularly.
Important
Long retention does not replace restore testing. A backup has value only if data can be successfully restored from it.
Summary¶
Key information:
| Mechanism | Purpose |
|---|---|
| Short-Term Retention | current restore points |
| Weekly GFS | weekly full copies |
| Monthly GFS | monthly full copies |
| Yearly GFS | yearly full copies |
| Deleted Items Retention | data from machines removed or excluded from the job |
A typical configuration may look like:
Each retention policy should be tailored to the organization's requirements and the capacity of the purchased service.