Restoring File Systems

The whole idea of backing up files is to have a copy of critical data in case something happens to the server. Ideally, you will never have to restore from backup in your administrative career. Achieving that ideal, though, is unlikely. You need to know how to restore backups after you've created them.

The ufsrestore command is used to restore files backed up with ufsdump. When you restore, you copy files from a backup media back to an active hard disk. Files can be restored from full or incremental dumps, with no major differences in ufsrestore syntax. If the superuser runs ufsrestore, files are restored with their original owner, last modification time, and permissions.

Before you begin a restore, you should have the tapes you need to perform the restore, the raw device name of the device you want to restore to, and a list of files or file systems you want to restore.

One of the features of ufsrestore is that it restores files in relation to their original directory location. For example, files in /export/home/qdocter are saved in relation to the file system, in this case /export/home. Therefore, the file /export/home/qdocter/solbook is written to tape as ./qdocter/solbook, and when restored to the /var/tmp directory, it would be restored to /var/tmp/qdocter/solbook.

This restoration procedure can become quite confusing if you are restoring a large number of files. If you want, you can create subdirectories in /var/tmp to restore to and then move the files to their needed locations after the restorations are complete.

Warning 

Never restore files to the /tmp directory. The /tmp directory uses the TMPFS file system, which does not support UFS security features such as Access Control Lists (ACLs).

Using the ufsrestore Command

The syntax for ufsrestore is as follows:

 # ufsrestore options arguments filename(s) 

There are only five options for ufsrestore. They are shown in Table 9.2.

Table 9.2: ufsrestore Options

Option	Description
i	Interactive; gives you some control over the restoration.
r	Recursive; re-creates the entire file system relative to the current working directory.
R	Resume; resumes an interrupted r-mode ufsrestore.
t	Table of contents; lists each filename that appears on the media.
x	Extract; enables you to remove only the requested files from the media.

Quite a number of arguments are available for ufsrestore. Some of the more common ones are listed in Table 9.3.

Table 9.3: ufsrestore Command-Line Arguments

Argument	Description
a archive_file	Reads the table of contents from the specified archive_file instead of the tape backup media. It's used with t, i, and x modes to check whether the needed files are on the media without actually having to mount the media.
b factor	Specifies a blocking factor (the number of 512-byte blocks to read in one pass) to use. By default, ufsrestore attempts to detect the blocking factor used in the ufsdump.
d	Turns on debugging output.
f dump_file	Uses the dump_file instead of /dev/rmt/0 as the file to restore from. If the dump_file is specified as -, ufsrestore reads from the standard input.
m	Extracts files by inode number instead of by filename and restores them into the current working directory, regardless of where they were previously located within the file system.
o	Takes the tape drive offline and ejects the media, if possible, after the restoration is complete.
s n	Skips to the nth file, if multiple dump files are on the same tape. For example, ufsrestore xfs /dev/rmt/0n 3 skips to the third dump file on the tape.
v	Enables verbose mode.

As an example, if you wanted to begin a recursive restore from the first tape device, you could use the following command:

 # ufsrestore rf /dev/rmt/0 

Or, to begin an interactive restore from the same device, you could use:

 # ufsrestore if /dev/rmt/0 

Interactive restorations enable you to use some shell-like commands to browse and interact with the restore media. The interactive commands supported are listed in Table 9.4.

Table 9.4: Interactive Restoration Commands

Command	Description
add filename	Adds the named file or directory to the list of files to extract. If a directory is specified, the directory and all files within the directory are added to the extraction list.
cd directory	Changes directories within the dump file.
delete filename	Deletes the file or directory from the list of files to be extracted. If a directory name is specified, that directory and all its files and subdirectories will be removed from the extraction list.
extract	Extracts all files on the extraction list and restores them into the current working directory on the hard disk. If you are asked to specify a volume number, enter 1 for the first volume (recommended).
help	Displays a list of available commands.
ls	Lists files within the present directory or the directory specified. Directories and files marked for extraction are prefixed with an asterisk (*).
marked	Functions like ls, except only files that are marked for extraction are listed.
pwd	Prints the present working directory within the backup hierarchy.
quit	Exits the interactive restore.
setmodes	Prompts the administrator with set owner/mode for '.' [yn]. Choose "yes" to set the mode (permissions, owner, and access times) of the current directory (into which files are being restored) equal to the mode of the root directory of the file system from which they were dumped. If restoring an entire file system, or files into their original directory, this is a good choice. Choose "no" to leave the mode of the current directory (into which files are being restored) unchanged. If you are restoring files into a directory other than the one they originally came from, this is the best choice.
verbose	Enables verbose mode. In verbose mode, ls lists the inode numbers of all files and directories, and ufsrestore displays information about each file as it's extracted.

As you can see by the commands available, interactive mode gives you a considerable amount of control over the restoration process.

Note 

If you do not specify a setmodes option, you will be prompted with set owner /mode for '.' [yn] after the restoration is complete. Understanding the differences between saying "yes" and saying "no" is critical because your answer will greatly affect the security of restored files.

You can also restore from remote locations, such as remote tape drives or remote hard disks. To restore remotely, you need to specify the location of the media you want to restore from. Here's an example of restoring from the first tape device on a server named fido:

 # ufsrestore xf fido:/dev/rmt/0 

Interactive and recursive restorations can also be performed when the restoration media is located on a remote system.

Real World Scenario: Are You Missing Something in the Restore?

