CRM/ERP Backup: policy for frequency and retention

Why CRM/ERP needs a backup policy

CRM/ERP holds data without which the business quickly stops: sales, money, shipments, contracts, access rights. With a clear policy, CRM/ERP backups stop being a one-off task for an admin and become a predictable process: what we back up, how often, where copies are kept and who is responsible.

Not only orders and postings are critical, but everything that keeps the system predictable:

• the database (deals, invoices, payments, balances)
• directories and settings (product catalog, counterparties, prices, tax rules)
• documents and attachments (acts, contracts, scans)
• integrations and exchange queues (cash registers, warehouse, bank-client, EDI)
• user accounts and roles (who sees and can change what)

It helps to separate two risks from the start: data loss and system downtime. Data loss means part of the history is gone (for example, orders from the last 6 hours). Downtime means data is intact but unusable (application crashed, disk full, network failed). The policy is needed to agree in advance which is worse for you and which actions start in each case.

A backup without a verification restore is not considered protection. A common situation: copies are created but no one checked they can be opened, that encryption keys are present, or that recovery fits within the allowable time.

Usually the whole system doesn't fail at once; specific elements fail: database, disks and storage, application, user accounts (rights removed, password changed, service user locked). A policy helps avoid guessing in an incident and follow a pre‑tested plan.

Goals and metrics: RPO, RTO and data criticality

A policy starts not with tool selection but with answers to two questions: how much data you can afford to lose and how fast the system must return to work. Without this, CRM/ERP backups easily become a set of copies that don't match the business expectations.

RPO (Recovery Point Objective) is the acceptable data loss in time. If RPO = 15 minutes, in the worst case you lose changes from the last 15 minutes: orders, payments, statuses, messages. RTO (Recovery Time Objective) is the time to restore the service to an operational state. If RTO = 2 hours, users must be working again within 2 hours, even if some reports or integrations are temporarily unavailable.

To make RPO and RTO realistic, classify data by criticality and set a target for each level:

• Critical: sales, warehouse, payments, user accounts, access rights
• Important: analytics, data marts, change histories
• Can wait: archives, old attachments, test environments

Example: Sales needs RPO 30 minutes and RTO 1 hour, while accounting accepts RPO 24 hours if month‑end closing isn't affected. For critical data you schedule more frequent copies and faster recovery, and for secondary data you keep infrequent archival copies.

Also check maintenance windows and load constraints. Heavy operations (full backups, consistent snapshots of large DBs, file dumps) are better scheduled at night or low activity periods. If there are no quiet windows, record that in the policy and include technical measures: more frequent incremental backups, replication or spreading tasks in time.

Backup frequency: choosing a mode for your system

Backup frequency in CRM/ERP depends not on a habit of daily copies but on how much data you can lose and how quickly you must restore. Even with the same system, sales and accounting will have different load peaks and risks.

A full backup is useful as a restore anchor point, but daily fulls are not always justified. They take more time and space, often fall into active windows and can interfere with other tasks. In practice, full backups are done less often and deltas fill the gaps.

Incrementals save only changes since the last backup and usually take less space. Differentials save changes since the last full backup. Differentials are simpler to restore (shorter chain); incrementals save space but require discipline: loss of one fragment breaks recovery.

If the DB supports transaction logs, copying them allows RPO to be reduced to minutes. This is important where every order or payment is critical.

A practical scheme often used as a baseline for a policy:

• full backup once a week in the quietest window
• daily differential or several incremental backups during the day
• transaction logs every 5–15 minutes for key databases
• a separate backup before upgrades, integrations and bulk uploads

Example: a retail company peaks 12:00–21:00 and month‑end closing is on the last day. Frequent incrementals run during the day, and before month‑end add an unscheduled full and preserve logs more often to avoid losing the latest postings and order statuses.

What exactly to back up in CRM/ERP

For backups to actually save you, copy more than just the database. In incidents it’s often not a table that failed but a combination: files, settings, integrations, licenses, customizations.

Minimum set, without which recovery will be incomplete

It’s useful to group components and know where each lives and how it is restored:

• operational databases (main DB, transaction logs, service DBs if any)
• CRM/ERP file storage (attachments, scans, documents, exports, exchanges with external systems)
• application and environment configuration (config files, connection parameters, job schedules, queues)
• integrations and secrets (API tokens, passwords, encryption keys, certificates, integration parameters with 1С, mail, telephony, etc.)
• customizations (scripts, plugins, print forms, reports, templates, stored procedures)

If you back up only the DB, you often end up with a system that starts but users can't see attachments, integrations with accounting don't work, and reports are broken because custom templates weren't restored.

Inventory: where things are stored and who owns them

Before locking a backup list into the policy, do a short inventory. It takes little time but can save days during recovery:

• what exactly is backed up and where it physically lives (server, VM, cloud, NAS)
• who owns the data (IT, business unit, contractor) and who grants access
• how to restore each component (steps, accounts, licenses, dependencies)
• where to check the result (signs the system works: login, search, create deal, open attachment)

