Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Ali Shahnazi (12.10.FC15, AIX) asked why encrypted ontape restores demanded removing key files and why setup took so long. Andreas Legner explained chunk clearing before encryption, which can be suppressed by clearing bit 0x10 in KERNEL_CTRL, and that v12 creates new keys each restore while v14 needs a key up front (onkstore). Ali confirmed it worked and noted KERNEL_CTRL is undocumented.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Ali Shahnazi — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi folks,
Informix 12.10.FC15
AIX
Using raw devices
I'm seting up encryption and came up with a doubt/question
Intialized an instance
Backed up and restored with encrypt option ( ontape -p -encrypt)
Created dbspaces ( took so long )
Created database and imported data
Backed up and restore (ontape -p )
Questions:
In step 5 above, when I kicked of ontape -p, it asked me to remove the key files. It looks like each restore counts as an attempt to do the encryption. Is this right? I was expecting to use the same keys that I created on step 2 and just do a quick backup/restore but it wasn't the case or I'm missing something.
While I deliberately truncated almost all tables, still the step 3 and step 5 took a long long time. It looks likle the encryption is going through the whole disk even it's an empty dbspaces?
------------------------------
Ali Shahnazi
------------------------------
↪ replying to Ali Shahnazi
Tomas Dalebjörk — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi Ali,
It was a very long time since I lastly worked with Informix, but if I remember it correctly, there is a setting in the $ONCONFIG, DISK_ENCRYPTION .. something to cover encryptions in the database.
Backup / Restore has a flag
ontape -r -encryptIf you want to store this directly on a on-premise storage, sharing same storage with other servers, than Spictera Unified Storage can be a great help.
One can send the backup to a VTL on the Spictera Unified Storage, or to a object-storage/bucket/s3, or mount the storage as a file-system mount point.
The storage is immutable, once the backup is written, it can't be changed/removed. A changed backup is equally to a new version of the same file/object.
This storage works for Any Device, Anywhere using Any Media. Possible to choose media according to defined policies whether it is Disk, CD, Tape, Cloud, NAS...
Eg
# mount -t spfs /backup
Regards Tomas
www.spictera.com
------------------------------
Tomas Dalebjörk
------------------------------
↪ replying to Ali Shahnazi
Andreas Legner — source: IBM Community (ConnectedCommunity.org) Informix forum
Hi Ali,
I'd assume the duration of your step 3 is due to chunk clearing, i.e. chunks would be zeroed out over their full size - for obvious security reasons (after all encryption is all about security.)
For testing purposes, or if you think there's nothing worth of being wiped out in those chunks before they become part of your Informix instance, this clearing can be suppressed. There used to be a separate onconfig parameter CLEAR_CHK_B4_ENCRYPT for this, but this recently (also in your 12.10.FC15) got bunched together with a set of other parameters, into new KERNEL_CTRL bitfield parameter (s. "onstat -g cfg full KERNEL_CTRL").
To turn on this suppression, or rather to turn of that clearing, you'd have to turn off the respective bit (0x00010) in this parameter's value, i.e. you take the current value (typically the default value, e.g. 0x30b5) remove the 0x10 (turning it to 0x30a5) and use this new value in your onconfig before starting your test.
To your questions:
yes, in the backup everything would reside un-encrypted, and wherever this gets restored (new or original environment), it will newly encrypt.
In Version 12 encryption will automatically create new (!) encryption keys each time (phys. restore or oninit -i) and force you to remove old ones.
In Version 14, though, you'll be forced to provide a key up front, using onkstore utility, so there a pre-existing key would be re-used, afaik.
try what I've described above
HTH,
Andreas
------------------------------
Andreas Legner
------------------------------
↪ replying to Andreas Legner
Ali Shahnazi — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks @Tomas.
Thanks @Andreas. What you said, making sense to me. In my next attempt, I'll try that and update here for future references.
------------------------------
Ali Shahnazi
------------------------------
↪ replying to Ali Shahnazi
Ali Shahnazi — source: IBM Community (ConnectedCommunity.org) Informix forum
Thanks again @Andreas.
Confirming that your trick worked.
2 points to share if anyone reached here :)
1 -
KERNEL_CTRL is an undocumented feature ( onstat -g cfg full KERNEL_CTRL)
2 - If you are combining encryption, redirect restore and STDIO, the order of the parameters in the 12.10 manual is not working.
# nohup ontape -p -rename -f <filename> -encrypt -t STDIO < backupfile &
------------------------------
Ali Shahnazi
------------------------------
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.