DFS Backup

(version 0.3)

Mission Statement

Due to serious deficiencies in the standard DFS backup system, which makes is unsuitable for CERN requirements, new backup system will be developed locally in CERN. The developed backup system will be flexible, easily maintainable and will offer simple interface for operator tasks and for end-user tasks. The procedures for dealing with unexpected situations will be included. It will be possible to reuse the package with different uderlaying backup mechanism in future.
The alpha version of the backup system should be ready in September 97, followed by beta version in October 97. The full package should be in operation in till the end of  97.

Case Study

  1. Normal Operation
    1. Backup Initialisation: The Database is created, jobs are scheduled.
    2. Backup Dump: The Database is dumped.
    3. Backup: Backup runs unattended under normal circumstances. The only required operator actions are visual labeling of new tapes and changing tapes in certain times.
    4. Recent Restore: Restore of entities backuped within current period works without operator attendance. User will reclaim those entities via standard interface.
    5. Old Restore: For restore of entities from previous periods, operator may be required to put certain tapes into drive. For user, this operation looks the same as Recent Restore.
  2. Problems
    1. Backup Recovery: The corrupted Database is restored.
    2. Filesystem Crash: Restore after aggregate or partition is lost  is just normal Restore.
    3. Tape Unreadable: If any tape is unreadable, restore will be done with most recent available backup and new backup (new phase) will be started immediately to replace bad tape.
    4. Server Crash: If server crashes, the full set of data will be restored on another (new) server.
    5. Database Lost: If the Database is lost, one of backup copies of that database will be used. The database can be recreated from information stored in tapes.
    6. Backup Failure: If any backup phase fails, it will be restarted immediately when possible. Next phase may be postponed till failed phase is performed.

Requirements

Definitions

  1. Period: The time when subsequent backups are placed in one set of tapes.
  2. Current Period: Period, with tapes still inside the drives.
  3. Entity: Set of data, which is backuped or restored together (usually fileset).
  4. Schema: The prescription, how and when are certain Entities backuped.
  5. Database: The system which keeps all information about Schemas and performed backups.

Requirements

  1. Functional Requirements
    1. Standard Backup: Under normal circumstances backup should run without operator intervention, except for periodic visual labeling and changing tapes in the begining of period.
    2. Restore of Recent Backup: Under normal circumstances restore of entities backuped within current period should run without operator attendance.
    3. Restore of Old Backup: Restore entity which is not present on current period (either at all or the required version) should be possible. Operator attendance may be required.
    4. Entity Description: Each Entity should have unique description.
    5. Database Lost: There should be at least two copies of the Database on different mediae.
    6. Database Structure: Database should be structured in human readable format.
    7. Schema Change: It should be possible to change Schema between two Periods.
    8. Backup Entities: These Entities should be available for Backup:
      1. Fileset.
    9. Restore Entities: These Entities should be available for Restore:
      1. Single directory.
      2. Fileset.
    10. Period Duration: Period should last at least one week.
    11. Period Periodicity: All periods should last the same time.
    12. Period Content: Set of tapes for one Period should contain at least one Full Backup of all backuped Entities.
    13. Backup UI: User interface for Backup operation should exist.
    14. Restore UI: User interface for Restore operation should exist.
    15. User Documentation: User Documentation should be available.
    16. Operator Documentation: Operator Documentation should be available.
    17. Developper Documentation: Developper Documentation should be available.
  2. System Properties
  3. Constrains
    1. Implementation Language: System should be implemented in scripting language.
    2. Modularity: Each tasks should be performed by single program unit.

Design

