AIX

 View Only

  • 1.  Using usbms0 for backups

    Posted Mon December 18, 2023 07:30 AM

    Hello,

    I know I can save a mksysb or savevg to /dev/usbms0 as per document https://www.ibm.com/support/pages/using-and-taking-advantage-usb-devices-and-aix#mksysb

    Is it possible to store both the mksysb AND savevg data on the same USB device or will the bootable mksysb be overwritten by the savevg?

    p.s. I would try this but can't get to the system easily to put a USB drive in to test this :-(



    ------------------------------
    Glenn Robinson
    ------------------------------


  • 2.  RE: Using usbms0 for backups

    Posted Mon December 18, 2023 01:15 PM
    Edited by Ron Arms Wed December 20, 2023 02:37 PM

    They would overwrite each other.  Although we treat the RDX similar to tape it's truly a removable hard drive.

    One way to perform what you're looking to do would be if you had a filesystem in rootvg such as /backup  where a savevg is performed of user volume group that writes/saves to the /backup filesystem in rootvg, then the mksysb would capture the savevg file.   Note, the RDX drives are not overly fast so while the RDX makes a great device option for AIX mksysb bootable backups it's not great once you start having a terabyte or more of data.

    Since the RDX is a hard drive it can be mounted as read/write filesystem, just keep in mind as a bootable mksysb so you need to be careful what you're modifying.

    Note:  While you can use SMIT to view contents of mksysb to view contents of a user defined volume group I usually use "lssavevg -f /dev/usbms0 -s".  The smit system backup manager menu's seem to only work for AIX mksysb's.



    ------------------------------
    Ron Arms
    ------------------------------

    Original Message


  • 3.  RE: Using usbms0 for backups

    Posted Tue December 19, 2023 11:55 AM

    You should be able to create a mksysb of your system and then add as many savevgs of any other VGs as space allows.  The mksysb must be first because the first step for mksysb is to format the device/media.

    First do a mksysb to the usb device using the mksysb options of your choice.  Mksysb wipes out the current device content because mksysb formats the device as a UDFS file system.

    Once the mksysb to the device is complete, manually mount the USB device and you should see a typical AIX file system.  This is just enough AIX to boot from the USB device and perform a restore of rootvg.  The actual rootvg backup file if I remember correctly is under /usr/sys/inst.images.  The bacukp file is really just a customized file list from rootvg fed to the the backup command. 

    Pick a location for your savevg(s) files on the mounted USB device.  Create directories if desired.  Run savevg on each vg and outputting the savevg to a file on the usb device.

    To restore rootvg, boot from the USB and restore rootvg using options of your choice.  Once rootvg is restored, boot from the restored system, mount the USB device and restore the remaining savevgs as needed using typical restore vg procedures.

    Our environement has a number of remote AIX servers with a fairly small disk footprint leaving a lot of available space.  We also have mirrored or raided disks so a single disk failure doesn't force a recovery.  Rather than make a mksysb to USB device, we create a mkssyb file to an excluded local directory/file on each system.  We then transfer a copy of that mksysb backup file to another storage location typically in a different facility to provide an offsite backup.  Should a full system recovery be required, the remote mksysb copy is used to create a bootable mksysb USB from an existing mksysb file and then the bootable USB is used to restore the failed system.  The one requirement when making the USB recovery device is that the system on which the recovery USB is created must be at the same or higher AIX level.  This is becasue the bootable part of the recovery device is made from the running AIX, not from the content of the mksysb backup.   Does this sound like a poormans backup system?  That's exactly what it is.  HMC, NIM etc can all play a role if you have them.  

    One large advantage of the disk saves and only create USB as needed is not having to manage USB sticks inserting them into servers for backup.  This method can be automated with a few scripts such that no manual intervention is required unless recovery is required.  Downtime for backup is minimal.  The copy to remote storage doesn't have to be done during the backup period. etc. etc.

    Jim



    ------------------------------
    Jim Rinn
    ------------------------------

    Original Message


  • 4.  RE: Using usbms0 for backups

    Posted Tue December 19, 2023 06:08 PM

    Jim,

    Thanks a lot, that helps a great deal.

    I am also implementing the copy of mksysb ISOs to a remote site so that I can use DD to copy to USB as required.

    Glenn 



    ------------------------------
    Glenn Robinson
    ------------------------------

    Original Message


  • 5.  RE: Using usbms0 for backups

    Posted Wed December 20, 2023 10:33 AM

    We've used the RDX USB media for years in this fashion...

    Run the mksysb to the device, then run multiple savevg's to the same device.

    This has worked well at several sites for several years, from AIX 6.1 into current releases...

    However, our experience is that the media, although reportedly bootable, can't be booted to restore/load the mksysb.

    We recently attempted an AIX 7.2 upgrade from AIX 7.1; we had issues with the upgrade and could not boot/recover from the RDX media. Which required a manual rebuild, as we did not have bootable AIX media for our 7.1 installation.

    Your mileage may vary, and I hope it does, for the better.



    ------------------------------
    Bob Wyatt
    ------------------------------

    Original Message


  • 6.  RE: Using usbms0 for backups

    Posted Mon November 11, 2024 11:59 AM

    Using RDX USB media for mksysb and savevg backups in AIX environments is a common approach, but as you've experienced, RDX devices can present bootability issues, especially during critical operations like system recovery or upgrades. 

    Create a Separate Bootable Media:

    • Since the RDX device isn't reliable for booting, consider creating separate bootable media (such as a DVD, bootable USB, or a network boot image) specifically for AIX 7.2. This will allow you to boot into a recovery environment and then restore from the RDX device if needed.
    • To create a bootable USB, use the mkdvd or mkboot commands with the appropriate device. Ensure you have a bootable ISO image as a fallback.


    ------------------------------
    Saif Sabri
    ------------------------------

    Original Message


  • 7.  RE: Using usbms0 for backups

    Posted 23 days ago

    This is precisely what we did after the pain and embarrassment of not being able to go back.

    What we do now is:

       Attach a USB thumb drive to a USB port.

       Create the mksysb, and verify the image file in /usr/sys/inst.images created on the thumb drive.

        At a schedule convenient to you, schedule some downtime and attempt a boot from the thumb drive.

    This has worked flawlessly thus far.

    You can (and probably should) still keep a mksysb as a part of your backup plan that meets your backup needs and scheduling. Thumb drives have a way of disappearing on even the best intention of the administrative team.

    Savevg's do not overwrite or destroy the mksysb data. We typically specify that the savevg image files are saved in the root directory on the RDX drive, but there is probably some value in creating a subfolder for the savevg images to prevent the unknown from striking (that may be why we couldn't boot when it was acutely needed). You will need to be conscious of where your map files are written when you put multiple savevg's on one RDX drive; if you can get by without a map file, great...

    Lastly, every mksysb or udfcreate operation you make to an RDX drive wipes out - loses - the drive contents. You may choose to make alternate storage arrangements once completed for the savevg's and mksysb image files if you desire or need to preserve them longer than your RDX drive rotation schedule. We happen to have a client that rotates a drive in for a week - it will collect a mksysb and 5 nights worth of savevg's. The problem with this is not only the retention schedule for the RDX drives, but whether this meets your auditing or retention policies.



    ------------------------------
    Bob Wyatt
    ------------------------------

    Original Message


  • 8.  RE: Using usbms0 for backups

    Posted 22 days ago
    One way to avoid the challenges of USB sticks and devices most of the time.

    In our environment the servers are in geographically separated locations (cities in this case), what we do is avoid the whole USB process at backup time by running the mksysb to a file.  What this does is create the mksysb image file on a local hdd rather than push it to the USB device at backup time.  Our servers a small and have only rootvg so we store the image into an mksysb excluded directory in rootvg so as not to save the save.  We gzip the image file to save some space but it's not necessary.

    The image file is then copied (ftp, sftp, rsync, etc) to a geographically remote server and we're done.   We leave the image file on the local server just in case we need to restore a file.  We also keep multiple image files (weekly) automatically removing them after a few weeks both locally and remotely.  Choose a retention cycle that meets your needs and disk space.  We even go so far as to put the copies on different remote servers. 

    If/When a restore is needed, we make a USB stick to do the restore.  Any system with the same or higher oslevel can create the USB stick.  Transfer the desired image file to the system where the USB stick is to be built and unzip it  if zipped.  Run mksysb using the 'from an existing image' option.  This  will create the bootable portion from the local AIX system and then copy the mksysb image to the image directory.  This stick is now the same as a mksysb that was made directly to the USB.  

    Jim



    Original Message