Backup & Disaster Recovery
Applies to the UMass Chan installation
This page describes the backup and disaster recovery arrangements for the Via Foundry installation hosted by UMMS Biocore at viafoundry.umassmed.edu. It documents how that specific deployment is operated.
Via Foundry is self-hosted software. Other installations are operated independently and are responsible for their own backup and disaster recovery. Nothing on this page should be read as a guarantee, service level agreement, or default behaviour of the software itself. If you run your own installation, treat this page as a reference model rather than a description of your environment.
Overview
The UMMS Biocore installation follows the 3-2-1 backup principle: three copies of the data, on two different storage systems, with one copy on physically separate infrastructure.
Backups run nightly, automatically. Every backup is integrity-checked, retained on a fixed schedule, and monitored, with alerts raised automatically if a run fails.
What is protected
The nightly backup covers the platform databases, which hold the state that cannot be regenerated:
- User accounts, groups, and permissions
- Projects and their configuration
- Run records, parameters, and history
- Pipeline and process definitions
- Metadata and sample tracking records
Schedule and retention
| Item | Value |
|---|---|
| Frequency | Nightly (automated) |
| Daily copies retained | 30 |
| Weekly copies retained | 12 |
| Monthly copies retained | 12 |
This gives same-week granularity for recent recovery plus roughly a year of longer-term restore points.
Where copies are kept
| Copy | Location | Purpose |
|---|---|---|
| 1 | Primary application storage | Live system |
| 2 | Secondary system, same facility | Fast restore |
| 3 | Separate storage infrastructure | Disaster recovery |
The third copy is held on a physically and administratively separate storage system, so that a failure affecting the primary facility does not affect it.
Encryption
- In transit: all backup transfers are encrypted (SSH).
- At rest: the off-site disaster recovery copy is encrypted with AES-256.
Encryption keys are held separately from the encrypted copy, so that possession of the off-site data alone is not sufficient to read it.
Protection against deletion and corruption
Backups are append-only with scheduled pruning — they are not a live mirror of the primary system. This is deliberate: if data on the primary system were deleted, corrupted, or encrypted by ransomware, that change does not propagate into the backup history. Earlier restore points remain intact and are stored read-only.
Integrity verification
Every backup is checksummed (SHA-256) when it is created and verified again on arrival at each destination. A mismatch fails the run and raises an alert immediately, so a silently corrupted backup is not left in place undetected.
Monitoring and alerting
- Failures generate an alert to the Biocore team immediately.
- Successful runs are reported in a weekly summary, including current backup inventory and available capacity.
This ensures a backup that silently stops running is noticed rather than discovered during an incident.
Recovery objectives
| Objective | Target |
|---|---|
| Recovery Point Objective (RPO) | 24 hours |
| Recovery Time Objective (RTO) | Approximately 4–8 hours |
RPO reflects the nightly backup cycle: at most one day of changes could be lost. RTO covers redeploying the application and restoring the databases from the most recent verified backup.
Restore testing
Recovery is tested quarterly, not merely assumed. The test restores from the encrypted off-site copy end to end — decrypting it, verifying the restored content matches its original checksum, and loading it into a scratch environment. Results are recorded, including time taken to restore.
Analysis result files
Analysis outputs (run working directories, result files, and reports) are replicated to a second system. Because these outputs are reproducible — they can be regenerated by re-running the pipeline with the same inputs and parameters — they are not held under the same versioned retention schedule as the databases.
Recommendation for users
Download and retain your own copies of results you consider critical, along with the original input data, in line with your institution's data retention requirements. This is good practice on any shared analysis platform and complements the platform-level backups described above.
Questions
For questions about backup or recovery arrangements for this installation, contact biocore@umassmed.edu.