💾 Database Backup & Restore
The Database Backup module in DaaiSuite takes regular, encrypted snapshots of your tenant database and stores them in your file storage location. It runs unattended on a server-managed schedule — once configured, you can forget about it. The goal is simple: if anything ever goes wrong (an accidental bulk delete, a failed import, a subscription incident), there is always a recent restore point to fall back on.
Each backup is full and self-contained — it captures every collection in your tenant DB at the moment the cron fires. Backups are isolated per tenant: your data never lives in the same folder as another customer’s backup, and only your authorised admins can request a restore.
📍 Screen: Settings → Database Backups
⚙️ Permissions: Database Backup is its own permission module — separate from general Settings. Create lets a user trigger a manual Backup Now. Update (treated as Restore on this screen) lets a user initiate a database restore. Most admins grant Create to senior staff and restrict Restore to one or two trusted users.
💡 Why Backups Matter
- Recoverable mistakes — A wrong bulk-import, a mis-configured cron, a deleted module record — any of these can be undone by rolling back to the last good snapshot.
- Compliance evidence — Indian SME compliance reviews (statutory audits, GST scrutiny) often ask for point-in-time data; a recent backup proves the figures filed match what was in the system at that date.
- Peace of mind during big changes — Before running a Salary year-end, an Employee bulk import, or a Catalog re-categorisation, you know there is a fresh restore point waiting.
- Disaster preparedness — Hardware, network, or hosting failures are rare but real. Off-database backups in your file storage location keep your records safe even if the live DB is unreachable.
📋 The Backups List
The page shows a table of every available backup for your workspace. The columns are:
| Column | Meaning |
|---|---|
| Date / Time | When the backup was taken (your local timezone). |
| Frequency | The schedule label that triggered the snapshot — e.g., monthly, 15-day, 7-day, 3-day, 24-hour, daily. Manual backups created via Backup Now are labelled manual. |
| Size | Compressed archive size on disk. A healthy workspace typically stays well under 100 MB. |
| Encrypted | A green lock 🔒 means the archive is AES-256-GCM encrypted (modern). An open orange lock means it is a legacy plaintext backup — still restorable, but less secure. |
| File | The internal archive filename (.gz.enc for encrypted archives). |
| Action | Restore button — see the Restore section below. |
💡 Empty table? If no backups appear, the first nightly automated backup runs at 1 AM IST. You can also create one immediately using Backup Now.
🟢 Trigger a Manual Backup — Backup Now
- Open Settings → Database Backups.
- Click Backup Now (top-right of the page).
- The backup starts in the background. After a few seconds, refresh the page — a new row labelled manual will appear at the top of the table.
💡 Use Backup Now before any high-risk operation — a large data import, a bulk delete, or a settings overhaul. Having a fresh snapshot a few minutes old is far safer than relying on last night’s automated backup.
⚙️ Backup Frequency
Backup frequency is configured at the infrastructure level — each workspace runs on a single server-assigned schedule. The Frequency column in the backup list shows the schedule label that was active when each snapshot was taken.
To request a frequency change for your workspace, raise a Support Ticket. Older backups are pruned automatically based on the active frequency, so the file-storage footprint stays bounded.
📊 Frequency Options
| Frequency | Cron fires | Best for |
|---|---|---|
| Monthly | Once every 30 days | Low-activity workspaces — small teams, light invoicing. |
| 15-Day | Twice a month | Standard operating tempo — default for most SMEs. |
| 7-Day | Once a week | Active workspaces with regular invoicing, payroll, and CRM activity. |
| 3-Day | Every three days | High-volume workspaces — heavy daily transactions, multi-branch. |
| 24-Hour | Once every 24 hours | Highest sensitivity — financial year-end, bulk migrations, compliance audits. |
| Daily (sandbox only) | Once per day | Sandbox / testing workspaces only. Not available on production workspaces. |
💡 Most production workspaces run on 7-Day or 15-Day. Higher frequencies are only useful if your data churn is heavy enough that losing a day or two of changes would actually hurt — otherwise you are just generating more files.
🔒 Encryption
All new backups are encrypted at rest using AES-256-GCM with a per-tenant derived key (HKDF). The archive format is .gz.enc with a DBK1 header. The encryption key is set server-side by your infrastructure team — if the key is missing, a yellow warning banner appears on the backups page and new backups will fail until it is configured.
📌 For infrastructure teams: Never rotate the
BACKUP_ENCRYPTION_KEYwithout first preserving the old value. Existing.gz.encarchives were encrypted with the current key — if the key changes, those archives become unreadable and restore will fail.
🗄️ Where Backups Are Stored
Every backup is written to your tenant’s file-storage location — the same place your invoice attachments, expense documents, and other module uploads live. Inside that location, backups are kept in a dedicated db-backups folder per tenant, so they never mix with day-to-day documents.
- Each file is named with the frequency and a timestamp, making it easy to spot the most recent snapshot.
- Files are gzip-compressed and (where the key is configured) encrypted to keep storage usage low and data secure.
- Retention is automatic — older snapshots that fall outside the retention window are cleaned up so the folder doesn’t grow forever.
⚠️ Backups occupy storage just like any other uploaded document. If your workspace is close to its file-storage limit, a higher backup frequency will shrink the headroom faster. Watch the storage indicator in your subscription dashboard if you are running near the cap.
🔄 Restoring a Backup
Restoring a backup is now a self-serve action, available from the same Database Backups page. Restore is destructive — the workspace’s entire current database is dropped and replaced with the chosen snapshot — so the UI gates the action behind a workspace-name confirmation.
⚠️ Restore is destructive. All data created or changed after the chosen snapshot’s timestamp will be permanently lost. This action cannot be undone (except by immediately restoring a newer backup).
What happens automatically before restore
The system always takes a pre-restore safety backup of the current state immediately before proceeding. This safety backup is kept for 7 days. If the restore itself goes wrong, the support team can use this snapshot to recover.
Steps to restore
- In the backup list, find the snapshot you want to roll back to and click its Restore button.
- A confirmation dialog appears showing the file name, date / time, and whether the backup is encrypted.
- Read the warning. When you are certain, type your workspace name exactly as shown in the dialog (this is the confirmation gate — the Restore Database button stays disabled until the text matches).
- Click Restore Database.
- The system takes the pre-restore safety backup, then restores the selected snapshot. The workspace is briefly unavailable during this process. Once complete, all users land on the restored state.
⚠️ Inform your team before restoring. Any work done by colleagues after the backup’s timestamp — invoices raised, attendance imported, leads updated — will disappear after restore. Always coordinate with department heads before triggering a restore during business hours.
💡 Need help picking the right snapshot? If you are unsure which date the data was still good, raise a Support Ticket from HRM → Support Tickets with a description of what changed and when. Support can help confirm the right snapshot before you restore.
📌 Important Notes
- One schedule per workspace — each workspace runs on a single server-assigned backup frequency. There is no per-module or per-collection backup; the snapshot covers the whole workspace DB.
- Daily frequency is sandbox-only — Daily is not available on production workspaces; the minimum production cadence is 24-Hour. This is a server-side setting.
- Retention is automatic — DaaiSuite prunes old backups based on the configured frequency. If you need an extended retention window for a legal or audit reason, ask Support to copy the snapshot file out of the active retention pool before it ages out.
- Backups are not the same as exports — a backup is a binary DB archive used for restore. If you want a readable copy of a single module, use that module’s Export action instead.
- Subscription state matters — when a subscription is suspended, file-storage access and the backup cron stop. Re-activate the subscription before relying on a fresh backup.
💡 Tips
- Review frequency yearly with your ops team. Backup frequency is a server-side setting — at every financial year-end, check whether your data churn has outgrown the current schedule and raise a Support request if a change is needed.
- Request a temporary frequency bump before big changes. Before a Salary year-end or a multi-thousand-row Employee bulk import, ask Support to increase the backup frequency for that window — going from 15-Day to 24-Hour gives you a tight safety net during the high-risk period.
- Keep storage healthy. If your file-storage gauge is near full, clean up unused module attachments before tightening backup frequency — backups can’t be written if storage is exhausted.
- Don’t rely on backups alone. For point-in-time data you reference often (e.g., last year’s invoice register), keep a Module Export alongside — it’s faster to read than restoring a full snapshot.
- Tag the manual backup. When you press Backup Now before a risky change, note the timestamp somewhere — it’s the row labelled manual in the table, and that’s the snapshot you want if you need to roll back the change.
🔗 Related Articles
- Settings (System) Hub
- Settings → Primary — company profile, address, and tax identifiers.
- Support Tickets — the channel for raising a restore-related support request.

