ODAVP: HowTo backup/restore your VM Guest

Asset ID:	1-71-1633166.1
Update Date:	2017-08-16
Keywords:

Solution Type Technical Instruction Sure

Solution 1633166.1 : ODAVP: HowTo backup/restore your VM Guest

Applies to:

Oracle Database Appliance Software - Version 2.8.0.0 and later
Oracle Database Appliance - Version All Versions to All Versions [Release All Releases]
Information in this document applies to any platform.

Goal

The goal of this guide is to provide knowledge and insights into Oracle VM that will help the reader develop backup and recovery processes that fit the unique requirements of the readers’ Oracle Database Appliance Virtualized Platform (ODA VP)

Solution

Oracle VM Guests

Oracle VM Guests are Virtual Machines that host guest operating systems, databases and applications that comprise various business systems within your ODA VP. Note in Figure below
that the Oracle VM Guests are shown as part of the storage repositories. The storage repository is where all configuration files and virtual disks reside for each Oracle VM Guest (DomU).

Understanding Storage

The primary function of storage repositories is to contain the configuration files and virtual system images for each Oracle VM Guest, plus static guest resources such templates.

Local Storage Repository

There are occasions where individuals and even data centers find that non-clustered repository are advantageous. In this case everything related to Oracle VM Guests will reside on local storage contained within single ODA node. Local internal disk can be used for storage repositories on each Oracle ODA Server, but has very limited application due to the fact that local physical disks are only available to the node in which they reside.

As the local storage repository is using "ext3" filesystem the guest VM must be stopped to backup it.

Shared Storage Repository

Oracle Database Appliance Virtualized Platform enables you to create one or more shared repositories for the storage of virtual machine (VM) files. A VM shared repository provides high availability support. A VM can be configured to fail over from one node to another node in case of node failure, and a VM can auto-restart on the preferred node or failover to another node if the preferred node is not available.You may configure VM high availability with Oracle Appliance Manager configuration command options such as FailOver and PrefNode

Sharedrepo

The Shared storage repository is using ACFS Oracle Automatic Storage Management Cluster File System (Oracle ACFS) is a multi-platform, scalable file system, and storage management technology that extends Oracle Automatic Storage Management (Oracle ASM) functionality to support customer files maintained outside of Oracle Database.

ACFS is supporting snapshots.

An Oracle ACFS snapshot is an online, read-only or read-write, point in time copy of an Oracle ACFS file system. The snapshot copy is space-efficient and uses Copy-On-Write functionality. Before an Oracle ACFS file extent is modified or deleted, its current value is copied to the snapshot to maintain the point-in-time view of the file system.

Oracle ACFS snapshots are immediately available for use after they are created. The snapshots are created in the .ACFS/snaps/ directory of the file system. They are always online while the file system is mounted. Consequently, an Oracle ACFS snapshot can support the online recovery of files inadvertently modified or deleted from a file system. With up to a total of 63 read-only, read-write, or combination of read-only and read-write snapshot views supported for each file system, flexible online file recovery solutions spanning multiple views can be employed. An Oracle ACFS snapshot can also be used as the source of a file system backup, as it can be created on demand to deliver a current, consistent, online view of an active file system. Oracle ACFS read-write snapshots enable fast creation of an snapshot image that can be both read and written without impacting the state of the Oracle ACFS file system hosting the snapshot images.

ACFS replication

Oracle ASM Cluster File System (ACFS) replication is a new feature in 11.2.0.2 on Linux; as its name suggests, it allows you to replicate files from one host to another. The terminology used is reminiscent of Oracle Data Guard, with a primary file system and a standby file system, with replication logs recording the changes. The replication logs are shipped across the network from the primary to the standby and the changes are applied.

Notes:
    - At the time of writing this article, ACFS replication for Guest VM shared storage between two ODAs is not supported (VM shared repo - DataGuard)
    - ACFS replication can not gurantee guest VM filesystem consistency
    - Starting with ODA software version 12.1, the Guest VMs and the VDisks are stored in ACFS snapshots. The replication of snapshot is not supported

The hot backup using snapshot is not a recommended procedure hence making it as internal only

Understanding Oracle VM Guest shared repository snapshot

Oracle ACFS allows snapshot of shared storage repository of your virtual machines and templates to create new copies which can then be backed up. There are two basic choices for snapshotting shared storage repository:

Cold snapshot – in this case the virtual machine is completely stopped. This choice offers widest number of supported conditions. When the virtual machine is in OFFLINE state, the data consistency is assured
Hot snapshot – in this case the virtual machine is running. This choice is only supported for Oracle VM Guests with no running databases (no transactional Guest VM). Snapshot of running Guest VM does not guarantee data consistency and the virtual disks might need to be filesystem checked before they are usable. Database Guest Virtual Machines and Guest Virtual Machines with heavy transactions are not suitable candidates for hot snapshot.

Challenges to Backup and Recovery Solutions for Oracle VM

Oracle VM Guests cannot directly access tape devices

At the time of this writing, Oracle Database Appliance VP does not support PCI pass-through SCSI devices for Oracle VM Guests. This means that controllers for robotic arms in tape libraries or SCSI tape devices cannot be presented directly to the Oracle VM guests.

Understanding what needs to be backed up

Oracle VM Guests are virtual machines containing a guest operating system such as Linux, Solaris or Windows. Each Oracle VM Guest can consist of a number of files, but require a minimum of the vm.cfg file and a system image.

Backup Strategies

This document discusses how to determine which Oracle VM components and objects need to be backed up in order to quickly and reliably recover from a system failure or disaster. The document does not attempt to explain backup and recovery concepts or procedures since organizations will already have well defined backup products, strategies and procedures defined. Oracle makes no suggestions about retention windows, recovery time objectives, multiplexing, multi-streaming or full, incremental and differential backups. It is also assumed by this document that the reader already knows how to perform hot backups and how to quiesce applications, databases, ODA servers or guests.

Preferred backup methods for Oracle VM

The choice of backup methods and technology used in your environment is completely up to you. For the purposes of this guide, products basically fall into two categories of backup technologies:

Linux tools – This includes such system applications such as cpio, dd, dump, tar, gzip, zip, rsync etc.
Snapshot – This includes snapshot capabilities of ACFS

Backup frequency

The frequency in which periodic backups are performed is completely dependent upon existing backup policies for your data center and functional business units. Generally, the frequency of backups is predicated on the tolerance for risk and recovery time objective (RTO) for both the business systems and the Oracle VM environment. Here are some general guidelines for backup frequency to give you a feel for how you might choose to design your backup/recovery plan. The backup requirements and recommendations of your individual business systems should always win over any general guidelines suggested in this guide pertaining to the frequency of backups.

Backup retention windows

The length of time to retain snapshots and tape backups is completely dependent upon existing backup policies for your data center and functional business units. Retention periods for snapshots are usually measured in terms of a few days to a week, necessarily short due to the way the software tracks changes between the live data and static data. Tape backups are retained for much longer periods, so if data need to be restored after a snapshot has been destroyed, then they can be restored from tape. Tape restores of course are measured in hours.

Using ACFS snapshot to back up Oracle VM Guests

The ACFS has the ability to snapshot Oracle VM Guests shared repository.
An obvious use case for the snapshot capability would be in a scenario where a point-in-time copy of an Oracle VM Guest would allow you to apply updates to the guest operating system and have an easy way to back out of the update in case things go awry. Snapshot may work under some limited circumstances as a backup and recovery solution for Oracle VM Guests, but it is probably going to be most effective as a means of making periodic ad-hoc backups of a virtual machine before making some sort of change that might have unforeseen catastrophic results. The usage of ACFS snapshot can reduce the guest VM downtime dramatically.

Backup for VM Guests

Oracle VM Guest OS level backup

To backup at the guest VM OS level, you can install standard backup agent (Oracle Secure Backup, NetBackup, etc.) into the virtual machine, and treat the guest VM as a regular host to perform backup and restore. In this case, the backup and restore is no different than any regular OS backup and restore.

VM Guest running from local storage repository

The VM guest running from local storage repository must be in OFFLINE status before the backup. As the Guest is not running, the filesystem consistency is guarantee. You should stop them from ODA_BASE, issuing the following command:

oakcli stop vm <vm_name>

The file level backups simply capture all files under the following directories on "dom0":

/OVS/Repositories/odarepo1/VirtualMachines/<vm_name> # on dom0 ODA node 0
/OVS/Repositories/odarepo2/VirtualMachines/<vm_name> # on dom0 ODA node 1

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above VM guest directories.

Once the backup has been completed, you can restart the Guest from ODA_BASE issuing the following command:

oakcli start vm <vm_name>

VM Guest running from shared storage repository version 12.1.2.0.0 and above

With the guest VM running from shared storage repository, you can have some more possibilities leveraging on ODA v 12.1.2.0.0 features

