Backing Up File Systems

People back up files for a variety of reasons. Perhaps the obvious reason is safety. If a system with critical data crashes, you need to have a copy of that data available, or business could be severely affected. Files are also backed up in case of accidental deletion, hardware failure, natural disasters, hackers, and a variety of other reasons. The point is: if you can't afford to lose it, you had better back it up.

A backup is an exact replica of a set of data, stored on an alternate media. Most of the time, you will be backing up hard disks. Hard disks can be backed up to other hard disks, tape drives, CD-ROMs, or even floppy disks. In recent years, compact disc backups have become increasingly popular as prices have dropped. Backing up to floppy disk is a ridiculous notion in many cases, unless you want a portable copy of only a few files. The most popular choice is magnetic tape backups. Of course, to back up to a magnetic tape, you need a tape drive.

The mention of natural disasters brings up another good point. It's advisable to store copies of your backups off-site. That way, if a disaster such as a tornado, hurricane, earthquake, or fire hits and your building is destroyed, your data is safe (hopefully) in an alternate location. A variety of companies provide secure off-site backup storage.

Solaris 9 has a new feature called UFS snapshots. Previously, file systems needed to be unmounted in order to be backed up. This was because backups have problems backing up files that could be modified, and unmounting the file system guarantees that the files wouldn't be touched. Now, the fssnap command can take a snapshot of a mounted file system, and that snapshot can be used to perform a backup.

The primary utilities used to back up and restore file systems are ufsdump and ufsrestore. The main focus of this chapter is on these two utilities. However, other backup and copy utilities such as tar, cpio, pax, and dd are covered as well. More advanced backup situations, such as backing up all systems across a network, call for the Solstice Backup software, which is beyond the scope of the Solaris Certified System Administrator exams.

Planning a Backup Strategy

Haphazardly backing up files and directories with no plan in mind would be as futile as trying to herd cats. Running backups takes time, and the tapes you will be backing up to cost money. In the long run, your company will be better served and you'll make better use of your resources if you plan a comprehensive backup strategy.

Deciding What to Back Up

The first question you need to ask is, "What needs to be backed up?" Critical files, such as customer service databases and financial records, are obvious choices. What about user files? It's generally a good idea to back up user home directories. Users trust you, the administrator, to protect their files, and that includes backing them up in case the server crashes. How about operating system files? Generally, most of these can be replaced easily enough from installation CDs. However, your custom operating system configuration files (such as /etc/passwd, /etc/shadow, /etc/system, and a host of others) can't be easily replaced, so you might want those backed up in one location. The last major category of software is applications. These can usually be recovered from their installation media, so they're not necessary to back up. However, data files should be. As an example, you probably don't need to back up the StarOffice application, but any data created with StarOffice is a candidate for backup.

Warning 

When backing up sensitive information, such as the /etc/passwd and /etc/shadow files (or other sensitive material), be sure to save the backup tapes in a secure location. You don't want the material to end up in the wrong person's hands.

One of the convenient backup features of Solaris is that file systems are automatically configured for backup ease. As an example, you can be assured that all critical operating system files are located on the root file system, located on slice 0. User files should be in /export/home, or slice 7. This grouping is convenient; if you want to back up all user files, for example, you can back up slice 7 and be assured you got them all.

Choosing a Backup Method

After you have decided what you need to back up, you need to decide what type of backup you will be performing. The three major choices you have are a full backup, incremental backup, or snapshot backup.

Full backup A full backup backs up all the data in the specified location (all files in a particular file system, for example). This kind of backup stores all data in one place, which makes all of your backed up files easy to locate. However, full backups can take a large number of tapes, depending on how much data you have. Also, you need to unmount all file systems to perform a full backup, and full backups take the longest amount of time of any of the backup types to complete.

