I would like the ability to split the schedule for backup and restore point retention.
Consider a forever incremental backup chain.
I run a backup.
Then the oldest incremental backup is merged into the full backup file.
Then the job finishes.
Then my offsite replication job can begin.
Because my offsite replication job uses WAN bandwidth, I'd like it to begin sooner so it can end sooner, to minimize running into the next day's business hours.
This would be more ideal for me:
I run a backup.
The offsite replication job runs.
Later at a separate scheduled time, the oldest incremental backup file is merged into the full backup file.
Additional considerations:
1) After hours is when backups and replications are preferred to run because both backups and replications use production resources (SAN/WAN).
2) Merging the backup files uses backup-only resources (because our backup storage is separate from our "regular" production storage), other than minimal CPU/RAM resources. Thus, the merge process can run during normal business hours without impacting our business.
As a small business, we don't have the luxury of:
A) having enough storage space for synthetic/active fulls (which probably wouldn't help this issue much if any anyway).
B) having enough money for more WAN bandwidth.
C) having "faster" storage that can handle high random read/write IO (the merging process).
-
averylarry
- Veteran
- Posts: 273
- Liked: 31 times
- Joined: Mar 22, 2011 7:43 pm
- Full Name: Ted
- Contact:
-
Mildur
- Product Manager
- Posts: 11835
- Liked: 3348 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: [ENHANCEMENT REQUEST] split schedule for backup and retention
Hi Ted,
To be honest, I do not see us separating the backup session from merging the incremental backup into the full backup.
What repository type are you using? Maybe local disks in your backup server?
On repositories that support Fast Clone, the required storage space is essentially the same as with your current forever forward incremental backup chain. In that case, you can enable weekly synthetic full backups. There will be no incremental-into-full merge at the end of the backup session, and the synthetic full backups will be space-less. And with Hardened Repositories, you can even enable immutable backups.
Best,
Fabian
To be honest, I do not see us separating the backup session from merging the incremental backup into the full backup.
What repository type are you using? Maybe local disks in your backup server?
On repositories that support Fast Clone, the required storage space is essentially the same as with your current forever forward incremental backup chain. In that case, you can enable weekly synthetic full backups. There will be no incremental-into-full merge at the end of the backup session, and the synthetic full backups will be space-less. And with Hardened Repositories, you can even enable immutable backups.
Best,
Fabian
Product Management Analyst @ Veeam Software
Who is online
Users browsing this forum: DBMandrake and 1036 guests