Free Gide On Next generation back-up of databases

Free Gide On Next generation back-up of databases

The methods introduced in the previous section for the back-up of databases (cold backup, hot back-up and fuzzy back-up) are excellently suited for use in combination with storage networks and intelligent storage subsystems. In the following we show how the back-up of databases can be performed more efficiently with the aid of storage networks and intelligent storage subsystems. The linking of hot back-up with instant copies is an almost perfect tool for the back-up of databases. Individually, the following steps should be performed:

1. Switch the database over into hot back-up mode so that there is a consistent data set in the storage system.

2. Create the instant copy.

3. Switch the database back to normal mode.

4. Back up the database from the instant copy.

This procedure has two advantages: first, access to the database is possible throughout the process. Second, steps 1–3 only take a few seconds, so that the database system only has to catch up comparatively few transactions after switching back to normal mode. Application server-free back-up expands the back-up by instant copies in order to additionally free up the database server from the load of the back-up

The concept shown in Figure 7.11 is also very suitable for databases. Due to the large quantity  of data involved in the back-up of databases, LAN-free back-up is often used – unlike in the figure – in order to back up the data generated using instant copy. In the previous section (Section 7.10.2) we explained that the time of the last back-up is decisive for the time that will be needed to restore a database to the last data state. If the last back-up was a long time ago, a lot of archive log files have to be reapplied. In order to reduce the restore time for a database it is therefore necessary to increase the frequency of database back-ups. The problem with this approach is that large volumes of data are moved during a

complete back-up of databases. This is very tie-consuming and uses a lot of resources, which means that the frequency of back-ups can only be increased to a limited degree. Likewise, the delayed copying of the log files to a second system (Section 6.3.5) and the holding of several copies of the data set on the disk subsystem by means of instant copy can only seldom be economically justified due to the high hardware requirement and the

associated costs. In order to nevertheless increase the back-up frequency of a database, the data volume to be transferred must therefore be reduced. This is possible by means of an incremental back-up of the database on block level. The most important database systems offer backup tools for this by means of which such database increments can be generated. Many network back-up systems provide special adapters (back-up agents) that are tailored to the back-up tools of the database system in question. However, the format of the increments is unknown to the back-up software, so that the incremental-forever strategy cannot be realized in this manner. This would require manufacturers of database systems to publish

the format of the increments. The back-up of databases using the incremental-forever strategy therefore requires that the back-up software knows the format of the incremental back-ups, so that it can calculate the full back-ups from them. To this end, the storage space of the database must be

provided via a file system that can be incrementally backed up on block level using the appropriate back-up client. The back-up software knows the format of the increments so the incremental-forever strategy can be realized for databases via the circuitous route of file systems.