ERPNext offsite backups to S3, Dropbox and Google Drive

How ERPNext offsite backups work and which method fits

A self-hosted ERPNext site needs copies of its backups somewhere other than the server that runs it, and ERPNext can push those copies to Amazon S3, Dropbox or Google Drive. For S3 and Dropbox, the supported method is a built-in backup integration: you configure the target in ERPNext, and the scheduler uploads the backup files on your chosen frequency. S3 is configured through the ERPNext Amazon S3 guide, which expects a bucket, an IAM policy and an Email Account. Dropbox is configured through Dropbox Settings after you create a Dropbox app in the Dropbox developer area. Google Drive is handled by the Google Workspace integration, so treat it as a separate project unless your team confirms the setup against the current Google Settings documentation.

The choice between these targets is usually driven by where your organization already has identity, retention and access controls, not by the ERPNext side. An S3 bucket gives you bucket policies, encryption settings and lifecycle rules that your cloud team already manages, but it adds an IAM user or role to govern. A Dropbox app is quicker to set up for a small team but places backup files in a consumer-style sharing model that your security team should review. Before you pick one, confirm which account owns the backup data, who can revoke the app or key, and whether the target meets your retention and geographic requirements. Also confirm the version of ERPNext you run, because from version 16 these backup integrations move into the separate offsite_backups app, which changes how you install and update them.

What you need before configuring offsite backups

Offsite backup jobs depend on a few things being in place before anyone opens the Backup Integrations settings. Confirm the ERPNext and Frappe version first, since it decides which app holds these integrations, then prepare the notification mailbox, the storage target and the network path from your server.

ERPNext and Frappe version

Confirm which major version runs on your bench, because the integration location changed in version 16. Starting with version 16, the Amazon S3, Dropbox and Google Drive backup integrations move out of Frappe into the separate offsite_backups app, so you must install that app on the site before the settings appear. On version 14 and 15, check the Frappe supported versions page to confirm your line is still receiving fixes before you build new automation on it.

Email account for backup notices

Create an Email Account in ERPNext before you configure any storage target. The S3 guide asks for this first because the scheduled job sends success and failure messages through it. Use a mailbox that someone reads during working hours, and test delivery with a sample message so a silent failure does not go unnoticed for weeks.

AWS bucket and IAM policy

Create a dedicated S3 bucket for ERPNext backups and enable Block all public access on it. Then create an IAM policy scoped to the S3 actions the integration needs, and attach it to a dedicated backup user rather than a shared administrator. Record the bucket name, region and key pair in your secrets store, not in a shared document.

Dropbox app in the developer area

Create an app in the Dropbox developer area before opening Dropbox Settings in ERPNext, because the ERPNext setup needs the app credentials that Dropbox issues. Choose the app permissions that allow file writes to the folder you plan to use, and keep the app owned by an account your organization controls, not a personal login.

Outbound network access from the server

The bench server must reach the storage endpoints over HTTPS. Confirm that egress rules, proxies and DNS allow connections to AWS, Dropbox and Google APIs from the host or container that runs the scheduler, and that TLS inspection does not break certificate validation. Test each destination from that same host, since a laptop test proves nothing about the server's path.

Google Drive requirements

Confirm the Google Drive requirements in your own environment before planning this path. Check which Google account or workspace will own the backup folder, what OAuth client setup your administrators allow, and whether your organization restricts third-party app access. Ask your Google Workspace administrator to confirm these points in writing before the server is configured.

Configuring S3, Dropbox or Google Drive backups step by step

This sequence takes an ERPNext site from no offsite copy to a verified backup that lands in your chosen storage, with failure and success notices going to a mailbox your team monitors. Each step ends with a check so you know it worked before you rely on it.

