Techly Business Continuity and Disaster Recovery Policy

Purpose

This policy sets out how Techly Operations Pty Ltd (Techly) protects Pyron's data against loss and restores the service after a failure, and it is plain about what Techly cannot yet recover from quickly.

Scope

Pyron's production service: its database, stored files, infrastructure and configuration, and the people who run it.

What is backed up

• The database. Backed up continuously by AWS, and restorable to any moment in the last 35 days. The backups are encrypted and held in the AWS Melbourne region, and copied to the AWS Sydney region, where the copy is also kept for 35 days. The database is protected against deletion, and a final snapshot is taken if it is ever deleted.
• Stored files. When a file is replaced or deleted, its earlier version is kept for 30 days.
• Infrastructure. Every cloud resource, network rule, alert and access assignment is defined in code, so it can be rebuilt from Techly's source repository, where the runbooks and procedures for running Pyron are written down too.
• Software. Each release is a built image in Techly's container registry, and can be rebuilt from its source.

Recovery objectives

• Recovery point: about five minutes. A restore can recover the database to within about five minutes of a failure, because its transaction logs are backed up that often.
• Recovery time: measured at each restore test. The first, on 26 October 2026, restored the database and verified it complete in 11 minutes. That is the database alone: bringing the whole service back on a restored database takes longer, and Techly makes no promise about it. There is no service level agreement.

Restore testing

Every quarter, the Technical Director restores the production database from its backups into a new, separate database, checks that it is complete and readable, measures how long it took, and then deletes it. The check confirms that every workspace's data is there, that its row counts match production's within a small tolerance, and that the newest entries of each workspace's audit trail are intact. The result and the time taken are recorded, and the recovery time above is updated from it. A failed test is treated as an incident.

The procedure is scripted, so that anyone who runs it makes the same checks and keeps the same record. Every run is recorded, a failed one included.

Known limits

• One availability zone. The production database runs in a single availability zone, with no standby. If that zone fails, Pyron is unavailable until the database is restored into another zone. Techly has accepted this at its current scale, and will add a standby when a customer's agreement calls for one.
• One region. Pyron runs in the AWS Melbourne region. The copy of the database's backups in Sydney means its data survives the loss of the whole Melbourne region, but the service would stop until it is rebuilt in Sydney or Melbourne recovers.

When something fails

1. The failure is handled as an incident under the Techly Incident Management Policy: an alert pages the on-call engineer, who follows the runbook for that alert.
2. The on-call engineer restores the service, fixing forward through the normal change process, or restoring data from backup if data was lost or damaged.
3. Affected customers are told by email what happened, what was affected and when the service is back.
4. If a restore was needed, the restored data is checked before the service is reopened.

Who is responsible

• The Technical Director owns this policy, runs the restore tests and leads recovery.
• Another director keeps customers informed during a long outage while the Technical Director restores the service.

Review

The Technical Director reviews this policy every year, after every restore test that changes the recovery time, and after any incident that needed a restore.