Thank you for your reply.
However, what is written here is the confirmation method when encryption is performed at the time of backup, isn't it?
CloudCatalyst encrypts the backed up data when it is uploaded to the cloud, so we couldn't verify the encryption with this procedure.
In addition, I know that I can check the existence of KMS in the property item of Storage Server of Cloud Catalyst ("MSDPCLD: kmsenabled" etc.).
However, I don't know how to make sure that the data uploaded by CloudCatalyst is encrypted.
Whenever a Netbackup image is copied or duplicated, the image information is updated in the Netbackup database.
One Netbackup image can have many FRAG(ments) depending on backup size and number of copies. You can inspect this change by running "bpimagelist -backupid" before and after duplication or a Netbackup image.
If a fragment is encrypted, field 28 of the FRAG line contain the KMS key tag. This is proof of the data being encrypted. Of cause you cannot see the FRAG lines for could catalyst before the copy is made. You need to wait after the image has been uploaded to the cloud.
To verify a encrypted backup. Move the KMS key to "depreciated" state and try to restore - as written in the "How to verify KMS encrypted the backup". The restore should fail with status code 85.
You may want to bookmark this technote:
How to interpret the different fields in "bpimagelist -l" output?
Hi Nicolai
What you are saying is correct for backups encrypted by NetBackup (eg duplicating to tape). However, when using KMS with Cloud Catalyst (or MSDP in general), the encryption is being performed by the storage server, not NetBackup.
So to determine if the CC backup is encrypted is more complex, and is not recorded in the NetBackup catalog as such.
Cheers
David
To clarify my answer above - to determine is the data is encrypted in MSDP (either standard, MSDP-C or CC), one needs to examine each segment stored. This is not a simple task as each segment is 128k (by default), so to verify for a large backup requires a lot of segments. Also remember that if you didn't enable encryption from the start, when data is stored only new segments will be encrypted (existing data in the pool will remain as is). What follows is a very basic guide to veiw the status of a segment and how to interrogate MSDP. The commands used will either be located in /usr/openv/pdde/pdcr/bin or <INSTALL_PATH>\Veritas\pdde
One for a backup (backupid), we are interested in the locations of the image information in the pool. You need to know the client name and policy that relate to the backup. This gets you the data object information. From the DO you can get a listing of the storage objects (SO) which contain a series of data container ID's (DCID) and fingerprints FP). You need these next to determine the status of the segment object. Here's an example for a small backup and looking at one single segment (SO) (my backupID is client1.ausdemo.veritas.com_1604360891)
# catdbutil --list --dbpath /msdp/cache/storage/databases/catalog/2/client1.ausdemo.veritas.com/Cloud-MSDP/ | grep client1.ausdemo.veritas.com_1604360891_C._F.*.img
2|/asb1media.ausdemo.veritas.com/Cloud-MSDP|client1.ausdemo.veritas.com_1604360891_C2_F1_R1.img|0|c309197f6cbda4e3bc1ef02c026e2316443e161f4a15dec31187007252abcb75|01fcea292180c6bf6ff059ffbd54e2cb|||0|N|0|0100600|0||260|1604360895|1604360896|1604360896|2097403||||0||PDVFS_2_F_0_ID_8_RT_0|0|5127|0|0|
# dcscan --do 5127 c309197f6cbda4e3bc1ef02c026e2316443e161f4a15dec31187007252abcb75
type of record : DO
version : 3
flags : 0x2
backup session : 3644244665
fptype : 3
size : 720
record crc : 1688145923
data crc : 1700991407
ctime : 1604363153
offset : 320
digest : c309197f6cbda4e3bc1ef02c026e2316443e161f4a15dec31187007252abcb75
file size : 2097403
segment size : 131072
no of SOs : 17
dotype : 1
file crc : 243871515
DO segments:
SO seq NO SO FP SO size SO DCID
0, e31c02488eafb69dddb009c21afe2b19a9a0f75f01ed8c50cc0812dd500ded8c, 131072, 4103
1, e79e4ceaf947272ec34a7b7f19cb14ed203c0cba649beb0a141820db7d9e9c8b, 131072, 4103
2, 267dd0d65ed358cf423c9ec0c662f60540e3b62cccb4f7616cd6987b592f6e45, 131072, 4103
3, a05040ffd12184f4a0c0c6dcebd644d8da63b3e2a3c50e556377276e7125be34, 131072, 4103
4, b9201eda04f8fe3efd094a920574aad455e4b11730ebb41d63f214c07076ed44, 131072, 4103
5, 3229d3eefe425ef0d188e1f4296de57df5b61661d3f1f22a6b0cebdad0feadc6, 131072, 4103
6, 5ce337796381633ec3145b69b94ecff0cd1fd78d40103d875b1f73db65140af3, 131072, 4103
7, 5f4fdc9d80846319f33c46fecae99e7c4d29856e487336a65743c47804d660d4, 131072, 4103
8, ee913ca8ca8e2d2b5c1519744b4d311d9e07119e918dab9de6a1498e39906034, 131072, 4099
9, 8fc3b91925fd241e26c8e3e44c534ee3553d41cc5a575a8e5ce4101920aab048, 131072, 4099
10, f956cd2d11ad30440d03feecbf47f189bf560fc9a14741fa048e26aabf226382, 131072, 4099
11, be3e86784dfe42a8e7b5b9e2fe41ad1983eef6ee8d3705d77f07b8dc1b78f0c6, 131072, 4099
12, 070bc80b235d1a076df0d8b20e5e9d8175c237cf30b2f6efe1ff9ebf9e5a1888, 131072, 4099
13, 78b4ee1cf4aea21bf0be136171f075538b654a9e7e9394edeefa45ef1dacfeca, 131072, 4099
14, d65697de09000d7ad34f761b222af8c371a3339c57b31c98e6ff798ef097b99e, 131072, 4099
15, 180363666f229517101eae6026a8f90c806eb9080c0e0badf94e44872c2fee28, 131072, 4099
16, 4534d683ef159d20b871161f763c007bd4be1b721fa2554f9fb9a0affb35652d, 251, 4099
--------------Locality Statistics---------------------
[dcid] [total so size] [total so count]
4099 1048827 9
4103 1048576 8
Total 2 containers, 17 SOs, 2097403 data size.
Average 8 SOs per container.
Average 1048701 size data per container.
------------------------------------------------------
# dcscan --so-data-format –so 4103 e31c02488eafb69dddb009c21afe2b19a9a0f75f01ed8c50cc0812dd500ded8c
type of record : SO
version : 3
flags : 0x1002
backup session : 0
fptype : 3
size : 131134
record crc : 2478969583
data crc : 4209862862
ctime : 1604363153
offset : 2505
digest : v
KMS Enc : YES
encryption key : F19E53391D562E80BB3BF7DFB6F036D1
data format : [AES-256-CTR Encrypted archive 256bit key LZO Compressed Streamable, v2, window size 143360 bytes]
#