Create the email account first
Before touching any storage service, an administrator creates an Email Account in ERPNext that the backup notices will be sent from and received by. The ERPNext Amazon S3 guide calls for this first so that success and failure emails reach a mailbox your team reads. Confirm the account sends and receives correctly by sending a test message from the account. The step is done when that test message arrives in the intended inbox.
Create the S3 bucket with public access blocked
In your AWS account, a cloud administrator creates a dedicated bucket for ERPNext backups and keeps Block all public access enabled, as the ERPNext S3 documentation recommends. Keep the bucket in the region and account your data policy allows, and confirm with your security team who may read the backups. The step is done when the bucket exists, shows public access as blocked in its permissions settings, and holds no objects yet.
Create a scoped IAM policy for the bucket
Create an IAM policy that grants only the S3 actions the ERPNext backup needs, limited to the backup bucket, then attach it to a dedicated IAM user or role used only for this integration. Avoid reusing broad administrator keys. The exact action list comes from the ERPNext S3 documentation, so copy it from there and have a reviewer compare it with your internal baseline. The step is done when the policy simulator or a review confirms the identity can write to the backup bucket and cannot reach other buckets.
Enter the credentials in ERPNext backup settings
In ERPNext, an administrator opens the backup integration settings for S3 and enters the access key, secret and bucket details for the IAM identity created in the previous step. Store the secret only in the settings fields and restrict who holds the System Manager role on the site. The step is done when the settings save without a validation error and the connection details show as stored.
Set the backup frequency
Choose how often the scheduler should push a backup offsite and confirm the site's scheduler is running, since scheduled backups depend on it. Set the frequency to match your recovery point expectations, and document the choice with the business owner of the data. Because scheduler behavior depends on your deployment, confirm with your platform team how the background workers are running. The step is done when the saved frequency appears in the settings and the scheduler reports as active.
Run a test backup and verify the copy
Trigger a backup manually rather than waiting for the schedule, then check the result in two places: the success notice in the Email Account inbox and the new object in the S3 bucket. Download one file and confirm it is a readable database backup. The step is done when the success email has arrived, the object is visible in the bucket with a timestamp matching the run, and a restore of that file has been tested on a non-production site.
Confirm failure alerts reach the team
Force a controlled failure, such as a temporarily wrong bucket name in a test environment, to confirm that the failure email arrives at the mailbox you set up in the first step. Restore the correct settings afterward and record the outcome. Ask your provider to confirm how Dropbox and Google Drive integrations send their notices, since the flow differs from S3. The step is done when a failure notice has been received and the correct configuration has been restored and re-tested successfully.

What changes in version 16 with the offsite_backups app

The Frappe version 16 migration guide moves Backup Integrations out of Frappe Framework and into a separate app, frappe/offsite_backups. For a site that sends backups to Amazon S3, Dropbox or Google Drive, this means the upgrade is not complete when Frappe and ERPNext are updated. The offsite backup integration has to be present as its own app on the bench, or the destination settings you rely on will not run as they did on version 15. Before the upgrade window, confirm with your team which of the three destinations is live, who owns its credentials, and whether a test backup has landed in the target location in the last cycle.

During the upgrade, check three things in order. First, confirm that offsite_backups is listed in the target bench and installed on each site that uses it, and that the app version matches the Frappe version you are moving to. Second, open the S3, Dropbox or Google Drive settings after the move and review them rather than assuming they carried over unchanged: confirm the credentials, the bucket or folder, the backup frequency, and the Email Account that receives success and failure notices. Third, trigger a manual backup and check that the file appears at the destination and that a notification arrives at the expected mailbox. Record the result in your change ticket.

The exact sequence, module names and any settings that move or are renamed belong to the migration guide for your target version, not to this page. Read the Frappe version 16 migration guide before you schedule the upgrade, and confirm each step against your own staging copy of the site. If a step in the guide does not match what you see on your bench, stop and check with the vendor before you continue. Treat an offsite backup you have not verified after the move as an open risk, not a completed task.

Choosing between S3, Dropbox and Google Drive as the offsite target

Amazon S3 suits organizations that already run AWS and want backup retention governed by bucket configuration and IAM policy. Access is granted through an IAM policy that names the S3 actions ERPNext needs, so the backup identity can write objects without holding broader rights. Retention is owned by whoever manages the bucket, which means lifecycle and versioning rules live outside ERPNext and need their own review.

