How do I back up virtual media?

Here’s how it works: Backups are made locally on the IFS, then the file is exported from the IFS to remote storage or to the cloud.

Backups are made locally on the IFS. Once the backup is complete, the IFS file is exported to remote storage or to the cloud.

Preparation is very similar to loading PTFs: an image catalog (*IMGCLG) is mounted on an IFS directory, and this catalog is loaded onto a virtual backup device (*DEVD).

This device can have the attribute “OPT” for a virtual DVD drive (PTFs, *SAVSYS) or “TAP” for a virtual tape drive (*ALLUSR backups).

As backups are exported, it is essential to keep track of them. This is why BRMS or third-party products are most often used, in order to avoid heavy and difficult-to-maintain development work for virtual tape tracking.

 

There are several possibilities:

• Fully manual management (CRTDEVTAP / CRTDEVOPT, IFS directory, *IMGCLG)
• Semi-manual management with BRMS (transfers and uploads “by hand”, then backups/restores via BRMS)
• BRMS interfaced with IBM Cloud Storage Solutions for i (IBM licensed product: 5733ICC)
• Third-party software (non-IBM)

 

For simplicity’s sake, I’ll refer to IBM Cloud Storage Solutions for i as “ICC”, from the IBM product code.

• Are my PTFs up to date?

In particular, for ICC, check the BRMS PTFs.

For other third-party solutions, please refer to the publisher’s documentation.

For other solutions, the latest Technology Refresh and the latest cumulative version should suffice.

 

• On which remote media can I save?

For ICC, IBM has validated the smooth operation of exchanges with the Clouds (IBM, Amazon and Google) via their respective protocols, but also by FTP to AIX or Linux Redhat.

Other types of storage potentially work, but have not been tested by IBM. Backups and, above all, restorations need to be tested. We don’t recommend using FTP transfers to a TrueNAS, precisely because of the restoration problems we’ve encountered.

However, it is also possible to store backups on non-IBM-approved media: create a directory for storing backups on non-IBM-approved media (e.g. TrueNAS), mount an NFS share pointing to this directory on IBM-approved media (e.g. AIX), and define an ICC resource (backup transfer target) with the NFS share pointing to non-IBM-approved storage as the receiving root directory.

Finally, some hardware can also “emulate” an IBM i-style Cloud environment. For example, IBM Spectrum Protect can emulate an Amazon Cloud (AWS) environment at ICC.

For other types of external storage, please refer to the publisher’s documentation or recommendations.

Finally, for (semi-)manual management, the price, the equipment already available, and the complexity of development will all have to be taken into account in the decision.

 

• Do I have enough disk space on my remote system?

When considering the amount of disk space required, please bear in mind :

• different types of backups (daily, monthly, one-off, etc.)
• the various IBM i backups
• retention of each backup
• the frequency of each type of backup
• compression (never compression for *SAVSYS!)
• the potential increase in partition disk occupancy over time
• price (in the context of a Cloud)

 

• What type of transfer should I use?

The type of transfer to be used naturally depends on the type of storage.

Depending on the third-party solution chosen, please refer to the documentation or recommendations provided by the publisher.

Publishers always offer FTP, but there are other, more modern and/or more secure types of transfer, such as RSYNC.

ICC currently offers 3 protocols: AWS S3, IBM SoftLayer, and FTP.

Each of these transfer types supports encryption, security and compression.

For the Spectrum Protect emulation example, the transfer used will be secure Amazon S3.

 

• Do I have enough free disk space locally?

Indeed, before transferring to remote storage, backups are first carried out locally, in the IFS. Most of the time, therefore, you need to ensure that your disk occupancy is below 50%.

In the case of ICC, the space available may be much less, as tapes are sent as they are backed up. Of course, the number and size of bands generated by BRMS will have to be adapted.

With or without ICC, it is still advisable to place your backups in an iASP. In fact, if communications between the IBM i being backed up and the remote storage are interrupted, the iASP will fill to capacity, but will never “overflow” onto the system ASP. And, with iASP, there’s no need to limit system ASP to below 50% occupancy!

 

• If I choose to use an iASP, how do I manage it?

As mentioned above, iASP is not mandatory, only recommended. Of course, it all depends on the technical architecture already in place (do we have enough disk space to allocate part of it to iASP?). If you choose to use it, first make sure you configure it properly:

1. The first step is to present the future iASP disks to the IBM i partition. Once the disks are visible, the CFGDEVASP ASPDEV(nom_iasp) ACTION(*CREATE) command is used to select the disks to be added to the iASP.
2. The iASP is created in a stopped state, so it must be started. Please note that the iASP must remain running for the duration of the backup AND transfer operation. You can check the iASP status with the WRKCFGSTS CFGTYPE(*DEV) CFGD(*ASP) command and start it with the VRYCFG CFGOBJ(nom_iasp) CFGTYPE(*DEV) STATUS(*ON) command. Don’t forget to start the device in the start-up program too, so you don’t get caught out after an IPL!
3. Once the iASP has been started, it needs to be presented to the chosen software solution, if applicable. In the case of Cloud Storage Solution, both BRMS and ICC need to be aware of this new iASP. BRMS only requires a reset, the option with the least impact is: INZBRM *DATA. ICC requires an additional order to be submitted, from the BRMS “Swiss Army knife” program: QBRM/Q1AOLD.

• What tape format do I need?

For manual management, the size of the tapes is free (max. 1 TB), but please note the available disk space.

Virtual DVD formats are more limited: the largest is *DVD4700 (4.7 GB).

The ADDIMGCLGE command adds a tape or DVD to the image catalog.

You’ll need to calculate the number of volumes required for backups (and in particular the number of DVDs required for *SAVSYS).

Once again, ICC uses the QBRM/Q1AOLD program to set the size of the bands automatically generated by BRMS. New tapes will be created by BRMS as soon as the last available tape is selected for backup. The number of bands therefore has little impact.

Indeed, by default, in BRMS and natively, a blank tape takes up virtually no disk space, whatever the defined size or format of the volumes.

 

• Can I save my system and microcode on virtual media?

Disc-based *SAVSYS are indeed possible, but only on virtual DVDs. However, these backups cannot be compressed or encrypted. In order to restore a complete OS from these DVDs, you need to be able to “mount” them. You need to burn the virtual media onto a physical medium readable by the IBM i, or mount it on a VIOS virtual drive associated with the IBM i, if possible.

However, as the restricted state (mandatory for a *SAVSYS) can complicate the backup, it is not systematic that the *SAVSYS is supported by the backup solution vendor.

In the case of ICC, the solution is capable of raising an IP address while keeping the restricted mode active. Once again, the QBRM/Q1AOLD program is used to define the IP address to be sent by BRMS. The documentation reminds you that certain IBM libraries must be backed up with *SAVSYS, as they will be used for data restoration (system libraries + BRMS + ICC + encryption and compression libraries, etc.).

 

• How do I perform a SAVE21 on disks?

In native mode, you need to program a *SAVSYS on DVD (without compression!) followed by a *NONSYS backup on tape (compression possible), while maintaining the restricted mode.

Tapes cannot be sent during backup, so transfers must be launched ALL at the end of the backup. It is therefore essential to keep at least 50% of disk space free, or to define an iASP.

As mentioned earlier, if *SAVSYS is impossible, then so is SAVE21. Simply refer to the publisher’s documentation, or ask them directly if *SAVSYS is supported.

ICC breaks down SAVE21 into 2 parts: the *SAVSYS, and the backup of the rest of the data (*NONSYS).

On a system where SAVE21s are to be run on virtual media, there must be at least 2 ICC resources, 2 media strategies, 2 media locations and 2 control groups. It’s then easy to identify the SAVE21 of daily newspapers.

 

• What do I need to check before using the solution?

Whatever solution you choose, don’t forget about maintenance and operation.

This involves planning (watch out for the *JOBQ in the context of a SAVE21!) commands for backup, maintenance, and possibly starting and stopping subsystem(s) or releasing JOBQs, as well as including the various commands in the startup program.

For solutions packaged by a publisher (including IBM), you’ll also need to make sure that your software support is up to date, and that your license is correctly filled in.

For ICC, the solution is an IBM-licensed product (5733ICC), whose licenses are applied to the partition, not the machine. As the solution is still in its infancy, the possibility of creating a ticket at IBM may be absolutely essential.

 

• What price am I willing to pay if I choose a vendor’s “packaged” solution?

The price of the solution is often the main parameter in the final choice. Don’t forget to factor maintenance into the cost of ownership, as well as the cost of time spent operating the solution (for in-house developments)!

If you have any further questions, or would like more information on the subject, armonie can help you with your project.