United States (change)
Shortcuts: Downloads Fedora Red Hat Network
Account Links: Cart Your Account Logout
A well thought-out backup strategy is essential for minimizing the loss of time and data involved in recovering from a disaster. Red Hat Enterprise Linux provides some tools which help to perform backups, and there are also third party products available for this task. Ultimately, the responsibility for developing and implementing a backup policy lies with the end user system administrator. The Red Hat Enterprise Linux Introduction to System Administration manual includes a chapter about Disaster Recovery that discusses the topic of backing up data at some length.
Dynamic data that is constantly changing, such as databases and user files, needs to be backed up frequently. There are many different back up strategies for this, including backing up to tape, to another server using ftp or scp, or to recordable media such as CDR or DVD. Implementing a backup policy that involves rotating backup media and keeping copies of backups offsite is the most reliable way of minimizing the disruption of inadvertent deletion by a user, server hardware failures or other acts of God.
The server operating system, once it is configured for operation, does not change so frequently and thus usually does not need to be backed up with the same frequency as dynamic data. When configuration changes are made, such as updating the installed packages, installing a new package, or changing the configuration of an installed package, the system may be backed up again in order to allow a replacement system to be brought online rapidly in the event of server failure or destruction.
How this backup is made depends on the particular circumstances of your system, for example, what media is to be used to make the backup? To what extent are you able to take the system offline during the backup? Does your system use RAID or LVM devices? How do you intend to perform a "bare metal restore" (restoring a system from scratch) - by installing, upgrading, and then restoring data, or by wholesale restoring an image? All of these different factors will influence how you make your backup.
Generally speaking, in order to perform a consistent backup, the data being backed up should not be modified during the backup. If data is modified during the backup then the backup may contained a mixture of modified and unmodified data, leading to any restore of the backup being in an unknown and unreliable state.
This means that in practice whenever a backup is being performed the system should be running in as restrictive a mode as possible. For example, with relevant services shut down in order to prevent them from accessing files, with file systems mounted in read-only mode to prevent processes from writing to them, with users disconnected, and with database applications stopped or table-level write locks applied. How much of this is possible on a production server will differ between sites.
Two common methods for backing up databases are to apply a table level write lock and then use a database dump utility to extract the data to a SQL file which can then be backed up, or if the database is located on an LVM volume, to stop it or write lock it and take an LVM snapshot, which can then be backed up. See a related article about LVM snapshots for more information.
The tar command is useful for creating a "tarball" archive of files, wrapping up files and directories into a single, easily exported file. It also has options that can be used to compress the files to make the tar file smaller than the files on disk.For example, here is a command to tar and zip the web server content directory:
# cd /var/www/html # tar -zcf archive.tar.gz *
Refer to the man page for tar for more information on using this utility.
Note: that it is not recommended to perform large scale backups using the tar command. This is a very CPU and I/O intensive method that is best suited for smaller tasks than complete or large scale system backups, for which more efficient methods exist.