ERPNext backup and disaster recovery guide

Why ERPNext backup and disaster recovery is harder than a database dump

A finance or operations lead asking whether ERPNext can be recovered after a failure is asking a question a database dump cannot answer. The useful question is whether the whole system can be rebuilt, at the same version, with its files and custom code intact, and whether anyone has proven it. Start by asking your team or partner to show a complete restore, not a list of backup jobs.

An ERPNext site is not one thing. Its business records live in MariaDB, but the site also depends on public and private files uploaded to it, a site configuration file that holds connection and encryption settings, any custom Frappe apps installed on the bench, and, in container deployments, the volumes that hold database data, files and configuration. A backup of one of these parts is not a recoverable system. Losing the database without the matching files can leave attachments, print formats and images broken, while restoring files without the matching database leaves documents pointing at records that do not exist.

The install route you choose determines where each piece comes from. The frappe/erpnext README lists three routes: Frappe Cloud, Docker Compose and manual installation with the bench command line tool. On Frappe Cloud, the platform operates the infrastructure, so you must confirm exactly which backups and restore points your plan provides, how far back they go, and who performs a restore. With bench on your own servers, the backup commands, storage location and restore steps are your responsibility. With Docker Compose, the state sits in named volumes and external services, so the backup has to cover the volumes and the image versions that match them. Write down which route applies, then list every location that holds site data under that route.

Several failure patterns make recovery harder than expected. The first is a restore that works on paper but has never been run end to end on a separate machine. The second is an offsite copy that contains the database but not the private files, which leaves approvals, invoices and attachments unreadable after a rebuild. The third is custom apps that do not match the restored version: a backup taken on one ERPNext release, restored onto a bench with different custom app commits, can fail during migration or quietly change behavior. Ask for a written restore runbook that names the ERPNext and Frappe versions, the app commits, and the order of steps, and confirm that a restore has been rehearsed in a clean environment.

Plan the recovery test before you agree on the backup design. Ask for evidence that a restore produces a site where a sample invoice, a stock ledger entry and a user login can be checked against the source, and record how long the rehearsal took. Those measurements, taken from your own environment, are the basis for any recovery time you give to finance and leadership, because the duration depends on data volume, network speed and the number of custom apps, and no figure for your environment should be assumed in advance.

Which ERPNext components must be backed up and restored together

An ERPNext site is only recoverable when its database, files, configuration, custom code and container state are restored as one consistent set. Missing any one of them can leave a restored site that starts with errors, loses attachments, or cannot decrypt stored credentials. The cards below list each component, what is lost without it, and who typically owns it.

MariaDB database with transactions and ledgers

The MariaDB database holds every transaction, ledger entry, stock movement and master record for the site. Without a consistent database backup, accounting periods and open documents cannot be recovered, and no other component can rebuild them. In container deployments this is the MariaDB service, and in bench deployments it is the database that bench backup dumps. Confirm with your DBA or platform team how backups are scheduled, where they are stored, and whether point-in-time recovery is available for your MariaDB version.

Public and private site files

Public and private site files include attachments, uploaded images, print outputs and documents linked to records. Without them, database rows still exist but point to files that no longer load, so invoices and purchase documents lose their supporting evidence. Public and private files are stored separately and must be captured together with the database so references match. Confirm the exact sites folder layout against your bench or container version before writing restore runbooks.

Site configuration and encryption keys

The site configuration file and its encryption key hold settings such as database credentials and the key used to encrypt stored passwords and sensitive fields. If the key is lost, encrypted values in the restored database cannot be read, including integration credentials and some user secrets. Store this material in a separate, access-controlled vault rather than alongside the database dump. Security or platform owners should confirm who holds the key and test that a restored site decrypts existing values.

Custom apps and version pins

Custom apps contain the business logic, DocTypes and integrations built for your organization, and their version pins record which ERPNext and Frappe releases they were tested against. Without the exact app source and pinned versions, a restore may pull newer code that fails to migrate the database. Keep app repositories, lock files and image tags under version control so the restored bench matches the state that produced the backup. Your development team owns this material and should confirm it can rebuild the same images.

Redis cache and queue state

Redis holds cache entries and the background job queue, and in most recovery plans it is rebuilt from scratch rather than restored. Jobs that were queued or running at the moment of failure may need to be re-triggered after recovery, which the operations team should review against any scheduled imports or email sends. Plan for an empty Redis on the recovery side and confirm how the Redis service in your frappe_docker Compose file is configured, including whether its data is persisted. Platform operations owns this check.

