For greatest safety, it's a good idea to buy disks of similar capacity from different drive manufacturers (or at least different models or batches) when building a RAID array, in order to reduce the likelihood of near-simultaneous drive failure.
6.2.4. Where Can I Learn More?
The manpages for md , mdadm , mdadm.conf , hdparm , smartd , smartd.conf , mkfs , mke2fs , and dmraid
The manpages for iscsid and iscsiadm
The Linux-iSCSI project: http://linux-iscsi.sourceforge.net
The Enterprise iSCSI Target project: http://iscsitarget.sourceforge.net/
6.3. Making Backups
Hard disks are mechanical devices. They are guaranteed to wear out, fail, and lose your data. The only unknown is when they will fail.
Data backup is performed to guard against drive failure. But it's also done to guard against data loss due to theft, fire, accidental deletion, bad editing, software defects, and unnoticed data corruption.
6.3.1. How Do I Do That?
Before making backups, you must decide:
What data needs to be backed up
How often the data needs to be backed up
How quickly you need to restore the data
How far back in time you need to be able to restore
Based on this information, you can develop a backup strategy, including a backup technology, schedule, and rotation.
6.3.1.1. Determining what data to back up
Any data that you want to preserve must be backed up; usually, this does not include the operating system or applications, because you can reinstall those.
Table 6-5 lists some common system roles and the directories that should be considered for backup.
Table 6-5. Directories used for critical data storage in various common system roles
| System role | Standard directories | Notes |
|---|---|---|
| Database server (e.g., MySQL) | /var/lib/mysql | Stop the database server or use snapshots to ensure consistency between tables. |
| Web server | /var/www/etc/httpd/home/*/~public_html | Also include any data directories used by web applications. |
| DNS nameserver | /var/named/etc/named.conf | This information usually changes slowly. |
| Desktop system, or any system accessed by individual users | /home | Exclude cache directories such as /home/*/.mozilla/firefox/*/Cache. |
| Samba server | All directories served by Samba | |
| CUPS print server | /etc/cups | Configuration information only; usually changes slowly. |
| All systems | /etc | Configuration information for most software and hardware installed on the system. |
6.3.1.2. Determining how often to back up your data
Generally, backup frequency should be decided based on how often (and when) the data changes, and how many changes you are willing to lose.
For example, printer configuration data may be changed only a few times a year, and losing the latest change won't cost much in terms of the work required to re-create that change. Word processing documents may be changed daily, and you may want to ensure that you don't lose more than one day's work (or even a half-day's work); on the other hand, orders on a busy web site may be received every few seconds, and you may decide that you can't live with the loss of more than a few minutes worth of data.
6.3.1.3. Determine how quickly you will need to restore your data
How long can you live without your data? The answer probably depends on regulatory and operational issues.
Some types of informationsuch as information about cross-border shipmentsmust be reported to government agencies on a daily basis, for example, and delays are penalized by fines of thousands of dollars per day. This puts a tremendous amount of pressure on the data-recovery process. On the other hand, personal music and photo collections may not need to be restored until weeks or months after the data loss.
6.3.1.4. Determine how far back in time you need to restore
Some types of data loss or corruption may not be realized until weeks, months, or years after they have occurred, while others will be immediately obvious. In some caseswhen data changes quicklyit may be necessary to be able to restore data to the state it was in on a specific date, while in other cases it's sufficient to be able to restore data to the state that it was in at the end of a particular month.
6.3.1.5. Decision 1: Incremental versus full backups, and backup rotation
Files may be selected for backup on an incremental basisonly files that have been changed since the last backup are selectedor a full backup may be performed.
Incremental backups often require significantly less storage space than full backups when dealing with large sets of individual files such as word processing documents because the number of documents that are changed each day is usually fairly small. On the other hand, a small SQL update query may cause all of the files in a database to be modified, nullifying the benefits of incremental backup in that context.
An incremental backup scheme usually involves making full backups periodically and then making incremental backups until the scheduled time of the next full backup. Restoring from an incremental backup therefore requires you to restore a full backup, then restore all of the incremental backups from that point forward. Thus, the time required for a restore operation may be much longer than for a system that uses only full backups. Also, if one of the backups is unusable due to media corruption or damage, you will not be able to reliably perform a full recovery.