Dynamic Root Disk: Quick Start & Best Practices

8
As a best practice, consider creating a shutdown script that runs drd sync so that files changed on
the original image after the clone was created will be propagated to the clone when it is activated
and booted (see the “DRD sync” section below for more details.)
If you need to restore the booted system image to be the primary boot path—that is, “undo” the drd
activate command—the drd deactivate command can be used.
After the Clone is Booted
After the clone is booted, a swlist of all software on the system should show all patches as configured.
Any configure errors are documented in the usual SD location:
/var/adm/sw/swconfig.log.
When the clone is booted, the original system is now inactive, and may be mounted by executing the
drd mount command. The mount point of the root file system of the original system is:
/var/opt/drd/mnts/sysimage_000.
If application testing shows the newly booted clone to be unacceptable, the system administrator can
use drd activate -x reboot=true to return to the original system.
Best Practices
The Best Practices below describe the high level steps required to complete a task, followed by
Additional Considerations to add more detailed information to tasks when needed. This allows the
reader to get a complete picture of the steps required to perform a task, with supporting information
provided to add clarity.
Each Best Practice begins with the creation of a clone, which was discussed in detail in the previous
section. Note that after a disk created by the drd clone command is booted, the original system
becomes an offline system image, and it can be manipulated using the drd runcmd, drd mount,
drd umount and drd activate commands. In the Best Practices that follow, references to
“inactive system image” or “inactive image” refer to the copy of the root volume group that is not
currently booted. It might be a clone, or, when the clone is booted, it might be the original system
image.
Best Practice 1 (BP1): Basic Maintenance - Patching
The most common benefit of a clone created by a drd clone command is to minimize the downtime
needed to perform proactive maintenance, and this best practice will focus on applying patches. For
this scenario, our setup is as follows:
Original image: /dev/disk/disk1
Clone disk: /dev/disk/disk5
Patches to apply: Quality Pack Patch bundle plus PHCO_77777
Depot with Quality Pack and PHCO_77777: depot_svr:/var/depots/1131
Objective: Perform maintenance on my server while minimizing downtime.
BP1: Overview of steps
1. Create the clone: drd clone –t /dev/disk/disk5