Backing Up the System i to NAS
by Stephen West

Originally published in System iNEWS Magazine, September 2010

As a small AS/400 shop (actually a company of one), I'm always striving to simplify, automate, save time, and save money. So when the cost of Network Attached Storage (NAS) devices dropped to an affordable level, I couldn't resist purchasing one of these new toys. I rationalized that I could back up my PC's to it. While setting up my PC's for backup to the NAS, I thought I could probably mount a drive to the AS/400 and write a program to save all my libraries to the NAS. This turned out to be easy. Let me tell you how I did it.

I purchased an HP Media Vault, which came with a 500 GB drive. And yes, you can mount a drive to the Media Vault from an AS/400. I have since added a second 500 GB drive, which I use only for backing up my AS/400.

Setting Up the NAS on the LAN

The setup for the HP Media Vault was simple. I'll leave this step to you, because you might choose one of the many other available NAS devices. Write down the name and IP address that the NAS device will be identified by. Oddly enough the default NetBIOS name is HPMediaVault. No spaces. You'll need this information to map a drive on the System i.

The HP Media Vault supports two types of file sharing standards. The one we'll be using is Network File System (NFS). Most NAS devices will offer the NFS standard.

Mounting a Drive from the System i to the NAS

The command for mapping a drive on the System i is MOUNT or ADDMFS (two commands for the same thing). The first parameter is file system type; it should be set to the special value *NFS.

The second parameter is the mounted file system path. This must be the server address followed by the absolute path to the NFS file share on the NAS device. The server address can be the NetBIOS name or the device's IP address. The absolute path for the HP Media vault is '/shares/Volume1/Backup' for the pre-installed drive.

The third parameter is the local IFS directory on which the NAS device will be mounted. The directory must exist for the MOUNT command to succeed. You can give the directory any name you choose. For this article and the associated code, I use a directory named NAS. You can create the directory by using a command similar to the following:

  
     MKDIR '/NAS'
  

The default value for the remaining two parameters, OPTIONS and CCSID, are acceptable. The System i command will look like the following:

NetBIOS name example:

  
     MOUNT  +
       TYPE(*NFS) +
       MFS('HPMediaVault:/shares/Volume1/Backup/') +
       MNTOVRDIR('\NAS')                              
  

IP address example:

  
     MOUNT  +
       TYPE(*NFS) +
       MFS('192.168.1.75:/shares/Volume1/Backup/') +
       MNTOVRDIR('\NAS')                              
  

Be sure that the NFS Server is running using iSeries Navigator (Network->Servers->TCP/IP->NFS).

Writing Code to Save a Library to the NAS

You can save a library to the NAS by coding three sources. The first is a Save To NAS (SAVTONAS) command that exploits the System i's elegant command-based interface. The second is the Command Processing Program (SAVTONASC), which saves the specified library to a save file (and calls the third program). The third is an RPGLE program (SAVTONASR) that reads from the save file and writes to an IFS file on the mounted NAS drive.

  
     SAVTONAS (CMD) -> SAVTONASC (CLLE) -> SAVTONASR (RPGLE)
  

The Save To NAS command (Figure 1) takes two parameters. The first is a library to be saved; the second is a remote NFS path name. The NFS path name will be passed to the MOUNT command on the MFS parameter. In our example, the value would be HPMediaVault:/shares/Volume1/Backup/. It identifies both the NAS device (HPMediaVault) and the path on the device where data is to be stored (/shares/Volume1/Backup/).

The Command Processing Program (SAVTONASC-Figure 2) takes in the same two parameters and performs several steps. The three most important steps are to create a save file to save the library to, save the library, and call the RPGLE program (SAVTONASR).

Reading records from a save file, then writing the records to a PC file is more easily done using RPGLE. The SAVTONASR program (Figure 3) does just that. Records in a save file are always 528 bytes long. WWSAVF is defined as a program-described file with input specifications to put the 528 bytes into field inRec. As the program loops through all the records in WWSAVF, each record is written to a PC file. Before data can be written to the PC file, the file needs to be created. The attributes O_CREATE, O_WRONLY, and O_SHARE_NONE tell the file open function from the "C" language run-time library tocreate the file if it does not already exist, to open it for write only, and do not share the open file. The procedure definitions for open(), write(), and close() are contained in the copy book ifsio_h. The special values O_CREATE, O_WRONLY, and O_SHARE_NONE are also defined there. The ifsio_h file was authored by Scott Klement and is available at http://www.scottklement.com/rpg/ifsio_h.rpgle.txt. A complete explanation of IFS file I/O can be found on Scott's web site.

