IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
     Home      Products      Services & solutions      Support & downloads      My account     
  IBM Wikis > AIX > ... > AIXV53AdminBestPractice > AIXV53Backup
AIX Log In | Sign Up   View a printable version of the current page.
AIXV53Backup
 Browse Space
Added by Steve Pittman, last edited by Steve Pittman on Mar 26, 2008  (view change)
Labels: 
(None)

AIX V5.3 backup and restore

This web page is intended to discuss ways of backing up and restoring the AIX rootvg. Given that AIX will not boot if the rootvg is badly damaged, rootvg backups must be restored by a process which is able to boot independently of the rootvg (eg, a boot image on tape).

The contents of this web page solely reflect the personal views of the authors and do not necessarily represent the views, positions, strategies or opinions of IBM or IBM management. Please use the Add Comment link at the bottom of the page to provide feedback. Note: Until you sign up and log in (using links in the upper right corner of this web page), you will not see the Add Comment link and you can not add a comment.

Bootable AIX rootvg backups are typically captured using the AIX mksysb command, or a bare metal restore option such as IBM Tivoli Storage Manager for System Backup and Recovery (formerly known as SysBack) or SBAdmin from Storix. (Using mksysb and/or TSMSBR with Network Installation Management (NIM) can provide additional flexibility.)

Note: According to the IBM Software on-line catalog, a IBM Tivoli Storage Manager for System Backup and Recovery Managed Processor License + SW Maintenance 12 Months (D521YLL) will cost $295 per server (as of 12/1/2006). And rumor has it that if one downloads the latest PTF (from the TSMSBR web page, follow the Technical support link on the left, then the link to Latest PTF for ITSM System Backup and Recovery ( SysBack ) 5.6 Users in the center), one will be able to install and use SysBack for 60 days before it fails due to lack of a license.


It is especially important to capture a bootable backup periodically while building and testing a new server. Capturing a new rootvg backup is recommended each time the AIX configuration is changed and before making significant AIX changes. For example, the IBM AIX 5L Operating System Service Strategy Details and Best Practices document (downloadable from the Service and support best practices for UNIX servers web page) says:

"Technology Levels Must be Applied as a Unit The rule has been changed that previously allowed applying individual updates/PTFs from a TL. The rule now says that installing a Technology Level is an "all or nothing" operation. Requisites are now added so the whole Technology Level is installed. Before applying a TL, you should always create a backup and plan on restoring that backup if you need to rollback to your previous level."

There are several ways to rollback to a previous AIX level. To rollback with a reboot, update AIX to the new Technology Level using alt_disk_install or the new multibos function shipped with AIX V5.3 Maintenance Level 3. To rollback with a restore, create a backup (mksysb) to a NIM server or to bootable media (CD, DVD, or tape) before updating AIX to the new Technology Level.

For more information on AIX backup options, see:

  1. the Backup methods chapter in the AIX V5.3 Operating system and device management manual,
  2. the Backing Up the Operating System in AIX 4 and 5 Technote,
  3. the Back up and restore your AIX system, Part 1: The when, why, and how of backing up IBM developerWorks tutorial,
  4. the Back up and restore your AIX system, Part 2: Implementing your backup strategy and restoration processes IBM developerWorks tutorial, and
  5. the Backing Up and Restoring Your AIX System white paper.

Note: Access to the IBM developerWorks tutorials requires an IBM ID. Registering for an IBM ID is quick and easy.