- Guest VM OFFLINE backup

If your guest VM can be stopped, the filesystem consistency is guarantee, you should stop the guest from ODA_BASE issuing:

oakcli stop vm <vm_name>

Using ACFS snapshot

You can get a shared VM repository snapshot, reducing dramatically the guest downtime, issuing fron ODA_BASE and as 'root' user:

acfsutil snap create -p <vm_name> <snap_vm_repo_name> <vm_repo_mountpoint>

example:
# acfsutil snap create -p OL6U4 repo_snap /u01/app/sharedrepo/srepo1

The VM clone snapshot is created on the following path

/u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/<snap_vm_repo_name>/VirtualMachines/<vm_name>

example:
/u01/app/sharedrepo/srepo1/.ACFS/snaps/repo_snap/VirtualMachines/OL6U4

Once the snapshot is created, you can startup the guest again, from ODA_BASE issuing the following command:

oakcli start vm <vm_name>

example:
oakcli start vm OL6U4

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above cloned VM guest directory. Example using 'rsync' os command:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids --stats \
      /u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/<snap_vm_repo_name>/VirtualMachines/<VM name> \
      <rsync destination>

ie:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids \
      /u01/app/sharedrepo/srepo1/.ACFS/snaps/repo_snap/VirtualMachines/OL6U4
      backup@remotehost:/VMBackup/

Note:starting with ODA 12.1.2.0.0 the 'VDisk' feature is available. If your VM is using such new feature you need to take care for these files on the VM backup as well. You can check the VDisk usage by your VM, issuing the following command:

# oakcli show vm <vm_name>

example
   # oakcli show vm OL6U4
   Resource: OL6U4
       AutoStart       :   restore
       CPUPriority     :   100
       Disks           :   |file:/OVS/Repositories/srepo1/.ACF
                           S/snaps/OL6U4/VirtualMachines/OL6U4
                           /dd5ea9a432024da0afd65dfbe38c97ff.i
                           mg,xvda,w|
       Domain          :   XEN_PVM
       ExpectedState   :   Offline
       FailOver        :   false
       IsSharedRepo    :   true
       Keyboard        :   en-us
       MaxMemory       :   2048
       MaxVcpu         :   2
       Memory          :   2048
       Mouse           :   OS_DEFAULT
       Name            :   OL6U4
       Networks        :   |type=netfront,bridge=priv1||type=n
                           etfront,bridge=net1|
       NodeNumStart    :   1
       OS              :   OL_5
       PrefNodeNum     :   1
       PrivateIP       :   192.168.16.55
       ProcessorCap    :   100
       RepoName        :   srepo1
       Source          :   0
       State           :   Offline
       TemplateName    :   otml_OL6U4
       VDisks          :   |oakvdk_svdisk1_srepo1||oakvdk_vdis
                           k1_srepo1|
       Vcpu            :   2
       cpupool         :   default-unpinned-pool
       vncport         :   None

You need to get the snapshot for all VDisks

acfsutil snap create -p oakvdk_<vdiskname> <vdiskrname_snap> <vm_repo_mountpoint>

example:
# acfsutil snap create -p oakvdk_vdisk1 vdisk1_snap /u01/app/sharedrepo/srepo1
# acfsutil snap create -p oakvdk_svdisk1 svdisk1_snap /u01/app/sharedrepo/srepo1

the VDisks file to backup are stored on the following path

/u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/<vdiskname_snap>/VirtualDisk

example:
/u01/app/sharedrepo/srepo1/.ACFS/snaps/vdisk1_snap/VirtualDisks/oakvdk_vdisk1
/u01/app/sharedrepo/srepo1/.ACFS/snaps/svdisk1_snap/VirtualDisks/oakvdk_svdisk1

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the vdisk. Example using 'rsync' os command:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids --stats \
      /u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/<vdiskname_snap>/VirtualDisks/oakvdk_<vdisk_name> \
      <rsync destination>

ie:
   rsync --archive --compress --hard-links --human-readable \
          --inplace --no-whole-file --numeric-ids \
          /u01/app/sharedrepo/srepo1/.ACFS/snaps/vdisk1_snap/VirtualDisks/oakvdk_vdisk1
          backup@remotehost:/VMBackup/

   rsync --archive --compress --hard-links --human-readable \
          --inplace --no-whole-file --numeric-ids \
          /u01/app/sharedrepo/srepo1/.ACFS/snaps/svdisk1_snap/VirtualDisks/oakvdk_sdisk1
          backup@remotehost:/VMBackup/

