Recovery

11.7 Recovery

11.7.1 Consistency Checking

  • The storing of certain data structures ( e.g. directories and inodes ) in memory and the caching of disk operations can speed up performance, but what happens in the result of a system crash? All volatile memory structures are lost, and the information stored on the hard drive may be left in an inconsistent state.
  • A Consistency Checker ( fsck in UNIX, chkdsk or scandisk in Windows ) is often run at boot time or mount time, particularly if a filesystem was not closed down properly. Some of the problems that these tools look for include:
    • Disk blocks allocated to files and also listed on the free list.
    • Disk blocks neither allocated to files nor on the free list.
    • Disk blocks allocated to more than one file.
    • The number of disk blocks allocated to a file inconsistent with the file's stated size.
    • Properly allocated files / inodes which do not appear in any directory entry.
    • Link counts for an inode not matching the number of references to that inode in the directory structure.
    • Two or more identical file names in the same directory.
    • Illegally linked directories, e.g. cyclical relationships where those are not allowed, or files/directories that are not accessible from the root of the directory tree.
    • Consistency checkers will often collect questionable disk blocks into new files with names such as chk00001.dat. These files may contain valuable information that would otherwise be lost, but in most cases they can be safely deleted, ( returning those disk blocks to the free list. )
  • UNIX caches directory information for reads, but any changes that affect space allocation or metadata changes are written synchronously, before any of the corresponding data blocks are written to.

11.7.2 Log-Structured File Systems ( was 11.8 )

  • Log-based transaction-oriented ( a.k.a. journaling ) filesystems borrow techniques developed for databases, guaranteeing that any given transaction either completes successfully or can be rolled back to a safe state before the transaction commenced:
    • All metadata changes are written sequentially to a log.
    • A set of changes for performing a specific task ( e.g. moving a file ) is a transaction.
    • As changes are written to the log they are said to be committed, allowing the system to return to its work.
    • In the meantime, the changes from the log are carried out on the actual filesystem, and a pointer keeps track of which changes in the log have been completed and which have not yet been completed.
    • When all changes corresponding to a particular transaction have been completed, that transaction can be safely removed from the log.
    • At any given time, the log will contain information pertaining to uncompleted transactions only, e.g. actions that were committed but for which the entire transaction has not yet been completed.
      • From the log, the remaining transactions can be completed,
      • or if the transaction was aborted, then the partially completed changes can be undone.

11.7.3 Other Solutions ( New )

  • Sun's ZFS and Network Appliance's WAFL file systems take a different approach to file system consistency.
  • No blocks of data are ever over-written in place. Rather the new data is written into fresh new blocks, and after the transaction is complete, the metadata ( data block pointers ) is updated to point to the new blocks.
    • The old blocks can then be freed up for future use.
    • Alternatively, if the old blocks and old metadata are saved, then a snapshot of the system in its original state is preserved. This approach is taken by WAFL.
  • ZFS combines this with check-summing of all metadata and data blocks, and RAID, to ensure that no inconsistencies are possible, and therefore ZFS does not incorporate a consistency checker.

11.7.4 Backup and Restore ( was 11.7.2 )

  • In order to recover lost data in the event of a disk crash, it is important to conduct backups regularly.
  • Files should be copied to some removable medium, such as magnetic tapes, CDs, DVDs, or external removable hard drives.
  • A full backup copies every file on a filesystem.
  • Incremental backups copy only files which have changed since some previous time.
  • A combination of full and incremental backups can offer a compromise between full recoverability, the number and size of backup tapes needed, and the number of tapes that need to be used to do a full restore. For example, one strategy might be:
    • At the beginning of the month do a full backup.
    • At the end of the first and again at the end of the second week, backup all files which have changed since the beginning of the month.
    • At the end of the third week, backup all files that have changed since the end of the second week.
    • Every day of the month not listed above, do an incremental backup of all files that have changed since the most recent of the weekly backups described above.
  • Backup tapes are often reused, particularly for daily backups, but there are limits to how many times the same tape can be used.
  • Every so often a full backup should be made that is kept "forever" and not overwritten.
  • Backup tapes should be tested, to ensure that they are readable!
  • For optimal security, backup tapes should be kept off-premises, so that a fire or burglary cannot destroy both the system and the backups. There are companies ( e.g. Iron Mountain ) that specialize in the secure off-site storage of critical backup information.
  • Keep your backup tapes secure - The easiest way for a thief to steal all your data is to simply pocket your backup tapes!
  • Storing important files on more than one computer can be an alternate though less reliable form of backup.
  • Note that incremental backups can also help users to get back a previous version of a file that they have since changed in some way.
  • Beware that backups can help forensic investigators recover e-mails and other files that users had though they had deleted!
Subscribe to: Posts (Atom)