Workers, scheduler and Compose volumes

Background workers and the scheduler run jobs such as scheduled reports, recurring documents and email queues, and they depend on the same database and files as the web processes. In container deployments, the Socket.io and Nginx services and the environment files used by each frappe_docker service must match the restored site, and the named volumes must be captured with the data they hold. Confirm the exact volume names and environment file locations against your Compose version before any restore, since they vary between setups. Platform engineering owns this layer.

Which backup method, offsite target and recovery model fit your ERPNext

This table compares the backup methods, offsite targets and recovery models available for a self-hosted or Frappe Cloud ERPNext site. Read each row against your recovery point and recovery time requirements, and confirm that the option you choose has been proven by a full restore. The main takeaway is that a backup you have never restored is an unverified assumption.

Option	When it fits	What it costs you operationally
Bench backup of database and files	Self-hosted benches where one scheduled job should capture the site database and its file store together	You own the schedule, retention, monitoring and restore runbook, and storage grows with each retained set
Database dumps scheduled separately from files	Sites with large file stores where you want frequent database copies without repeating the file copy	Two schedules to monitor, and a restore must pair a database dump with a file set from a compatible point in time
Volume or disk snapshots of host or container volumes	VM or Docker hosts where you want to return the whole stack quickly after a host failure	Snapshots can capture MariaDB mid-write unless the database is quiesced or dumped, so test restores before relying on them
Offsite copy to a second cloud account	Teams that want backups outside the failure domain of the production account	Storage and transfer fees recur, and cross-account access keys and roles need their own review and rotation
Offsite copy to a data center or on-premises target	Regulated organizations with required storage locations or an existing secondary site	Your team maintains hardware, bandwidth and secure transfer, and restores over a WAN take longer to complete
Point-in-time recovery with MariaDB binary logs	Businesses that must recover to a moment between daily backups, such as before a faulty bulk import	Binary logs must be enabled, retained and shipped offsite, and replay needs database skill and rehearsal
Daily full backups only	Smaller sites that can accept losing up to one day of postings and stock movements	Simpler to run and restore, but every transaction after the last backup is lost in a disaster
Frappe Cloud managed backups versus self-hosted recovery	Teams that prefer platform-run hosting and backups over running their own restore process	Shared sites from 5 US dollars per month and servers from 20 or 125 US dollars per month per the ERPNext pricing page, excluding recovery work; confirm backup features with Frappe

How to build an ERPNext backup and restore pipeline in sequence

This sequence builds an ERPNext backup and restore pipeline in the order the work happens, from inventorying the site and versions to a tested restore on an isolated host. Each step closes with a check, such as a file listing, a checksum comparison or a successful login on the restored site. The result is a backup set that a second engineer can restore from a written runbook.

