Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Beginning Ubuntu Linux - From Novice To Professional (2006)

.pdf
Скачиваний:
71
Добавлен:
17.08.2013
Размер:
25.54 Mб
Скачать

468

C H A P T E R 3 2 B A C K I N G U P D A T A

You can also elect to perform a full backup after a certain number of days have passed (up to 1,000). A full backup means that SBackup creates a new backup file, rather than appending an already existing file with any new or edited files.

Restoring Data via SBackup

If the worst happens and you need to restore any number of files from the backup, you can click System Administration Simple Backup Restore.

The first step is to click in the Available Backups drop-down list to choose a backup file from which to restore. The filenames contain the dates and times the backups were made, and it makes sense to choose the latest file (unless you want to revert to an older version of a file).

Once the backup has been selected, the files it contains will be displayed beneath. Each directory will have a small triangle to its left, which you can click to expand the directory to show its contents.

After you’ve found the file or directories you want to restore, highlight them and then click the Restore button. But beware, because this will rewrite the files and directories to their original locations—files or directories already there with matching filenames will be overwritten!

If you want to restore the files to a different location, click the Restore As button, and then choose a folder.

Caution Restored files and directories are owned by root. This is because SBackup runs with superuser powers. Therefore, one of the first things you’ll have to do is use the chown command, preceded by sudo, to change the ownership and group of the file to what they were originally. See Chapter 14 for more details about file ownership and how the chown command works.

Making Backups from the Command Line

Although SBackup allow the uninitiated to make quick backups, the tar program is preferred by Linux old-timers. This creates .tar files and is one of the original carryovers from Unix. tar stands for Tape ARchive and refers to backing up data to a magnetic tape backup device. Although tar files are designed for backup, they’ve also become a standard method of transferring files across the Internet, particularly with regard to source files or other installation programs.

A tar file is simply a collection of files bundled into one. By default, the tar file isn’t compressed, although additional software can be used to compress it. tar files aren’t very sophisticated compared to modern archive file formats. They’re not encrypted, for example, but this can also be one of their advantages.

Note Linux comes with a couple more backup commands, which you might choose to use. They are cpio and pax. Both aim to improve on tar in various ways, but neither is broadly supported at the moment. cpio is installed by default under Ubuntu, and pax can be found via the Synaptic Package Manager. Examine their man pages for more details.

C H A P T E R 3 2 B A C K I N G U P D A T A

469

Creating tar Files

Perhaps unsurprisingly, tar files are created at the console using the tar command. Usually, all that’s needed is to specify a source directory and a filename, which can be done like so:

tar -cf mybackup.tar /home/keir/

This will create a backup called mybackup.tar based on the contents of /home/keir/. tar is automatically recursive so, in this example, it will delve into all subdirectories beneath /home/ keir. The -c command option tells tar you’re going to create an archive, and the -f option indicates that the filename for the archive will immediately follow. If you don’t use the -f option, tar will send its output to standard output, which means that it will display the contents of the archive on the screen.

If you typed in a command like the preceding example, you would see this message:

Removing leading '/' from member names.

This means that the folders and files added to the archive will all have the initial forward slash removed from their paths. So, rather than store a file in the archive as this:

/home/keir/Mail/file1

The file will be stored as follows:

home/keir/Mail/file1

The difference between the two forms concerns when the files are later extracted from the archive. If the files have the initial slash, tar will write the file to /home/keir/Mail/file1. If there’s already a file of that name in that location, it will be overwritten. On the other hand, with the leading slash removed, tar will create a new directory wherever you choose to restore the archive. In this example, it will create a new directory called home, and then a directory called keir within that, and so on.

Because of the potential of accidentally overwriting data by specifying absolute paths in this way, a better way of backing up a directory is simply to change into its parent and specify it without a full path:

cd /home/

tar -cf mybackup.tar keir

When this particular archive is restored, it will simply create a new folder called keir wherever it’s restored.

Compressing tar Archives

You can also compress the archive from within tar, although it actually calls in outside help from either bzip2 or gzip, depending on which you specify.

