Fedora ARM Secondary Architecture/ARM Fedora Backup Management

This is a draft only!
It is still under construction and content may change. Do not rely on this information.

Seneca CDOT ARM Project: Management Server Backup Strategy and Recovery Plan

• Phone: X33463
• Email: fedora-arm at senecacollege dot ca

Scope

This document is intended for those who are familiar with administering the ARM Project's management servers. Having knowledge of the CDOT ARM standard operation procedures may lead to a better understanding of this document.

Purpose

The purpose of this document is to describe the process for the backup and synchronization of critical data and provide example of some possible disaster recovery scenarios.

Introduction

The Fedora ARM Project is a highly active R & D project. Because of the rapid change, the project required some specific backup strategies to be implemented on top of regular backup strategies. In the event of an emergency, this document should provide enough information to re-create a similar management platform that will keep the project running.

Background

Like all Fedora projects, the ARM Project has a small yet active global community. The build firm is located in Ontario, Canada. Infrastructure support for the build firm is provided by the Seneca Center for Development and Technology at Seneca College in Toronto. The number of available ARM builders in the firm can vary. The builders are not backed up as those are easily recreated from available images.

As for the management servers, there are five major ones that are critical to this operation. For a complete list of servers and the services those offer please consult the necessary documents. These four servers are Australia (Koji builders temporary work storage), Chile (The complete ARM repository), Hongkong (Koji hub and web interface), Iraq (Central backup management and storage) and Ireland (Koji database).

Description

The backup system has been broken into two custom scripts. First one is to create local copy of the configurations and to back up the repository to removable drives, it is called blaze. The second script is called wildfire and it is to synchronize those local copies to different locations over the network. The servers get the copies of those scripts from the central backup management and storage server (iraq) via scp and runs blaze first and then wildfire. The scripts are located at:

         /usr/local/bin/

Initial Setup

++a++

Backup script explanation/source

maybe source here? possible description of it?

Backup layout example

backup layout example

source	files or folder	type of data	destination	location
hongkong	/etc	configurations	backup_server	/var/backup/
chile	/var/lib/db	database	backup_server	/var/backup/

Backup restore example

configs, database, repo commands etc...

Data Retention

• Removable drives will keep data up to 3 days old
• Network synced drives/servers will keep data up to 30 days old