Heritage Operations Processing System
By using the HOPS database, you agree to the following Terms of Use.

Terms of Use

  • This database system may be used by UK heritage railways, to the extent defined by the owners.

  • Use of the database by railways or companies that do not satisfy the owner's criteria of 'heritage' may still be permitted subject to negotiation and purpose of use.

  • In order to maintain the integrity of the database and the reputation of the website and the industry as a whole, house rules will naturally be required. These are set out here.

  • There is currently no charge to use the database for bona-fide heritage railways, however, the owners reserve the right to apply charge to part or all of the database in the future.

  • HOPS must absolutely not be used to send spam e-mail. If any railway is found to be using HOPS to send spam e-mail their authority to use the system may be withdrawn without warning.

  • If the owners of the HOPS system encounter any issues with an individual user from a railway, we will attempt to negotiate with the railway concerned to resolve the issue. This might be due to, for example, the user's behaviour on a discussion forum.

  • If any issue with an individual user or a railway organisation as a whole cannot be satisfactorily resolved by negotiation, the owners of the database reserve the right, at their absolute discretion, to refuse a specific user or a specific railway access to the database again.

  • This website uses cookies. Find out more about how....

  • It is the responsibility of the subscriber railways, before entering data into HOPS, to ensure that doing so is within the terms under which the subject user initially provided the information to the railway.

Data Protection & Security

  • User account passwords are stored in the database in encrypted form, from which they cannot be decrypted. Passwords are not visible by the programming team nor anyone at any railway. For this reason passwords can never be revealed even to the user to whom they belong. If a password is forgotten it can only be reset to a new random password.

  • Records are kept of all users' activity on the site.

  • HOPS maintains a response plan for any breach of data security.

All data we hold is secured to the full extent required by the Data Protection Act. This includes, but is not limited to:
  • Running a secure operating system (Debian Linux), with operating system and application security updates applied in a timely manner.

  • Maintaining a firewall to prevent unwanted access to the server.

  • Providing secure access to the website over HTTPS, to prevent snooping of data or man-in-the-middle attacks.

  • A permissions system to prevent unauthorised access, modification and deletion of data through the website itself.

  • Offsite backups to prevent loss of data through hardware failure or accidental damage.

  • Hosting the server in a secure third-party physical location.

  • Limiting login to the server itself to the administrators of HOPS.

  • HOPS is exempt from registration with the Information Commissioner's Office (ICO), however, we have elected to voluntarily register (A8029883).

  • Our track record: In the five years we have been running HOPS, we have not had a single problem related to unauthorised access to data. In that time we have been trusted by over 50 railways to store data for over 7000 users.

  • When a user is archived from HOPS some data is retained indefinitely for recording purposes, ie, names on rosters. Other data, including contact information, etc, is removed after a suitable period. The period is currently two years, but is shortly to be reviewed.

  • Users may request disclosure of all information held about them in HOPS. Requests of this nature, if they cannot be settled by the user's home railway, should be addressed to help@heritage-ops.org.uk. A fee may be payable.

  • HOPS will only change the point of contact at a railway (and hence the person from whom we will take instruction on the use or release of the railways data) following a reasonable corroboration of the validity of the request for the change, and reserves the right to refused such requests if we suspect they are not legitmate.


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 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.


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 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.

Disaster Recovery

  • Recovery from loss-of-data-related incidents will be via the back-up process as described above.

  • Recovery from mechanical failures of discs, etc, will be via the offsite back-up process as described above.

  • HOPS is run by a very small team. In the case of incapacity of the current Program Manager (Danny Scroggins) the following plan will apply:
    • In the short term the site will continue to operate, but development will cease.
    • Luke Cartey (luke.cartey@heritage-ops.org.uk) will assume control of the site from a technical perspective and control of the company.
    • Alex Seal (alex.seal@heritage-ops.org.uk) will assume control of the management of users and railway clients.
    • All Railway HOPS Administrators will be contacted and advised of the circumstances.

  • In the case of the death of current single shareholder (Danny Scroggins) the following plan will apply:
    • The single shareholding in HOPS Ltd, the company that owns the website and shop, will pass to Luke Cartey.
    • Luke Cartey will arrange for the ownership of HOPS Ltd, including the responsibility for the website tools, to be transferred to a railway or organisation willing to maintain the website tools (even if not the shop) under the same ethos and general principles as it has grown up.
    • A small group of well-established heritage railway individuals has been identified to assist in advising on the suitability of organisations. The final decision will be Luke Cartey's.
    • Before access to the data passes to the new owners, each Railway HOPS Administrator will be given the opportunity to have their data removed from the system.
    • If no railway or organisation willing to assume control of HOPS can be found, the website and the company will shut down. The 'exit clause' above applies (ie, data will be sent back to the railways).

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