Backup & Restore Policy
Last updated: 14 September 2025
This policy sets how Technophobia Ltd backs up, stores, tests, and restores data for systems we manage. It supports our Information Security Policy, DPA, and SLA.
1. Scope and objectives
- Applies to environments we host or operate for clients and our own operational systems.
- Aims: keep availability and integrity; enable reliable restores; limit data loss.
- Client-owned platforms are in scope only where the SoW says we manage them.
2. Roles and responsibilities
- Service Owner: sets targets (RTO/RPO), approves schedules.
- Engineer: configures jobs, monitors results, runs restores.
- Security Lead: reviews encryption, access, and retention.
- Client Contact: confirms retained data meets business needs.
3. Recovery objectives
- Default RTO: 8 hours for hosted n8n; 24 hours for documentation and repos.
- Default RPO: 24 hours for workflow data; 24–48 hours for docs.
- Projects may set tighter targets in the SoW or SLA.
4. Backup matrix (typical)
| System / Data | Method | Frequency | Retention | Location | Owner |
|---|---|---|---|---|---|
| n8n database (PostgreSQL or SQLite) | Encrypted snapshot or dump | Daily + rolling hourly WAL/snapshots where supported | 7–14 days | Primary region + offsite copy | Engineer |
| n8n files (configs, custom nodes) | Repo commit + nightly archive | On change + nightly | 30 days | Private Git + object storage | Engineer |
| Server/VM | Image snapshot | Daily | 7–14 days | Provider snapshot store | Engineer |
| Run logs and metrics | Central log store | Continuous | 30–90 days | Log platform (UK/EU) | Engineer |
| Docs and runbooks | Versioned cloud storage | On change | 6 years for project records | UK/EU storage | Service Owner |
If a client requires longer retention, we record it in the SoW and adjust storage.
5. Encryption and access
- Backups are encrypted at rest and in transit.
- Access is limited to engineers on a need-to-know basis with MFA.
- Keys and credentials are stored in a secrets vault, not in code.
6. Restore testing
- Database restore test at least twice a year per hosted environment.
- File/config restore test at least yearly or after major upgrades.
- We log test results and fix gaps found.
7. Restore process
- Identify incident, scope, and target point-in-time.
- Prepare staging environment; verify checksums.
- Restore DB and files; switch endpoints or promote after tests.
- Validate key workflows; confirm with the client before final cutover.
- Post-restore review and documentation.
8. Monitoring and failure handling
- We alert on backup job failures, age of last good backup, and snapshot quotas.
- Failed jobs are re-run within 4 hours; repeat failures trigger a P2 incident.
9. Retention and deletion
- We follow the retention windows in the matrix and our Data Retention Schedule.
- Backups expire automatically; early deletion follows the DPA and SoW.
10. Exclusions and limits
- Third-party SaaS systems are backed up per that provider’s features unless the SoW adds an export routine.
- High-volume raw data (e.g., large transient queues) may not be backed up; we document this risk where relevant.
11. Changes and reviews
- We review schedules on major platform changes or at least yearly.
- Any change to RTO/RPO or retention is recorded in the SoW or support plan.
Contact
Questions or a restore request?
Technophobia Ltd · Company No. 14898332 · VAT GB 495 7043 58
13B Devonshire Road Industrial Estate, Millom, LA18 4JS, United Kingdom
+44 1229 774591 • hello@technophobia.uk