To create a tar archive compressed using bzip2, the following should do the trick:

tar -cjf mybackup.tar.bz2 keir

470

C H A P T E R 3 2 B A C K I N G U P D A T A

This will create a compressed backup from the directory keir. The -j command option passes the output from tar to the bzip2 program, although this is done in the background. Notice the change in the backup filename extension to indicate that this is a bzip2 compressed archive.

The following command will create an archive compressed with the older gzip compression:

tar -czf mybackup.tar.gz keir

This uses the -z command option to pass the output to gzip. This time, the filename shows it’s a gzip compressed archive, so you can correctly identify it in the future.

Extracting Files from a tar Archive

Extracting files using tar is as easy as creating them:

tar -xf mybackup.tar

The -x option tells tar to extract the files from the maybackup.tar archive.

Extracting compressed archives is simply a matter of adding the -j or -z option to the -x option:

tar -xjf mybackup.tar.bz2

Note Technically speaking, tar doesn’t require the preceding hyphen before its command options. However, it’s a good idea to use it anyway, so you won’t forget to use it with other commands in the future.

Viewing tar Archive Information

To view the contents of a tar archive without actually restoring the files, use the -t option:

tar -tf mybackup.tar |less

This example adds a pipe into less at the end, because the listing of files probably will be large and scroll off the screen. Just add the -j or -z option if the tar archive is also compressed.

In addition, you can add the -v option to all stages of making, extracting, and viewing an archive to see more information (chiefly the files that are being archived or extracted).

Typing -vv provides even more information:

tar -cvvf mybackup.tar keir

This will create an archive and also show a complete directory listing as the files and folders are added, including permissions.

C H A P T E R 3 2 B A C K I N G U P D A T A

471

Saving the File to a CD-R/RW

Once the tar file has been created, the problem of where to store it arises. As I mentioned earlier, storing backup data on the same hard disk as the data it was created to back up is foolish, since any problem that might affect the hard disk might also affect the archive. You could end up losing both sets of data!

If the archive is less than 700MB, it might be possible to store it on a CD-R or CD-RW. To do this from the command line, first the file must be turned into an ISO image, and then it must be burned.

To turn it into an ISO image, use the mkisofs command:

mkisofs -o backup.iso mybackup.tar.bz2

You can then burn the ISO image to a CD by using the cdrecord command. Before using this, you must determine which SCSI device number your CD-R/RW drive uses (all CD-R/RW or DVD-R/RW drives are seen as SCSI devices, even if they’re not). Issue the following command (with superuser powers—cdrecord accesses the system hardware directly):

sudo cdrecord -scanbus

You should find the device numbers listed as three numbers separated by commas. To burn the backup image, all you need to do is enter a command in this format:

sudo cdrecord dev=<dev number> speed=<speed of your drive> mybackup.iso

On a typical system, this might take the following form:

sudo cdrecord dev=0,0,0 speed=24 mybackup.iso

Note Remember that you can use the man command to learn about any commands, including those detailed here. In the case of cdrecord in particular, this is worthwhile, because it’s a very powerful piece of software.

Summary

In this chapter, we looked at making backups. First, you saw how to verify where your personal and other vital data is stored. Then we looked at how the SBackup tool can be used to back up system configuration and personal data. Finally, you learned how to use tar at the command line to back up any kind of data.

In the next chapter, we’ll look at how tasks can be scheduled to occur at various times under Ubuntu.

C H A P T E R 3 3

■ ■ ■

Scheduling Tasks

In this book, you’ve learned about various tasks you can perform to keep Ubuntu running smoothly. You may decide that you want some of these tasks to occur on a regular basis. For example, perhaps you want your /home folder to be backed up every day, or perhaps you want to clean the /tmp folder to ensure that you always have enough free disk space. You could carry out each task individually, but human nature would no doubt step in, and you would forget, or you might perform the action twice, because you’ve forgotten that you’ve already done it.

As you might expect, Linux is able to automate the running of particular tasks. They can either be run periodically at scheduled times or as one-time tasks. Using Linux’s scheduling features is explained in this chapter.

