Your backups, your recovery plan
Because the software runs on your infrastructure, AtlasOA, LLC does not hold a copy of your data and cannot restore it for you. The products include backup features, and this page explains how to build a complete backup strategy around them.
Last reviewed: September 2026
Responsibility: backups, off-site storage, restore testing, and disaster recovery are your institution's responsibility. The recommendations below are guidance, not a service we perform. See Shared responsibility.
What the built-in features do
| Feature | AtlasOA | Atlas K-12 |
|---|---|---|
| Database backup | Yes, using SQLite's safe online backup | Yes, using SQLite's safe online backup |
| Automatic backups | Before every import, sync, data clear, and restore; plus an optional schedule (every 1 to 168 hours) | No; an administrator starts each backup |
| Retention | Keeps the newest 50 by default (adjustable from 5 to 500) | No automatic rotation |
| Restore | Administration > Backups > Revert; a safety backup is taken first | No restore screen; stop the application and replace the database file |
| Off-site copy | Built-in copy to a network share; SFTP and S3-compatible destinations need additional components in the installed build | Use your backup system |
| Includes uploaded files | Only through the off-site copy option | No |
| Encrypted | No | No |
| Status | Backup list in Administration | Latest backup and 30-day count on the Security Health page |
Built-in backups sit on the same server as the database. They protect against mistakes, not against losing the server.
What to include in your backups
- AtlasOA: the data folder (
%LOCALAPPDATA%\AtlasOAfor the installed build:database.db,uploads,backups_db, and the license and secret-key files), plusaudit_log.dbandbackup_config.json, which the installed build currently keeps in the application folder. - Atlas K-12: the data folder (
%LOCALAPPDATA%\AtlasK12:atlas_k12.dband its-waland-shmfiles,uploads,backups, and.secret_key), and the Compass model files if you do not keep the installer. - Keep the secret-key file with the database. Stored integration and email passwords are encrypted with a key derived from it; without it you will re-enter those passwords after a restore.
- Your reverse proxy configuration and certificates.
Recommended strategy
- Nightly backups of the data folders above with your existing backup system (for example Windows Server Backup or Veeam).
- Encrypt backup copies, because the database and files are not encrypted by the applications.
- Keep an off-site or immutable copy so ransomware or site loss cannot take every copy.
- Consistent copies: use SQLite-aware or volume-snapshot backups, or stop the application before a plain file copy, so the database and its write-ahead log are captured together.
- Virtual machine snapshots are useful before updates, but are not a substitute for backups stored elsewhere.
- Test restores on a schedule by restoring to a separate machine and signing in.
- Decide your targets: how much data you can afford to lose (recovery point) and how long you can be without the system (recovery time). Your backup frequency and spare hardware follow from those answers.
Recovering on new hardware
- Install the same version of the application on the replacement server.
- Stop the application.
- Restore the data folder (and, for AtlasOA, the audit log and backup settings files).
- Start the application, sign in, and confirm recent data and the audit chain status.
- Update DNS or the reverse proxy to point at the new server.
Uninstalling AtlasOA deletes its data folder after a confirmation prompt; do not uninstall a server you intend to recover from.
Do not take our word for it. Test it yourself. Install AtlasOA or Atlas K-12 on a machine your institution controls, use sample or non-production data, and let your own people decide.