Backing Up Primafact Case Files Properly

What actually needs to be backed up

A complete Primafact backup needs to cover the underlying database, the associated document store where scanned files live, and any configuration or index data the application depends on to function after a restore. Backing up only the visible document folders and missing the database, or vice versa, leaves a firm with a partial and likely unusable recovery.

Why file-level copies of an open database are risky

A standard file copy job, the kind built into many basic backup tools, copies files as they sit on disk at that moment. If Primafact's database is open and actively being written to during that copy, the resulting backup can capture the database mid-write, producing a file that looks copied successfully but is not usable for a real restore.

This is one of the most common gaps we find when reviewing a firm's existing backup setup: the backup software reports success every night, but no one has verified that the actual Primafact data inside those backups is restorable. A proper backup approach for a database-backed application like Primafact accounts for this by capturing a consistent snapshot rather than copying open files directly.

Retention for litigation files

Litigation matters can stay active for years, and firms often need to reference closed files well after a matter concludes. Backup retention should be planned around how long your firm typically needs to access historical matter data, not around a generic 30 or 90 day default that many backup tools ship with out of the box.

This retention planning should happen alongside broader firm backup planning, particularly if PCLaw billing history for the same matters needs to be retained on a similar or coordinated schedule.

Where backups should live

• A copy stored separately from the primary server, not just on a second folder on the same machine
• At least one copy stored offsite or in the cloud, isolated from a local server failure or ransomware event
• Backups protected from being altered or deleted by the same account credentials used for daily operations
• Encryption for backup data both in transit and at rest, given the sensitive nature of case file contents

Testing restores, not just backup jobs

A backup that has never been restored is an assumption, not a safeguard. Periodic restore testing, ideally to a separate test environment rather than the live server, confirms that the Primafact database and document store actually come back functional, searchable, and complete.

1. Schedule a restore test on a defined interval, not only after an incident.
2. Restore to an isolated environment to avoid disrupting live operations.
3. Verify that documents open, searches function, and matter structure is intact after the test restore.
4. Document the results and time required, since restore speed matters during an actual outage.
5. Adjust backup configuration if any gap is found during testing.

Disaster recovery beyond backup: planning for a full outage

Backup answers the question of whether data can be recovered. Disaster recovery answers the broader question of how quickly the firm can get back to working in Primafact after a server failure, ransomware incident, or site-level disaster. A firm's disaster recovery plan should specify realistic recovery time expectations and be reviewed alongside general cybersecurity planning, since ransomware is now one of the leading causes of forced recovery events for professional services firms.

Sources and further reading

• Canadian Centre for Cyber Security: Backup your data

Frequently asked questions