BigAdmin System Administration Portal
Feature Article
Print-friendly VersionPrint-friendly Version

Backup, Restore, and Disaster Recovery on a System With Zones Installed

Penny Cotten, November 2005 (reviewed November 2006)

Backup, restore, and disaster recovery are critical elements of data management. When you use zones, the requirements of your organization will dictate the solution you choose to back up your system running the Solaris Operating System (OS).

Backing up file systems means copying file systems to removable media, such as tape, to safeguard against loss, damage, or corruption. Restoring file systems means copying current backup files from removable media to a working directory.

Although written in November 2005, this article was reviewed for accuracy in November 2006. This document discusses various methods for backing up zone configurations and data on your system, and provides recommendations on the different methodologies that can be used.


Determining Where to Perform the Backup

You can perform backups in individual non-global zones, or you can back up non-global zones from the global zone.

Backing Up LOFS Directories

Because many non-global zones share files with the global zone through the use of loopback file system read-only mounts (usually /usr, /lib, /sbin, and /platform), it is important to use a global zone backup strategy to back up LOFS directories. Backing up the LOFS file systems in non-global zones is not advisable. Restoring in this situation will be impossible, and any attempt by the non-global administrator to do so could cause a serious problem.

Backing Up Your System From the Global Zone

You might choose to perform your backups from the global zone if:

  • You have network backup software such as Symantec/VERITAS NetBackup.

  • You want to back up the configurations of your non-global zones as well as your application data.

  • Your primary concern is disaster recovery. If you need to restore everything or almost everything on your system, including the root file systems of your zones and their configuration data as well as the data in your global zone, it is best to use the global zone as the point where the backup takes place.

  • You want to use ufsdump to perform a data backup. Because importing a physical disk device into a non-global zone would change the security profile of the zone, ufsdump should only be used from the global zone.

Backing Up Individual Non-Global Zones on Your System

You might decide to perform your backups within the non-global zones if:

  • Non-global zone administrators want to back up the data in the zones they administer so that they can recover from less serious failures or restore application or user data specific to a zone.

  • You want to use programs that back up on a file-by-file basis, such as tar(1) or cpio(1).

  • You use the backup software of a particular application or service running in a zone. It might be difficult to execute the backup software from the global zone because application environments, such as directory path and installed software, would be different between the global zone and the non-global zone.

    If the application can perform a snapshot on its own backup schedule in each non-global zone and store those backups in a writable directory exported from the global zone, the global zone administrator can pick up those individual backups as part of the backup strategy from the global zone.


Summary of Zone Backup Methods

The following sections summarize methods that can be used to back up files in zones.

Using ufsdump to Perform Backups

You can perform full or incremental backups using the ufsdump command. This procedure backs up the zone /export/zone1 to /backup/zone1.ufsdump, where "zone1" is replaced with the name of a zone on your system.

1. (Optional) You can shut down the zone before using the ufsdump command, to put the zone in a quiescent state and avoid backing up shared file systems.

global# zlogin -S zone1 init 0

2. (Optional) Check the zone's status.

global# zoneadm list -cv

ID NAME     STATUS       PATH
0 global    running      /
- zone1     installed    /export/zone1

3. Perform the backup.

global# ufsdump 0f /backup/zone1.ufsdump /export/zone1