Incremental backup An incremental backup backs up only the data that has changed recently. There are a variety of strategies for incremental backups. The strategies are important enough to warrant their own section a little later. Incremental backups are faster (they back up only those files that have changed) and require less space than the other backup types. However, if you have a lot of incremental backups, it can be difficult to locate the exact data you require.

Snapshot backup A snapshot backup is created with the fssnap command. The single biggest advantage of a snapshot is that it can be taken while the file system is mounted. If you have a large file system, users will notice a performance decrease while the snapshot is being generated, but it's much more convenient than having to unmount the file system, perform a backup, and then mount the file system for user access.

The type of backup that you want to perform often goes hand in hand with your proposed backup schedule. A backup schedule is the schedule you establish to ensure timely and complete backups of your data. The backup schedule you devise will depend on the amount of time needed to perform a backup, time available to perform backups, and time required to restore critical file systems. You should also attempt to create a schedule that minimizes the number of required backup tapes, to save costs.

Note 

The frequency of your backups determines the number of backup tapes you will use. Typically, administrators like to rotate backup tapes and use one tape per backup volume. So if you perform a full backup every Sunday and an incremental backup every night, you will need seven tapes to rotate (plus at least one spare). If you were to do a full backup every night, you would need only two tapes (provided that one tape can store all your data): one for the current night and one for the previous night.

In terms of how often you should back up, a good general rule is that if it's critical or it changes frequently, back it up often. In other words, files that might change once a week probably don't need to be backed up every night. Similarly, if a file changes daily, backing it up once a week might increase the chances of data loss.

If you do not have a lot of time to perform backups, then an incremental backup is a good choice. Both full and incremental backups are initiated with the ufsdump dump_level command. A dump level of 0 indicates a full backup. Levels 1 through 9 are various levels of incremental backups. The numbers themselves have no built-in meanings. They're just used in relation to other incremental backups. A few examples should clarify the numbering issue.

Example 1 You perform a full backup (level 0) on Sunday night. Monday night, you perform an incremental level 3 backup. The level 3 backup will back up files that have changed since the last lower-level backup. In other words, it will archive all files that changed Monday.

Example 2 Sunday night, you perform a full (level 0) backup. Monday night, you perform a level 3 backup, which backs up all files changed on Monday. Tuesday, you run a level 3 backup again. It will back up all files that have changed on Monday and/or Tuesday. The key is, it will back up all files modified since the last lower-level backup, which was on Sunday (level 0).

Example 3 Sunday night, you perform a level 0 backup. Monday night, you perform a level 3 backup, which backs up all files changed on Monday. Tuesday night, you run a level 5 backup. This backup will back up all files that have changed since Monday's backup.

Example 4 Sunday night, you perform a level 0 backup. Monday through Thursday nights, you run level 5 backups. Each night will back up progressively more material. On Friday night, you perform a level 3 backup. The level 3 backup will back up all files changed since the last lower-level backup, which was Sunday.

Example 5 Sunday night, you perform a level 0 backup. Here's the rest of your schedule: Monday level 4, Tuesday level 5, Wednesday level 6, Thursday level 7, and Friday level 3. The levels 4, 5, 6, and 7 backups will just back up their respective days' changes. The level 3 on Friday will back up all files changed during the week, back to the level 0 performed on Sunday.

The key thing to remember about the incremental backups is that the numbers 1-9 themselves have no importance. In other words, you could do a whole week of level 3 backups, or a whole week of level 7 backups (just think of extending Example 2 into a whole week), and there would be no difference. The numbers become important only when used in relation to other incremental backups.

Most facilities use a combination of full and incremental backups. Some prefer to run a full backup every weekend, when there's the most time to run backups, and incremental backups every night. Others prefer a monthly full backup. The right answer for your network depends on the importance of your data and how much time you want to spend restoring a server if it does crash.

