EA Repository Disaster Recovery: Backup, Restore and Business Continuity Planning for Sparx EA

A mature EA repository holds years of governance decisions, approved designs, traceability artifacts, and compliance evidence, so losing it is a business problem as much as an IT one. Protecting it takes the same discipline as any critical system: verified backups sized to each database platform, restores you have tested, defined RTO and RPO targets, and a continuity plan that ranks failure modes by impact instead of treating them as equal.

The Sparx EA repository is often left out of enterprise backup policy, and the gap rarely shows until the day someone needs a restore that was never tested.

For the architect and the platform owner, the job is to make sure the model that holds the organization’s architecture decisions can always be recovered. AI-augmented work raises the stakes: when AI builds or changes large parts of the model, one instruction can touch many elements. By hand, a mistake is limited by how fast a person can click. With AI, the architect decides what should change and takes a verified backup or a baseline first, then reviews the result before it stands. The skill is knowing what recovery you need and testing it before the day you need it. A recoverable repository is what lets people use it boldly.

Why EA repository backup is different

The reasons it gets skipped are organizational more than technical. The repository is often seen as "the architects' tool" rather than a business system. It starts small, it is not customer-facing, and it does not look like an obvious compliance or regulatory concern, so it slips past enterprise backup policy during the initial deployment and stays out of scope long after it has stopped being small.

The view changes once you account for what accumulates in a mature repository:

Architecture decisions. Why was application A chosen over application B? Which constraints govern the program, and which trade-offs were accepted in the technology strategy? Those decisions live in the repository as tagged values, element notes, decision records, and relationship structures. Lose them and you lose the institutional memory of why the current architecture exists at all.

Program traceability. Artifacts produced for program gates, approved designs, compliance mappings, standards assessments, are frequently referenced in documents that live outside the repository. If the repository goes, those references become unresolvable.

Compliance evidence. In regulated industries, the repository may hold evidence that specific designs were reviewed, approved, and compliant at specific points in time. That cannot be reconstructed after the fact.

Years of invested effort. A mature practice represents years of modeling, governance, review, and curation. None of it comes back without the data.

Backup options by database platform

The right backup mechanism depends on where your repository database lives. Sparx EA repositories most commonly run on SQL Server, PostgreSQL, or MySQL, each with its own native tooling and managed-cloud equivalent.

SQL Server

SQL Server Agent schedules backup jobs. A daily full-database backup produces a file that restores the complete repository; with the database in full recovery model, transaction log backups add point-in-time recovery to any moment within the log retention window, not just the last full backup.

Azure Backup handles SQL Server on an Azure VM with policy-driven, configurable retention. Azure SQL Database goes further: automated backups are built in, with full backups weekly, differentials every 12 hours, and transaction log backups every 5 to 10 minutes.

Recommended: daily full backups via SQL Server Agent or an Azure Backup policy, plus hourly transaction log backups for active repositories. Keep daily backups for at least 30 days and weekly backups for 12 weeks.

PostgreSQL

pg_dump creates a logical backup as a SQL script or archive file. Run it on a schedule (a cron job) and you get a portable backup that restores to any compatible PostgreSQL instance, the standard approach for self-hosted setups.

pg_basebackup captures a filesystem-level snapshot of the data directory. Paired with WAL (write-ahead logging) archiving, it enables point-in-time recovery to any moment within the WAL retention window.

Managed cloud PostgreSQL, Amazon RDS, Azure Database for PostgreSQL, Google Cloud SQL, manages backups for you. RDS provides automated daily backups with point-in-time recovery up to the configured retention period, which can be set as high as 35 days.

Recommended: daily pg_dump for self-hosted instances, with WAL archiving for point-in-time recovery. On managed cloud instances, set backup retention to at least 14 days.

MySQL

mysqldump produces a logical backup as a SQL script. Like pg_dump it schedules cleanly and yields a portable file; for small-to-medium repositories on MySQL, a daily mysqldump is adequate.

Binary logging enables point-in-time recovery from a mysqldump base. The binary log records every transaction, so you can restore to any point between the base backup and now.

Managed cloud MySQL, Amazon RDS and Azure Database for MySQL, offers automated backup with configurable retention, mirroring their PostgreSQL equivalents.

EAP file backup (small or solo repositories)

