| Database server (e.g., MySQL) | Stop the database server or use snapshots to ensure consistency between tables. | |
| Web server | Also include any data directories used by web applications. | |
| DNS nameserver | This information usually changes slowly. | |
| Desktop system, or any system accessed by individual users | Exclude cache directories such as | |
| Samba server | All directories served by Samba | |
| CUPS print server | Configuration information only; usually changes slowly. | |
| All systems | 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 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.
Given the choice between full and incremental backups, I recommend using full backups whenever practical.
6.3.1.6. Decision 2: Decide on the backup media
Cost, capacity, and speed usually drive the selection of backup media. There are many options available:
DVDR/RW
