Restore from a backup

How the assisted restore process works in Mosce ERP: phases, security checks, safety net and post-restore steps.

Restoring an account from a backup is a process assisted by the Mosce ERP support team. This article explains what to expect during the process, what security checks are performed before touching any data, and which settings you should review after the restore completes.

Reading time: ~6 min

When to use this

A massive accidental data deletion occurred and you need to recover the previous state.
A data import failed midway through and left the account in an inconsistent state.
You need to clone your account's state to another instance (for example, for a test environment).

Before you start

The restore is an operator-assisted process - you cannot start it from the interface on your own. You must contact support.
You need to know which backup you want to restore from: the approximate date and time, or the identifier if you can access the backup list.
The restore overwrites the account's current data with the backup data. Review the full scope with the support team before confirming.

How to start a restore

Contact the Mosce ERP support team from Settings → Support inside the platform, or through the support channel indicated in your plan contract.
Provide:
- The backup you want to restore from (date and time, or ID if you know it).
- The reason for the request.
- Whether there is data from the period after the backup that must be preserved or that is already lost.

The support team will assess the request, confirm the scope with you and run the process.

The phases of the restore process

Phase 1 - Backup validation

Before any change, support verifies that the backup file is intact:

Decrypts the backup file.
Verifies the SHA-256 checksums of each file listed in the manifest.
Confirms that the backup's schema version is compatible with the current platform version.

If validation fails, the process stops and support informs you. No data is modified.

Phase 2 - Security pre-check (dry run)

Support runs a full validation pass in dry-run mode: it simulates the complete restore without writing any data. The dry run verifies:

That all backup records are valid and consistent.
That there are no integrity conflicts that would prevent the restore.
The volume of data to restore and the estimated time.

Support informs you of the dry-run result before proceeding. If there are findings that change the scope, they are discussed with you before continuing.

Phase 3 - Snapshot of the current state

Before writing a single row from the backup, support creates a complete snapshot of the account's current state. This snapshot is the safety net: if the restore fails or produces an unexpected result, support can revert the account to the state prior to the restore process.

Phase 4 - Restore

Support runs the restore: it deletes the current data of the affected tables and inserts the backup data. The process can take between 5 and 30 minutes depending on the data volume.

During the restore, some account functions may be temporarily paused to guarantee data consistency.

Phase 5 - Post-restore reconciliation

Once the data is restored, support runs referential integrity checks to confirm that all records are coherent with each other. Counters, balances and cross-references between modules are reviewed.

The reconciliation result is communicated when confirming that the restore is complete.

Safety net - rollback if something fails

The snapshot created in Phase 3 allows the account to be reverted to the state prior to the restore if a problem occurs during phases 4 or 5. The rollback uses the same process as the restore - support can run it if the restore produces an unexpected result.

The rollback option is valid only while the pre-restore snapshot is available (typically 48 hours after the restore). After that time, the snapshot is deleted.

Post-restore steps

Review the integrations

If the account was restored from a backup that uses a different encryption configuration than the current one, some integrations may be marked as "requires reconfiguration":

Private storage: the credentials may have changed. Go to Settings → Integrations → Storage and re-enter the credentials for your private storage.
Email provider: if the email configuration was encrypted with a different key, you will need to re-enter the SMTP or provider credentials.
Stripe: the payments integration may require reconnection if the API key changed between the backup and the restore.

Mosce ERP shows a notice on the integrations screen indicating which ones require reconfiguration. Complete these reconnections before resuming normal operations.

Verify the restored data

Before resuming normal operations, verify that the critical data was restored correctly:

Review the last invoices issued before the restore point.
Verify the customer and supplier balances.
Confirm that the inventory reflects the expected state.

If you find discrepancies between what was restored and what was expected, report it to support immediately while the pre-restore snapshot is still available.

Common errors

Symptom	Likely cause	Solution
The restore process takes longer than expected	Data volume larger than estimated	This is normal for large accounts; support will inform you of the status
An integration says "requires reconfiguration"	The encryption key changed during the process	Re-enter the credentials of the affected integration
The data of a module was not restored	That module was not active on the backup date	Check with support whether the backup includes that module