One thing to remember when using C language run-time library routines: You'll need to specify that the RPGLE program is to use binding directory QC2LE. This can be done via the RPGLE header specification or on the compile command.

These IFS I/O routines are writing directly to a mounted file system, so the file is created on the NAS, and not on the local System i. Most of the programming errors you might encounter would result in the PC file not opening and a non-zero file descriptor being returned from the open() function. The ReportError procedure will send a program message containing the error number and text to the external message queue so a user of the SAVTONAS command will know what went wrong.

Writing Code to Restore a Library from the NAS

What good are the PC files if you can't depend on them to be useable for recovery. It's essential to prove the worth of the new PC files.

  
     RSTFRMNAS (CMD) -> RSTFRMNASC (CLLE) -> RSTFRMNASR (RPGLE)
  

The Restore from NAS (RSTFRMNAS—Figure 4) command takes the name of a library that was saved and reverses the whole process. It calls command processing program RSTFRMNASC (Figure 5) to create a save file and calls RSTFRMNASR (Figure 6) to read the data from the corresponding PC file and write it to the save file. Then it does a Restore Library (RSTLIB) command using the save file. Voila' – library restored.

On the return voyage the save file WWSAVF is opened for output, so this calls for output specifications for our program described file instead of input specifications. Because we're reading from the PC file using the read() procedure, the O_RDONLY is specified when opening the PC file, instead of O_WRONLY.

Putting It All Together (to Automate the Backup)

The program SAVTONASC creates a save file, dumps a list of libraries to file QTEMP/WWLIBS using the Display Object Description (DSPOBJD) command, loops through the libraries in the file (ignoring those beginning with the letter "Q"), saves each library to save file QTEMP/WWSAVF, then calls RPGLE program SAVTONASR. The program SAVTONASR reads data from save file QTEMP/WWSAVF and writes the data to a PC file in the IFS. The location of the PC file being written just happens to be on the drive mapped to the NAS.

You can view the rest of the details for program SAVTONASC, such as creating a list of user libraries and looping through the list to save each library to the NAS, by downloading the code associated with this article.

Now that you have successfully tested that saved libraries are restorable, let's engage in a little automation. You can automate regular backup by scheduling the backup to occur during off hours when no one is using the system. For this you'll need a job scheduling program. i5/OS provides the IBM Job Scheduler free with a licensed copy of i5/OS. You might have a third-party job scheduler that you want to use instead. Create an entry in the IBM Job Scheduler to call the SAVTONAS command daily or once a week or once a month, whatever frequency suits your needs. Use the Work with Job Schedule Entries (WRKJOBSCDE) command to pull up the screen shown in Figure 7.

From this screen, press Function Key 6 to prompt the Add Job Schedule Entry (ADDJOBSCDE) command. Figure 8 shows the values for automatically performing a weekly save on Sundays, right after midnight. Press Function Key 9 for Additional Parameters to fill in job queue and text parameters as shown in Figure 9. Press Enter to complete the process of scheduling a weekly backup.

The SAVTONAS and RSTFRMNAS commands will mount the drive to the HP Media Vault (or to your choice of NAS device), if you provided the absolute path on the command. Alternately, you can add the MOUNT command to the QSTRUP system startup program, so that the NAS device can be accessed.

Making It Better

You might want to add a few missing features. First, each backup will overlay the files from the previous backup. An obvious improvement would be to retain multiple generations of backups. Second, including objects stored in the IFS would be advantageous. Third, sending out a notification as to whether or not the backup completed successfully would be beneficial. Fourth, you could add encryption to prevent theft of your data. I'm sure you can think of other features to add.

There's a joke about the devil challenging Jesus to a programming contest. They both set to coding and the power fails minutes before the final bell. The devil concedes that he lost everything when the power failed, so his final program doesn't have much. Jesus, on the other hand, has the most spectacular program and wins the contest. After all (here comes the punch line), "Jesus saves."

The simple truth is that power failures and other unanticipated events can cause us to lose our data. If we save, we'll win the contest. Even if our programs are not spectacular, we can back up our system in a spectacularly inexpensive way.

Stephen West has worked on the AS/400 platform since its announcement on June 21, 1988. For the past 18+ years, Stephen has been a consultant and contract programmer for Workware, Inc., which has allowed him to work at many companies with a diverse set of AS/400-centric technologies.

Figure 1. The Save To NAS command

Figure 2. The SAVTONASC Command Processing Program

Figure 3. The SAVTONASR program

Figure 4. The RSTFRMNAS command

Figure 5. The RSTFRMNASC Command Processing Program

Figure 6. The RSTFRMNASR program