Backup
A backup is an additional copy of data stored separately from the original so it can be restored after a failure, error or attack. In an ERP context, the backup protects the database, documents and configuration so that a company can keep working without data loss when problems occur.
A backup is a copy of data deliberately kept separate from the original so that the previous state can be restored after data loss. The cause of a loss can be many things: a defective storage medium, an accidentally deleted record, a faulty update, an encryption attack (ransomware) or a fire in the data center. A backup answers the question “How do I get my data back when the live system can no longer provide it?” – making it the life insurance of every digital business application.
In an ERP environment the backup is especially important, because the ERP system holds a company’s central data foundation: the product master, customer and supplier master, open orders, stock levels, documents and postings. If this data foundation is lost irretrievably, operations grind to a halt – no orders, no invoices, no shipping. A verified, regularly running data backup ensures that after an incident a company can become operational again within a manageable time and with as little data loss as possible.
At a glance
- Backup = an additional, separately stored copy of data for restoration
- Protects against hardware failure, operator error, faulty updates and ransomware
- Key metrics: RPO (maximum data loss) and RTO (recovery time)
- Proven rule: 3 copies, 2 media types, 1 copy offsite (3-2-1)
- A backup is only ever worth as much as its tested restore
How a backup works: backup and restore
A backup is created when software reads out the current data and writes it as a copy to a second location – to another server, a network storage system, a tape drive or cloud storage. So that the copy does not become outdated immediately, it is repeated at fixed intervals: often daily, and for critical systems several times per hour. The actual purpose only becomes apparent in the counterpart, the restore: the lost state is played back from the saved copy, in whole or in part.
Technically there are several backup types. A full backup copies the entire data set every time – complete, but storage- and time-intensive. An incremental backup only saves the changes since the last backup, a differential backup the changes since the last full backup. In practice these types are combined: a weekly full backup as the basis, with daily incremental runs in between. This keeps storage requirements manageable without letting the data gap grow too large.
RPO and RTO: the two decisive metrics
How good a backup is can be measured by two values. The Recovery Point Objective (RPO) describes the maximum tolerable data loss – with a daily backup, up to 24 hours of work. The Recovery Time Objective (RTO) states how long the restore may take until the system is running again. Both values derive from the business risk: an online shop with thousands of orders per day needs a much smaller RPO than a business that invoices only monthly.
Backup strategy: the 3-2-1 rule
A single copy in the same place as the original offers little protection – a fire, theft or encryption attack hits both at once. As a rule of thumb, the 3-2-1 strategy has therefore become established: at least three copies of the data, on two different types of media, one of them kept offsite. This way, even if the site is completely lost, an intact copy remains reachable. Modern variants add an “immutable” copy that even an attacker with administrator rights cannot overwrite or delete – effective protection against ransomware.
The strategy also includes the retention period: how many generations of a backup are kept? A common mistake is to keep only the most recent copy. If an error – such as a faulty import or a creeping data corruption – is only noticed after days, all backups have already been overwritten with the error. A staggered retention (daily for two weeks, weekly for a few months, monthly for a year) keeps older, clean states available as well.
Backup in the ERP system
With an ERP, it is not just a simple file store that is backed up, but a running database with thousands of linked records. A ERP backup therefore has to be consistent: all related postings, stock levels and documents must reflect the state of the same point in time, otherwise the restore produces a contradictory data set. Database systems solve this via consistent snapshots or via continuous backup of the transaction log, with which the state can be rolled back to almost any second.
How the backup is organized depends heavily on the operating model. With a cloud ERP in the SaaS model, the provider handles the technical backup in the data center; scope, RPO, retention and the option of a single-record restore are then set out in the contract and SLA terms. With an on-premise installation or self-hosting, responsibility lies with the company itself – including planning, execution and regular restore tests. In both cases it should be clearly defined who recovers which data, and how quickly, in an emergency.
Distinction: backup vs. disaster recovery vs. high availability
These three terms are often confused. A backup is the data copy from which lost data can be retrieved. Disaster recovery is the broader contingency plan that describes how the entire operation restarts after a major outage – backups are one building block of it, but replacement hardware, responsibilities and procedures are part of it too. High availability (anchored in an availability SLA), on the other hand, prevents outages through redundancy during live operation, but is no substitute for a backup: a deleted or encrypted record would otherwise only be reliably mirrored to all nodes.
Why backups also matter legally in the DACH region
Data backup is not just technical prudence, it also touches on legal obligations. The GoBD require that tax-relevant data and documents remain available, readable and unchanged throughout the statutory retention period – without a reliable backup this cannot be achieved. A backup alone does not yet meet the requirement for audit security (that additionally needs immutability and traceability), but it is the basic precondition for being able to access older document states at all.
On top of this comes data protection: under the GDPR, the ability to quickly restore personal data after an incident is explicitly one of the technical protective measures. At the same time, backups containing personal data must themselves be protected (for example encrypted) and included in the deletion concepts. Anyone who documents data backup cleanly is paid back twice – in an emergency as a fast restore, and towards auditors as demonstrated diligence.
The most important principle: test the restore
The most common and most expensive backup mistake is relying on untested backups. A backup that has never been restored is only an assumption: tapes can be unreadable, cloud copies incomplete, database dumps corrupted – and experience shows this comes to light precisely in an emergency, when it is too late. Only a successful restore in a test environment proves that the backup works and that recovery succeeds within the planned RTO.
A robust backup concept therefore includes regular, logged restore tests, monitoring that immediately reports failed backup runs, and clear responsibility. For ERP systems it is advisable to run through a full restore at least once a year and document the results – this brings calm in an emergency and is at the same time part of clean process documentation.
Example
Example: ransomware hits an online retailer
A mid-sized online retailer with around 300 orders per day runs its ERP in self-hosting. On a Monday morning all servers are encrypted and a ransom demand appears. The live system is no longer usable, and the backups on the same network were also encrypted by the attacker – except for one immutable copy written nightly to a separate cloud storage.
From this offsite copy the service provider restores the ERP onto replacement hardware. Because the last clean backup dates from 2 a.m., only the orders of the current morning are lost (RPO ~7 hours), and these are reconstructed from the marketplace confirmations. After a good half day the system is productive again (RTO). Without the separate, immutable copy and the previously tested restore procedures, the outage would have lasted days – or data would have been lost for good.
Frequently asked questions
Related services
Questions about Backup in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.