DFS Backup

(version 0.1)

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 Recovery: The corrupted Database is restored.
    4. Backup: Backup runs unattended under normal circumstances. The only required operator actions are visual labeling of new tapes and changing tapes in certain times.
    5. Recent Restore: Restore of entities backuped within current period works without operator attendance. User will reclaim those entities via standard interface.
    6. 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. Filesystem Crash: Restore after aggregate or partition is lost  is just normal Restore.
    2. 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.
    3. Server Crash: If server crashes, the full set of data will be restored on another (new) server.
    4. Database Lost: If the Database is lost, one of backup copies of that database will be used.
    5. 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 file.
      2. Single directory.
      3. 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 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.
    18. Database Backup: The backup information (Database) itself should be backuped using at least two different techniques.
  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 real databases:
    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
        3. file of directory of fileset
      2. Attributes:
        1. dump: link 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 directoy structure format seems to satisfy best our requirements. Possibilities of using other approaches may be added later, including functions making trasformations between various formats.
    There are two real databases:
    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:
        • 000
          • 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
        • 001
    2. Entity:
      1. Structure: <fileset>[/<directory>[/<directory>]][/<file>]
      2. Attributes (stored in .../):
        1. dump:<period>:<tape>:<record> - link to Dump database
        2. children - defined by structure
        3. parents - defined by structure
        4. place - defined by structure
      3. Example:
        • user.hrivnac
          • ...
            • dump:000:0:001 -> $dbHome/$dbName/Dump/000/0/001
            • dump:000:3:001 -> $dbHome/$dbName/Dump/000/3/001
          • 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):
        1. ChangeTape: instruction to operator
  4. Schema Format: <cron time> [<fileset> <level>[/<level>]|command] [# comment]
    1. Example:

      2. 02 10 * * 2 ChangeTapes
      22  2 * * 3 user.hrivnac full
      22  2 * * 4 user.hrivnac full:first
      22  2 * * 5 user.hrivnac full:first:second
      22  2 * * 6 user.hrivnac full:first
      22  2 * * 0 user.hrivnac full:first:second
      22  2 * * 1 user.hrivnac full:first
      22  2 * * 2 user.hrivnac full:first:second
      23  2 * * 4 user.rtb     full
      23  2 * * 5 user.rtb     full:first
      23  2 * * 6 user.rtb     full:first:second
      23  2 * * 0 user.rtb     full:first
      23  2 * * 1 user.rtb     full:first:second
      23  2 * * 2 user.rtb     full:first
      23  2 * * 3 user.rtb     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. updateDB(<entity>, <dbName>): Updates both databases. New information is valid only after cerification.
    2. certifyDB(<entity>, <dbName>): Certifies the information in both databases if dump is successfull.
    3. dump(<entity>): Performs the dump.
    4. reDump(<entity>): Redoes the dump in case of failure.
  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>): Certify Entity.
  4. SystemInterface: The interface to system functions:
    1. dump(<fileset>, <tape>, <version>): Performs dump.
    2. restore(<fileset>, <tape>, <server>, <aggregate>): Performs restore.
    3. tape(<number>): Puts tape into drive.
  5. 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.

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.txt
  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-8Aug: 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.

Project Plan

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