Inventory the site, apps and version pins
The engineer responsible for the ERPNext instance lists every site on the bench, every installed app with its branch or tag, and the ERPNext and Frappe versions in use, including any custom apps pinned to a commit. Record the bench directory, the site configuration and the database and file locations. The step is complete when this inventory is stored outside the server and a second engineer can match it against the running system. Confirm the support status of each version on the Frappe supported versions page before you rely on it.
Confirm the backup command for your bench version
Run the backup help on the bench you operate and read the options it accepts, because flags for including files, controlling encryption or setting output paths can differ between bench releases. Run a test backup on a non-production site and inspect what it produces. Then write the exact confirmed command into the runbook. Do not copy commands from older guides without checking them against the installed version. The step closes when the test run reports where the database dump and file archives were written and the command completes without errors.
Schedule database and file backups
Create a scheduled job on the host, run under the bench user, that executes the confirmed backup command for each site with database and file content included. Set the schedule outside business peaks and write each run's output to a log the operations team can read. Run the job once manually and confirm that a database dump and a file archive are both produced for every site. Compare the timestamps and sizes of the new files with the previous run to catch outputs that exist but are empty.
Back up Compose volumes and environment files
For containerized deployments, include the Docker volumes that hold MariaDB data, site files and any Redis data your setup persists, along with the Compose files and environment files that define image tags and secrets. Store the environment files in an encrypted location with restricted access, separate from the general backup location. Save the exact image tags in use alongside the archives. The step closes when a listing of the volume archives and copied configuration files matches the running stack and the tag list is saved with them.
Encrypt and copy backups offsite
Encrypt each archive before it leaves the host, then copy it to an offsite target that everyday ERPNext operators cannot delete with their normal credentials. Use separate credentials for the offsite target, held by a different administrator group where your organization allows it. Confirm the target's access logging and object versioning settings with its provider. Compare checksums of the local and offsite copies. The step is complete when the checksums match and a copy can be listed from the offsite location using the separate credentials.
Set retention and naming rules
Write down how long each backup type is kept, how many daily, weekly and monthly copies remain, and what naming pattern identifies the site, date, ERPNext version and whether files are included. Retention periods should reflect legal and finance requirements, which compliance and finance owners should confirm before you set them. Apply the rules to both local and offsite copies and run the prune job in dry-run mode first. The step closes when the dry run lists only the files the rules say to delete.
Record the restore runbook with exact versions
Write a runbook that a second engineer can follow without help. Include the exact ERPNext, Frappe and custom app versions from the inventory, the restore steps in order, the backup command confirmed earlier, the location of encryption keys, the holder of the offsite credentials and the post-restore checks. For container deployments, list the image tags and the Compose file revision. The step closes when a peer engineer reads the runbook and identifies every input a restore needs without asking the author.
Test a restore on an isolated host
Restore the latest offsite backup onto a host with no network path to production, using the runbook and the same ERPNext and app versions. For container deployments, start the restored stack with the image tags recorded earlier and confirm each service starts. Run the post-restore steps exactly as the runbook specifies, then compare record counts for key DocTypes against the source and log in to the restored site with a test user. Repeat the restore test on a regular schedule. The step closes when the login succeeds and the comparisons match.

How recovery differs for single bench, Docker Compose and Frappe Cloud

On a single bench install, ERPNext, the Frappe Framework, MariaDB and the site files run on one virtual machine that your team administers. Bench backups of the database and files are produced on that same host, so the backup files sit next to the live system until you copy them elsewhere. Your team controls the schedule, retention, encryption, offsite transfer and restore procedure. The hypervisor or cloud provider controls disk snapshots, storage durability and hardware replacement, and those may or may not be part of your plan.

A restore starts with a fresh bench on the same ERPNext and Frappe versions that produced the backup. You then restore the database and files and run the migration steps that version requires.

Where backups land: on the bench host, so a host failure can take the backups with it.
What you control: schedule, retention, offsite copies and restore testing.
What the host controls: VM snapshots, storage redundancy and hypervisor-level replication.
Air-gapped networks: move the offsite copy by approved media, and stage matching Frappe and ERPNext packages on the restore machine before an incident.
Version match: restore onto the same major version and app versions you backed up.

Confirm with your team which backup options your installed bench version provides and how long a full restore takes in your environment.

What drives the effort and cost of ERPNext recovery work

This table lists the factors that change how much design, testing and recurring work an ERPNext backup and recovery engagement needs, and how to reduce each one. Read each row as a question to answer before asking for a quote, since most drivers are set by your own data, environments and business targets. The main takeaway is that the same platform can need very different recovery work depending on these inputs.

Driver	Why it changes effort	How to keep it down
Database and file volume	Larger MariaDB schemas and public and private file folders lengthen backup runs, copies and restore tests, and make full restores slower to verify.	Set retention per data type, schedule heavy copies off-peak, and measure restore time on a realistic copy before fixing the design.
Number of sites and companies	Each bench site has its own database and file set, so every site needs its own backup scope, restore order and verification step.	Consolidate sites where the business allows, and document one standard backup and restore procedure applied to all sites.
Custom apps and upgrade history	Custom apps, patches and server scripts must be restored together with a matching bench version, and older apps may fail after a migrate.	Keep custom apps in version control, pin app versions in the bench, and record which app commit matches each backup.
Attachment volume	Attachments stored as files can outgrow the database, which raises storage costs, copy time and the chance of missing files in a restore.	Check attachment growth early, plan separate retention for files, and verify file counts after each restore test.
Recovery time objective set by the business	A short time to restore usually needs a warm standby, tested runbooks and more frequent verification, which adds design and monitoring work.	Ask the business to state a recovery time target per process, then design only for the processes that need it.
Recovery point objective set by the business	Tight data loss limits may require point-in-time recovery from MariaDB binary logs, which adds log retention, shipping and testing.	Confirm how much transaction loss each function can accept, such as accounting or stock, before choosing log-based options.
Number of environments needing restore copies	Staging, test and production each need restore procedures, data masking decisions and sometimes separate credentials, multiplying the test runs.	Restore to staging on a fixed schedule, mask personal data during the copy, and limit test restores to agreed environments.
Compliance evidence requirements	Assessors may ask for backup schedules, job logs, restore test records and access reviews, which must be produced and kept over time.	Define the evidence list in the scope, automate log collection, and agree with your auditor which records they will accept.
Isolated restore host availability	A separate host for test restores needs its own servers, network controls and access, and it must match the production bench version.	Confirm whether an isolated host exists or is available in your cloud account, and whether it can be built from the same images.

