Handbook of Local Area Networks, 1998 Edition:LAN Management Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next Continuous Backup and Transaction Tracking The techniques described previously allow a system to be restored to its state at the time of the last backup. How often a backup is done depends on how critical the data is. A company’s financial files might get backed up twice a day while routine correspondence might be copied only every two days. Some data is so critical that a business cannot afford to lose any of it. For these instances, a continuous file history can be recorded. Often this type of data is found in online data base systems. Most serious data base systems maintain a separate log of transactions. There are various reasons for doing this that include backing out transactions to correct errors. This log can also be effectively used for providing continuous backup. If a consistent backup of the data base is made, and then the transaction log is backed up frequently, a system can be restored to the time of the last transaction captured by restoring the backup and then reapplying each of the transactions. It is good practice, then, to store the transaction log on a disk other than the one the data resides on, and to have it backed up frequently or even duplexed. When a full backup of the data base is performed a new log file should be started. The log file itself should then be backed up repeatedly, as often as after every transaction is written to it. This same technique can be applied to important non-data base files by acquiring a system that supports continuous backup. These systems basically capture a baseline backup of the files of interest and then create their own log of all the writes to those files. Using this technique, a file can be restored to the time of the last write. Tracking the File History and Recovering Files Knowing what media to use when recovering a whole volume is often straightforward. As described above, the last full backup is restored and then the necessary partial backups are applied, depending on what type of backup strategy has been employed. Usually the media is physically labeled and this is all that is necessary. To recover individual files or groups of files, however, the communications manager must know what media is being used. Even if the most recent version is desired, knowing which media it is on is not always obvious and finding it without the help of the file history system can be tedious. It is important for file history or backup systems to keep an online data base that tracks all versions of files and where they are stored. Various approaches to finding these files can then be supported. When the primary file system is used, a file is referred to by its unique path name (i.e., the volume, directory, and file name used for storing it). Well-designed history data bases support this same view of files and their relationships. Users can then browse the backup file history much as they would browse the directory of the primary file system. When a particular file is selected, each of its versions and their location can be displayed. A common type of user’s request is “Recover my spreadsheet; it was called BUD. . . something. I had it a few months ago.” To find such a file, locating it by name or type is a good approach. The file history system should support searching by file name, by extent, and permit the use of wildcards (e.g., those supported in the DOS and Novell operating systems directories). Another approach is to locate the file by the save set to which it was copied. A save set is a grouping of data that was all copied to a backup media together. Most backup systems that have online data support some method for tracking the files as they were stored. Tracking a file by save set allows looking for a file as it existed at a particular time. MEDIA ROTATION SCHEMES So far this chapter has not discussed how long each copy of a file is to be kept. In the previous discussions it has been implicit that when a copy has been made it is henceforth always available. This is not usually necessary, or cost effective; it would mean always buying new storage media to replace the ones that fill up. When a file has been superseded by later versions it is, after some period of time, usually not required. Keeping too few copies of files, however, can seriously diminish the security of the data, and so tradeoffs are almost inevitable. The speed with which files can be restored, the amount of time available for backup, and the amount of data also enter into the equation. Various schemes for reusing media are employed, both as a cost saving measure and to keep system clutter (e.g., data base size and number of tapes) under control. When media are reused, previously backed up data is overwritten. The file history data base must be updated to reflect the media’s new contents. Most backup data bases remove all the files stored on a tape when the user indicates that a tape is to be reused. The administrator should know four things in order to make appropriate decisions about media rotation: •  The periods each day when the network is fairly dormant (the backup window). •  The amount of data on the network disks. •  The expected time that would be available to the manager to perform a full system restoration. •  How far back in time the file history must go. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.