Access control: Permissions come from an IAM policy scoped to the target bucket, not from ERPNext user roles.
Bucket hardening: The ERPNext S3 guide recommends enabling Block all public access on the bucket.
Failure visibility: Create an Email Account in ERPNext first so that failed and successful backup notices have a route to a monitored mailbox.
Credential handling: Access keys are stored in ERPNext settings, so rotation and least privilege need an owner on the AWS side.
Dependencies: An AWS account, a bucket, an IAM policy and a sending mailbox must exist before scheduling starts.

Confirm with your AWS administrators whether lifecycle rules, object versioning and bucket-level logging are already standard in your account before you accept the default retention behavior.

Mapping backup settings to storage targets

This table maps each value you enter for an offsite backup target to its counterpart in Amazon S3, Dropbox and Google Drive, and marks whether it is an identifier or a secret. Use it to decide what goes into a shared configuration document and what must stay in a secrets store. Exact field names change between releases, so confirm them against the official setup pages before you configure anything.

Setting	Amazon S3	Dropbox	Google Drive
Target identifier	Bucket name and region, which are identifiers and can be recorded in change tickets	Dropbox folder path where backup files are written, an identifier	Target folder in the Google account, an identifier
Credential	IAM access key ID and secret access key, both sensitive; prefer a dedicated IAM user or role scoped to the backup bucket	App key and app secret from the Dropbox developer area; treat the secret as sensitive	OAuth client ID and client secret from Google Cloud credentials; the client secret is sensitive
Permissions granted	IAM policy with only the S3 actions the backup needs, limited to the backup bucket and its objects	App permissions selected when the Dropbox app is created, limited to what the backup upload requires	OAuth scopes requested during consent; confirm the minimum scope the Drive integration needs
Public access	Block all public access on the bucket should stay enabled, as the ERPNext S3 guide recommends	Not applicable; access is governed by the app and the account it is authorized against	Not applicable; confirm sharing settings on the target folder so backups are not link-shared
Notification target	Email Account created first so the site can send success and failure emails for S3 backups	Email Account used for backup success and failure notices, confirmed in the Dropbox backup guide	Email Account used for backup notices, set up before enabling the Drive integration
Where it is entered	Backup settings in ERPNext, following the field names in the official S3 guide	Dropbox Settings in ERPNext, after the Dropbox app exists	Google Settings in ERPNext, with the credentials from Google Cloud
Rotation and revocation	Rotate IAM keys and review the policy when staff or hosts change; record the owner of the key	Regenerate the app secret if exposed; re-authorize the connection after changes	Revoke and reissue the client secret if exposed; reauthorize the Google connection
Where to confirm exact names	Follow the ERPNext Amazon S3 backup guide for field names and required actions	Follow the ERPNext Dropbox backup guide and the Dropbox developer documentation	Follow the Google Drive integration setup in ERPNext documentation and confirm current Google Cloud screens

Securing offsite backup credentials and data

Offsite backups move a full copy of your ERPNext database and possibly uploaded files outside the server that runs them. The controls below decide who can reach that copy, how the connection is authenticated and what happens if a credential leaks, so they belong in the design before the first scheduled backup runs.

Scope the IAM policy to one bucket

Create an IAM policy for the S3 service that grants only the actions the backup job needs, such as uploading and listing objects in the ERPNext backup bucket, and nothing account-wide. Avoid broad administrator or full S3 permissions on the backup user. Review the policy against the ERPNext S3 backup guide and confirm with your own security team that deletion and versioning permissions match your retention rules. A narrow policy limits the damage if the key is exposed.

Block public access on the bucket

Enable Block all public access on the backup bucket before storing anything in it. A database dump is business and personal data, and a public bucket is one of the most common ways such data leaks. Confirm that account-level public access blocks are also set, since a bucket-level setting alone does not cover every path.

Replace long-lived shared keys

Prefer short-lived credentials over static access keys where your environment allows it, such as an instance role for a server in the same cloud account. If a static key is unavoidable, store it only in the ERPNext site configuration with restricted file permissions, rotate it on a schedule and record who holds it. Do not reuse the same key for other integrations or staff access.

