DFS Backup

(version 0.2)

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.
  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:
      1. Items: record of tape of period
      2. Attributes:
        1. date
        2. fileset
        3. level: backup level (full, differential)
    2. Entity:
      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
  2. Database Format: There are several possibilities how to store database:
    1. Real database (relational or OO) programs:
      1. +: Efficient.
      2. +: Fast.
      3. +: Small (compressed).
      4. -: May cost money (if commercial).
      5. -: May require significant amount of work (if home-made).
      6. -: Not human readable.
      7. -: Recovery after corruption problematic.
    2. Plain file:
      1. +: Easy to implement.
      2. +: Human readable.
      3. +: Recovery after corruption possible.
      4. -: Unefficient.
      5. -: Slow.
      6. -: Quite big.
    3. Directory structure:
      1. +: Efficient.
      2. +: Fast.
      3. +: Easy to implement.
      4. +: Human readable.
      5. +: Recovery after corruption possible.
      6. -: Quite big.
    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.
    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.
  3. Schema Content:
    1. backup:
      1. when (what time)
      2. what (what Entity)
      3. how (what level)
    2. command:
      1. when (what time)
      2. what (what to perform)
  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.a* full
      22  2 * * 4 BackupEngine dump user.a* full:first
      22  2 * * 5 BackupEngine dump user.a* full:first:second
      22  2 * * 6 BackupEngine dump user.a* full:first
      22  2 * * 0 BackupEngine dump user.a* full:first:second
      22  2 * * 1 BackupEngine dump user.a* full:first
      22  2 * * 2 BackupEngine dump user.a* full:first:second
      23  2 * * 4 BackupEngine dump user.b* full
      23  2 * * 5 BackupEngine dump user.b* full:first
      23  2 * * 6 BackupEngine dump user.b* full:first:second
      23  2 * * 0 BackupEngine dump user.b* full:first
      23  2 * * 1 BackupEngine dump user.b* full:first:second
      23  2 * * 2 BackupEngine dump user.b* full:first
      23  2 * * 3 BackupEngine dump user.b* full:first:second
  5. Options:
    1. Items:
      1. dbHome: <directory>
      2. tape: <dev-file>
    2. Example:

      3. dbHome: /var/backupDB
      tape: /dev/rmt8

Proccess Decomposition

  1. BackupEngine: The proccess taking care of backup. Accepts calls, usually from cron.
    1. clone(<entity>): Creates backup clone.
    2. updateDB(<entity>, <dbName>): Updates database.
    3. prepareDump(<entity>): Prepares dump.
    4. dump(<entity>, <level>): Performs the dump.
  2. RestoreEngine: The program taking care of restore. Runs only on demand. Containes GUI. Is available to end-users.
    1. restore(<entity>, <dbName>): Performs the restore.
    2. find(<entity>, <dbName>): Finds the Entity to restore.
  3. DatabaseManager: The only program talking to databases. Usually not used directly by users.
    1. create(<dbName>, <dbPlace>): Creates new database (both levels).
    2. add(<entity>, <dbName>): Adds Entity.
    3. remove(<entity>, <dbName>): Removes Entity.
    4. find(<entity>, <dbName>): Finds Entity.
    5. certify(<entity>, <dbName>): Certifies Entity.
    6. check(<dbName>, <period>:<tape>:<record>): Checks information from tape against database.
    7. update(<dbName>, <period>:<tape>:<record>): Updates information in database from tape.
    8. dump (<dbName>, <file>): Backups database itself.
    9. restore(<dbName>, <file>): Restores database itself.
  4. SystemInterface: The interface to system functions:
    1. dump(<fileset>, <tape>, <version>): Performs dump.
    2. restore(<fileset>, <tape>, <server>, <aggregate>): Performs restore.
    3. tape(<period>:<tape>:<record>): Puts tape into drive and position it. Ask Operator if neccessary.
  5. Tape Manager: The only program talking to tape drives. Interface to tape drive functions. Usually noy used directly by users.
    1. tape(<tape>): Puts tape into drive.
    2. label(<label>): Labels tape currently in drive.
    3. position(<record>): Positions current tape.
    4. record(): Finds, where current tape is positioned.
  6. ConfigurationManager: The only program updating the configuration data. Containes GUI. Stores all information in standard place.
    1. dataBase(<dbName>): Creates database.
    2. setSchema(<dbName>): Reads the whole schema from STDIN.
    3. getSchema(<dbName>): Writes the whole schema into STDOUT.
    4. setOptions(<dbName>): Reads options from STDIN.
    5. getOptions(<dbName>): Writes options into STDOUT.
    6. option(<dbName>, <optionName>): Gets single option.
    7. setPeriod(<dbName>, <period>): Sets current period.
    8. getPeriod(<dbName>): Gets current period.

Functional Decomposition

  1. Backup Initialisation:
    1. ConfigurationManager.setOptions(<dbName>) < Options.txt
    2. ConfigurationManager.dataBase(<dbName>)
      1. DatabaseManager.create(<dbName>, <dbPlace>)
    3. ConfigurationManager.setSchema(<dbName>) < Schema.txt
    4. ConfigurationManager.setPeriod(<dbName>, <period>)
  2. Backup:
    1. BackupEngine.updateDB(<entity>, <dbName>)
      1. DatabaseManager.add(<entity>, <dbName>)
    2. BackupEngine.dump(<entity>)
    3. BackupEngine.certifyDB(<entity>, <dbName>)
      1. DatabaseManager.certify(<entity>, <dbName>)

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.

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.

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: Design Review (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
J.Hrivnac, 6Oct97