1. Home
  2. Settings
  3. Settings (System)
  4. Database Backup

Database Backup

💾 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:

ColumnMeaning
Date / TimeWhen the backup was taken (your local timezone).
FrequencyThe 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.
SizeCompressed archive size on disk. A healthy workspace typically stays well under 100 MB.
EncryptedA 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.
FileThe internal archive filename (.gz.enc for encrypted archives).
ActionRestore 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

  1. Open Settings → Database Backups.
  2. Click Backup Now (top-right of the page).
  3. 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

FrequencyCron firesBest for
MonthlyOnce every 30 daysLow-activity workspaces — small teams, light invoicing.
15-DayTwice a monthStandard operating tempo — default for most SMEs.
7-DayOnce a weekActive workspaces with regular invoicing, payroll, and CRM activity.
3-DayEvery three daysHigh-volume workspaces — heavy daily transactions, multi-branch.
24-HourOnce every 24 hoursHighest sensitivity — financial year-end, bulk migrations, compliance audits.
Daily (sandbox only)Once per daySandbox / 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_KEY without first preserving the old value. Existing .gz.enc archives 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

  1. In the backup list, find the snapshot you want to roll back to and click its Restore button.
  2. A confirmation dialog appears showing the file name, date / time, and whether the backup is encrypted.
  3. 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).
  4. Click Restore Database.
  5. 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

How can we help?