Encrypt backups at rest and in transit

Confirm that the target encrypts objects at rest and that every upload uses TLS. Ask your cloud or storage provider which default encryption applies and whether you can manage the keys yourself. Dropbox and Google Drive hold files under their own controls, so check the account security settings, the encryption they describe and whether the OAuth or app connection can be revoked centrally.

Limit who can read backup files

Backups can contain customer records, payroll, bank details and uploaded attachments, so restrict read access to a short list of named roles such as the backup owner and the recovery team. Use separate accounts for backup administration and day-to-day ERPNext use. Review access quarterly and remove people who change roles, and confirm that the folder shared through Dropbox or Google Drive is not open to a wider group.

Treat backup copies as sensitive data

Plan retention, deletion and restore testing for every offsite copy as you would for the live database. Decide how long copies stay, how removed records are handled for data protection requests, and where restored copies may be opened. Ask your compliance lead to confirm these rules, since DeployOpen prepares the controls and evidence but independent auditors assess them.

Why ERPNext offsite backups fail and how to fix them

This table lists the failures that most often stop ERPNext offsite backups to S3, Dropbox or Google Drive, with the cause and fix for each. Read it as a checklist: confirm the cause in your own logs and settings, then apply the fix before changing schedules or credentials.

Failure	Likely cause	Fix
Upload denied by S3	IAM policy missing the actions the backup needs, or attached to the wrong user or role	Create an IAM policy for the S3 service with the required actions, attach it to the identity ERPNext uses, and confirm the bucket name and region match the settings
Bucket exposed or upload blocked	Block all public access set incorrectly, or a bucket policy conflicts with the IAM policy	Enable Block all public access on the bucket as the ERPNext S3 guide recommends, then review the bucket policy for statements that override the intended access
No failure emails arrive	Email Account not created before the backup job was configured, so there is no sender to notify	Create and test an Email Account first, then confirm the backup settings point to it and check spam folders for the first alert
Dropbox backups stop silently	Access token expired or revoked after the Dropbox app or user permissions changed	Reauthorize the Dropbox app in Dropbox Settings, confirm the app has the file permissions it needs, and check the next scheduled run
Backups overlap or pile up	Backup frequency shorter than the time a full backup and upload takes, so jobs queue behind each other	Measure the duration of a full run on a copy of production, then set the frequency with headroom and confirm with your ops team before changing it
Backups missing after version 16	Backup integration moved to the separate offsite_backups app, so old settings or the app itself are not present	Confirm the offsite_backups app is installed on the site, re-enter the integration settings, and run a manual backup before trusting the schedule
Credentials leak into logs or shared settings	Keys entered by someone who left, or stored in a shared document or ticket	Rotate keys, use a dedicated service identity with least privilege, and record the owner and rotation date in your access register

Questions buyers ask before setting up offsite backups

What does it cost to set up ERPNext offsite backups?

The cost is mostly labor plus the storage you pay your cloud or file provider for. The ERPNext backup integrations for Amazon S3, Dropbox and Google Drive are not priced by Frappe, and the supplied facts do not give a figure for storage or setup time. Self-hosting ERPNext is free, so the expense is the people and the infrastructure around it. Ask any quote to split the work into a one-time setup (bucket or app creation, IAM policy, email alerts, a first test restore) and recurring items (storage volume, retention, monitoring and staff time for failure emails). Ask the provider to state which storage tier and retention period the estimate assumes.

How long does an offsite backup setup take?

Duration depends on how many sites you run, whether your bucket and IAM policies already exist, and how much testing your change process requires. A single site with an existing cloud account is a small task. Multiple sites, new cloud accounts, or strict approval steps add time. No duration figure is supplied for this work, so ask for a timeline in the written scope, with separate milestones for the schedule, the failure notifications and the first restore test.

What does my team need to provide for the backup setup?