Finally, here are some points to remember about performing backups:

  • Unmount the file system before running ufsdump unless you are using fssnap to create a snapshot.

  • If you choose to back up a file system that is mounted, directory changes or file-level changes might not be backed up properly.

  • The ufsdump command can be used to back up remote machines onto a local machine with a tape drive.

  • If you are performing backups across the network, the system containing the tape drive must have an entry in its /.rhosts file for each client machine that will be using the tape drive.

  • To back up an NIS+ server database, use the nisbackup command.

Choosing Backup Media

When backing up hard disks, you have a limited number of choices for backup media. The most common destinations for backups are another hard disk, tape drive, floppy disk, or CD-ROM. Backing up to CD-ROM is becoming increasingly popular, but has yet to become as well practiced as backing up to tape drive.

If you are backing up only a few files, you can back them up to a floppy disk. However, for most networks, this is not an option for repeated backups. Backing up to another hard disk is possible, but if done in large volumes, this backup option is not very cost-effective. For most networks, backing up to a tape volume is the best choice.

Choosing a Tape Device and Understanding Tape Device Naming

Depending on your company's budget, you can choose from a variety of tape drives to purchase and install. Some of the older tape technologies, such as the 1/2-inch reel tape, hold approximately 140MB each. Other options include 8mm 14GB cartridge tapes, and DLT 7000 tapes, which hold up to 70GB of data. If budget is not an issue to you, you can spend tens of thousands of dollars on auto-loading tape drives that hold multiple tapes, store thousands of gigabytes, and transfer nearly 2GB per minute.

Regardless of the tape device you choose, if it's going to be managed by Solaris, you need to understand the naming conventions used. The first tape device in Solaris is referenced by its raw logical name of /dev/rmt/0. The /dev directory, as you know by now, holds logical device names, not physical device names. The /dev/rmt directory stands for raw magnetic tape. A tape device number can also be followed by a density rating of l for low, m for medium, h for high, u for ultra, or c for compressed. If no density is specified, the tape drive will write at its preferred density (the highest density it supports). The last option that follows a tape device name is n, for no rewind. As an example, the second tape drive in a machine, using medium density and no rewind, would be represented as /dev/rmt/1mn.

Managing Tape Devices

The mt (magnetic tape control) command can be used to check the status of a tape drive, such as the parameters the tape drive is configured with. Tape devices described in the /kernel/drv/st.conf file can be queried by using mt. To check the status of your first tape drive, you would use:

 # mt -f /dev/rmt/0 status 

The mt command can also be used to rewind, forward, re-tension, and erase magnetic tapes. See man mt for more information.

Taking proper care of your tapes and tape drives is critical to your backup planning. Poor-quality tapes might not be able to be read, and if the backup data can't be read, it's useless.

When you first install a tape device, perform a trial backup and ensure that you can read files off of the tape. Always store tapes in a dry, dust-free place, away from magnetic devices. Label your tapes with the date, backup type, and general contents, and maintain a separate log of tape backups and locations. If a tape starts to show wear, replace it immediately.

Using ufsdump to Perform Backups

After you've acquired your backup hardware and completed your backup planning, you are ready to use the ufsdump command to back up files.

Note 

Because of the name of the backup program, ufsdump, you will hear a lot of people refer to backups as dumps.

One of the negatives about using ufsdump is that it doesn't automatically detect the number of tapes you'll need. Then again, considering the different technologies and tape sizes available, one could hardly expect ufsdump to know every possibility. Therefore, to find out how many tapes you'll need, you will need to run a test:

 # ufsdump S / 177897280 

The S displays an estimate of the number of bytes needed to perform a backup of this file system, in this case, the root (/). If you can convert the number to megabytes in your head, great. If not, feel free to use a calculator. The number of bytes listed in this example is 177,897,280, which is roughly 170MB. Now, based on the capacity of the tapes you are using, you can determine how many tapes you'll need to back up the root.

How ufsdump Works

Executing the ufsdump command initiates a two-phase process. In the first phase, ufsdump scans the raw device for the file system, builds a table (in memory) of directories and files found, and then writes the table of contents to the backup media. In the second phase, ufsdump parses the inodes in numerical order, reading file contents and writing the data to the backup media.

