[Help] - Improve scenario and avoid busy jobs

[sistema]

[sorry for my bad english]

Here the scenario:

300 VM.

20 JOB on local disk with 30 restore-point
All JOB are forward incremental


JOB on Tape:

2 GFS job for a Disaster Recovery to eject and keep offsite (weekly and Monthly)

10 GSF JOB for long-retention on tape

Some JOB are very big:
for example: Oracle = 38TB and FileServer = 12 TB

Often the JOBs are concurrent in particular the tape job are too long and freeze the incremental jobs

This is an example:

Code: Select all

LOG Tape_4Trimestrale_5Annuale_ORACLE
Building source backup files list started at 4/16/2019 6:38:21 PM             
2 synthetic full backups will be placed into the quarterly media set          00:00
Source backup files detected. VBK map: 2            
Queued for processing at 4/16/2019 6:38:23 PM             
Required backup infrastructure resources have been assigned   
Using tape library FUJITSU ETERNUS LT S2 4.91 14:30:33
Drive 2 (Server: VEEAMSRV, Library: FUJITSU ETERNUS LT S2 4.91, Drive ID: Tape3) locked successfully 
Current tape is AIO615L7             
New tape backup session started, encryption: disabled 01:35
Backup to media set quarterly started at 4/16/2019 6:38:21 PM               
Creating full backup map for oracle11.vm-56269_BA18D2019-04-07T050030.vib             20:45
Processing oracle11.vm-56269_BA18D2019-04-07T050030.vbk                17:38:06
Tape AIO615L7 is full     
Unloading tape AIO615L7 from Drive 2 (Server: VEEAMSRV, Library: FUJITSU ETERNUS LT S2 4.91, Drive ID: Tape3) to Slot 7    02:21
Unloading tape Z0007WL7 from Drive 3 (Server: VEEAMSRV, Library: FUJITSU ETERNUS LT S2 4.91, Drive ID: Tape0) to Slot 47 00:45
Loading tape Z0007WL7 from Slot 47 to Drive 2 (Server: VEEAMSRV, Library: FUJITSU ETERNUS LT S2 4.91, Drive ID: Tape3) 00:39
Current tape is Z0007WL7           
Continuing backup session for Full backup set 4/16/2019 6:41:07 PM     
Continuing task for oracle11.vm-56269_BA18D2019-04-07T050030_2f71c446-0103-44fa-b5bb-4a5e840bc89a.vsb                 03:43:26
Changes in source backup files detected, rescan required            
0 folders and 1 files have been backed up            
No backup files found    
Source job retry is required. Waiting...   00:07


LOG Oracle(INCREMENTAL)
Job started at 4/17/2019 5:00:14 AM     
Building list of machines to process         00:04
VM size: 10.3 TB              
Changed block tracking is enabled           
Processing Orcl92            01:50
Processing oracle11        01:28:39
All VMs have been queued for processing           00:00
Merging oldest incremental backup into full backup file (99% done)        06:24:41
Waiting for required backup files to be released by another job: Tape_4Trimestrale_5Annuale_ORACLE                 06:13:13

If we have correctly understand, a lot of time is used by the tape jobs to recreate the full backup (14 hours??)
During this operation the files of the daily job are obviously busy and in fact the daily tells us: Waiting for backup files to be released by another job: Tape_4Trimestrale_5Annual_ORACLE

We would like to optimize the situation in terms of time and methods of execution, so we thought we were making the following changes:

- Switch to reverse incremental in order to avoid the reconstruction time of the full house to send it to tape (we have no time problems in the backup)
- Activate Parallel processing on tape (if it doesn't risk consuming too many tapes unnecessarily)

Do you think these changes can improve the situation?


Thank you

[Dima P.]

Hello sistema,

May I ask what type of backup repository are you using?

- Switch to reverse incremental in order to avoid the reconstruction time of the full house to send it to tape (we have no time problems in the backup)

Synthesized full backup is indeed slower but I'd recommend you to test parallel processing on the first place (as you can enable parallel processing of backup chains within a single job). Cheers!