Backup & Restore

Data & safety Admin only Encrypted

Your billing data is your business record, so eBilling Lite protects it three ways: automatic encrypted backups every night, an on-demand download so you can keep your own copy, and a careful restore process that never overwrites your live books without review. This page explains all of it, step by step.

Who can do this

Backup download and restore requests are limited to the company admin role. The automatic nightly backup runs on its own - you do not have to start it. On the hosted service, approving and applying a restore is done by MISAC Intelligence Pvt. Ltd (see Restoring data); on a self-hosted install your own administrator runs it with the server tools.

On this page: How your data is protected · Automatic backups · Downloading your own backup · Restoring data · The restore lifecycle · Self-hosted · Good practice

How your data is protected

Layer	What it gives you
Automatic nightly backup	A full copy of your database is taken every night at midnight (Nepal time), encrypted where a key is configured, and kept for about a month - so there is always a recent point to recover from.
On-demand download	You can pull a fresh backup of your own company at any time and keep it wherever you like.
Reviewed restore	Putting data back is a request that is approved, staged in a separate database, checked, and only then made live - your current data is never overwritten blindly.

Backups · Automatic backups

You do not need to schedule anything - the system backs itself up. Every night at midnight (Nepal time) it makes a complete dump of your company database (and, for the provider, the central control database), so a recent copy always exists. On the hosted multi-company service, each company's dumps are filed under its own slug folder.

What	Detail
How often	Once a day, automatically, at midnight Nepal time (NPT).
What is captured	A full snapshot of your company's database - every invoice, credit/debit note, receipt, purchase, payment, master record and setting.
Where they are kept	On the hosted service, each company's backups are stored in its own folder (named by your company slug) under the backup location, kept separate from every other company.
Encryption	When an encryption key is configured for your deployment, backups are encrypted at rest, so a backup file is unreadable without the key.
How long they are kept	Recent backups are retained for about a month (30 days by default); older ones are cleared automatically so storage does not grow forever.
Offsite copy	Where your provider has configured it, each backup is also copied to a separate offsite location, so a single failure cannot lose both the system and its backups.
Backup history	Each run is logged with its result, size and time, so your provider can confirm backups are succeeding.

You still get your own copy

Automatic backups live on the system. For your own peace of mind - or your accountant's - use the on-demand download below to keep an independent copy off the platform as well.

Backups · Downloading your own backup

As a company admin you can generate and download a backup of your own data whenever you want. It produces a single file containing your entire company database.

Open the backup actionFrom the admin area, choose Download Backup.
The system builds a fresh dumpIt snapshots your company database right then - not last night's copy, but a current one.
The file downloadsYou receive a single backup file. If encryption is enabled it arrives encrypted (a .gpg file); otherwise it is a database dump file (.dump).
Store it safelyKeep it somewhere secure - it is your complete business record.

A backup file is your whole database - treat it as sensitive

The download contains every figure, customer detail and document in your company. Anyone with the file (and, if encrypted, the key) has your full books. Store it somewhere private, not a shared drive or email, and delete old copies you no longer need.

When to take a manual backup

Before a big change - bulk edits, a fiscal-year roll-over, or going live.
At month-end or year-end, alongside filing, as your own archive.
Any time you simply want an independent copy in your own keeping.

Restoring data

Restoring puts a backup back in place of your current data. Because that replaces real, IRD-reported financial records, it is deliberately not a one-click action. It runs as a request that is approved, staged safely, checked, and only then made live - so a restore can never quietly destroy your current books.

Restore is request-and-approve, by design

You submit a restore (upload the backup file). MISAC Intelligence Pvt. Ltd then reviews it, restores it into a separate staging database, checks it, and promotes it to live. Your existing data stays untouched the whole time, and even after promotion the previous database is retained for rollback. This is a compliance safeguard, not red tape.

Why a restore needs approval

Restoring is the one action that can overwrite live, IRD-reported books, so it is gated behind a deliberate review rather than left as a single click. The approval step is a safeguard that protects your data in several concrete ways:

The approval prevents	What would otherwise be at risk
The wrong backup being restored	A backup from the wrong date, the wrong company, or an out-of-date copy could be loaded by mistake. A reviewer confirms the file is the correct, intended one before anything is made live.
Unintentional or accidental changes	A restore is not an "undo" - it replaces your current records wholesale. Requiring a second, deliberate approval stops an accidental click from silently rewriting your books.
Permanent data loss	The backup is first loaded into a separate scratch database and checked, and your previous database is retained after promotion - so a bad or mistaken restore can be rolled back instead of destroying the data you have now.
Corrupt or tampered files	A checksum is recorded when the file is uploaded, and the backup is restored and verified in staging first - so a corrupt, incomplete, or altered file is caught before it can ever reach your live data.
Compliance and audit gaps	Issued invoices and credit notes are reported to the IRD, so the records are legally significant. Every restore is logged with who requested it, who approved it, and when - leaving a clear, reviewable trail.

In short, the approval turns a restore into a checked, reversible, and recorded recovery action instead of a one-click overwrite. It protects you from restoring the wrong copy, from accidental or unintended changes to live records, and from losing data you cannot get back.

Submitting a restore request

Open Restore and choose your fileFrom the admin area, start a restore request and select a backup file to upload.
Upload the backupChoose a backup file - a database dump (.dump) or an encrypted backup (.gpg). Files up to 2 GB are accepted.
SubmitThe request is created with status Pending and queued for your provider. Your uploaded file is stored privately (never on a public link), and a checksum is recorded so it cannot be tampered with.
Track itYour restore requests are listed with their current status, any reviewer notes, and timestamps.

The restore lifecycle

A restore request moves through clear stages. You see the status at each step.

PendingYou have submitted the file; it is waiting for the provider to review.
Approved → restored to a scratch databaseThe provider approves and the backup is restored into a brand-new, separate scratch database. Your live data is not touched.
ReviewedThe provider checks the restored data in the scratch database to confirm it is the right copy and looks complete.
Promoted (made live)Your company is repointed to the restored database. The previous database is kept so the change can be rolled back if needed.

All the statuses you might see

Status	Meaning
Pending	Submitted, waiting for provider review.
Restoring	The backup is being loaded into a scratch database (a brief, in-progress state).
Restored to scratch	Loaded into the staging database, ready for the provider to review before going live.
Promoted	Made live - your company now runs on the restored data. The old database is retained for rollback.
Rejected	The provider declined the request; the uploaded file is removed.
Failed	The backup could not be restored (for example a corrupt or wrong-format file). The scratch attempt is cleaned up and the reason is recorded.

Restore replaces your books - use it only for genuine recovery

A promoted restore makes the uploaded backup your live, official record, including its IRD-reported documents. Use it to recover from data loss or a serious mistake, in coordination with your provider - not as a routine "undo". When in doubt, take a fresh download of the current state first, so you can always come back to it.

What MISAC Intelligence Pvt. Ltd can do

For completeness, the provider (super-admin) side of backup and restore includes:

Download any single tenant's database, the central control database, or a full archive of everything in one file.
Review the restore-request queue across all companies.
Approve a request (restore into a scratch database), reject it, or promote the scratch database to live.
Trigger an immediate backup and review the backup history/logs.

Self-hosted installations

The automatic nightly backup runs on the hosted multi-company service. If you run eBilling Lite on your own server (self-hosted) - or as a single-company install - backups and restores are your own system administrator's responsibility, using the standard PostgreSQL tools (pg_dump / pg_restore), typically on a nightly schedule. The concepts here are identical - regular encrypted backups, retention, and a staged restore - but the scheduling and approval are run by your administrator rather than a hosted provider.

Good practice

Keep an independent copy. Rely on the automatic backups, but also download your own copy periodically and store it securely off the platform.
Back up before big changes. A fresh download before a risky operation gives you a known-good point to return to.
Protect backup files. They contain your entire business - store them privately and remove old copies.
Treat restore as recovery, not undo. For small mistakes, correct the document (void, credit note); reserve a full restore for genuine data loss, with your provider involved.

Common questions

Do I have to run the nightly backup myself?: No - it is automatic. The manual download is an extra copy for you, on top of it.
Why can't I just restore a backup myself instantly?: Because it overwrites real, IRD-reported records. The approve-stage-promote flow makes sure a restore is intentional, verified, and reversible.
If a restore goes wrong, can it be undone?: Yes - when a restore is promoted, the previous database is retained, so your provider can roll back to it.
What format is the download?: A PostgreSQL dump file (.dump), or an encrypted .gpg file when encryption is on. Keep it as-is; it is what you upload if you ever need a restore.
How long are backups kept?: About a month by default (30 days). For longer retention, keep your own downloaded copies.