For repositories still on a file format (the older EAP file or the newer QEA file), backup is copying the file to a safe location: at minimum a network share, ideally cloud storage, always off the machine it lives on. For a file in active use, a daily copy is appropriate. Most shared practices use a server-hosted database for exactly the resilience reasons covered here.

Backup frequency: what "active" means

Frequency should track how fast the repository changes, specifically, how much data loss you can tolerate if a failure forces a restore from the most recent backup.

Lightly used repositories (one or two architects, occasional additions): daily backup is enough. An RPO of up to 24 hours is acceptable where daily progress is modest.

Actively used repositories (five or more architects, daily modeling): daily backup as a floor, with transaction log or WAL-based point-in-time recovery to pull RPO down to hours.

Program-critical repositories (driving delivery artifacts in a critical phase): continuous or near-continuous backup with point-in-time recovery. During a gate review, losing even four hours of work can be unacceptable, so frequent transaction log or WAL checkpoints are warranted.

Recovery testing: the step that is always skipped

A backup you have never restored is not a backup you can rely on. Backup files can be corrupt, incomplete, or written to storage that turns out to be unreachable on the day you need it.

What a restore test means: take a recent backup file, restore it to a staging or dedicated recovery environment, connect Sparx EA to the restored database, and confirm the content is complete, accessible, and functional.

How often: for active repositories, a monthly restore test is good practice. Where backups are automated in the cloud, a quarterly test confirms the automation is producing recoverable output.

What to check: element count and package structure match production, diagrams render, MDG Technology profiles are intact, users can connect through PCS, and reports generate. A test that only confirms the database came up is not thorough enough.

RTO and RPO targets for the EA repository

RTO (recovery time objective) is how long the repository can be offline before the impact is unacceptable. RPO (recovery point objective) is how much data loss is tolerable, measured as time since the last recoverable state. Classify your repository, then let the targets drive backup frequency, infrastructure, and monitoring. The figures below are starting points to adapt with your business, not standards.

RTO and RPO targets for the EA repository

Repository classification	Suggested RTO	Suggested RPO
Low-use repository (few architects, non-critical period)	24-48 hours	24 hours
Active practice repository	4-8 hours	4-8 hours
Program-critical repository (active delivery period)	2-4 hours	1-2 hours
High-stakes compliance / regulated environment	1-2 hours	< 1 hour

Business continuity: tiered impact scenarios

Different failures in the Sparx EA stack produce very different impact profiles. Treating them as equivalent wastes continuity budget, so rank them.

Pro Cloud Server failure

When the Pro Cloud Server instance goes down, Sparx EA clients cannot reach the shared repository and all multi-user access is offline. Architects may hold locally cached versions of recent diagrams, but the shared repository is not available for read or write.

Direct-connection fallback. If the database itself is still reachable, EA clients can connect to it directly as an emergency access path where your network and credentials allow. Treat it as temporary, because it bypasses the access controls PCS provides, but it can retrieve critical content during a short PCS outage.

Recovery. A PCS service restart is usually a matter of minutes. If the server itself has failed, recovery means standing up a replacement PCS instance and reconnecting it to the database; a pre-configured standby instance shortens that considerably.

Database server failure

If the database becomes unavailable, the entire repository is inaccessible, and PCS cannot broker connections to a database that will not respond. This is the more serious scenario. Recovery from backup is the primary path: RTO depends on restore time (a function of backup size and infrastructure), and RPO depends on backup frequency. On managed cloud databases such as Azure SQL or RDS, failover to a standby replica can cut RTO sharply.

AI and reporting layer failure

If an AI or business-intelligence integration that sits on top of the repository goes down, AI-assisted querying and dashboard refresh are offline, but core EA access is not. Architects keep working in Sparx EA as before; only the stakeholders relying on those downstream tools are affected. If reporting views live in the repository database, the database backup covers them. A separate reporting database that refreshes from the model can be rebuilt from the repository. A service restart resolves most availability issues; configuration problems such as an expired API key or a changed network path take longer to diagnose.

Frequently asked questions

What this asks of the architect

Disaster recovery for a Sparx EA repository is ordinary discipline: verified backups, tested restores, and clear RTO and RPO targets, applied to a system that often misses out on all three. Get the database and Pro Cloud Server layers right, rank your failure modes by impact, and the repository your practice depends on is protected like any other business-critical system. If you are weighing the platform decisions underneath, see why Sparx EA and the work your architects do day to day.