When ufsdump writes data to the backup media, it does so in a default block size. (Although the block size can be specified, the default is generally adequate.) When ufsdump receives a message from the tape device that a partial block of data was written, ufsdump assumes that the physical end of the media has been reached. If more backup data needs to be written, and you don't have an automatic tape loader, ufsdump will instruct you to insert an additional tape to continue.

Because ufsdump copies data from the raw disk slice, any files that are being modified (meaning the new information is stored in memory buffers) will not be backed up properly. This is why it's recommended that you unmount file systems before backing them up. Additionally, ufsdump does not back up free blocks or make an exact image of a disk slice. If your slice contains symbolic links, the link will be backed up, not the file that the link points to.

The /etc/dumpdates File

When used with the -u option, ufsdump updates the /etc/dumpdates file. Each line in /etc/dumpdates is a separate entry and shows the file system backed up, the level of the backup, and the day, date, and time of the backup. Here is a sample /etc/dumpdates file:

 # more /etc/dumpdates /dev/rdsk/c0t0d0s0          0 Sun Sep 29 20:30:05 2002 /dev/rdsk/c0t0d0s7          0 Sun Sep 29 22:09:32 2002 /dev/rdsk/c0t0d0s0          5 Mon Sep 30 20:04:18 2002 /dev/rdsk/c0t0d0s7          9 Mon Sep 30 22:02:58 2002 # 

There's absolutely no reason not to update the /etc/dumpdates file. Updating it doesn't slow down your backups, or inconvenience users. However, not updating it can cause problems for your proposed backup schedule.

Problems can be caused because when you perform an incremental backup, ufsdump checks the /etc/dumpdates file to see when the last backup of that file system occurred. Then, based on the level of that backup, ufsdump knows which files it needs to back up and which files it can ignore. Not only does ufsdump use the /etc/dumpdates file as a log, you as an administrator can verify that backups are being completed by periodically inspecting /etc/dumpdates.

Using ufsdump

The basic syntax for ufsdump is as follows:

 # ufsdump options arguments filenames 

By default, ufsdump is executed with the following options and arguments:

 # ufsdump 9uf /dev/rmt/0 filenames 

Note 

Notice that unlike most other commands in Solaris, arguments for ufsdump are not preceded with a dash (-).

Table 9.1 lists valid ufsdump options.

Table 9.1: ufsdump Options

Option

Description

0-9

Defines a dump level. 0 is a full dump, and 1-9 are incremental dumps.

a archive_file

Writes a backup copy of the table of contents to the specified archive_file, readable only by ufsrestore.

b factor

Specifies a blocking factor (the number of 512-byte blocks to write) for tape writes.

c

Sets the tape drive type to cartridge and block size to 126 instead of 1/2-inch reel tape.

d bpf

Defines tape density in bytes per inch.

D

Backs up files to floppy disk.

f dump_file

Uses the dump_file as the backup media, instead of the default /dev/rmt/0. The dump_file can be another hard disk on a local or remote machine. If on a remote machine, the format for dump_file must be machine_name:device_name.

l

Auto-loads tape devices. The ufsdump command waits two minutes for the tape device to be ready and then continues. If the device is not ready, ufsdump prompts the administrator to continue.

n

Notifies all members in the sys group that ufsdump requires immediate attention, by sending messages to their terminal.

N device_name

Uses the device_name specified when recording information in /etc/dumpdates, and when comparing against information in /etc/dumpdates for incremental backups.

o

Takes the tape device offline when the dump is completed, or rewinds and ejects the media if end-of-media is detected.

s size

Defines the size of the media being backed up to. Specified in feet for reel media, or 1024-byte blocks for floppy disks.

S

Estimates the space needed for the backup, in bytes.

t tracks

Defines the number of tracks for cartridge tapes.

u