How to protect ERPNext backups, credentials and restore paths

A backup of an ERPNext site holds the same business data as the live system, plus the configuration and keys needed to read it. The cards below cover the controls that keep those copies confidential, recoverable and out of places where they can be misused. Each one names a decision or check to make before the first scheduled backup runs.

Encrypt backup files at rest and in transit

Backup archives contain the MariaDB database and the private and public file folders, so they carry accounting, stock and personal data in clear form unless encrypted. Decide where encryption happens, either by encrypting archives before they leave the bench host or by using encryption on the storage target, and confirm the transfer uses TLS. Check that encrypted copies can still be restored by someone other than the original administrator.

Use scoped credentials for the offsite target

The account that uploads backups to an offsite bucket or server should not be able to read, delete or list everything in it. Where the provider supports it, create a credential that can only write new objects, and use a separate, tightly controlled identity for restores. Confirm with your provider which permissions are available, because not every storage service offers write-only scopes.

Restrict who can download or restore backups

A backup file is effectively a copy of the whole ERP, so anyone who can download one can read every ledger entry. Limit download and restore rights to a named group of administrators, and log each access. Review that list when staff change roles, since bench access, server login and storage console access each grant a separate path to the same data.

Protect site config and encryption keys

ERPNext site folders contain a site configuration file with database credentials and the encryption key used for stored secrets such as some integration passwords. If that key is lost, encrypted fields cannot be read after a restore, and if it is copied with the backup, anyone holding the archive can decrypt those fields. Decide where the key is kept separately from the backup, document how it is recovered, and test that a restore works with it.

Keep backups out of shared test environments

Server Scripts run Python on the server, and from version 15 they are disabled by default and must be enabled with the server_script_enabled setting. Frappe Cloud public shared benches do not allow them at all. Before restoring production data into a test site, confirm where that site runs, whether scripts are enabled there, and who can log in, because a shared or loosely controlled test site can expose live data.

Verify restore paths before an incident

A backup is only protected if the restore path is also controlled, so the steps, credentials and approvals needed to restore should be written down and rehearsed. Confirm which person can authorize a restore, which account pulls the archive, and where the restored site is built. Record the results of each rehearsal so that gaps in access or keys are found before a real outage. For broader server and application controls, see the ERPNext security hardening topic.

How to prove an ERPNext restore works before a disaster

A backup is proven only when a restored copy of the site opens, behaves like production, and holds the numbers it held at the backup point. Run that test end to end on an isolated host that matches production: the same ERPNext and Frappe Framework versions, the same custom apps at the same commits, and a bench layout that mirrors the live one. Confirm the exact restore commands for your bench version against the current Frappe and ERPNext documentation before the first run, and keep them in a runbook that names the backup files, the database and file archives, and the site configuration needed to bring the copy up. A restore that finishes without an error message has only shown that the files were read, not that the business can use them.

The checks that matter start after the command returns. Confirm the site loads, that a named user can log in with the roles they hold in production, and that key DocTypes such as Customer, Item, Sales Invoice, Purchase Invoice and Journal Entry have record counts matching a count taken from production at the backup timestamp. Then reconcile money and stock: compare the trial balance and general ledger totals, and the stock balance by warehouse, against figures recorded from production at the same point. Open a sample of attachments on invoices, delivery notes and employee records to confirm the file store was restored, not only the database. Differences should be explained before the test is signed off, not averaged away.