Scheduling with crontab

Under Ubuntu, the main way of scheduling tasks is via the cron daemon. This works on behalf of the user in order to schedule individual tasks, and it is also used by the system to run vital system tasks, although a different way of working is used in each case.

For cron to run user-scheduled tasks, it reads a file called crontab. Each user has her own version of this file, which is stored in the /var/spool/cron/crontabs directory. This file can be edited in a text editor, but a special command should be used to do so.

Note System-wide tasks are handled by the /etc/crontab/ file. This runs scripts contained in /etc/ cron.hourly, /etc/cron.daily, and so on, depending on when the tasks are meant to be run (every hour, day, week, or month). The average user never needs to bother with system-wide cron jobs. These are handled by the internal system, and programs create their own entries as and when necessary.

The cron daemon starts at bootup and simply sits in the background while you work, checking every minute to see if a task is due. As soon as one comes up, it commences the task, and then returns to a waiting status.

473

474

C H A P T E R 3 3 S C H E D U L I N G T A S K S

Creating a Scheduled Task

Adding a scheduled task is relatively easily and is done via the shell. Entering the following command will cause your personal crontab file to be loaded into the GNU nano text editor, ready for editing:

crontab -e

If this is the first time you’ve edited your crontab file, it will most likely be completely empty (in fact, you might see a message about crontab having to create the file from scratch). However, don’t be put off. Adding a new entry is relatively easy and normally takes the form of something like this:

01 12 15 * * tar -cjf /home/keir/mybackup.tar.bz2 /home/keir

Let’s examine the line piece by piece. The first part—the numbers and asterisks—refers to when the task should be run. From left to right, the fields refer to the following:

Minutes, from 0 to 59

Hours, in 24-hour time, so from 0 to 23

Day dates, for the day of the month, from 1 to 31 (assuming the month has that many days)

Months, from 1 to 12

Day, for a particular day, either from 0 to 6 (0 is Sunday), or specified as a three-letter abbreviation (mon, tue, wed, and so on)

In the example, the task is set to run at the first minute at the twelfth hour (midday) on the fifteenth day of the month. But what do the asterisks stand for? They’re effectively wildcards and tell cron that every possible value applies. Because an asterisk appears in the month field, this task will be run every month. Because an asterisk appears in the day field, the task will be run every day.

You might have noticed a logical contradiction here. How can you specify a day if you also specify a date in the month? Wouldn’t this seriously limit the chances of the task ever running? Yes, it would. If you were to specify sat, for example, and put 15 in the date field, the task would run on only the fifteenth of the month if that happened to be a Saturday. This is why the two fields are rarely used in the same crontab entry, and an asterisk appears in one if the other is being used.

After the time and date fields comes the command itself: tar. As you learned in the previous chapter, tar is designed to back up your personal data.

Only standard BASH shell commands can be used in the command section. cron isn’t clever enough to interpret symbols such as the tilde (~) as a way of referring to your home directory. For this reason, it’s best to be very thorough when defining a cron job and always use absolute paths.

Let’s take a look at another example (shown in Figure 33-1):

59 23 * * 0-3 tar -cjf /home/keir/mybackup.tar.bz2 /home/keir

C H A P T E R 3 3 S C H E D U L I N G T A S K S

475

Figure 33-1. Editing crontab lets you schedule tasks using the nano text editor.

The first field says that this task will run at the fifty-ninth minute of the twenty-third hour (that is, one minute before midnight). The date and month field have asterisks, so this implies that the task should run every day and every month. However, the day field contains 0-3. This says that the task should run on only days 0 through to 3, or Sunday through Wednesday.

You can have as many cron entries as you like; simply give each a separate line. You don’t need to put them in date or time order. You can just add them as and when you see fit.

When you’re finished, save the file and quit GNU nano in the usual way (by pressing Ctrl+X).

Editing crontab with the GUI

