|< Day Day Up >|| |
Once you have established the SLA, you can choose a backup method. There are several methods available, and the choice depends on your particular requirements.
The most simple and effective backup method is the classical backup. In this case, you simply save the files containing the database on tape. Because copying data on tape is a time-consuming process, you should copy the file first to a new location and then execute the backup. In theory, you do not have to close the database during the copy process. However, if you do not close the database, you have no guarantee of data consistency. If files are updated in the database while it is being copied, you will not know exactly which data has been updated and which has not. Because copying the database file on disk should take much less time than copying on tape, it is better to close the directory server during the copy process.
This is the backup method offered by the system administrator (or, better, by the operators). This backup strategy is very effective because it is based on proven methods. You may copy not only the data files, but also administrative information such as configuration files. Normally, every enterprise has such an optimized backup strategy in place to guarantee that there will be no data loss after hardware or software failures. In the event of a hardware failure, it is clear that it takes some time to replace the damaged devices, to reboot the system, and to install the backup data if necessary. Depending on the type of maintenance contract and the type of hardware failure, the service may be unavailable for a couple of days.
If this is not acceptable, you can install redundant hardware. For example, you could use disk mirroring to continue the service in the event of a disk crash.
You can also back up the directory and its configuration files at regular intervals so that it can be reinstalled on the same or a different server after a disaster. There are two ways to do this. You can execute a search and save the result on tape or other device, or you can simply export the whole directory. This type of backup is helpful if your directory has been destroyed because of an error in an application program. However, it may not be enough simply to dump out only the directory. You will also need the schema and several configuration files to reconstruct completely. Look at the documentation that ships with the directory server to understand what, exactly, you need to save.
Replication is another backup possibility. If you have your directory server replicated, you still have one server running should one of the two servers be down. If you have a master-slave replication environment, it depends on which of the servers is down. If the slave server is down, you simply wait until it is available again and then replicate the whole server again. If the master server is down, you cannot update the directory for the time the server is not working. If you have a master-master or multimaster environment, it does not matter which of the servers are down because you have more than one master.
Replication can also be combined with the other backup methods. The slave server can be used for offline backup as described in the section about replication in Chapter 5. Once the backup has finished, take the slave server online again and the replication process will align the slave server in case of updates of the directory during the backup.
You have, however, a consistent backup even if during the backup updates occurred on the directory.
|< Day Day Up >|| |