A restored copy must not behave like production toward the outside world. Before background workers and the scheduler start, disable or redirect anything that sends or receives live traffic: outgoing email accounts, payment gateway and bank connectors, e-commerce and webhook endpoints, SMS or messaging integrations, and API keys or tokens that other systems use. Keep the restored site's scheduler and workers under observation so you can confirm that scheduled jobs start and that none of them post to a live system. Check the restore against the integration settings in your own configuration, because the list depends on which apps and connectors you run, and treat any unexpected outbound message as a failed test.

If a restore fails, stop, record the exact step and error, and leave production untouched. Abort by removing the test site and its database on the isolated host, using credentials that cannot reach production databases, and do not repoint DNS, proxies or connection strings toward the copy until the restore has passed every check. Then record the result as evidence: the date, backup identifiers and checksums, ERPNext and Frappe versions, the runbook version, the reconciliation figures, each check with its outcome, the people who ran and reviewed the test, and the retention period for the record. Repeat the test after any change to the backup job, the database engine or a custom app, so the evidence matches the system you would actually recover.

Common questions about ERPNext backup and disaster recovery

What does ERPNext backup and disaster recovery cost, and what drives it?

The ERPNext software has no license fee, so the cost sits in infrastructure and the work around it. The ERPNext pricing page says self-hosting is free and lists Frappe Cloud shared site hosting from 5 US dollars per month, and Frappe Cloud servers from 20 US dollars per month for shared instances or 125 US dollars per month for dedicated servers. These are hosting figures only and do not include offsite storage, monitoring, or restore testing.

Cost drivers: data volume, number of sites and environments, retention period, how often restores are tested, and whether you run bench or containers.

One-time work: design of the recovery plan and the first restore test. Recurring costs: storage, monitoring, and periodic restore tests.

Ask any quote to split these items, state who pays for each, and name who owns the storage accounts. The decisions and effort tables on this page show which items move the total.

How long does it take to set up ERPNext backups and a recovery plan?

The duration depends on how many decisions your team has already made. No duration was established for this topic, so confirm any estimate in writing against a stated scope rather than relying on a general figure.

Main drivers:

Deployment type: self-hosted bench, Docker Compose, or Frappe Cloud
Number of sites and custom apps that must be backed up
Whether point-in-time recovery for MariaDB is required
The state of offsite storage and access approvals
How many people must sign off the recovery plan

Fixed-scope engagements agree deliverables and timelines in writing before work starts, so ask for each deliverable tied to a test. Also ask who runs the first restore test, because a plan that has never been restored is unproven. The effort table on this page breaks the work into components you can compare against your own timeline.

What must our internal team provide for ERPNext recovery work?

Plan to provide four things: server access, storage accounts, data owners, and a restore window.

Server access: accounts with sufficient rights on the bench host, database host, or container platform, plus network paths to offsite storage.

Storage accounts: accounts owned by your organization so that copies stay under your control.

Data owners: usually finance or operations leads who confirm which records and balances matter and sign off reconciliation after a test restore. A restore that starts but produces wrong ledger totals has failed.

Change approval: a named owner who can approve a maintenance window for test restores and someone who can read logs.

Ask the quote to list each dependency with the date it is needed. The decisions table on this page lists which access decisions need formal approval.

Can our own team set up ERPNext backups without a partner?

Yes, in principle. The frappe/erpnext README says ERPNext can be installed on Frappe Cloud, with Docker Compose, or manually with the bench command line tool, so the tooling is open to any team with the right skills. The real decision is skills and time. Someone must understand MariaDB, file storage, offsite replication, secrets handling, and restore procedures, and must run restore tests on a schedule.

Teams most often underestimate the testing and reconciliation steps, since the backup command is the simplest part. A partner is useful when you lack that skill set, need an independent check before an assessment, or want fixed-scope delivery with written deliverables. DeployOpen implements, hardens, backs up, and documents self-hosted platforms inside the client's infrastructure, and prepares evidence for compliance assessments. Compare the effort table with your staff's available hours before deciding.

Does Frappe Cloud remove the need for an ERPNext backup plan?

No. Frappe Cloud hosts and runs the platform, but your organization still decides what must be recoverable, how far back you need to go, where copies must sit, and who approves a restore.

Ask Frappe Cloud in writing what backups it takes, how long they are kept, where they are stored, and how you would request a restore. Those details were not established for this page, so confirm them directly.