Backup options which might not work as expected

  • A mksysb command backs up only those filesystems in the root volume group which are mounted when mksysb runs.

  • As stated in the Backing Up the Operating System in AIX 4 and 5 Technote cited above, "The IBM AIX UNIX differs from other UNIXs because of two main features: the Object Database Manager (ODM) and the Logical Volume Manager (LVM). Due to the ODM and the LVM, as well as the ability to have multiple volume groups, a complete system archive made with cpio or tar will not restore properly."

  • Mirroring - AIX LVM mirroring (RAID-1) is in the base operating system. The AIX rootvg can be mirrored, but please note that if a new logical volume is added to a mirrored volume group, the new logical volume is not mirrored! (Use the mklvcopy command to mirror a single logical volume. Use the migratepv command to move parts or all of a logical volume to a different physical disk in preparation for mirroring. An AIX logical volume can be mirrored or moved elsewhere while it remains in use.) Mirroring can protect against disk failures, but can not protect against other sources of damage (eg, accidentally erasing a crucial file, file data corruption due to a software failure, etc). If AIX won't boot due to corruption of the AIX rootvg, any attempt to recover (which may or may not succeed) will require bootable media at the same Technology Level as the operating system to be recovered. When mirroring a volume group to only two disks, disable the quorum mechanism for the volume group to create what is known as a nonquorum volume group. (The mirrorvg command disables quorum by default.) Please note that while a nonquorum volume group will stay varied on if a disk fails, a two-disk volume group can not be varied on without the force option unless the disk with two VGDAs is available.

  • FlashCopy and similar LUN copy services (eg, EMC TimeFinder or HDS ShadowImage) from other data storage vendors - Care must be taken when capturing a FlashCopy image of a mounted AIX JFS or JFS2 filesystem. Consistency groups or the freeze/thaw options of the AIX chfs command must be used to capture a copy of the mounted filesystem and its JFSLOG/JFS2LOG at the same point in time across all LUNs on which the filesystem and log reside. (See the AIX V5.3 Release Notes for more information regarding freeze/thaw.) A backup/restore methodology which uses FlashCopy with neither consistency groups nor freeze/thaw against LUNs containing mounted filesystems may be tested and work repeatedly, yet may eventually fail no matter how many times it has been used successfully. The failure will be subtle. The FlashCopy itself will complete without errors. The failure will manifest itself as data corruption. Either the filesystem won't mount (metadata corruption), AIX will later crash or otherwise report errors with filesystem metadata (metadata corruption), or the application will fail when attempting to use the copy (file corruption). Please note that the FlashCopy has functioned correctly, as far as it is able. It is the way in which FlashCopy is used that is flawed. And while use of consistency groups can protect metadata integrity, file data integrity is not protected. File data integrity must be protected by other means (eg, application recovery techniques following restore, AIX freeze/thaw, etc). Please see Clarification of Supported and Unsupported Methodology for Flashcopy Backups of Mounted AIX Filesystems for more information.

  • dd of a logical volume containing a mounted filesystem - As discussed regarding FlashCopy above, metadata and file data integrity can suffer if a copy is not captured at a single point in time. Given the way in which it operates, dd can not possibly capture a copy of a logical volume at a single point in time. A backup/restore methodology which uses dd without freeze/thaw against logical (or physical) volumes containing mounted filesystems may be tested and work repeatedly, yet may eventually fail no matter how many times it has been used successfully. The failure will be subtle. The dd itself will complete without errors. The failure will manifest itself as data corruption. Either the filesystem won't mount (metadata corruption), AIX will later crash or otherwise report errors with filesystem metadata (metadata corruption), or the application will fail when attempting to use the copy (file corruption). Please note that dd has functioned correctly, as far as it is able. It is the way in which dd is used that is flawed. This caveat applies when using dd to clone an AIX rootvg on a VIO Server unless the AIX client LPAR is shut down while the dd is done. This caveat applies when using dd to copy one hdisk to another when the source hdisk contains filesystems which are mounted and not frozen when the dd is run. (Please note that the alt_disk_copy command can be used on a running AIX system to capture a copy of rootvg to a spare disk outside of rootvg.)

  • dd from and back to a raw logical volume - Using dd to restore a raw logical volume will overwrite the logical volume control block which, according to the LVCB warnings article, is in the first 512 bytes of the logical volume. In most circumstances, it is undesirable to overwrite the LVCB. The command dd if=/dev/r$lvname /nas/$lvname.dd bs=1m will work fine to back up a raw logical volume, provided the physical partition size is a multiple of 1m. To restore the entire raw logical volume except for the LVCB use: 
    lvname=lv03					# Name of logical volume which was backed up
lvsize=$(wc -c /nas/$lvname.dd | awk {'print $1'})	# Size of file to which LV was backed up
lvcbsize=512					# Size (in bytes) of logical volume control block
((ddblksize=1024*1024))				# Block size (in bytes) to use so dd runs reasonably fast
((smlblks=ddblksize/lvcbsize-1))			# Compute number of small blocks to write
((bigblks=lvsize/ddblksize-1))			# Compute number of big blocks to write
dd if=/nas/$lvname.dd of=/dev/r$lvname bs=$lvcbsize seek=1 skip=1 count=$smlblks
dd if=/nas/$lvname.dd of=/dev/r$lvname bs=$ddblksize seek=1 skip=1 count=$bigblks

    The target logical volume must, of course, be exactly the same size as the logical volume which was backed up. It is possible to restore using a single dd command, but then the entire logical volume must be restored using bs=512, which is ssslllooooowwwww.

    As with any new procedure, be sure to carefully test before using in production.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.2.10 Build:#528 Nov 29, 2006)
    About IBM      Privacy      Contact