Adds an entry into the /etc/dumpdates file.

v

Verifies the backup by comparing written backup data against the source file(s).

w

Warning mode. Lists the file systems present in /etc/dumpdates that have not been backed up within a day. This option must be used alone.

W

Warning mode with highlights. Similar to w, except that W displays all file systems in /etc/dumpdates and highlights the file systems that haven't been backed up within a day.

Because ufsdump can detect end-of-media for most tape devices, the c, d, s, and t options are rarely needed.

Even though the default output for dump files is /dev/rmt/0, many administrators prefer to specify the device name by using the f option anyway. The f option can also be used to designate another hard disk, or even a remote hard disk, as the backup media to use. For instance, if you wanted to back up your local slice 7 to a hard disk slice on a remote computer named igor, you could use the following command:

 # ufsdump 0uf igor:/dev/rdsk/c0t0d0s4 /dev/rdsk/c0t0d0s7 

Remember, though, in order to back up to a remote system, the computer you are on must have an entry in the remote computer's /.rhosts file.

Another common scenario would be to perform an incremental backup and to not rewind the tape. This might be because you want to add additional backup information to the tape because it's not yet filled up. Here's how you could do that:

 # ufsdump 9uf /dev/rmt/0n /dev/rdsk/c0t0d0s7 

Notice the n at the end of the device name. That tells the tape drive to not rewind after the dump is completed. You will also notice that the file system to back up is always at the end of the command. You can specify either the raw device name (as the examples in this chapter have so far) or the mount point directory for the device, as long as the device has an entry in the /etc/vfstab file.

When using ufsdump, you don't need to back up entire file systems. Individual files and/or directories can be specified instead of file systems. When you back up files or directories, though, a level 0 backup is always performed. You cannot incrementally back up individual files or directories. Multiple files or directories can be specified for the filenames variable; separate multiple entries with spaces.

Here are a few more examples. To back up the root file system (remember, you have to unmount the file system, so to back up root, you need to take the computer into the S run level) to a cartridge tape device and verify the backup:

 # ufsdump 0uvcf /dev/rmt/0 / 

To back up an individual directory, such as a home directory, and not rewind the cartridge tape, you could use:

 # ufsdump 0ucf /dev/rmt/0n /export/home/ldocter 

In summary, although the ufsdump utility is a solid performer, it does have a few limitations. The first is that it can't calculate the number of tapes needed to perform a given backup. That's why you need to use ufsdump S to get an idea of how many tapes you need. Second, ufsdump cannot accurately perform backups of mounted file systems. Third, ufsdump cannot back up files mounted from a remote server. The files must be backed up from the server they are located on.

Finally, to increase security on your network, make sure that root is the only user that has access to the ufsdump command. And if you're doing centralized backups on your network, remove all root access entries from the /.rhosts files on clients and servers. This will prevent any unauthorized over-the-network backups.

Using UFS Snapshots

Traditionally, to back up a UFS file system, you were instructed to unmount the file system, making it inaccessible to users. This typically meant performing your backups late at night and on the weekends. For networks that required 24-hour access, there was no choice but to inconvenience users. Now another method is available: a UFS snapshot. A snapshot can be taken of a mounted UFS file system and then used to create a backup archive, while leaving the file system mounted and accessible the entire time.

UFS snapshots were originally introduced with the Solaris 8 1/01 release and are an integrated part of Solaris 9. A UFS snapshot is a backing-store image (a fancy name for an image used as a backup) of a file system at a given point in time and is created with the fssnap command.

UFS snapshots are based on the Sun StorEdge Instant Image tool. There are, however, some differences. Whereas an image taken with Instant Image remains on the system after reboots, images taken with fssnap do not. This means that if you want to use an fssnap backing-store file for backup purposes, you must make the backup before rebooting. The fssnap command works on all UFS file systems, but Instant Image does not work on the root (/) or /usr file systems. Finally, while Instant Image backing-store files are the same size as the file system they are copies of, UFS snapshots are designed to take as little space as possible, and maximum size limits can be placed on UFS snapshot backing-store files.