Although it’s not installed by default, the gcrontab program lets you edit the crontab file via a graphical interface. You’ll find the program in the Ubuntu software repositories and can install it using the Synaptic Package Manager (see Chapter 8).

Using the program is similar to manually editing crontab. Start by clicking the Add New button to add a scheduled job, and then use the various icons on the second toolbar to alter the time, day, month, and so on. You can then click the lightning icon to add the actual command.

Note To be frank, I can’t see any reason to use gcrontab over simply editing the crontab file manually, but if you really hate using the command line, it might be worth investigating.

476

C H A P T E R 3 3 S C H E D U L I N G T A S K S

Scheduling with anacron

If cron has an Achilles’ heel, it is that it expects your computer to be up and running all the time. If you schedule a task for around midnight, as in one of the previous examples, and your computer isn’t switched on at that time, the task simply won’t run.

anacron was created to fix this problem (see Figure 33-2). It also can run scheduled tasks, but unlike cron, it doesn’t rely on exact times or dates. Instead, it works on the principle of time periods. For example, tasks can be set to run every day. In fact, tasks can be set to run ever x number of days, regardless of whether that’s every two days or every hundred thousand. It also doesn’t matter if the computer is shut down and rebooted during that time; the task will be run only once in the specified time period. In addition, tasks can be specifically set to run at the beginning of each month, regardless of the length in days of each month.

Figure 33-2. anacron is used to run tasks periodically, such as every couple of days.

anacron is primarily designed to be used for system maintenance, and the anacrontab file holds the details of the tasks. Unlike as with crontab, each user doesn’t have his own anacrontab file. However, there’s no reason why you can’t add your own commands to the main anacrontab file. This file can be edited in any text editor, and you don’t need to use a special command to edit it (as with crontab), although you’ll need to adopt superuser powers to do so.

Each line in anacrontab takes the following form:

days

delay

name of task

command

The days field holds the number of days in between the running of the task. To set the task to run every day, you would enter 1. To make the task run every nine days, you would add 9. To set it to run monthly, you should type @monthly.

C H A P T E R 3 3 S C H E D U L I N G T A S K S

477

The delay field tells anacron how long to wait after it’s run before running the task, specified in minutes. It is necessary because anacron is usually run at bootup, and if it were to run the scheduled tasks instantly, the machine would grind to a halt because it is already busy.

A delay of five minutes is usually adequate, although if some tasks are already scheduled to run on the same day before that task, you should allow enough time for them to finish.

The name of task field is for your personal reference and shouldn’t contain either slashes or spaces (hint: separate words using underscores or full stops).

The command field is, as with crontab, the shell command that should be run.

Note anacron is run as the root user, so if you do add your own entry to anacrontab, any files it creates will be owned by root, too. If you use anacron to create a backup of your /home directory, for example, the resultant backup file will be owned by root, and you’ll need to use the chown command to change its ownership so you can access it. See Chapter 14 for more information about the chown command.

Let’s look at an example of an anacrontab entry:

1

15

backup_job

tar -cjf /home/keir/mybackup.tar.bz2 /home/keir

This will run the specified tar command every day (because 1 is in the days field), and with a delay of 15 minutes after anacron is first run.

anacron is run automatically every time you boot, but you can also run it manually by simply typing it at the command prompt (with superuser powers):

sudo anacron

Using at to Schedule One-Off Tasks

What if you quickly want to schedule a one-time-only task? For this, you can use the at command. Adding a job with at is very easy, largely because the at command accepts a wide variety

of time formats. For example, typing the following at the command prompt will run a job at lunchtime tomorrow:

at noon tomorrow

It really is as simple as that!

Alternatively, you can specify a time, date, and even a year:

at 13:00 jun 25 2008

This will run the job at 1 p.m. on June 25, 2008. The various time and date formats are explained in the at command’s man page.

Once the at command containing the date has been entered, you’ll be presented with a mock shell prompt. Here, you can type the commands you want to run. Many shell commands can be entered, one after the other; just press Enter between them. Then press Ctrl+D to signal that you’re finished editing. At this point, at will confirm the time and write the task into its list.