Although AIX, being a UNIX standards compliant operating system comes with a variety of backup and restore tools by default, there are still some situations where system administrators feel them stuck up with these available tools. A very common situation is where a system administrator is asked to backup of a system which does not have any locally available attached tape drive. On AIX, IBM provides Sysback to do the remote backups on filesystems, volume groups and directories levels. Even you can do remote mksysb with Sysback tool. However, Sysback is a licensed product and you have to purchase separate license for this tool from IBM. There are few other commercial products available for remote backups and restore but off course they have constraint of cost
System administrators, have been using remote tar solution (based of combination of various standard UNIX commands including dd , tar and rsh ) to solve this problem since long time. Some system administrators also use rdump command to get this work done.
In this article, I will cover different ways to do remote backup and restore on AIX using tar command. In first section, I will describe traditional way of doing remote tar by combining it with rsh and dd commands and in later section I will describe usage and configuration of GNU tar on AIX, which you can easily combine with Ssh to ensure data flow security over the network during remote backup and restore operations.
Traditional way of using tar for remote Backup/Restore Operations
Just like system administrators of any other UNIX operating system, AIX system administrators can also use tar command with rsh and dd command combination to do the remote backup and restore. This solution is useful in circumstances where corporate does not give any permission to system administrator to use any GNU based tools in their production environment.
In my environment, I have one Lpar named “Jproapp” on P570 which does not have any tape drive attached and available for backups. On the other hand, another p640 server named “okmedb” has one DLT tape drive available. I decided to take a remote tar backup of a filesystem “/oradb/data” (which was mounted on Jproapp) to this tape drive available on okmedb. One possible solution would be to mount this filesystem using NFS on okmedb and then take a simple tar backup to locally available tape drive. However, like other system administrators, I wanted to avoid NFS in production environment due to its performance issues. So I opted for using traditional way of using tar for remote backup operation. I simply resolved hostnames of these servers on each other (so that I can ping Jproapp by name while on okmedb and vice versa) and then created a user named “operator” on both systems (who should have at least read access to /oradb/data filesystem on Jproapp system).
Next step would be rsh setup for this user. I simply created a .rhosts file in $HOME directory of “operator” user on okmedb system with the following contents (so that this operator user from Jproapp system can remotely execute commands on okmedb).
---------------------------------------------------------------------
Operator Jproapp
----------------------------------------------------------------------
I checked that rsh from Jproapp to okmedb for user operator is working fine by executing following command on “Jproapp”
/home/operator> rsh okmedb date
Command should display date and time from okmedb without asking any password.
Once rsh setup is done, rest is simply execution of tar command on Jproapp as follows:
/home/operator> cd /oradb/data
/home/operator> tar –cvf - * | rsh okmedb “dd of=/dev/rmt0 bs=64k conv=block”
To restore the data, you have to again rely on some sort of similar commands combination. For example to restore same data in /home/operator/tmp directory of Jproapp, you have to use following commands sequence
/home/operator> cd tmp
/home/operator> rsh okmedb “dd if=/dev/rmt0 bs=512b” | tar –xvf –
It should be noticed that while taking backups, data can be sent with larger block size (as I used 64k). However, while you try to restore data using larger block size, you may face problems. In my case, I faced “not enough memory” errors even with block size of 10k while restoring same data which was originally backed up with 64k block size. Because of this, I had to use a smaller block size of 512b while restoring data with remote tar technique. This, no doubt slow down restoration process, but the process itself completed without any errors.
GNU tar, a useful solution for remote backups
GNU tar is a GNU based tape archiver program which is capable of doing similar backup and restoration tasks, as done by traditional tar. However, it comes with some more powerful features which are currently not available for native tar. Some important features are as follows:
1. Remote backup/restoration support
2. Large file backup support
3. Incremental backup support
4. Data appending capability on same tape cartridge
More details on this GNU project is available on web site
http://www.gnu.org/software/tar/
Off course, other features of GNU tar are also important (like large files support), we will concentrate only on remote backup/restoration capability of GNU tar on AIX in this article.
There are many ways to get GNU tar for AIX. You can download source code of latest available version of GNU tar from ftp://download.gnu.org.ua/pub/alpha/. You can also obtain executable version (which then can be executed to get installp format of binary) from Bull web site (http://www.bullfreeware.com). However, easiest way to obtain GNU tar for AIX 5L is to use AIX Tool Box for Linux Applications CD or AIX Tool Box web site (http://www-03.ibm.com/servers/aix/products/aixos/linux/download.html) which provide the software in rpm format. So, I downloaded this GNU software from AIX Tool Box web site and then installed it on my both servers (Jproapp and okmedb) by using rpm manager available on AIX.
#home/root> rpm -i gnu-tar-1.14-2.aix5.1.ppc.rpm
It is very important to note down that you have to not only install GNU tar on the server which is going to use GNU tar for backup and restoration but also on the server which will act as remote tape server ( server with tape drive locally attached ) in the solution. Reason of this is that, in order to access the tape drive on a remote machine, GNU tar uses the remote tape server written at the University of California at Berkeley and according to GNU tar documentation, this remote tape server software must be installed as prefix/libexec/rmt on any machine whose tape drive you want to use remotely. GNU tar calls this rmt component by running an rsh or Ssh to the remote machine, optionally using a different login name if one is supplied.
A copy of the source for the remote tape server is provided by default with GNU tar. It is Copyright © 1983 by the Regents of the University of California, but can be freely distributed. It is compiled and installed by default along with GNU tar.
As installation prefix for rpm based GNU utilities on AIX 5L is /opt/freeware, I was expecting “rmt” availability in /opt/freeware/bin after GNU tar installation. However, installation of GNU tar did not create rmt in any such directory and execution of GNU tar began to fail. There is no such AIX specific GNU tar documentation which could help me in overcoming this issue so I looked for other options. The only “rmt” executable present on AIX 5L is /usr/sbin/rmt so I decided to create a symbolic link on both servers as follows:
#/home/root> mkdir /opt/freeware/libexec
#/home/root> ln –s /usr/sbin/rmt /opt/freeware/libexec/rmt
And it worked. When I executed following command on Jproapp, it started backup over the network using GNU tar and remote tape drive present on okmedb server.
#/home/root>/opt/freeware/bin/tar –cvf operator@okmedb:/dev/rmt0 /oradb/data/*.dbf
For restoration, I executed (on Jproapp)
#/home/root> cd /oradb/data/tmp
#/home/root> /opt/freeware/bin/tar –xvf operator@okmedb:/dev/rmt0
You can easily restore even a single file also by specifying name of the file at the end of above mentioned command.
GNU tar, in the above scenario has two main advantages. First, you can easily restore files on the server with locally attached server without any problem. For example, in my scenario I can use simple tar –xvf command on okmedb system to restore data directly on local system which has been backed up from jproapp system remotely. Second , is off course simplicity of command line being used in case of GNU tar solutin. I also experienced some performance improvement in case of GNU tar usage as compared to native tar usage with rsh and dd comands.
SSH Integartion into remote tar solutions
Many organizations require proper security measures to be enforced while they allow data flow on their networks. Also on some Unix/Linux variants, rsh is not enabled by default and ssh appears to be the only remote communication method for these operating systems.
GNU tar supports remote backups and restoration over SSH (although if you see online manuals of GNU tar, there is no specification mentioned about SSH support).The trick is to use –rsh command parameter available with GNU tar.
To setup GNU tar configuration to work with SSH, I had to first of all install Openssh /Openssl on two AIX systems (Jproapp & Okmedb). I used OpenSSH 3.8.1.0 and Openssl 0.9.6.7 (which are available for download from Bull Free software archive web site) and install /configure Openssh based SSH server to run and listen on port 22 (on Okmedb Server) for any incoming connections from Jproapp.
As my objective was to take data backups from Jproapp server over the network to the tape drive available on Okmedb server, so I concentrated towards configuring Openssh in such a way that Jproapp user on Jproapp server should be able to login to Okmedb server using RSA or DSA authentication ( without having any need of passwords usage).I generated public/private dsa based keys pair without any pssphrase on Jproapp.
#/home/jproapp>ssh-keygen –t dsa –b 2048
And then copied it to Okmedb, using scp command
#/home/jproapp>scp /home/jproapp/.ssh/id_dsa.pub jproapp@okmedb:/home/jproapp
Note: You may face some problems while using scp at this stage so better to modify paths to include scp command in $PATH environment variable for the user on both servers (either by editing /etc/environment file or .profile for that specific user).
Next, I created .ssh directory in /home/jproapp and created authorized file (on Okmedb) as follows:
#/home/jproapp> mkdir .ssh;cd.ssh
#/home/jproapp/.ssh> cat /home/jproapp/id_dsa.pub >>authorized_keys
Finally I tested ssh connectivity from Jproapp to okmedb server with DSA authentication. Command should return system date and time from okmedb without prompting for any passwords.
#/home/jproapp>ssh okmedb date
Once SSH configuration is done, we can easily use –-rsh command parameter with GNU tar on Jproapp to use SSH instead of rsh for remote communication.
/home/jproapp>whereis tar
/opt/freeware/bin
/home/jproapp>tar -cvf jproapp@okmedb:/dev/rmt0 --rsh=/usr/bin/ssh .
The whole data flow over the network will now use SSH. You can also verify this SSH usage by stopping sshd running on okmedb and then executing same above GNU tar command (which will give following error, now, in this case)
/home/jproapp> tar -cvf jproapp@okmedb:/dev/rmt0 --rsh=/usr/bin/ssh .
ssh: connect to host kmedbold port 22: Connection refused
/opt/freeware/bin/tar: jproapp@kmedbold\:/dev/rmt0: Cannot open: There is an input or output error.
/opt/freeware/bin/tar: Error is not recoverable: exiting now
SSH can also be configured to use with traditional remote tar technique. For example, in my already configured scenario, if I execute following command on Jproapp, remote tar will start with usage of SSH.
tar -cvf - * | ssh okmedb "dd of=/dev/rmt0 bs=64k conv=block"
In summary, GNU tar provides a comprehensive way of doing remote backups over the network. There is however an essential need of having this tool well tested according to specific scenarios and environments. This could easily be achieved by doing frequent restorations for testing purposes as a part of comprehensive backup strategy.
About Author: Khurram Shiraz is senior system Administrator at KMEFIC, Kuwait. In his eight years of IT experience, he worked mainly with IBM technologies and products especially AIX, HACMP Clustering, Tivoli and IBM SAN/ NAS Storage. He also has worked with IBM Integrated Technology Services group. His area of expertise includes design and implementation of high availability and DR solutions based on pSeries, Linux and windows infrastructure. He can be reached at aix_tiger@yahoo.com.
Note: This article is again one of my published work , which was published in AIX Update July 2007 edition.
No comments:
Post a Comment