As on you have copied out the VM guest files, you can remove the snapshot, from ODA_BASE as root user:

acfsutil snap delete <snap_vm_repo_name> <vm_repo_mountpoint>

example:
# acfsutil snap delete repo_snap /u01/app/sharedrepo/srepo1

Note: having VDisks you need to remove the related snapshots above

acfsutil snap delete <vdiskrname_snap> <vm_repo_mountpoint>

example:
# acfsutil snap delete vdisk1_snap /u01/app/sharedrepo/srepo1
# acfsutil snap delete svdisk1_snap /u01/app/sharedrepo/srepo1

Without ACFS snapshot usage

If you can keep the guest VM down until you have copied out the guest VM files, you can skip the ACFS snapshot usage. The guest VM file are under the VM folder (on ODA_BASE):

/u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/<vm_name>/VirtualMachines/<VM name>/*

example:
/u01/app/sharedrepo/srepo1/.ACFS/snaps/OL6U4/VirtualMachines/OL6U4/*

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above VM guest directories. Example using 'rsync' os command:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids --stats \
      /u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/<vm_name>/VirtualMachines/<VM name> \
      <rsync destination>

ie:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids \
      /u01/app/sharedrepo/srepo1/.ACFS/snaps/OL6U4/VirtualMachines/OL6U4
      backup@remotehost:/VMBackup/

Note:starting with ODA 12.1.2.0.0 the 'VDisk' feature is available. If yor VM is using such new feature you need to take care for these files on the VM backup as well. You can chek orthe VDisk usage issuingte followin command:

the VDisk file to backup are stored on the following path

/u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/oakvdk_<vdisk_name>/VirtualDisks/oakvdk_<vdisk_name>

example:
/u01/app/sharedrepo/srepo1/.ACFS/snaps/oakvdk_vdisk1/VirtualDisks/oakvdk_vdisk1
/u01/app/sharedrepo/srepo1/.ACFS/snaps/oakvdk_svdisk1/VirtualDisks/oakvdk_svdisk1

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the vdisk. Example using 'rsync' os command:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids --stats \
      /u01/app/sharedrepo/<vm_repo_name>/.ACFS/snaps/oakvdk_<vdisk_name>/VirtualDisks/oakvdk_<vdisk_name> \
      <rsync destination>

ie:
   rsync --archive --compress --hard-links --human-readable \
          --inplace --no-whole-file --numeric-ids \
          /u01/app/sharedrepo/srepo1/.ACFS/snaps/oakvdk_vdisk1/VirtualDisks/oakvdk_vdisk1
          backup@remotehost:/VMBackup/

   rsync --archive --compress --hard-links --human-readable \
          --inplace --no-whole-file --numeric-ids \
          /u01/app/sharedrepo/srepo1/.ACFS/snaps/oakvdk_sdisk1/VirtualDisks/oakvdk_sdisk1
          backup@remotehost:/VMBackup/

Once you have copied out the guest files, you can startup the guest again, from ODA_BASE issuing the following command:

oakcli start vm <vm_name>

VM Guest running from shared storage repository version 2.8, 2.9 and 2.10

With the guest VM running from shared storage repository, you can have some more possibilities leveraging on ACFS snapshot.

- Guest VM OFFLINE backup

If your guest VM can be stopped, the filesystem consistency is guarantee, you should stop the guest from ODA_BASE issuing:

oakcli stop vm <vm_name>

Using ACFS snapshot

You can get a shared repository snapshot, reducing dramatically the guest downtime, issuing fron ODA_BASE and as 'root' user:

acfsutil snap create shared_repo <repo_mount_point>

ie
acfsutil snap create shared_repo /u01/app/sharedrepo/shared_repo

The ACFS snapshot is created on the following path

/u01/app/sharedrepo/<reponame>/.ACFS/snaps/<reponame>/VirtualMachines/<vm_name>

ie.
/u01/app/sharedrepo/shared_repo/.ACFS/snaps/shared_repo/VirtualMachines/OL6U4

Once the snapshot is created, you can startup the guest again, from ODA_BASE issuing the following command:

oakcli start vm <vm_name>

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above VM guest directories. Example using 'rsync' os command:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids --stats \
      <share repo mount point>/.ACFS/snaps/<reponame>/VirtualMachines/<vm_name> \
      <rsync destination>

ie:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids \
      /u01/app/sharedrepo/shared_repo/.ACFS/snaps/shared_repo/VirtualMachines/OL6U4
      backup@remotehost:/VMBackup/

As on you have copied out the VM guest files, you can remove the snapshot, from ODA_BASE as root user:

acfsutil snap delete shared_repo <repo_mount_point>

ie
acfsutil snap delete shared_repo /u01/app/sharedrepo/shared_repo

Without ACFS snapshot usage

If you can keep the guest VM down until you have copied out the guest VM files, you can skip the ACFS snapshot usage. The guest VM file are under the VM folder (on ODA_BASE):

/u01/app/sharedrepo/<shared repo name>/VirtualMachines/<vm_name>/*

ie:
/u01/app/sharedrepo/shared1/VirtualMachines/OL6U4/*

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above VM guest directories. Example using 'rsync' os command:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids --stats \
      /u01/app/sharedrepo/<shared repo name>/VirtualMachines/<vm_name> \
      <rsync destination>

ie:

rsync --archive --compress --hard-links --human-readable \
      --inplace --no-whole-file --numeric-ids \
      /u01/app/sharedrepo/shared1/VirtualMachines/OL6U4
      backup@remotehost:/VMBackup/

Once you have copied out the guest files, you can startup the guest again, from ODA_BASE issuing the following command:

oakcli start vm <vm_name>

- Guest VM in Pause status backup

If your guest VM can not be stopped, but you can pause it for few time and it is supporting the kernel file system sync (kernel.sysrq=1 on /etc/sysctl.conf) like Oracle Linux, from dom0 execute:

xm sysrq <vm_name> s

Note: as sysrq 's' = flush data to disk, it's not supported on Solaris and Ms Windows

then you can pause the guest issuing (from dom0):

xm pause <vm_name>

Note: When a guest VM is in paused state the domain will still consume allocated resources like memory (keeps it resident in memory), but will not be eligible for scheduling by the hypervisor.

a this time you can take the snapshot (from ODA_BASE)

acfsutil snap create shared_repo <repo_mount_point>

ie
acfsutil snap create shared_repo /u01/app/sharedrepo/shared_repo

once you have the repository snapshot, the Guest VM can be unpaused (from dom0):

xm unpause <vm_name>

Note as the command sequence 'pause', 'snap create', 'unpause' execution is very fast.

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above VM guest directories. Example using 'rsync' os command:

As on you have copied out the VM guest files, you ca remove the snapshot, from ODA_BASE as root user:

acfsutil snap delete shared_repo <repo_mount_point>

ie
acfsutil snap delete shared_repo /u01/app/sharedrepo/shared_repo

Note: this methodology can not guarantee guest filesystem consistency. When you are getting the disk image files backup, what you are getting is roughly
the same as you'd have on the disks of a bare-metal machine after yanking the power cord. The guest filesystem sync request could not be enough. It will only sync data which
applications have asked the OS to write to disk, anything cached by the application (particularly the case with databases) will not be included. It's a method that will "work well enough" for some use cases typically low write frequency/volume, no applications which cache data, "robust" filesystems.

- Guest VM ONLINE backup

If you can not stop your Guest VM, you can not gurantee the filesystem consistency, then a filesystem check will be executed later, after the restore, from ODA_BASE and as 'root' user:

acfsutil snap create shared_repo <repo_mount_point>

ie
acfsutil snap create shared_repo /u01/app/sharedrepo/shared_repo

The ACFS snapshot is created on the following path

/u01/app/sharedrepo/<reponame>/.ACFS/snaps/<reponame>/VirtualMachines/<vm_name>

ie.
/u01/app/sharedrepo/shared_repo/.ACFS/snaps/shared_repo/VirtualMachines/OL6U4

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above VM guest directories. Example using 'rsync' os command:

As on as you have copied out the VM guest files, you can remove the snapshot, from ODA_BASE as root user:

acfsutil snap delete shared_repo <repo_mount_point>

ie
acfsutil snap delete shared_repo /u01/app/sharedrepo/shared_repo

Note:

as discussed above, the VM Online backup can not guarantee the guest filesystem consistency. You should check if your VM copy will work fine or if you need to perform an FS check building a template and cloning it. (see below: 'Recovery VM Guest by import/clone)'. You could import/clone the guest on local repository without impacting the shared repository.

Recovery for VM Guests

The VM files restore must be done when the guest status is OFFLINE. You should stop the guest from ODA_BASE issuing:

oakcli stop vm <vm_name>

VM Guest running within local storage repository

In case your VM guest is running within local repository, you need to copy the files on one of the following directory (dom0):

/OVS/Repositories/odarepo1/VirtualMachines/<vm_name> # on dom0 ODA node 0
/OVS/Repositories/odarepo2/VirtualMachines/<vm_name> # on dom0 ODA node 1

Once you have copied the VM files, you can start the VM issuing the following command from ODA_BASE:

oakcli start vm <vm_name>

Note: check the guest console for potential filesystem repair needed actions in particular if the backup has been taken with running VM

VM Guest running within shared storage repository version 12.1.2.0.0 and above

In case your VM is running within shared repository, you need to copy the guest files on the following directory (ODA_BASE):

/u01/app/sharedrepo/<reponame>/.ACFS/snaps/<VM name>/VirtualMachines/<VM name>

example:
/u01/app/sharedrepo/srepo1/.ACFS/snaps/OL6U4/VirtualMachines/OL6U4

Note: if your VM was using VDisks, you need to restore them as well, the related path is as following :

Once you have copied the VM files, you can start the VM issuing the following command from ODA_BASE:

oakcli start vm <vm_name>

Note: check the guest console for potential filesystem repair needed actions in particular if the backup has been taken with running VM

VM Guest running within shared storage repository version 2.8, 2.9 and 2.10

In case your VM is running within shared repository, you need to copy the guest files on the following directory (ODA_BASE):

/u01/app/sharedrepo/<reponame>/VirtualMachines/<vm_name>

ie.
/u01/app/sharedrepo/shared_repo/shared_repo/VirtualMachines/OL6U4

Once you have copied the VM files, you can start the VM issuing the following command from ODA_BASE:

oakcli start vm <vm_name>

Note: check the guest console for potential filesystem repair needed actions in particular if the backup has been taken with running VM

Recovery VM Guest by import & clone

Having the VM files (virtual disks *.img, configuration file vm.cfg) you can generate the VM template executing:

tar -Scvfz <vm_name>.tgz -C <backup VM path> .

ie:
tar -Scvfz OL6U4.tgz -C /VMBackup/OL6U4 .

You can now import such <vm_name>.tgz as VM template, from ODA_BASE:

oakcli import vmtemplate vmtemplatename -files image_files -repo repo_name [- node 0 | 1 ]

Having the template imported you can now clone the VM:

oakcli clone vm vm_name -vmtemplate template_name -repo repo_name [-node 0|1]

you can start the VM issuing the following command from ODA_BASE:

oakcli start vm <vm_name>

Note: check the guest console for potential filesystem repair needed actions in particular if the backup has been taken with running VM

Backup & Recovery ODA_BASE

Backup ODA_BASE

ODA_BASE, running from local storage repository, must be in OFFLINE status before the image backup. You should stop ODA_BASE from dom0, issuing the following command:

oakcli stop oda_base

The image backups simply capture all files (swap.img, System.img, u01.img, vm.cfg) under the following directories on "dom0":

/OVS/Repositories/odabaseRepo/VirtualMachines/oakDom1 # on ODA dom0

You can use Linux tools such as cpio, tar, gzip, scp, sftp, rsync to move away the content of the above ODA_BASE directories.

Once the backup has been completed, you can restart the ODA_BASE issuing the following command from dom0:

oakcli start oda_base

You should repeat the same on second node.

Restore ODA_BASE

The ODA_BASE files restore must be done when the status is OFFLINE. You should stop ODA_BASE from dom0, issuing the following command:

oakcli stop oda_base

You need to copy back the ODA_BASE's files (swap.img, System.img, u01.img, vm.cfg) on the following directory (dom0):

/OVS/Repositories/odabaseRepo/VirtualMachines/oakDom1 # on ODA dom0

Once you have copied the ODA_BASE files, you can start it issuing the following command from dom0:

oakcli start oda_base

References

<BUG:18353891> - LNX64-112-CMT: PLEASE PROVIDE "XM COMMANDS" CAPABILITY FROM ODA_BASE
<BUG:17819047> - LNX64-112-CMT: OAKCLI SHARED REPO SUPPORT FOR ACFS REPLICATION
http://www.oracle.com/technetwork/server-storage/engineered-systems/database-appliance/documentation/dbappliancebackupstrategies-519664.pdf
<BUG:18103258> - LNX64-112-CMT: PROVIDE BACKUP/RESTORE AUTOMATION FOR RUNNING VM

Attachments

This solution has no attachment