The hard disk containing the user home directories on your Solaris file server crashed. As recommended, you have created regular backups. You have replaced the hardware and now are going to perform a restore by using ufsrestore.

Your backup schedule is to perform a level 0 dump on Sunday, followed by a level 2 on Monday, 3 on Tuesday, 4 on Wednesday, 5 on Thursday, and 6 on Friday. You follow this routine every week. The hard disk crashed on Wednesday.

When you perform the restore, you restore from the tape marked "Sunday" and then from the tape marked "Tuesday." You verify that the new hard disk is operational and run a quick check to make sure files are there. Everything seems okay.

Later that day, you receive calls from users saying that their restored data doesn't quite look right. Some files are missing, and others contain incorrect data, while others seem to be fine. The users are concerned and not sure how this could have happened. They quickly dismiss the idea that the files they are talking about were modified on Wednesday and therefore lost when the hard disk crashed. What could be the problem?

It appears as though you missed a tape during the restoration process. Incremental backups back up only the files that have changed since the last lower-level backup. The dump you ran Tuesday backed up files that had changed since the last lower-level backup, which was done Monday. The Tuesday tape didn't have Monday's changes. That explains why some files might be okay (because they weren't modified Monday), and others weren't.

There are two solutions to your problem, one of which you can use now. To get the users' files back, you need to restore the full backup (Sunday), followed by Monday's tape and then Tuesday's tape. The second solution requires a bit of planning. If you were to run a level 0 dump on Sunday, followed by the same level dump (level 5 for example) each weeknight, you could restore as you had originally, and all files should be as up-to-date as possible.

Special Case Restorations

So far, this chapter has discussed only restoring files from a tape backup, not necessarily restoring entire file systems. Restoring full file systems is an involved process and can take quite a bit of time if the file system is large. But if the file system is irreparably damaged or corrupted, or the hard disk has failed, you might not have any other choice. Restoring the root (/) and /usr file systems requires its own special process, which will be covered later in this section.

Restoring Entire File Systems

Before you can restore an entire file system, you must have superuser or equivalent rights. These steps also require you to have unmounted the old file system, replaced hardware as necessary, and created a new file system at least large enough to hold the file system you want to restore.

Note 

For information on creating file systems, see Chapter 7, "File System Management."

After you have created the new file system, you can follow these steps to restore the old file system from backup:

1. Mount the file system you just created on a temporary mount point. The temporary mount point can be called anything you would like, but for brevity, you can use /new.

    # mount /dev/dsk/device_name /new 

2. Change directories to your new mount point.

    # cd /new 

3. Insert the tape containing your last full backup into the tape drive and restore the files.

    # ufsrestore rvf /dev/rmt/0 

4. If you have incremental dumps more current than your last full dump, continue restoring, from lowest-level dump to highest, until all your dumps are restored.

5. Check to ensure that the file system is restored properly. How you do this is up to you, but an easy way is to use the ls command to verify that the right files are in the right places.

6. Remove the restoresymtable file. This file is used by ufsrestore as a check point in the restore process and is no longer needed.

    # rm restoresymtable 

7. Change to another directory (such as the root) and unmount the new file system.

    # cd / # umount /new 

8. Insert a new, blank tape and make a full backup of the new file system. After all the work you have performed to restore this file system, you had better make a fresh dump.

    # ufsdump 0uf /dev/rmt/0 /dev/rdsk/device_name 

9. Mount the new file system.

    # mount /dev/dsk/device_name mount_point 

10. Verify access to the newly restored and mounted file system.

     # ls mount_point 

Your file system should be restored and operational.

The root (/) and /usr file systems are the two most critical file systems to Solaris operation. In fact, they are the only two required file systems to operate Solaris. Because of their critical nature, and because the root file system is used to boot, restoring these two file systems requires special steps.

As with restoring any other file system, you need to have superuser or equivalent rights. You also must have added a new system disk to the computer and created a new file system on it. You will have to boot to the CD-ROM or to the network to restore the file system. After those tasks are completed, follow this procedure:

1. Mount the file system you just created on a temporary mount point. The temporary mount point can be called anything you would like, but for brevity, you can use /new.

    # mount /dev/dsk/device_name /new 

2. Change directories to your new mount point.

    # cd /new 

3. Insert the tape containing your last full backup into the tape drive and restore the files.

    # ufsrestore rvf /dev/rmt/0 

4. If you have incremental dumps more current than your last full dump, continue restoring, from lowest-level dump to highest, until all your dumps are restored.

5. Check to ensure that the file system is restored properly. How you do this is up to you, but an easy way is to use the ls command to verify that the right files are in the right places.

6. Remove the restoresymtable file. This file is used by ufsrestore as a check point in the restore process and is no longer needed.

    # rm restoresymtable 

7. Change to another directory (such as the root) and unmount the new file system.

    # cd / # umount /new 

8. Check the new file system for consistency.

    # fsck /dev/rdsk/device_name 

9. Create boot blocks on the new root partition.

    # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/device_name 

10. Insert a new, blank tape and make a full backup of the new file system. After all the work you have performed to restore this file system, you had better make a fresh dump.

     # ufsdump 0uf /dev/rmt/0 /dev/rdsk/device_name 

11. Repeat steps 1 through 10 for the /usr file system, if necessary.

12. Reboot the system.

     # init 6 

Your root (/) and /usr file systems should be restored and operational.