Example: a company has ERP on a server and files on a network disk. After a failure they restore the DB in an hour but spend two days finding a certificate for a government integration and the key to decrypt archives. These small items should be in the backup package with separate access rules.

Storage and rotation: retention periods, locations, immutable copies

Even perfect backup frequency won't help if copies live in one place and are quickly overwritten. The policy must answer three questions: how long we keep, where we store, and how we protect copies from change.

A common retention scheme for CRM/ERP backups is straightforward and easy to explain to the business:

• daily copies: keep 7 days
• weekly copies: keep 30 days
• monthly copies: keep 90 days
• month archive: keep 12 months
• year archive: keep 3–7 years (if required by policy or law)

Tie retention to business needs: incident investigations, month‑end closing, audits and tax periods. If accounting needs last year's data, record exact retention rather than vague statements.

Rotation and cleanup must be assigned to a role, not to abstract IT. The policy should state who watches storage usage, who approves deletion of old copies and what to do when storage is near capacity (pause secondary jobs, expand storage, move archives to cheaper media).

For locations follow the 3‑2‑1 principle: three copies, on two different storage types, one copy off the main site. This can be a separate server, separate storage and a remote site or datacenter.

A separate point is immutable copies. They protect against ransomware and admin mistakes: history cannot be quietly wiped even with elevated privileges. Specify which copies are immutable (for example weekly and monthly), for how long and who can change that setting. If a systems integrator builds your infrastructure, discuss support for immutable repositories on your hardware and on the remote site in advance.

Encryption and keys: how not to lose access to backups

Encryption for CRM/ERP backups is not optional. Backups often contain more information than the production DB: personal data, financial documents, attachments and logs. If an archive leaks, the damage is comparable to a production breach.

Encrypt both during transfer and at rest. During transfer protect the channel between CRM/ERP server, storage and replication site. At rest encrypt the file or volume on disk and object storage if used. In the backup policy state explicitly: unencrypted copies are invalid.

Key management

Keys are more important than archives. If a key is lost or blocked, recovery is impossible even with perfect copies.

Minimum rules:

• store keys separately from backups (different system, different access)
• assign a key owner (usually InfoSec) and an emergency access procedure
• rotate keys on schedule and when staff leave
• keep a secure key backup and regularly verify it can be read

Separation of duties

A typical mistake: the CRM/ERP admin also manages backups and keys. One compromised account then gives access to everything. Better separate roles:

• system admin runs backups and views status
• InfoSec manages keys and access policies
• a separate person or group confirms restore operations

Also check compliance with internal policies and regulators: who can access data, where copies are physically stored, how key issuance is logged and who approves exceptions.

Responsibility and oversight: who does and who checks

Backups fail more often from lack of ownership than from technology. If roles are not assigned, backups may run for months but at the moment of an incident no one knows where the last copy is or who has key access.

Split duties so one person does and another verifies. Typically four roles suffice:

• system owner (business): sets priorities, confirms RPO/RTO and retention, accepts risks
• administrator (IT): configures schedule, storage, rotation, performs restores on request
• InfoSec: approves encryption, accesses, key rules, enforces compliance
• control owner (IT or internal audit): regularly reviews reports and initiates test restores

Keep operation logs. Logs should show: job start, result (success/failure), size and content, storage location, and any manual actions (deletion, policy change, restore). Record what happened and who did it.

Alerts should go to specific people with clear thresholds. Configure notifications at minimum for: failed backup, missed window, storage full, integrity check error, unauthorized deletion.

A minimal document set should be short but current:

• backup diagram (what is backed up and where)
• schedule and retention
• list of locations and access rules
• contacts and escalation procedure
• short restore and verification instruction

Example: a nightly CRM backup failed due to full storage. The admin gets an alert and frees space; the control owner checks in the morning that the new backup succeeded and the job hasn't been failing for two days in a row. If you have 24/7 support and rely on an external partner, predefine who accepts such incidents and the response time.

Step by step: how to draft and implement a backup policy

For backups to work in a real incident, the policy must be a clear instruction: what to do, when, where copies are, who is responsible and how to verify results.

5 steps to follow in order

1. Record what you protect: databases, attachments, integrations, key reports. Next to each, set RPO/RTO targets (for example orders — no more than 1 hour lost, recovery within 4 hours).

2. Choose backup types and schedule not in general terms but by time and load. Usually this mixes full and incremental backups plus separate exports of critical directories. Specify exact windows: days, hours, duration, traffic limits.

3. Describe storage and rotation so it’s clear where the fresh and long‑term copies live and what is deleted automatically. Separate locations: at least one copy must be off the primary infrastructure. Use immutable copies where possible.

4. Include encryption and access rules: who can run a backup, who can read, who can delete. State where keys are stored, who rotates them and how to act when staff change. Otherwise you can end up with a backup you cannot open.

5. Set up success monitoring: failure alerts, a daily short report, and a monthly summary. Add thresholds: how many consecutive errors are acceptable and when an incident is raised.

Then produce working artifacts: data diagram, schedule, responsibility matrix, restore instruction and verification log. If implementation is done by internal IT with an integrator, set the rule: one performs ops, the other confirms results by reports and spot checks.