DUMP: Date of this level 0 dump: Wed Aug 10 16:13:52 2005
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rdsk/c0t0d0s0 (bird:/) to /backup/zone1.ufsdump.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 63 Kilobyte records
DUMP: Estimated 363468 blocks (174.47MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 369934 blocks (180.63MB) on 1 volume at 432 KB/sec
DUMP: DUMP IS DONE

4. Boot the zone.

global# zoneadm -z zone1 boot

Creating a UFS Snapshot Using fssnap

This approach uses the fssnap command, which creates a temporary image of a file system intended for backup operations.

This method can be used to provide a clean, consistent backup of the zone files only, and it can be executed while zones are running. However, it is a good idea to suspend or checkpoint active applications that are updating files when the snapshot is created. An application updating files when the snapshot is created might leave these files in an internally inconsistent, truncated, or otherwise unusable state.

In the example procedure below:

  • There is a zone named zone1 under /export/home.
  • /export/home is a separate file system.
  • The destination backup is /backup/zone1.ufsdump. You must create /backup before you begin.

1. Create the snapshot:

global# fssnap -o bs=/export /export/home

/dev/fssnap/0

2. Mount the snapshot.

global# mount -o ro /dev/fssnap/0 /mnt

3. Back up zone1 from the snapshot.

global# ufsdump 0f /backup/zone1.ufsdump /mnt/zone1

DUMP: Date of this level 0 dump: Thu Oct 06 15:13:07 2005
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/rfssnap/0 (bird:/mnt) to /backup/zone1.ufsdump.
DUMP: Mapping (Pass I) [regular files]
DUMP: Mapping (Pass II) [directories]
DUMP: Writing 32 Kilobyte records
DUMP: Estimated 176028 blocks (85.95MB).
DUMP: Dumping (Pass III) [directories]
DUMP: Dumping (Pass IV) [regular files]
DUMP: 175614 blocks (85.75MB) on 1 volume at 2731 KB/sec
DUMP: DUMP IS DONE

4. Unmount the snapshot.

global# umount /mnt

5. Delete the snapshot.

global# fssnap -d /dev/fssnap/0

Note that the snapshot is also removed when the system is rebooted.

Using find and cpio to Perform Backups

The following method uses find and cpio on a running zone.

1. Change directories to the / directory:

global# cd /

2. Back up zone1 files that are not loopback mounted to /backup/zone1.cpio.

global# find export/zone1 -fstype lofs -prune -o -local | 
  cpio -oc -O /backup/zone1.cpio

3. Verify the results.

global# ls -l backup/zone1.cpio

-rwxr-xr-x 1 root root 99680256 Aug 10 16:13 backup/zone1.cpio

Using Network Backup Software to Back Up and Restore Your System

You can use a product such as Symantec/VERITAS NetBackup to back up or restore your Solaris system. Symantec/VERITAS NetBackup enables enterprise-wide coordination of backups, archives, and restores. A description of NetBackup support for Solaris 10 systems with installed zones is available at http://seer.support.veritas.com/docs/275107.htm.

The NetBackup client software is supported in a non-global zone. The NetBackup master server and media server are supported in the global zone. The NetBackup master server manages backups, archives, and restores. Media servers provide additional storage by allowing NetBackup to use the storage devices that they control, such as 4-mm tape drives.

You can restore entire systems or specific files and directories. NetBackup locates the selected files and directories and restores them to the disk on the client.

You do not have to change standard NetBackup architecture to apply it to a system with zones installed. You can treat each non-global zone as though it is a standalone server running the NetBackup client software.

The backup should be performed when the zone and its applications have quiesced the data to be backed up.

Note: Your network backup software should be configured to skip all inherited LOFS file systems if possible.

Tip: If you would like to consolidate servers or take advantage of the higher-network bandwidth between non-global zones on the same system as compared to wired networks, you can also co-locate the media server on the same system. The connection between the server and the storage device must have sufficient bandwidth for all backup streams.

Complete documentation for Symantec/VERITAS NetBackup products is available at:
http://www.sun.com/products-n-solutions/hardware/docs/Software/Storage_Software/VERITAS_NetBackup/index.html


Determining What to Back Up

You can back up everything in the non-global zone, or, because a zone's configuration changes less frequently, you can perform backups of the application data only.

Backing Up Application Data Only

If application data is kept in a particular part of the file system, you might want to perform regular backups of this data only. The zone's root file system might not have to be backed up as often because it changes less frequently.

Determining where an application places its files might prove more difficult than it would appear. Some files are stored in each user's home directory, some files are stored under /etc (mostly configuration data), and other files are kept under /var.

Assuming the application administrator knows where the data is stored, it might be possible to create a system in which a per-zone writable directory is made available to each zone. Each zone can then store its own backups, and this location can be used by the global administrator as one of the places on the system to back up.

General Database Backup Operations

If the database application data is not under its own directory, the following rules apply.

  • Ensure that the databases are in a consistent state first. Databases must be quiesced because they have internal buffers to flush to disk. Make sure the databases in non-global zones have come down before starting the backup from the global zone.
  • Within each zone, use file system features to make a snapshot of the data. Back up the snapshots directly from the global zone. This will minimize elapsed time for the backup window and remove the need for backup clients/modules in all of the zones.

Tape Backups

Each non-global zone can snapshot its private file systems when it is convenient for that zone, when the application has been briefly quiesced. Later, the global zone can back up each of the snapshots and put them on tape after the application is back in service.

This method has the following advantages:

  • It minimizes the number of tape devices needed.
  • There is no need for coordination between the non-global zones.
  • It doesn't require assigning devices directly to zones, which improves security.
  • Generally, it leaves system management in the global zone, which is preferred.

About Restoring Non-Global Zones

In the case of a restore where the backups were done from the global zone, the global administrator can reinstall the affected zones and then restore that zone's files. Note that this assumes:

  • The zone being restored has the same configuration as it did when the backup was done.
  • The global zone has not been upgraded or patched between the time when the backup was done and the time when the zone is restored.

Otherwise, the restore could overwrite some files that should be merged by hand.

For example, there could be a need to merge files by hand in the case of a global zone that has been subsequently patched after the backup, but prior to the restore of the non-global zone. In this case, you would have to be careful when restoring a zone's files that were backed up since a backed up file might not be compatible with the newly installed zone that was built after the patches were applied to the global zone. In this case, you would have to examine the files individually and compare them to the copies in the newly installed zone. In most cases, you will find that the file can be copied directly in, but in some cases, you must merge the changes originally made to the file into the newly installed or patched copy in the zone.

Note: In the case of a catastrophic loss of all file systems in the global zone, restoring everything in the global zone restores the non-global zones as well, as long as the respective root file systems of the non-global zones were included in the backup.

Backing Up Individual Zone Configurations for Future Use

You should make copies of your non-global zones' configurations in case you have to recreate the zones at some point in the future. You should create the copy of the zone's configuration after you have logged into the zone for the first time and responded to the sysidtool questions.

You can print the configuration of each zone to a file as shown below.

1. Become superuser, or assume the Primary Administrator role.

2. Print the zone configuration for a zone named zone1 to a file named zone1.config.

global# zonecfg -z zone1 export > zone1.config

How to Restore Individual Non-Global Zones

To restore a non-global zone from a file created with the zonecfg export command, use the following procedure.

1. Become superuser, or assume the Primary Administrator role.

2. Specify that zone1.config be used as the zonecfg command file when recreating the zone:

global# zonecfg -z zone1 -f zone1.config

3. Install the zone:

global# zoneadm -z zone1 install

4. To prevent the system from displaying the sysidtool questions asked upon initial zone log in, delete the file zonepath/root/etc/.UNCONFIGURED. For example:

global# rm /export/home/zone1/root/etc/.UNCONFIGURED

For more information about the sysidconfig(1M) questions asked the first time you log in to a non-global zone, see "Performing the Initial Internal Zone Configuration" in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

5. (Optional) Manually restore (and possibly hand-merge) files such as application data backups into the newly created zone's file system.


References

Discuss and comment on this resource in the BigAdmin Wiki


Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.


BigAdmin
  
 
 
 
 
Would you recommend this Sun site to a friend or colleague?
Contact About Sun News & Events Employment Site Map Privacy Terms of Use Trademarks Copyright Sun Microsystems, Inc.