Creating, Displaying, and Deleting Snapshots

Because creating a UFS snapshot is memory intensive, users will notice a performance drain when fssnap is used. Creating snapshots of larger file systems will increase the delay in performance.

When you execute the fssnap command, the backing-store file will initially consume no disk space and then grow rapidly as the snapshot is created. Make sure the snapshot has plenty of room to grow; if it runs out of space, it might delete itself, causing the backup operation to fail. Check the /var/adm/messages log for possible errors. You can limit the size of a backing-store file by using the -o maxsize=n [k,m,g] option, where n is the size in kilobytes, megabytes, gigabytes, or a combination of the three.

To create a snapshot, use the following syntax:

 # fssnap -F ufs -o bs=/backing_store_file /file_system 

The backing_store_file option is the name of the snapshot you are creating, and file_system is the file system you are making the snapshot of. Snapshots must reside in an alternate file system; they can't be part of the file system that's having its snapshot taken.

Here's an example of creating a snapshot, named /snapshot1, of the /export/home file system:

 # fssnap -F ufs -o bs=/snapshot1 /export/home /dev/fssnap/0 # 

Running the fssnap command created the snapshot, as the /snapshot1 file exists, and it also created a virtual device representing the snapshot. The virtual device is named /dev /fssnap/0. Later in this chapter, you'll see how the virtual device name can be used to create a backup of the snapshot.

To display existing snapshots or to get detailed information about snapshots, use the fssnap -i command. For detailed information on a snapshot, you can either specify the snapshot name or use the UFS file system-specific version of fssnap:

 # fssnap -i    0    /export/home # /usr/lib/fs/ufs/fssnap -i Snapshot number               : 0 Block Device                  : /dev/fssnap/0 Raw Device                    : /dev/rfssnap/0 Mount point                   : /export/home Device state                  : idle Backing store path            : /snapshot1 Backing store size            : 0 KB Maximum backing store size    : Unlimited Snapshot create time          : Fri Oct 04 09:06:50 2002 Copy-on-write granularity     : 32 KB 

Snapshots can be deleted in one of two ways. Either reboot the system or execute the fssnap -d /file_system command.

Backing Up and Restoring Snapshots

Backing up a snapshot is just like backing up an unmounted file system. You can use the ufsdump command to either fully or incrementally back up snapshots. Here's an example of performing a full backup of the UFS snapshot, snapshot1, used previously in this chapter:

 # ufsdump 0ucf /dev/rmt/0 /dev/rfssnap/0 

Note 

The ufsdump command wants to see raw device names, so you need to know the raw device name of your snapshot. To get this information, use /usr/lib/fs /ufs/fssnap -i.

Creating incremental backups of snapshots is a bit more involved. When performing an incremental backup of a snapshot, only the files modified since the last snapshot was taken will be backed up. The tricky part is, you have a snapshot that has a raw device name, yet it doesn't necessarily correspond to the raw device name of the file system you took the snapshot of. For example, looking at the previous output from /usr/lib/fs/ufs/fssnap -i, all you know of the original snapshot file system is that it's /export/home. So, to perform an incremental backup, you need to specify the original raw device as well (this is done with the -o raw option). Here's an example:

 # ufsdump 9ufN /dev/rmt/0 /dev/rdsk/c0t0d0s7 `fssnap -F ufs -o raw,bs=/   snapshot1,unlink /dev/rdsk/c0t0d0s7` 

Backups created with UFS snapshots are restored just as any other backup is restored. If you used ufsdump to perform the backup, you will use ufsrestore to restore.




Solaris 9. Sun Certified System Administrator Study Guide
Solaris 9 Sun Certified System Administrator Study Guide
ISBN: 0782141811
EAN: 2147483647
Year: 2003
Pages: 194

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net