Almost all applications store their data in file systems or in databases. Therefore, in this section we will examine the backup of file servers (Section 7.9) and in the next section we will look more closely at that of databases (Section 7.10). The chapter concludes with organizational aspects of networkbackup(Section7.11).
Almost all applications store their data in file systems or in databases. Therefore, in this section we will examine the backup of file servers (Section 7.9) and in the next section we will look more closely at that of databases (Section 7.10). The chapter concludes with organizational aspects of networkbackup(Section7.11). This section first of all discusses fundamental requirements and problems in the backup of file servers (Section 7.9.1). Then a few functions of modern file systems will be introduced that accelerate the incremental backup of file systems (Section 7.9.2). Limitations in the backup of
7.9.1 Backup of file servers
We use the term file server to include computers with a conventional operating system such as Windows or Unix that exports part of its local file systems via a network file system or makes it accessible as service (Novell, FTP, HTTP). The descriptions in this section can be transferred to all types of computers, from user PCs through classical file servers to the web server.
File servers store three types of information:
- data in the form of files;
- metadata on these files such as file name, creation date and access rights; and
- metadata on the file servers such as any authorized users and their groups, size of the individual file systems, network configuration of the file server and names, components and rights of files or directories exported over the network.
Depending upon the error situation, different data and metadata must be restored. The restoring of individual files or entire file systems is relatively simple: in this case only the file contents and the metadata of the files must be restored from the backup server to the file server. This function is performed by the backup clients introduced in Section 7.4.
Restoring an entire file server is more difficult. If, for example, the hardware of the file server is irreparable and has to be fully replaced, the following steps are necessary:
- Purchasing and setting up of appropriate replacement hardware.
- Basic installation of the operating system including any necessary patches
- Restoration of the basic configuration of the file server including LAN and storage network configuration of the file server.
- If necessary, restoration of users and groups and their rights.
- Creation and formatting of the local file systems taking into account the necessary file system sizes.
- Installation and configuration of the backup client.
- Restoration of the file systems with the aid of the network backup system.
This procedure is very labour-intensive and time-consuming. The methods of so-called Image Restore (also known as Bare Metal Restore) accelerate the restoration of a complete computer: tools such as 'mksysb' (AIX), 'Web Flash Archive' (Solaris) or various disk image tools for Windows systems create a complete copy of a computer (image). Only a boot diskette or boot CD and an appropriate image is needed to completely restore a computer without having to work through steps 2–7 described above. Particularly advantageous is the integration of image restore in a network backup system: to achieve this the network backup system must generate the appropriate image. Furthermore, the boot diskette or boot CD must create a connection to the network backup system.
7.9.2 Backup of file systems
For the classical network backup of file systems, backup on different levels (block level, file level, file system image) has been discussed in addition to the incremental-forever strategy. The introduction of storage networks makes new methods available for the backup of file systems such as server-free backup, application server-free backup, LAN-free backup, shared disk file systems and instant copies.
The importance of the backup of file systems is demonstrated by the fact that manufacturers of file systems are providing new functions specifically targeted at the acceleration of backups. In the following we introduce two of these new functions – the so-called archive bit and block level incremental backup.
The archive bit supports incremental backups at file level such as, for example, the incremental-forever strategy. One difficulty associated with incremental backups is finding out quickly which files have changed since the previous backup. To accelerate this decision, the file system adds an archive bit to the metadata of each file: the network backup system sets this archive bit immediately after it has backed a file up on the backup server. Thus the archive bits of all files are set after a full backup. If a file is altered, the file system automatically clears its archive bit. Newly generated files are thus not given an archive bit. In the next incremental backup the network backup system knows that it only has to back up those files for which the archive bits have been cleared.
The principle of the archive bit can also be applied to the individual blocks of a file system in order to reduce the cost of backup on block level. In Section 7.4 a comparatively expensive procedure for backup on block level was introduced: the cost of the copying and comparing of files by the backup client is greatly reduced if the file system manages the quantity of altered blocks itself with the aid of the archive bit for blocks and the network backup system can call this up via an interface.
Unfortunately, the principle of archive bits cannot simply be combined with the principle of instant copies: if the file system copies uses instant copy to copy within the disk subsystem for backup (Figure 7.11), the network backup system sets the archive bit onlyon the copy of the file system. In the original data the archive bit thus remains cleared even though the data has been backed up. Consequently, the network backup system backs this data up at the next incremental backup because the setting of the archive bit has not penetrated through to the original data.
7.9.3 Backup of NAS servers
NAS servers are preconfigured file servers; they consist of one or more internal servers, preconfigured disk capacity and usually a stripped-down or specific operating system (Section 4.2.2). NAS servers generally come with their own backup tools. However, just like the backup tools that come with operating systems, these tools represent an isolated solution (Section 7.1). Therefore, in the following we specifically consider the linking of the backup of NAS servers into an existing network backup system.
The optimal situation would be if there were a backup client for a NAS server that was adapted to suit both the peculiarities of the NAS server and also the peculiarities of the network backup system used. Unfortunately, it is difficult to develop such a backup client in practice:
- If the NAS server is based upon a specific operating system the manufacturers of the network backup system sometimes lack the necessary interfaces and compilers to develop such a client. Even if the preconditions for the development of a specific backup client were in place, it is doubtful whether the manufacturer of the network backup system would develop a specific backup client for all NAS servers: the necessary development cost for a new backup client is still negligible in comparison to the testing cost that would have to be incurred for every new version of the network backup system.
- Likewise, it is difficult for the manufacturers of NAS servers to develop such a client. The manufacturers of network backup systems publish neither the source code nor the interfaces between backup client and backup server, which means that a client cannot be developed. Even if such a backup client already exists because the NAS server is based upon on a standard operating system such as Linux, Windows or Solaris, this does not mean that customers may use this client: in order to improve the Plug&Play- capability of NAS servers, customers may only use the software that has been tested and certified by the NAS manufacturer. If the customer installs non-certified software, then he can lose support for the NAS server. Due to the testing cost, manufacturers of NAS servers may be able to support some, but certainly not all network backup systems.
Without further measures being put in place, the only possibility that remains is to back the NAS server up from a client of the NAS server (Figure 7.12). However, this approach, too, is doubtful for two reasons:
- First, this approach is only practicable for smaller quantities of data: for backup the files of the NAS server are transferred over the LAN to the network file system client on which the backup client runs. Only the backup client can write the files to the backup medium using advanced methods such as LAN-free backup.
- Second, the backup of metadata is difficult. If a NAS server supports the export of the local file system both via CIFS and also via NFS then the backup client only accesses one of the two protocols on the files – the metadata of the other protocol is lost. NAS servers would thus have to store their metadata in special files so that the network backup system can back these up. There then remains the question of the cost for the restoring of a NAS server or a file system. The metadata of NAS servers and files has to be re-extracted from these files. It is dubious whether network backup systems can automatically initiate this process.
As a last resort for the integration of NAS servers and network backup systems, there remains only the standardization of the interfaces between the NAS server and the network backup system. This would mean that manufacturers of NAS servers would only have to develop and test one backup client that supports precisely this interface. The backup systems of various manufacturers could then back up the NAS server via this interface. In such an approach the extensivity of this interface determines how well the backup of NAS servers can be linked into a network backup system. The next section introduces a standard for such an interface – the Network Data Management Protocol (NDMP).
Figure 7.12 When backing up a NAS server over a network file system, the connection between the NAS server and backup client represents a potential performance bottleneck. Backup over a network file system makes it more difficult to back up and restore the metadata of the NAS server
7.9.4 The Network Data Management Protocol (NDMP)
The Network Data Management Protocol (NDMP) defines an interface between NAS servers and network backup systems that makes it possible to back up NAS servers without providing a specific backup client for them. More and more manufacturers – both of NAS servers and network backup systems – are supporting NDMP. The current version of NDMP is Version 4; Version 5 is in preparation.
NDMP uses the term 'data management operations' to describe the backup and restoration of data. A so-called data management application (DMA) – generally a backup system – initiates and controls the data management operations, with the execution of a data management operation generally being called an NDMP session. The DMA cannot directly access the data; it requires the support of so-called NDMP services (Figure 7.13). NDMP services manage the current data storage, such as file systems, backup media and tape libraries. The DMA creates an NDMP control connection for the control of every participating NDMP service; for the actual data flow between source medium and backup medium a so-called NDMP data connection is established between the NDMP services in question. Ultimately, the NDMP describes a client-server architecture, with the DMA taking on the role of the NDMP client. An NDMP server is made up of one or more NDMP services. Finally, the NDMP host is the name for a computer that accommodates one or more NDMP servers.
NDMP defines different forms of NDMP services. All have in common that they only manage their local state. The state of other NDMP services remains hidden to an NDMP service. Individually, NDMP Version 4 defines the following NDMP services:
- NDMP Data Service The NDMP data service forms the interface to primary data such as a file system on a NAS server. It is the source of backup operations and the destination of restore operations. To backup a file system, the NDMP Data Service converts the content of the file system into a data stream and writes this in an NDMP data connection, which is generally created by means of a TCP/IP connection. To restore a file system it reads the data stream from an NDMP data connection and from this reconstructs the content of a file system. The Data Service only permits the backup of complete file systems; it is not possible to back up individual files. By contrast, individual files or directories can be restored in addition to complete file systems.
- NDMP Tape Service The NDMP Tape Service forms the interface to the secondary storage. Secondary storage, in the sense of NDMP, means computers with connected tape drive, connected tape library or a CD burner. The Tape Service manages the destination of a backup or the source of a data restoration operation. For a backup, the Tape Service writes an incoming data stream to tape via the NDMP data connection; for a restoration it reads the content of a tape and writes this as a data stream in a NDMP data connection. The Tape Service has only the information that it requires to read and write, such as tape size or block size. It has no knowledge of the format of the data stream. It requires the assistance of the DMA to change tapes in a tape library.
- NDMP SCSI Pass Through Service The SCSI Pass Through Service makes it possible for a DMA to send SCSI commands to a SCSI device that is connected to a NDMP server. The DMA requires this service, for example, for the changing of tapes in a tape library.
Figure 7.13 NDMP standardizes the communication between the data management application (DMA) – generally a backup system – and the NDMP services (NDMP data service, NDMP tape service), which represent the storage devices. The communication between the NDMP services and the storage devices is not standardized
The DMA holds the threads of an NDMP session together: it manages all state information of the participating NDMP services, takes on the management of the backup media and initiates appropriate recovery measures in the event of an error. To this end the DMA maintains an NDMP control connection to each of the participating NDMP services, which – like the NDMP data connections – are generally based upon TCP/IP. Both sides – DMA and NDMP services – can be active within an NDMP session. For example, the DMA sends commands for the control of the NDMP services, whilst the NDMP services for their part send messages if a control intervention by the DMA is required. If, for example, an NDMP Tape Service has filled a tape, it informs the DMA. This can then initiate a tape change by means of an NDMP SCSI Pass Through Service.
The fact that both NDMP control connections and NDMP data connections are based upon TCP/IP means that flexible configuration options are available for the backup of data using NDMP. The NDMP architecture supports backup to a locally connected tape drive (Figure 7.14) and likewise to a tape drive connected to another computer, for example a second NAS server or a backup server (Figure 7.15). This so-called remote backup has the advantage that smaller NAS servers do not need to be equipped with a tape library. Further fields of application of remote backup are the replication of file systems (disk-to-disk remote backup) and of backup tapes (tape-to-tape remote backup)..
Figure 7.14 NDMP data service, NDMP Tape Service and NDMP SCSI Pass Through Service all run on the same computer in a local backup using NDMP. NDMP describes the protocols for the NDMP control connection (1) and the NDMP data connection (2). The communication between the NDMP services and the storage devices is not standardized (3)
In remote backup the administrator comes up against the same performance bottlenecks as in conventional network backup over the LAN (Section 7.6). Fortunately, NDMP local backup and LAN-free backup of network backup systems complement each other excellently: a NAS server can back up to a tape drive available in the storage network, with the network backup system co-ordinating access to the tape drive outside of NDMP by means of tape library sharing (Figure 7.16).
Figure 7.15 In a backup over the LAN (remote backup) the NDMP tape service runs on the computer to which the backup medium is connected. The communication between the remote services is guaranteed by the fact that NDMP control connections (1) and NDMP data connections (2) are based upon TCP/IP. The backup server addresses the tape library locally, which means that the NDMP SCSI Pass Through Service is not required here
Figure 7.16 NDMP local backup can be excellently combined with the LAN-free backup of network backup systems
In Version 5, NDMP will have further functions such as multiplexing, compressing and encryption. To achieve this, NDMP Version 5 expands the architecture to include the so-called translator service (Figure 7.17). Translator services process the data stream (data stream processor): they can read and change one or more data streams. The implementation of translator services is in accordance with that of previous NDMP services. This means that the control of the translator service lies with the DMA; other participating NDMP services cannot tell whether an incoming data stream was generated by a translator service or a different NDMP service. NDMP Version 5 defines the following translator services:
- Data stream multiplexing The aim of data stream multiplexing is to bundle several data streams into one data stream (N:1-multiplexing) or to generate several data streams from one (1:M-multiplexing). Examples of this are the backup of several small, slower file systems onto a faster tape drive (N:1-multiplexing) or the parallel backup of a large file system onto several tape drives (1:M-multiplexing).
- Data stream compression In data stream compression the translator service reads a data stream, compresses it and sends it back out. Thus the data can be compressed straight from the hard disk, thus freeing up the network between it and the backup medium.
- Data stream encryption Data stream encryption works on the same principle as data stream compression, except that it encrypts data instead of compressing it. Encryption is a good idea, for example, for the backup of small NAS servers at branch offices to a backup server in a data centre via a public network.
Figure 7.17 NDMP Version 5 expands the NDMP services to include translator services, which provide functions such as multiplexing, encryption and compression
NDMP offers many opportunities to connect NAS servers to a network backup system. The prerequisite for this is NDMP support on both sides. NDMP data services cover approximately the functions that backup clients of network backup systems provide. One weakness of NDMP is the backup of the NAS server metadata, which makes the restoration of a NAS server after the full replacement of hardware significantly more difficult (Section 7.9.1). Furthermore, there is a lack of support for the backup of file systems with the aid of snapshots or instant copies. Despite these missing functions
NDMP has established itself as a standard and so we believe that it is merely a matter of time before NDMP is expanded to include these functions.
Use the following table of contents to navigate to chapter excerpts or click here to view Network Backup in its entirety.
|ABOUT THE BOOK:|
|Storage networks will become a basic technology like databases or local area networks. According to market research, 70% of external storage devices will be connected via storage networks in 2003. The authors have hands-on experience of network storage hardware and software, they teach customers about concrete network storage products, they understand the concepts behind storage networks, and show customers how storage networks address their business needs. This book explains how to use storage networks to fix malfunctioning business processes, covering the technologies as well as applications -- a hot topic that will become increasingly important in the coming years.Purchase the book from Wiley Publishing|
|ABOUT THE AUTHOR:|
|Authors Ulf Troppens and Rainer Erkens are both employed at IBM TotalStorage Interoperability Center in Mainz, Germany a testing, development and demonstration laboratory for storage products and storage networks. Both authors work at the interface between technology and customers. Wolfgang Müller is currently working as a software architect in the Storage Software Development Department at IBM in Mainz, Germany, where the focus is on software development projects supporting open standards such as SMI-S/CIM/WBEM and IEEE 1244.|
This was first published in July 2007