If you engage a partner for integration, agree not only on setup but also on ongoing support: monitoring, test restores and key access procedures. In projects with GSE.kz this format usually prevents situations where everything is set up but no one watches it.

Test restores: minimum requirements and how to run them

A backup without verification easily becomes a checkbox: it exists but cannot be restored. Include test restores in the policy as strictly as backups themselves.

Minimum for most companies is quarterly. If CRM/ERP is critical for sales, production or finance, test monthly or after each major update (app version, DB schema, integrations).

Tests to perform

Start simple and increase complexity to check the full recovery path:

• point restore: one file, report, attachment or customer record
• restore the database on a separate server or instance
• bring up a test CRM/ERP stand from backup end‑to‑end
• verify recovery in an incident‑like mode (restricted access, no hints)

After each test measure not only time but result quality.

What to measure and how to record the protocol

Log metrics to see progress and find weak spots:

• actual recovery time vs target RTO
• recovery point achieved vs RPO
• data integrity: spot checks of documents, directories, rights
• integration functionality: mail, telephony, 1С, ESB, APIs, file exchange

The test protocol should be short and unambiguous: date and system version, which backup was used, who performed it, steps, actual times, failures, relevant logs and the resolution.

Example: restoring a stand from the nightly copy took 40 minutes, but mail integration did not start due to an expired certificate. Actions: update the certificate, add certificate expiration checks to monitoring, repeat the test within a week and close the item only after a successful repeat.

Common mistakes that make backups useless

The problem is usually not the absence of copies but that they are unusable for restore.

The worst case is backing up only the database. On restore you find settings, file stores, templates, attachments, integration modules, certificates, schedules and queue configs are missing. The system may be up but not functioning: emails don’t go out, integrations with accounting fail, attachments are missing from deals.

Another frequent issue is having archives but no access. Encryption keys were held by one person, their account left with the admin, storage permissions changed, or an account was blocked. Formally a backup exists; in practice it is unrecoverable.

Keeping backups next to production (same server, same virtualization, same domain) is dangerous. With ransomware or compromised accounts both production and backups can be encrypted because access is identical.

A silent killer is lack of error control. The backup job runs and nobody checks reports, storage fills up and copies stop being created — you only learn on the day of failure.

Finally, manual deletion of copies can break investigations. When rotation is not automated someone may free space and accidentally delete the exact period needed for audit or rollback.

A sign of a healthy process: you know in advance what is backed up, where it is, who holds keys and how quickly you'll notice a backup failure.

Example scenario: incident and recovery under the policy

A branch company uses CRM for sales and ERP for warehouse and shipments. Managers create deals during the day; in the evening the warehouse closes balances and prints waybills. Losing a day’s data is unpleasant; losing a week is critical.

An incident occurs Monday morning after a scheduled update: the ERP DB won't start and logs show file corruption. CRM is working but the ERP integration stopped and the warehouse cannot ship. The policy sets RPO 4 hours and RTO 2 hours for the system.

The on‑call admin starts the recovery procedure. The policy already documents where copies are, how they are encrypted and who has key access, so there is no pause looking for them.

Actions follow a checklist:

• record failure time and choose a restore point: last successful full + last incremental before the incident
• perform recovery on a dedicated server or virtual site (often faster than repairing the live system)
• check DB integrity and start ERP services, then verify exchange with CRM
• run business checks: open 5–10 typical documents (order, invoice, receipt, write‑off), reconcile balances for control items
• switch users and record actual RTO and data loss (actual RPO)

Communication is part of the policy. IT informs the business within 10–15 minutes: what failed, what we are doing, when the next update will be. The IT lead confirms the time estimate, and the process owner (sales director or warehouse manager) accepts the result: system is operational, checks passed, discrepancies understood and logged.

Quick checklist and next steps

To make CRM/ERP backups work in an incident you need configuration and regular verification.

• RPO and RTO for CRM/ERP are recorded and data priorities are set (what to restore first)
• backup schedule and rotation are configured: how long to keep daily, weekly and monthly copies
• storage locations are defined: at least two, plus deletion protection (immutable copies where possible)
• encryption is enabled, key locations and access are documented, and procedures for staff changes are defined
• roles are assigned: who runs, who verifies, who accepts results; alerts and regular checks are in place

Make sure practice exists, not only rules. Keep test restore protocols: date, what was restored (DB, files, integrations), recovery time, problems and follow‑ups.

If you need a quick fix, start with three steps:

1. Do a short audit of current backups: where they are, what period is covered, what is encrypted, which alerts actually arrive.

2. Perform a trial restore in a separate environment. For example, restore the system to yesterday at 18:00 and check login, reports, exchange with 1С, mail and telephony.

3. Record improvements and deadlines: what to adjust in schedule, storage, access, and when to repeat the test.

If you need reliable infrastructure and turnkey implementation, consider a solution on domestic hardware with system integration and 24/7 support. For example, GSE.kz (gse.kz) manufactures servers and helps assemble infrastructure for backup and recovery, including rack S200 Series.