Heritage Operations Processing System
 

Backups

There are three parts of the makeup of HOPS:
* The website
* The documents
* The database

- The website is the interface that you use to browse HOPS and the pages that present information calculated from the data in the database.

- The documents are files that railways upload such as in the Operations Documents area or the competence decision supporting files.

- The database is what stores all the information that allows HOPS to run (such as permissions, etc) and all the information that railways enter into it (such rosters, competence, etc).


THE WEBSITE:

The website is controlled by a version control system which means we can roll back to any point in history. This would be appropriate, for example, if we made an error in the code that caused the website to stop working properly, this might be minor, such as one little function, or major such as the whole site.

To guard against the loss of the version control records (fire, etc), these are backed up off site every morning at 6.45. By the nature of a version control system it is only necessary to keep the most recent backup (as this contains all the records back to the beginning of time). This means the worst case scenario (loss of the server) we can wind the website interface back to 6.30 of the current morning.


THE DOCUMENTS:

Documents that railways upload to HOPS are backed up off site every day at 6.45am.

We only keep the most recent daily backup (as it takes a massive amount of space). This means we can retrieve documents back to 6.30 of the current morning. (If a document was accidentally deleted before 6.30am of that day, it would not form part of the most recent backup and therefore could not be retrieved).


THE DATA:

The data is backed up on the server, in case of accidental deletion or error by you or us, and also off-site in case of a catastrophic failure of the server (such as physical disk failure, fire, etc). The server is part of a professional commercial server farm with a high level of failure protection in place.

The data is now backed up every HOUR (was every 24 hours up to this week). Backups are taken at xx:17 minutes past each hour.

The hourly backups are rotated daily, so we'll keep the twenty four most recent hourly backups.

This means that we can now have a look at the state of (and restore from) the database in hourly increments for the last 24 hours in case of any accidental deletion or alteration to records (by you or us).

The daily backup system is unchanged, in that a backup is taken at 6.30 every morning that is rotated weekly, so we keep the seven most recent daily backups.

This means that we can have a look at the state of (and restore from) the database in daily increments for the last seven days in case of any accidental deletion or alteration to records (by you or us).

Saturday morning's backups are rotated monthly, so we always keep the most recent four of those.

This means that we can have a look at the state of (and restore from) the database in weekly increments for the last four weeks in case of any accidental deletion or alteration to records (by you or us).

Backups taken on the first of each month are rotated annually, so we always keep the most recent twelve of those.

This means that we can have a look at the state of (and restore from) the database in monthly increments for the last twelve months in case of any accidental deletion or alteration to records (by you or us).

Backups taken on 1st January are kept forever, back to 2011.

The first ever backup taken, 1st February 2010, will also be kept forever.

At 6.45 every morning the entire server is backed up off-site in case of a server incident (fire, flood, problem with server company, etc). The off site backup is rotated daily, so we only keep the most recent backup.

This means that, at any one time, let's say 3pm on Tuesday 28th May 2014, there will be the following backups of the data on the server:

14:17 Tuesday 28 May 2014
13:17 Tuesday 28 May 2014
12:17 Tuesday 28 May 2014
11:17 Tuesday 28 May 2014
10:17 Tuesday 28 May 2014
09:17 Tuesday 28 May 2014
08:17 Tuesday 28 May 2014
07:17 Tuesday 28 May 2014
06:17 Tuesday 28 May 2014
05:17 Tuesday 28 May 2014
04:17 Tuesday 28 May 2014
03:17 Tuesday 28 May 2014
02:17 Tuesday 28 May 2014
01:17 Tuesday 28 May 2014
00:17 Tuesday 28 May 2014
23:17 Monday 27 May 2014
22:17 Monday 27 May 2014
21:17 Monday 27 May 2014
20:17 Monday 27 May 2014
19:17 Monday 27 May 2014
17:17 Monday 27 May 2014
16:17 Monday 27 May 2014
15:17 Monday 27 May 2014

06:30 Tuesday 28 May 2014
06:30 Monday 27 May 2014
06:30 Sunday 26 May 2014
06:30 Saturday 25 May 2014
06:30 Friday 24 May 2014
06:30 Thursday 23 May 2014
06:30 Wednesday 22 May 2014

06:30 Saturday 25 May 2014
06:30 Saturday 18 May 2014
06:30 Saturday 11 May 2014
06:30 Saturday 4 May 2014

06:30 1 May 2014
06:30 1 April 2014
06:30 1 March 2014
06:30 1 February 2014
06:30 1 January 2014
06:30 1 December 2014
06:30 1 November 2014
06:30 1 October 2014
06:30 1 September 2014
06:30 1 August 2014
06:30 1 July 2014
06:30 1 June 2014

06:30 1 January 2014
06:30 1 January 2013
06:30 1 January 2012
06:30 1 January 2011

06:30 1 February 2010 (first ever backup)

These backups will also all be backed up off-site:

All of these backups above can be used to restore the the entire database or individual records.

In ADDITION, we now maintain a binary log on the server of every action that caused changes to the data in the database.

This means that in the case of a global system failure, we will be able to restore the global database to the last known good backup, and then re-run every action on the database that took place since that backup again to bring it back to the state it was at the moment before the failure. (This can only be applied to the whole global database, not individual records or railways).

The binary log is not backed up off site.

So, whilst all failures are different, the very worst that we can now do it restore to 6.45 any morning. (This was previously the best we could do).

Depending on the nature of the failure the best we can now do is seconds before the failure.

If you would like more information about HOPS please contact us.