Hello Veeam Team,
i open also a ticket about this
Case # 07475684 - Question about Backup Offload with SOBR Repository
The topic is the change in the offload policy ONLY for the plugin backup (in my case RMAN plugin) for the offload process.
Before 12.2, as for settings of the Scale Out repository in "copy mode" the backup were offload just after they are created in the performance tier; this is, in my opinion, the righ way of doing that.
Starting from 12.2, don't understand for wich ratio, this beavihour change, beacause the Offload wait 24h before copy the backup file from the performance tier to the capacity tier. In my case we do a REDO log backup every 2 hour that, starting from versione 12.2, must wait 24 hour to be secured in my capcitiy, immutable, external capacity tier.
Also the documentaion is not so clear; first i read "With the Copy policy, Veeam Backup & Replication checks backup files every 1 hour and runs an offload job only if new backup files exist" and then that "with both the Copy and Move policies, Veeam Backup & Replication copies and moves to the capacity tier only non-active backup files created more than 24 hours ago, which match the capacity tier configuration parameters".
-
- Novice
- Posts: 9
- Liked: 1 time
- Joined: Dec 10, 2019 10:46 am
- Contact:
-
- VP, Product Management
- Posts: 7202
- Liked: 1547 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: NewFeature Request: Revert back the SOBR Offload policy for plugin backup
It is a backend change to address some scale-out performance issues and to align on the same standard for all workloads across the product including image level DB processing.
We have plans to shorten this time with each version along side of improvements in the backend to be able to backup thousands of DBs on single server/cluster and to scale this out to thousands of DB servers.
For now you can change this in the following way:
Veeam Backup Server
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: reg_dword
DB2PluginReuseStorageTimeMinutes
SapHanaPluginReuseStorageTimeMinutes
SapOraclePluginReuseStorageTimeMinutes
OracleRMANPluginReuseStorageTimeMinutes
SQLPluginStgWriteMinutes (12.1 and later)
SQLPluginStgWriteHours (v12)
Defined in Minutes
Default is 1440 (24h)
If you have a single server with just some DBs there is likely no issue in going down to 20min to catch the offload window.
If you run 10th of thousands of DB backups with 5min log backup, I would be careful and go gradually down monitoring Veeam DB load and Repository load.
We have plans to shorten this time with each version along side of improvements in the backend to be able to backup thousands of DBs on single server/cluster and to scale this out to thousands of DB servers.
For now you can change this in the following way:
Veeam Backup Server
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: reg_dword
DB2PluginReuseStorageTimeMinutes
SapHanaPluginReuseStorageTimeMinutes
SapOraclePluginReuseStorageTimeMinutes
OracleRMANPluginReuseStorageTimeMinutes
SQLPluginStgWriteMinutes (12.1 and later)
SQLPluginStgWriteHours (v12)
Defined in Minutes
Default is 1440 (24h)
If you have a single server with just some DBs there is likely no issue in going down to 20min to catch the offload window.
If you run 10th of thousands of DB backups with 5min log backup, I would be careful and go gradually down monitoring Veeam DB load and Repository load.
Who is online
Users browsing this forum: No registered users and 2 guests