Virtual Full Backup probably is the most know feature of Oracle Zero Data Loss Recovery Appliance (ZDLRA) and you can check here how it works. In this post I will show how virtual full backup works internally and integrate INDEX_BACKUP task with tables like PLANS, PLAN_DETAILS, CHUNKS, and BLOCKS.
About the internal tables, you can check my previous post “ZDLRA Internals, Tables and Storage” where I explained details about that. To understand the INDEX_BACKUP task, check my post “ZDLRA Internals, INDEX_BACKUP task in details”. But if you know nothing and want to start reading about ZDLRA, you can check my post “Understanding ZDLRA” and check all the features and details.
The base for this article is virtual full backup and incremental forever strategy. I explained both at “ZDLRA, Virtual Full Backup and Incremental Forever” and I included hot it’s work integrated with rman backup. Basically, after an initial backup level 0, you execute just level 1 backups and ZDLRA generated a virtual backup level 0. But here, in this post, I will show you how it works in some internal details.
Database Environment
In this post, I used a new datafile with 1MB (block size of 8k) and I create a small table to load some data. After every load, I took backup for the datafile (level 1). The idea is to show how ZDLRA will index the backups, generate, and store internally the virtual full backup. The database here runs over 19c, and the ZDLRA it is running 19c version too. But, this works the same for every database version supported, and for every ZDLRA version.
Creating the tablespace, checking the datafile, and creating the table:
SQL> create tablespace simon datafile '/u01/app/oracle/oradata/ORCL19/simon01.dbf' size 1m autoextend on next 1m maxsize 10m;
Tablespace created.
SQL>
SQL> select file_id from dba_data_files where tablespace_name = 'SIMON';
FILE_ID
----------
5
SQL>
SQL> create table test(c1 decimal(1,0), c2 varchar2(128)) tablespace simon;
Table created.
SQL> insert into test (c1, c2) values (0, 'SIMON');
1 row created.
SQL> commit;
Commit complete.
SQL>
And after that, doing the initial backup level 0 for the datafile:
RMAN> list backup of datafile 5;
specification does not match any backup in the repository
RMAN> BACKUP INCREMENTAL LEVEL 0 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 5;
Starting backup at 22-09-2019_17:54:27
allocated channel: ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: SID=75 device type=SBT_TAPE
channel ORA_SBT_TAPE_1: RA Library (ZDLRAS1) SID=9327516A92A43E0DE053010310ACCB56
channel ORA_SBT_TAPE_1: starting incremental level 0 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/u01/app/oracle/oradata/ORCL19/simon01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 22-09-2019_17:54:28
channel ORA_SBT_TAPE_1: finished piece 1 at 22-09-2019_17:54:29
piece handle=ORCL19_2aucdsak_1_1 tag=TAG20190922T175427 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
Finished backup at 22-09-2019_17:54:29
Starting Control File and SPFILE Autobackup at 22-09-2019_17:54:29
piece handle=c-310627084-20190922-05 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 22-09-2019_17:54:30
RMAN>
RMAN> list backup of datafile 5;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -------------------
2729 Incr 0 40.00K SBT_TAPE 00:00:02 22-09-2019_17:54:30
BP Key: 2730 Status: AVAILABLE Compressed: YES Tag: TAG20190922T175427
Handle: VB$_1887643964_2728I Media:
List of Datafiles in backup set 2729
File LV Type Ckp SCN Ckp Time Abs Fuz SCN Sparse Name
---- -- ---- ---------- ------------------- ----------- ------ ----
5 0 Incr 2320763 22-09-2019_17:54:28 NO /u01/app/oracle/oradata/ORCL19/simon01.dbf
RMAN>
So, as you can see, the tablespace SIMON was created (datafile #5). After that, the table TEST was created and some data loaded. At the end, the first backup of datafile was done and this was indexed by ZDLRA.
Basic information for database
For this database (database name ORCL19), inside internal tables of ZDLRA, we can see that have the DB_KEY as 2202 and DB_INCKEY as 2203. The DF_KEY for the datafile is 2689. This info is important to identify correctly the backups.
[oracle@zdlras1n1 ~]$ sqlplus rasys/change^Me2
SQL*Plus: Release 19.0.0.0.0 - Production on Sun Sep 22 17:53:21 2019
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Last Successful login time: Sun Sep 22 2019 17:39:03 +02:00
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> set linesize 250
SQL> select db_key, dbinc_key from rc_database where name = 'ORCL19';
DB_KEY DBINC_KEY
---------- ----------
2202 2203
SQL>
SQL> select df_key, file#, ts#, create_scn, create_time, block_size, blocks from df where dbinc_key = 2203 and file# = 5;
DF_KEY FILE# TS# CREATE_SCN CREATE_TI BLOCK_SIZE BLOCKS
---------- ---------- ---------- ---------- --------- ---------- ----------
2689 5 6 2319183 22-SEP-19 8192 128
SQL>
Virtual Full Backup and PLANS
After the backup ingests, and the task INDEX_BACKUP finished at ZDLRA, we have one virtual full backup linked with the datafile. This information came from VBDF and PLANS tables:
SQL> select vb_key, ckp_scn, vcbp_key, srcbp_key, blocks, chunks_used from vbdf where db_key = 2202 and df_key = 2689 order by vb_key asc;
VB_KEY CKP_SCN VCBP_KEY SRCBP_KEY BLOCKS CHUNKS_USED
---------- ---------- ---------- ---------- ---------- -----------
2728 2320763 2730 2701 128 1
SQL>
SQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;
TYPE DB_KEY VB_KEY DF_KEY TASK_ID OLD BLKSREAD MAXRANK NUMCHUNKS READSIZE NEEDCHUNK FREECHUNK
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
8 2202 2728 2689 19 1 1
SQL>
Above we can see that this virtual full backup with VB_KEY have 128 blocks (128 * 8K = 1M) and have one plan for this backup. This virtual full backup/plan has just 19 blocks (BLKSREAD) and used 1 chunk to store it (NUMCHUNKS).
But this not show how ZDLRA see the backup, the virtual full backup store the information at PLAN_DETAILS table. Reading this table we can see the foundation of virtual full backup:
SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;
DF_KEY TYPE VB_KEY BLKRANK BLOCKNO CHUNKNO NUMBLKS COFFSET NUMBYTES
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
2689 8 2728 1 0 1 1 8192 24576
2689 8 2728 1 2 1 17 32788 2167
2689 8 2728 1 4294967295 1 1 34955 294
SQL>
Let’s explain what this means:
- The datafile block 0 (column BLOCKNO) until block 1 (BLOCKNO+NUNBLKS) are stored at chunk 1.
- The datafile block 2 (column BLOCKNO) until block 19 (BLOCKNO+NUNBLKS) are stored at chunk 1
- The datafile block 4294967295 (the last block of datafile) is stored at chunks 1.
To show this I created the schema below. This represents the first 13 blocks of the virtual full backup and will help to visualize the virtual full backup next. So, the virtual full backup with VB_KEY 2728 can be reconstructed following the PLANS_DETAILS as:
Subsequent backups
If we continue to modify data in this tablespace/datafile and execute new incremental backup level 1 we can see more details. So, first, add more data and do a backup:
SQL> BEGIN
2 FOR i IN 1 .. 300 LOOP
3 insert into test (c1, c2) values (2, DBMS_RANDOM.STRING('P', 128));
4
5 if (MOD(i, 100) = 0) then
6 commit;
7 end if;
8
9 END LOOP;
10
11 commit;
12 END;
13 /
PL/SQL procedure successfully completed.
SQL>
RMAN> BACKUP INCREMENTAL LEVEL 1 DEVICE TYPE SBT FILESPERSET 1 DATAFILE 5;
Starting backup at 22-09-2019_18:34:30
using channel ORA_SBT_TAPE_1
channel ORA_SBT_TAPE_1: starting incremental level 1 datafile backup set
channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set
input datafile file number=00005 name=/u01/app/oracle/oradata/ORCL19/simon01.dbf
channel ORA_SBT_TAPE_1: starting piece 1 at 22-09-2019_18:34:31
channel ORA_SBT_TAPE_1: finished piece 1 at 22-09-2019_18:34:32
piece handle=ORCL19_2cucduln_1_1 tag=TAG20190922T183430 comment=API Version 2.0,MMS Version 12.2.0.2
channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01
Finished backup at 22-09-2019_18:34:32
Starting Control File and SPFILE Autobackup at 22-09-2019_18:34:32
piece handle=c-310627084-20190922-06 comment=API Version 2.0,MMS Version 12.2.0.2
Finished Control File and SPFILE Autobackup at 22-09-2019_18:34:36
RMAN>
And now inside of ZDLRA we have two virtual full backups and two plans (for PLANS look the number of blocks read – this is normal since I added more data above):
SQL> select vb_key, ckp_scn, vcbp_key, srcbp_key, blocks, chunks_used from vbdf where db_key = 2202 and df_key = 2689 order by vb_key asc;
VB_KEY CKP_SCN VCBP_KEY SRCBP_KEY BLOCKS CHUNKS_USED
---------- ---------- ---------- ---------- ---------- -----------
2728 2320763 2730 2701 128 1
2768 2322525 2770 2735 128 1
SQL>
SQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;
TYPE DB_KEY VB_KEY DF_KEY TASK_ID OLD BLKSREAD MAXRANK NUMCHUNKS READSIZE NEEDCHUNK FREECHUNK
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
8 2202 2728 2689 19 1 1
1 2202 2768 2689 27 1 2
SQL>
The virtual full backups have these PLAN_DETAILS:
SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;
DF_KEY TYPE VB_KEY BLKRANK BLOCKNO CHUNKNO NUMBLKS COFFSET NUMBYTES
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
2689 8 2728 1 0 1 1 8192 24576
2689 8 2728 1 2 1 17 32788 2167
2689 8 2728 1 4294967295 1 1 34955 294
2689 1 2768 1 0 1025 1 8192 24576
2689 1 2768 1 2 1025 2 32788 252
2689 1 2768 1 4 1 4 33038 408
2689 1 2768 1 8 1025 16 33040 45339
2689 1 2768 1 71 1 3 34703 252
2689 1 2768 1 4294967295 1025 1 78379 293
9 rows selected.
SQL>
Checking in details the last virtual full backup, VB_KEY 2768, we can see interesting things and start to understand how it’s work. So, to “mount” the virtual full backup 2768 we have:
- The datafile block 0 (column BLOCKNO) until block 1 (BLOCKNO+NUNBLKS) are stored at chunk 1025.
- The datafile block 2 (column BLOCKNO) until block 4 (BLOCKNO+NUNBLKS) are stored at chunk 1025.
- The datafile block 4 (column BLOCKNO) until block 8 (BLOCKNO+NUNBLKS) are stored at chunk 1 (and came from previous virtual full backup).
- The datafile block 8 (column BLOCKNO) until block 24 (BLOCKNO+NUNBLKS) are stored at chunk 1025.
So, the virtual full backup with VB_KEY 2768 for DF_KEY can be reconstructed following the PLANS_DETAILS. It is the image below represents the Delta Store and actual virtual full backups:
Look that ZDLRA started to save space to store the backup, being “smart” and indexing all the blocks to needed to create the virtual full backup. But the important here it is that ZDLRA understood and indexed every datafile block that was inside of backup. And the virtual full backup “does not exist”, it is basically the index for each version of the block.
If I continue to insert/delete/update some of the lines from this table I will possibly change blocks (and same blocks already created) and if I do some subsequent backups I have these plans:
SQL> select vb_key, ckp_scn, vcbp_key, srcbp_key, blocks, chunks_used from vbdf where db_key = 2202 and df_key = 2689 order by vb_key asc;
VB_KEY CKP_SCN VCBP_KEY SRCBP_KEY BLOCKS CHUNKS_USED
---------- ---------- ---------- ---------- ---------- -----------
2728 2320763 2730 2701 128 1
2768 2322525 2770 2735 128 1
2818 2323607 2820 2779 128 1
2874 2324062 2876 2829 128 1
2936 2324792 2938 2885 128 1
SQL> select * from plans where db_key = 2202 and df_key = 2689 order by vb_key asc;
TYPE DB_KEY VB_KEY DF_KEY TASK_ID OLD BLKSREAD MAXRANK NUMCHUNKS READSIZE NEEDCHUNK FREECHUNK
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
8 2202 2728 2689 19 1 1
1 2202 2768 2689 27 1 2
1 2202 2818 2689 27 1 3
1 2202 2874 2689 27 1 3
1 2202 2936 2689 27 1 4
SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;
DF_KEY TYPE VB_KEY BLKRANK BLOCKNO CHUNKNO NUMBLKS COFFSET NUMBYTES
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
2689 8 2728 1 0 1 1 8192 24576
2689 8 2728 1 2 1 17 32788 2167
2689 8 2728 1 4294967295 1 1 34955 294
2689 1 2768 1 0 1025 1 8192 24576
2689 1 2768 1 2 1025 2 32788 252
2689 1 2768 1 4 1 4 33038 408
2689 1 2768 1 8 1025 16 33040 45339
2689 1 2768 1 71 1 3 34703 252
2689 1 2768 1 4294967295 1025 1 78379 293
2689 1 2818 1 0 2049 1 8192 24576
2689 1 2818 1 2 1025 2 32788 252
2689 1 2818 1 4 1 4 33038 408
2689 1 2818 1 8 2049 1 32788 257
2689 1 2818 1 9 1025 7 33293 36549
2689 1 2818 1 16 2049 3 33045 17304
2689 1 2818 1 19 1025 1 76821 1026
2689 1 2818 1 20 2049 4 50349 29052
2689 1 2818 1 71 1 3 34703 252
2689 1 2818 1 4294967295 2049 1 79401 301
2689 1 2874 1 0 3073 1 8192 24576
2689 1 2874 1 2 1025 2 32788 252
2689 1 2874 1 4 1 4 33038 408
2689 1 2874 1 8 3073 1 32788 262
2689 1 2874 1 9 1025 2 33293 347
2689 1 2874 1 11 3073 13 33050 94555
2689 1 2874 1 71 1 3 34703 252
2689 1 2874 1 4294967295 3073 1 127605 296
2689 1 2936 1 0 4097 1 8192 24576
2689 1 2936 1 2 1025 2 32788 252
2689 1 2936 1 4 1 4 33038 408
2689 1 2936 1 8 3073 1 32788 262
2689 1 2936 1 9 1025 2 33293 347
2689 1 2936 1 11 3073 13 33050 94555
2689 1 2936 1 71 1 3 34703 252
2689 1 2936 1 4294967295 4097 1 32788 278
35 rows selected.
SQL>
As you can see above now I have 5 virtual full backups (2728, 2768,2818,2874, and 2936) stored in 5 chunks (1, 1025, 2049,3073,4097). In this case, if I want need to read the virtual full backup 2936 I read the PLAN_DETAILS and check that:
- The datafile block 0 until block 1 are stored at chunk 4097.
- The datafile block 2 until block 4 are stored at chunk 1025.
- The datafile block 4 until block 8 are stored at chunk 1.
- The datafile block 8 are stored at chunk 3073.
- The datafile block 9 until block 10 are stored at chunk 1025.
- The datafile block 11 until block 24 are stored at chunk 3073.
The image below represents this:
Automated Delta Pool Space Management
Since ZDLRA contains a “self-managed” rman catalog, the backups need are managed automatically. This means that unnecessary data are deleted from time to time to avoid redundancy and to be more space-efficient. For ZDLRA this is called “automated delta pool space management”, specifically the “delta pool optimization“, to optimize the delta pool.
Internally this means that ZDLRA constantly checks the ingest backup and try to optimize the Delta Store. If I continue to change data and to do more backups we can see this in action:
SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;
DF_KEY TYPE VB_KEY BLKRANK BLOCKNO CHUNKNO NUMBLKS COFFSET NUMBYTES
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
2689 1 2768 1 0 1025 1 8192 24576
2689 1 2768 1 2 1025 2 32788 252
2689 1 2768 1 4 1 4 33038 408
2689 1 2768 1 8 1025 16 33040 45339
2689 1 2768 1 71 1 3 34703 252
2689 1 2768 1 4294967295 1025 1 78379 293
2689 1 2818 1 0 2049 1 8192 24576
2689 1 2818 1 2 1025 2 32788 252
2689 1 2818 1 4 1 4 33038 408
2689 1 2818 1 8 2049 1 32788 257
2689 1 2818 1 9 1025 7 33293 36549
2689 1 2818 1 16 2049 3 33045 17304
2689 1 2818 1 19 1025 1 76821 1026
2689 1 2818 1 20 2049 4 50349 29052
2689 1 2818 1 71 1 3 34703 252
2689 1 2818 1 4294967295 2049 1 79401 301
2689 1 2874 1 0 3073 1 8192 24576
2689 1 2874 1 2 1025 2 32788 252
2689 1 2874 1 4 1 4 33038 408
2689 1 2874 1 8 3073 1 32788 262
2689 1 2874 1 9 1025 2 33293 347
2689 1 2874 1 11 3073 13 33050 94555
2689 1 2874 1 71 1 3 34703 252
2689 1 2874 1 4294967295 3073 1 127605 296
2689 1 2936 1 0 4097 1 8192 24576
2689 1 2936 1 2 1025 2 32788 252
2689 1 2936 1 4 1 4 33038 408
2689 1 2936 1 8 3073 1 32788 262
2689 1 2936 1 9 1025 2 33293 347
2689 1 2936 1 11 3073 13 33050 94555
2689 1 2936 1 71 1 3 34703 252
2689 1 2936 1 4294967295 4097 1 32788 278
2689 1 3002 1 0 5121 1 8192 24576
2689 1 3002 1 2 5121 2 32788 255
2689 1 3002 1 4 1 4 33038 408
2689 1 3002 1 8 3073 1 32788 262
2689 1 3002 1 9 1025 1 33293 128
2689 1 3002 1 10 5121 1 33043 215
2689 1 3002 1 11 3073 13 33050 94555
2689 1 3002 1 24 5121 28 33258 4986
2689 1 3002 1 52 1 1 34703 84
2689 1 3002 1 56 5121 8 38244 1168
2689 1 3002 1 72 1 1 34787 84
2689 1 3002 1 128 5121 843 39412 125460
2689 1 3002 1 4294967295 5121 1 164872 301
45 rows selected.
SQL>
Here, look the plan for virtual full backup 2768 (that was one of the first and already consolidated) changed. Look that for block 0 the chunk that store changed from 1 to 1025. And this occurred for other blocks (blocks 8-13 as an example), look the plans right now:
The red arrows represent the change that we can see in the PLAN_DETAILS table for VB_KEY 2728. The back arrows represent the blocks needed (from previous backups) if I want to read the virtual full backup 3002.
At the end if I do another backup we can see more evolution for space management:
SQL> select * from plans_details where df_key = 2689 order by vb_key asc, blockno asc;
DF_KEY TYPE VB_KEY BLKRANK BLOCKNO CHUNKNO NUMBLKS COFFSET NUMBYTES
---------- ---------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
2689 1 2818 1 0 2049 1 8192 24576
2689 1 2818 1 2 1025 2 32788 252
2689 1 2818 1 4 1 4 33038 408
2689 1 2818 1 8 2049 1 32788 257
2689 1 2818 1 9 1025 7 33293 36549
2689 1 2818 1 16 2049 3 33045 17304
2689 1 2818 1 19 1025 1 76821 1026
2689 1 2818 1 20 2049 4 50349 29052
2689 1 2818 1 71 1 3 34703 252
2689 1 2818 1 4294967295 2049 1 79401 301
2689 1 2874 1 0 3073 1 8192 24576
2689 1 2874 1 2 1025 2 32788 252
2689 1 2874 1 4 1 4 33038 408
2689 1 2874 1 8 3073 1 32788 262
2689 1 2874 1 9 1025 2 33293 347
2689 1 2874 1 11 3073 13 33050 94555
2689 1 2874 1 71 1 3 34703 252
2689 1 2874 1 4294967295 3073 1 127605 296
2689 1 2936 1 0 4097 1 8192 24576
2689 1 2936 1 2 1025 2 32788 252
2689 1 2936 1 4 1 4 33038 408
2689 1 2936 1 8 3073 1 32788 262
2689 1 2936 1 9 1025 2 33293 347
2689 1 2936 1 11 3073 13 33050 94555
2689 1 2936 1 71 1 3 34703 252
2689 1 2936 1 4294967295 4097 1 32788 278
2689 1 3002 1 0 5121 1 8192 24576
2689 1 3002 1 2 5121 2 32788 255
2689 1 3002 1 4 1 4 33038 408
2689 1 3002 1 8 3073 1 32788 262
2689 1 3002 1 9 1025 1 33293 128
2689 1 3002 1 10 5121 1 33043 215
2689 1 3002 1 11 3073 13 33050 94555
2689 1 3002 1 24 5121 28 33258 4986
2689 1 3002 1 52 1 1 34703 84
2689 1 3002 1 56 5121 8 38244 1168
2689 1 3002 1 72 1 1 34787 84
2689 1 3002 1 128 5121 843 39412 125460
2689 1 3002 1 4294967295 5121 1 164872 301
2689 1 3074 1 0 6145 1 8192 24576
2689 1 3074 1 2 5121 2 32788 255
2689 1 3074 1 4 1 4 33038 408
2689 1 3074 1 8 3073 1 32788 262
2689 1 3074 1 9 1025 1 33293 128
2689 1 3074 1 10 5121 1 33043 215
2689 1 3074 1 11 3073 13 33050 94555
2689 1 3074 1 24 5121 28 33258 4986
2689 1 3074 1 52 1 1 34703 84
2689 1 3074 1 56 5121 8 38244 1168
2689 1 3074 1 72 1 1 34787 84
2689 1 3074 1 128 5121 843 39412 125460
2689 1 3074 1 4294967295 6145 1 32788 281
52 rows selected.
SQL>
The image that represents the actual story now it is:
If you check the table and the image you can see that ZDLRA check block a block and now the block #8 for VB_KEY 2728 came from chunk 2049 (done by virtual full backup 2818). If you check with the previous report you can see that backup #8 was split from previous chunk and this information was added for VB_KEY 2728.
At the end, this means that ZDLRA optimized the delta store too, maybe, allow that chunk 1 can be deleted in the future. Probably during the INDEX_BACKUP/PLAN_DF tasks the ZDLRA checked that the block 1 it is the same that exists in others chunks and marked the existing version in chunk number 1 as obsolete.
Virtual Full Backup
This is how the virtual full backup works. Every datafile block that enters inside of ZDLRA from rman backup it is indexed and stored to create the virtual full backup. As you saw above, the idea is creating the representation for every virtual full backup of datafile (VBDF table) linking with one plan (PLANS and PLAN_DETAILS tables).
Going further, you can see that does not exist 1 to 1 relation between backup that was ingested and the virtual full backup. It is just a matrix of pointers for blocks inside chunks. This is the reason that ZDLRA it is different from other backup appliances, it can analyze block a block and index it efficiently.
Disclaimer: “The postings on this site are my own and don’t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community. Post protected by copyright.”
Pingback: ZDLRA, Configuring Tape Library | Fernando Simon
Pingback: ZDLRA, ORDERING_WAIT task state | Fernando Simon