Solaris zone recovery support
When using BMR to back up and restore Solaris Zones, you need to address some unique considerations.
Bare Metal Restore can restore a Solaris system running Zones. Although BMR cannot restore individual non-global zones, all non-global zones in a system are re-created as part of the global zone restoration. If global and non-global zones are based upon ZFS filesystems, then user does not require to do the 'vfstab' configuration."
To restore all non-global zones in a dissimilar disk restoration scenario
- Remap the file system that hosts the zone (also known as zone path) to restore the zone files.
If a non-global zone imports slices from the global zone that are not remapped, BMR removes the slices from the zone configuration.
If a non-global zone imports slices from the global zone that are remapped to different disks, BMR readjusts the zone configuration and any zone vfstab (ZONEPATH/root/etc/vfstab) entries to use the new device names.
If a non-global zone imports systems from the global zone file that are not remapped, BMR removes any references to them in the zone configuration.
- Test
You may have to re-create and restore all file systems imported or used by a non-global zone after BMR restoration. These file systems usually don't appear in the global zone vfstab (/etc/vfstab).
BMR relies on entries in /etc/vfstab to document the file systems that are subject to restoration. Dynamically-created and mounted file systems that do not appear in /etc/vfstab (even if backed up by NetBackup) do not automatically restore. The easiest way to force BMR to restore such file systems is to add an entry to /etc/vfstab that documents the devices and mount points used, with the field set to . Then, the dynamic file systems can continue to be used as before. BMR is aware of them, recreates them unless unmapped in DDR, and restores their contents if backed up by NetBackup.
Zone features cause dynamically mounted file systems to appear, as follows:
FS entries that involve devices in the global zone.
Device entries imported from the global zone but mounted either by the /etc/vfstab of the non-global zone, or dynamically by the zone itself.
To automate BMR zone restoration, Add entries to the global zone /etc/vfstab that cause BMR to restore them (unless unmapped by DDR), as follows:
For FS entries, the global zone devices are used as special and raw values with a mount point that appears under the root of the non-global zone. The entry to add to the global zone's /etc/vfstab should use the global zone's device paths with the full path to the non-global zone mount point, including the zone path. For example, if the zone looks like:
zonepath=/export/zone1 fs: dir=/export special=/dev/dsk/c0t9d0s6 raw=/dev/rdsk/c0t9d0s6 type=ufsThen the global zone entry in /etc/vfstab should be as follows:
/dev/dsk/c0t9d0s6 /dev/rdsk/c0t9d0s6 /export/zone1/root/export ufs - no -
For device entries mounted by the non-global zone, the following issues must be dealt with when you configure for BMR restoration:
The dynamic mount that is used involves the imported device path under the zone path. For a device that is mounted by /etc/vfstab inside a non-global zone, there are one or more device entries in the zone, such as the following:
zonepath=/export/zone2 device: match=/dev/*dsk/c0t0d0s4
The devices that are listed are in the non-global zone's /etc/vfstab as follows:
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /local ufs - yes -
This command causes the global zone to dynamically mount.
/export/zone2/dev/dsk/c0t0d0s4 on mount point
/export/zone2/root/local. However, to make BMR automatically recreate the file system, you should add the documenting entry to the global zone /etc/vfstab instead as follows:
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /export/zone2/root/local ufs - no -
(If you use the device paths relative to the zone path, BMR only recreates the mount point instead of restoring the whole file system.)
The device match should not use wildcards to allow BMR to edit if DDR is used. When the device specification involves a wildcard, if DDR mapping is done that affects the zone (for example, if you unmap or move a file system from one disk to another), BMR is not able to edit the entry. The affected zone's /etc/vfstab is edited, but the device match entries are edited only if the match does not include a wildcard.
For example, change the following entry:
match=/dev/*dsk/c0t0d0s4
The entry must use two device entries, as follows:
match=/dev/dsk/c0t0d0s4 match=/dev/rdsk/c0t0d0s4
If the entries are changed as the example shows, BMR DDR correctly updates the zone definitions and vfstab file.