Frappe's supported versions policy also states that customers must be on a listed version and subscribed to a matching Frappe Cloud support plan to receive warranty coverage from Frappe. Check your version status and plan before finalizing the recovery plan. The shared hosting starting price of 5 US dollars per month, from the ERPNext pricing page, covers hosting only. Use the decisions table to build the list of questions for Frappe Cloud.

How often should we test ERPNext restores, and who schedules the tests?

No fixed frequency was established for this topic, so set the schedule from your risk tolerance and rate of change. Tie tests to events: before and after each major upgrade, after changes to custom apps, after adding sites or moving hosts, and on a regular calendar your data owners accept.

ERPNext ships frequent minor releases on supported versions. The frappe/erpnext releases page lists v16.51.1 on October 15, 2026 and v15.123.0 on October 14, 2026, so a test after updates helps catch breaks early.

Each test should restore to a separate environment, run a sample of transactions, and compare balances with data owners. Platform engineering usually runs the restore, while data owners sign off the results. Record the schedule and sign-off steps in the recovery plan. The effort table on this page shows the work involved in each test.

What to monitor, document and review after ERPNext backups go live

A backup is only proven when operations checks it after go-live, so the first job is monitoring that proves each bench backup ran and produced usable output. Check the site database dump and the public and private file archives separately, and alert on any job that fails, produces a zero-byte file, or writes a file much smaller than the previous run. Confirm how your scheduler (cron, a systemd timer or a container job) reports failures, and route alerts to a named owner instead of a shared mailbox. Offsite copies need their own alert. A successful local backup can hide a failed upload, so track the offsite transfer as a separate job with its own success and failure signal.

Restore drills turn backup files into evidence. Agree the drill schedule with the finance and operations leads, because the gap between drills sets how much recent data the business would have to re-enter after a failure. Each drill should restore to a separate environment, run the matching bench migrate step, and then check sample sales and purchase documents, ledger totals, stock balances and attached files. Record how long the restore actually took, since that measured time is what the recovery plan should use. Keep the drill log with the backup records so that an auditor or a new administrator can see what was tested and when.

The runbook must record the ERPNext, Frappe and custom app versions for every backup, along with the site name, the database engine version and the commit or tag of each custom app. This matters because a backup from one major version must be restored onto a supported version. According to Frappe's supported versions page, version 14 reached end of life on January 31, 2026, version 15 is planned to be supported until the end of 2027, and version 16 until the end of 2029. Backups taken on version 14 therefore need a documented upgrade path before they can be restored into a supported release. Any version change, including a minor update, needs a fresh restore test.

Frappe ships frequent minor releases for both supported majors. The ERPNext releases page lists v16.51.1 (October 15, 2026) and v15.123.0 (October 14, 2026), which shows how quickly the version in production can drift from the version in the runbook. Treat each adopted release as a trigger to update the runbook entry, rerun a restore test in staging and confirm that custom apps still install. Set a recurring review date for retention and runbook content, assign it to a named owner, and confirm with your Frappe support plan or partner whether any warranty condition depends on running a listed version. The upgrade section of this guide covers the upgrade steps themselves.

How DeployOpen scopes, builds and hands over ERPNext recovery work

DeployOpen treats ERPNext backup and disaster recovery as a written, fixed-scope piece of work inside your own infrastructure. We agree which sites, databases, files and deployment types are covered, then build, test and document the recovery path so your team can run it after handover.

How we scope

Inventory every bench, site, MariaDB instance, file store and container deployment that holds ERPNext data.
Record which recovery targets and restore points your business has asked for, confirmed in writing before build starts.
Identify custom apps, scheduled jobs and integrations whose data must be checked after any restore.

How we build

Configure bench backups of the database and public and private files, with offsite copies in storage you control.
Set up point-in-time recovery options for MariaDB where your hosting and retention needs call for them.
Adapt the plan for self-hosted bench installs and for frappe_docker container deployments, including volumes and Compose services.

How we hand over

Run restore tests on a separate environment and record the steps, timings and any data checks performed.
Deliver a written recovery plan with roles, escalation steps, credentials handling and the exact commands used.
Walk your administrators through backup monitoring, restore drills and what to check after each restore.

How we support

Offer ongoing support, periodic restore testing and backup review as a retainer, scoped separately from the build.
Update the recovery plan when ERPNext, Frappe or your custom apps move to a new version.
Confirm with your team and any partner who owns upgrades which recovery tasks each party performs.

ERPNext backup and disaster recovery