physical Solaris Server File+OracleDB Backup SYNC

[uk1984]

We have a scenario with a Solaris physical server (sparc) where there are 2 zones. And in each zone there is an Oracle Database.
We want to backup these 2 zones best possible.
Since it is no VM we need at least the Veeam Agent for Solaris (sparc).
And for the OracleDB we can activate the Application-aware Settings within the Agent.

Now our question would be how the backup of those 2 components: normal files and the Oracle Database is handled.
We need the files which are backupped to be totally in sync with the Oracle Database.

Because when the application writes something to database also files are then created outside of the Database in the normal filesystem which are referenced to in the Database.

So that in a restore scenario the OracleDB is totally consistent/matching, so timestamps in the DB whith the filesystem files.
Can this be achieved with Veeam?
If so are there specific settings to take you would recommend?

We also thought of the Oracle RMAN Plugin to use, but that then would be a 2 staged restore and we anyways need to Files+OracleDB.
Only OracleDB restore "standalone" has no benefit to us.

I tried to ask this the support, but since this is no break/fix topic, they didn't provide me an answer.

Hope someone can help here

[rovshan.pashayev]

Hello Udo,

As I understand you want the backup of normal files is in sync with the Oracle DB backup for consistent restore scenarios.
While I review it, can you tell me if "entire machine backup and restore" was ever considered? Also, what is the disk layout structure of this Solaris SPARC machine?

[uk1984]

We do "entire machine", but for application consistency OracleDB will have to be configured.
And we would like to know how Veeam internally handles this regarding "order"... and the impact on "timestamps" on files and OracleDB.
It's ZPOOL.

root@msasun7i:~# zpool status
pool: pkvprod
id: 381961790925682929
state: ONLINE
scan: scrub repaired 0 in 4h03m with 0 errors on Fri Apr 5 14:09:29 2024
config:

NAME STATE READ WRITE CKSUM
pkvprod ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t5000C500DA736567d0 ONLINE 0 0 0
c0t6742B0F000000F1300000000004A47B2d0 ONLINE 0 0 0
c0t6742B0F000000F1200000000004AAADDd0 ONLINE 0 0 0

errors: No known data errors

pool: pkvtest
id: 14052902844342972205
state: ONLINE
scan: scrub repaired 0 in 31m06s with 0 errors on Sun Apr 14 23:19:27 2024
config:

NAME STATE READ WRITE CKSUM
pkvtest ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t5000C500DA735FE3d0s6 ONLINE 0 0 0
c0t6742B0F000000F1300000000004A47A8d0 ONLINE 0 0 0
c0t6742B0F000000F1200000000004AAA92d0 ONLINE 0 0 0

errors: No known data errors

pool: rpool
id: 11012937185024732085
state: ONLINE
status: The pool is formatted using an older on-disk format. The pool can
still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'. Once this is done, the
pool will no longer be accessible on older software versions.
scan: scrub repaired 0 in 13m52s with 0 errors on Sun Mar 24 16:06:47 2024
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
c0t6742B0F000000F1200000000004AB5A2d0 ONLINE 0 0 0
c0t6742B0F000000F1300000000004A5201d0 ONLINE 0 0 0
c0t5000C500DA735EF3d0 ONLINE 0 0 0

errors: No known data errors

-----

root@msasun7i:~# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
0. c0t5000C500DA736567d0 <SEAGATE-ST1200IN9SUN1.2T-ORAB-1.09TB>
/scsi_vhci/disk@g5000c500da736567
/dev/chassis/SYS/HDD0/disk
1. c0t5000C500DA735EF3d0 <SEAGATE-ST1200IN9SUN1.2T-ORAB-1.09TB>
/scsi_vhci/disk@g5000c500da735ef3
/dev/chassis/SYS/HDD1/disk
2. c0t5000C500DA735FE3d0 <SEAGATE-ST1200IN9SUN1.2T-ORAB-1.09TB> solaris
/scsi_vhci/disk@g5000c500da735fe3
/dev/chassis/SYS/HDD2/disk
3. c1t0d0 <VT-eUSB-7722-1.91GB>
/pci@300/pci@1/pci@0/pci@2/usb@0/storage@1/disk@0,0
/dev/chassis/SYS/MB/EUSB_DISK/disk
4. c0t6742B0F000000F1200000000004AAA92d0 <NFINIDAT-InfiniBox-0h-169.31GB>
/scsi_vhci/ssd@g6742b0f000000f1200000000004aaa92
5. c0t6742B0F000000F1200000000004AAADDd0 <NFINIDAT-InfiniBox-0h-159.35GB>
/scsi_vhci/ssd@g6742b0f000000f1200000000004aaadd
6. c0t6742B0F000000F1200000000004AB5A2d0 <NFINIDAT-InfiniBox-0h-49.36GB>
/scsi_vhci/ssd@g6742b0f000000f1200000000004ab5a2
7. c0t6742B0F000000F1300000000004A47A8d0 <NFINIDAT-InfiniBox-0h-169.31GB>
/scsi_vhci/ssd@g6742b0f000000f1300000000004a47a8
8. c0t6742B0F000000F1300000000004A47B2d0 <NFINIDAT-InfiniBox-0h-159.35GB>
/scsi_vhci/ssd@g6742b0f000000f1300000000004a47b2
9. c0t6742B0F000000F1300000000004A5201d0 <NFINIDAT-InfiniBox-0h-49.36GB>
/scsi_vhci/ssd@g6742b0f000000f1300000000004a5201

[rovshan.pashayev]

Hello Udo,

We do "entire machine", but for application consistency OracleDB will have to be configured.

You do leverage Backup Job Scripts, don't you?