Design Choises

  1. Database Content: There are two parts of the database:
    1. Dump (This part is optional. It is not required for succesfull dumps and restores. It can be used to check the dump content of tapes and it can be used for recreating of the destroyed or lost database):
      1. Items: record of tape of period
      2. Attributes:
        1. date
        2. fileset
        3. level: backup level
    2. Entity (This part is mandatory. It stores all information needed for succesfull dumps and backups. It should be backuped itself frequently. It can be restored from information available from tapes and/or from the Dump part.):
      1. Items:
        1. fileset
        2. directory of fileset
      2. Attributes:
        1. dump: connection to Dump database entry
        2. children
        3. parents
        4. place: position of Entity in in original subsystem
        5. date
        6. period
        7. tape
        8. record
        9. level
  2. Database Format: There are several possibilities how to store database (real database, plane file, directory structure). The directory structure format seems to satisfy best our requirements. Possibilities of using other approaches may be added later, including functions making trasformations between various formats.

    3. The database is structured in following way::
    1. Dump:
      1. Structure: <period>/<tape>/<record>
      2. Attributes:
        1. date:<yyyy:mm:dd:hh:mm:ss>
        2. fileset:<xxx>
        3. level:<aaa[:aaa]>
      3. Example:
        • A
          • 0
            • fileset:user.hrivnac
            • 000
              • date:1997:09:05:02:00:00
              • level:full
            • 001
              • date:1997:09:06:02:00:00
              • level:full:first
          • 1
        • B
    2. Entity:
      1. Structure: <fileset>[/<directory>[/<directory>]][/.../<attributes>]
        1. Attributes:
          1. <period>:<tape>:<record>:<data>:<level>
      2. Example:
        • user
          • hrivnac
            • ...
              • A:0:001:1997:09:05:02:00:00:full
              • A:3:001:1997:09:06:02:00:00:full:first
            • work
    Not all attributes are stored for all Entities. Some attributes may have different format depending on other attributes. If any entry doesn't contain any needed attribute, the attribute situated higher in the hierarchy is used. Non-existence of Entity children doesn't mean that they are not backuped, it only means that they cannot be recovered as single Entities. As fileset itself is mapped into directory hierarchy (replacing "." with "/"), system finds out where real directory starts by the existence of "..." subdirectory.
  3. Schema Content:
    1. backup:
      1. when (what time)
      2. what (what entity)
      3. how (what level)
  4. Schema Format: <cron time> [<fileset> <level>[/<level>]|command] [# comment]

    5. Schema is formated like standard crontab. It allows using of the Schema as input to cron for scheduling.
    1. Example:

      2. 22  2 * * 3 BackupEngine dump user.hrivnac full              0
      22  2 * * 4 BackupEngine dump user.hrivnac full:first        0
      22  2 * * 5 BackupEngine dump user.hrivnac full:first:second 0
      22  2 * * 6 BackupEngine dump user.hrivnac full:first        0
      22  2 * * 0 BackupEngine dump user.hrivnac full:first:second 0
      22  2 * * 1 BackupEngine dump user.hrivnac full:first        0
      22  2 * * 2 BackupEngine dump user.hrivnac full:first:second 0
      23  2 * * 4 BackupEngine dump user.rtb     full              1
      23  2 * * 5 BackupEngine dump user.rtb     full:first        1
      23  2 * * 6 BackupEngine dump user.rtb     full:first:second 1
      23  2 * * 0 BackupEngine dump user.rtb     full:first        1
      23  2 * * 1 BackupEngine dump user.rtb     full:first:second 1
      23  2 * * 2 BackupEngine dump user.rtb     full:first        1
      23  2 * * 3 BackupEngine dump user.rtb     full:first:second 1
  5. Options:
    1. Items:
      1. tape: <dev-file>
      2. blocksize: <tape block size>
    2. Example:

      3. tape: /dev/rmt8
      blocksize: 16k

Proccess Decomposition

See StP.
 

Functional Decomposition

See StP.

Implementation

Implementation Choises

  1. Implementation Language: The system will be implemented in Tcl language. This allows easy access into DCE/DFS functionality and allows later easy implementation of GUI front-end based on Tk package. As all functions are totaly independent, any of them can be replaced by function implemented by any other language (for example Perl).

Examples

Initialisation

Backup+Restore Test

Project Diary

  1. 21Jul-25Jul: Initial Case Study and Requirements Definition (version 0.1)
    1. General Case Study and URD created.
  2. 4Aug-6Aug: Initial Design (version 0.1)
    1. Database format desided (filesystem).
    2. Schema format desided.
    3. Proccess and Functional Decomposition done.
    4. Implementation languaga chosen (Tcl).
    5. Proccess skeletons created.
  3. 7Aug-8Aug: Initial Design (version 0.2)
    1. Period renamed from number lo letter.
    2. Updating database from tape added.
    3. Links fom Entity database to Dump database replaced by full description.
    4. TapeManager proccess added.
    5. BackupEngine.certify erased.
    6. Schedule reformat to have standard crontab format.
  4. 1Sep-23Sep: Prototype implememntation (version 0.3)
    1. Database handling.
    2. Dump to files (full and incremental).
    3. Restore from fles (full and incremental).

Project Plan

  1. 21Jul-25Jul: Initial Case Study and Requirements Definition (version 0.1)
  2. 4Aug-8Aug: Initial Design (version 0.2)
  3. 25Aug-29Aug: Full Design (version 0.2)
  4. September: Implementation (alpha)
  5. October: Full Cycle (beta)
  6. November: Full Cycle (version 1.0)
  7. December: Deployment.

previous versions: 0.1, 0.2
J.Hrivnac, 6Oct97