There are two methods of backing up large amounts of data:
To understand these two types of backups and which one is right for a site or system, it is important to have an understanding of file system structure and data placement. Once you have decided on a strategy for data placement, you can develop a backup strategy for that data. See "Implementing Scheduled Backups" for an example of a backup strategy that includes weekly complete system backups and daily incremental backups.
It is important to understand the difference between a file system and a directory. A file system is a section of hard disk that has been allocated to contain files. This section of hard disk is accessed by mounting the file system over a directory. Once the file system is mounted, it looks just like any other directory to the end user. However, because of the structural differences between the file systems and directories, the data within these entities can be managed separately.
When the operating system is installed for the first time, it is loaded into a directory structure, as shown in the /root File System Tree illustration.
The directories on the right (/usr, /tmp, /var, and /home) are all file systems so they have separate sections of the hard disk allocated for their use. These file systems are mounted automatically when the system is booted, so the end user does not see the difference between these file systems and the directories listed on the left (/bin, /dev, /etc, and /lib).
Data is defined as programs or text and for this discussion is broken down into two classes:
User programs and text should not be placed in file systems designed to contain system data. For example, a system manager might create a new file system and mount it over a /local.
In general, backups of user and system data are kept in case data is accidentally removed or in case of a disk failure. It is easier to manage backups when user data is kept separate from system data. These are the reasons for keeping system data separate from user data:
To back up the system data, unmount all user file systems, including /home with the umount command. If these file systems are in use, you will not be able to unmount them. It is worth scheduling the backups at low usage times so they can be unmounted; if the user data file systems remain mounted, they will be backed up along with the operating system data. To ensure that only the operating system file systems are mounted, enter the following command:
mount
The only mounted file systems should be /, /usr, /var, and /tmp, and the output of the mount command should be similar to the following:
node mounted mounted over vfs date options
/dev/hd4 / jfs Jun 11 10:36 rw,log=/dev/hd8
/dev/hd2 /usr jfs Jun 11 10:36 rw,log=/dev/hd8
/dev/hd9var /var jfs Jun 11 10:36 rw,log=/dev/hd8
/dev/hd /tmp jfs Jun 11 10:36 rw,log=/dev/hd8
Once you are certain that all user file systems are unmounted, refer to "Backing Up Your System" for information on backing up the operating system data.
When you finish backing up the operating system, mount the user file system using the smit mount command. Next, you can back up files, file systems, or other volume groups, depending on your needs. Procedures on these backups are covered later in the chapter.
Cloning allows you to save configuration data along with user or system data. For example, you might want to replicate a system or volume group; this is sometimes called cloning. You can then install this image onto another system and can use it just like the first system. The mksysb command is used to clone the rootvg volume group, which contains the operating system, while the savevg command is used to clone a volume group. Procedures for backing up both your system and user volume groups are discussed later in the chapter.