Skip to main content

Business continuity & recovery

Meetings do not wait, and neither should the service that documents them. Sally is engineered so that day-to-day outages stay small, disasters stay recoverable, and customer data survives a bad day. The programme is aligned to ISO 22301 and BSI 200-4, and it applies to the production environment plus the subprocessors named in Annex 3 of the DPA.

Data location
Germany only
Full backup cadence
Daily (min.)
Point-in-time recovery
Yes, log-based
Restore tests
At least annually

Redundancy at the infrastructure layer​

✓
Redundant hardware at the database tier
RAID storage and ECC memory prevent single-disk and single-bit failures from disrupting the service.
✓
Database cluster with automatic failover
A replicated cluster keeps a warm standby ready. A primary failure triggers automatic failover to the standby.
✓
Load-balanced, stateless application tier
Two front servers behind a load balancer serve the API. Rolling deployment means new versions ship without downtime.
✓
Separate backup storage in Germany
Backups sit on a physically separate storage instance in Germany, encrypted with AES-256 keys that stay with Aliru.

Backups and point-in-time recovery​

  • Daily full backup at minimum, complemented by a continuous transaction log archive that allows restore to nearly any point in time.
  • Restore procedures are defined for each critical dataset. Restore is prioritised by impact on confidentiality, integrity and availability.
  • Backups never leave Germany. Both the primary site and the backup site are inside the Federal Republic.
  • Encryption at rest with AES-256. The rules from the Key Management page apply to backups too: the infrastructure provider cannot decrypt them.

Detection, escalation and recovery​

Incidents follow a three-level escalation:

✓
Level 1, Disruption (limited impact)
Handled by the on-call incident lead. Contained without customer notification unless data protection is affected.
✓
Level 2, Serious incident (partial outage)
BCM coordination and the data protection officer are looped in. Impacted customers are informed.
✓
Level 3, Emergency (core service down or RTO/RPO at risk)
Crisis management activates the DR path. Customer notification within 24 hours if a personal data breach is possible (DPA § 9).

The recovery playbook always follows the same skeleton: contain, root-cause, restore from the appropriate backup, validate integrity before re-opening traffic, ramp capacity while monitoring closely, then document lessons learned and adjust the TOMs.

Testing​

  • Restore tests at least annually. Backups are only real backups after a successful restore, so we test them.
  • Failover simulations quarterly or semi-annually. The database cluster and application tier are exercised regularly.
  • Effectiveness review documented. Test results feed back into the TOMs and this programme.

Communication in the event of a breach​

Where a personal data breach is possible, Aliru informs the customer without undue delay and at the latest within 24 hours of becoming aware. The notification carries: nature and extent, affected data categories and estimated number of subjects (as known), suspected causes, mitigation already taken or planned, and where relevant a recommendation to inform data subjects. Notifying the supervisory authority under Art. 33 GDPR sits with the customer as controller, and Aliru supports with the required information.

What sits with the customer​

  • Configure retention so that recovery only ever needs to restore data you actually still need.
  • Test your own downstream integrations (e.g. webhooks, CRM sync) so a Sally restore does not surface stale entries in your systems.
  • Report suspected incidents promptly. The faster we know, the more of the recovery window remains.