Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. Veritas NetBackup™ Bare Metal Restore™ Administrator's Guide
  3. Appendix A. NetBackup BMR related appendices
  4. Solaris zone recovery support
Veritas NetBackup™ Bare Metal Restore™ Administrator's Guide

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

  1. 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.

  2. 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 Mount at boot field set to No. 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=ufs

    Then 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.

Feedback

Was this page helpful?
Previous

About ZFS storage pool support

Next

BMR client recovery to other NetBackup Domain using Auto Image Replication

Feedback

Was this page helpful?