You need an administrator on the ERPNext site, access to the cloud account that will hold the backups, and someone who can approve IAM policies. For Amazon S3, the setup guide asks you to enable Block all public access on the bucket, create an IAM policy for the S3 service with the needed actions, and create an Email Account first so that backup success and failure emails reach people who will act on them. For Dropbox, a Dropbox app must exist in the Dropbox developer area before ERPNext Dropbox Settings can be configured. Name a recipient list for alerts before work starts.

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

Yes, if your team has administrator access to the ERPNext site and the cloud account, and can read the vendor setup guides. The configuration steps are documented for S3, Dropbox and Google Drive. The harder parts are the IAM policy design, retention decisions, alert routing and restore testing, which need someone who owns the backup policy. A partner is useful when you want a fixed scope, documented evidence of testing, or the work done alongside an upgrade. Compare the internal staff hours against a written scope before deciding.

How should we test ERPNext backup restores?

A backup that has never been restored is an assumption, not a recovery plan. Schedule restores into a separate, non-production ERPNext site on a regular basis, check that the database, files and document counts match expectations, and record the result. Confirm that the backup files can be downloaded from S3, Dropbox or Google Drive and that the credentials still work. Keep the restore procedure written down so someone other than the original administrator can run it. Ask any partner to include restore tests as a named deliverable with a written result.

What changes for offsite backups in ERPNext version 16?

In version 16, the backup integrations move out of Frappe into a separate app. The Frappe version 16 migration guide lists Backup Integrations among the modules moved to frappe/offsite_backups. This means you need to install and manage that app as part of your upgrade, and check that your existing backup configuration carries over. Plan the move as a change to the upgrade, not as a routine settings edit, and test a backup and restore after the upgrade. Confirm the current version support status on the Frappe supported versions page before you schedule the upgrade.

What drives ongoing backup costs over time?

The main recurring drivers are the volume of data you keep, how long you keep it, how often backups run, and the staff time spent watching failure emails. Storage volume grows with your database and files, and retention multiplies it: keeping many daily copies costs more than keeping a few. Frequency affects both storage and the amount of data you could lose between backups. Ask the quote to show how each of these is priced, what the cloud provider charges for storage and requests, and who is responsible for responding to failed backup emails.

Does offsite backup mean our data is secure and compliant?

Offsite storage gives you a copy outside the ERPNext server, but it does not by itself secure the data or satisfy a compliance requirement. Security depends on the bucket settings, the least-privilege IAM policy, the access controls on the Dropbox or Google Drive account, and how credentials are stored. Compliance depends on your retention policy, encryption choices and the evidence you keep. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports, so confirm requirements with your assessor.

How DeployOpen scopes and delivers ERPNext offsite backups

DeployOpen plans and implements ERPNext offsite backups inside your own cloud accounts, so backup copies land in the Amazon S3, Dropbox or Google Drive destinations you choose and control. We agree the scope in writing first, then build, test, document and hand over the setup so your team can run it.

How we scope

We confirm which ERPNext version and deployment method your site runs before choosing a backup destination.
We record the destination (S3 bucket, Dropbox app or Google Drive account), backup frequency and who receives success and failure emails.
We agree in writing which IAM policies, retention expectations and restore checks are in scope before work starts.

How we build

We create the bucket with public access blocked, a scoped IAM policy and an Email Account, following the ERPNext S3 guide.
We configure the Dropbox or Google Drive connection and schedule backups in ERPNext, then run test backups to confirm delivery.
We check failure notifications by triggering a controlled failure and confirming the alert reaches the right mailbox.

How we hand over

We deliver a runbook covering credentials, bucket and policy settings, schedule details and where each backup is stored.
We document the restore procedure and walk your team through restoring a backup into a non-production site.
We record any version-specific steps, including the move of backup integrations into the separate offsite_backups app in version 16.

How we support

Ongoing support, upgrades and periodic restore testing are available as a retainer, scoped separately from the build.
We review the backup setup when you upgrade ERPNext or Frappe, since integration packaging can change between versions.
Support covers changes to credentials, rotation of access keys and adjustments to schedules as your data volume grows.

ERPNext offsite backups to Amazon S3, Dropbox and Google Drive