1C and CRM Backup: What to Copy and How to Test It

Backup of a 1C or CRM database is a regular copy of data that you can deploy on a clean server and open. It takes three things: a copy of the database itself, a copy of the files and settings around it, and restore testing on a schedule. A copy that has never been restored remains an assumption.

We covered the general 3-2-1 scheme and the RTO and RPO terms in the article on recovering IT systems after failures. Here is the practice for databases: what exactly to copy, which method to use, how often, and how to make sure the copy works.

What a backup includes besides the database itself

A backup includes everything without which the database cannot be opened on a new server: not only the database file or dump, but also the files next to it, the configuration and the environment settings.

Tip Write a one-page list of what you copy and keep it away from the server. On the day of an outage it shows what is missing for a restart.

Which backup method to choose for a database

The method depends on the DBMS, the size of the database and how much data the company is ready to lose between copies. Client-server 1C and CRM databases run on a DBMS, for example PostgreSQL or Microsoft SQL Server, and the rules of that DBMS apply to them.

The PostgreSQL documentation describes three approaches: an SQL dump, a file system level copy, and continuous archiving with point-in-time recovery.

For the last method the PostgreSQL documentation says: you can restore the database to its state at any time after the base backup, but you need a continuous sequence of archived log files. That is why archiving is set up and tested before the first base copy, and the process is kept under watch.

The same documentation states that pg_dump does not produce a file system level backup and cannot be used for continuous archiving: such dumps are logical and do not contain enough data to replay the log. The two schemes are not mixed; you choose one deliberately.

Important A file-mode 1C database is a single file, and copying it while users are working is risky: the copy may be inconsistent. Copy the file when sessions are closed, and treat a database export made with 1C tools as an extra copy until a test restore has been done.

How often to copy 1C and CRM databases

Copy frequency equals the acceptable data loss (RPO): if the business can lose an hour of work, copies are needed at least hourly; if a day, daily. This number is set by the manager, not by the administrator.

The figure differs between systems. An accounting database that posts documents all day loses more from a nightly copy than a counterparty directory that changes once a week. A CRM with active correspondence and calls should be copied more often than a database opened once a month.

• Full copy — usually at night, when the load is lowest.
• Intermediate copies or log archive — during the working day, for systems with a short RPO.
• User files and server settings — on a schedule tied to how often they change.
• A copy before changes — before updating the configuration, the platform or the DBMS, separate from the schedule.

How to check that a copy restores

There is only one way to check a copy: deploy it on a separate machine and work in the database. A log entry saying the job finished proves that a file was created, not that data can be restored from it.

1. Take the copy from the storage, not from the production server: this also tests access to the copy.
2. Deploy it on a test machine with no access to the production database and no integrations, so that it does not send emails and payments to customers.
3. Open the database and run control checks: the latest document is there, a report for a chosen date matches the production database, attachments open.
4. Measure the time from start to a working database and compare it with the RTO.
5. Record the result and fix the gaps you found: what was missing and how long it took.

DBMS checks help but do not replace a test restore. The Microsoft SQL Server documentation says that RESTORE VERIFYONLY checks that the backup is complete, the volumes are readable and the checksum matches, but does not verify the structure of the data inside the backup.

The CISA recommendations for small and medium businesses add: test both full and partial restores and make sure you can roll data back at least seven days.

Where to keep copies: the 3-2-1 scheme and Uzbek law

Copies are stored so that one incident cannot destroy both the database and all its copies. CISA describes the 3-2-1 scheme in the same recommendations.

• 3 copies of important data
• 2 different types of media
• 1 copy outside the company site
• 7 days minimum rollback depth per CISA recommendations

In a ransomware attack one more copy matters: one that cannot be reached from the working network. The CISA ransomware response guide describes restoring data from offline, encrypted backups, with a warning: take care not to re-infect clean systems during recovery.

A copy holds the same data as the production database, so the storage location is checked against the same rules. Under Article 27-1 of the Law On Personal Data No. ZRU-547 as amended by Law No. ZRU-1125 of 26.03.2026, biometric and genetic data and data of users of telecom operators working in the country must be stored in Uzbekistan. Under Article 20, databases with such data are subject to registration in the State Register of Personal Data Databases.

Other personal data may be stored abroad under the conditions of the law. We wrote about choosing a cloud in the article on cloud and server options in Uzbekistan. For a database with biometrics, the copy is kept in the country, and the scheme is agreed with a lawyer.

Where to start if there are no copies or they have never been tested

Start with an inventory and a first test restore, not with buying storage: until you know what exactly you are protecting, any decision is guesswork.

1. List your databases and services: 1C, CRM, website, mail, file server. Next to each, write who uses it and what stops without it.
2. Ask department heads to name acceptable downtime and data loss. That gives the RTO and RPO for each system.
3. Set up copying to a separate disk or server and add a second copy off-site.
4. Run the first test restore and write down what went wrong. The result gives you a list of improvements for the next month.

What to put in a backup policy

A policy turns backup into a process instead of a one-off setup: it names who is responsible, what is copied and how the result is checked. One page is enough.

• a list of systems and databases with assigned RPO and RTO;
• what is copied for each system: database, files, configuration, settings, keys;
• the method and schedule, full and intermediate copies;
• where each copy is stored, including one off-site and one unreachable from the working network;
• who is responsible for copies and who covers during vacation;
• the date and result of the last test restore and the date of the next one;
• who is notified if a backup job fails.

Which mistakes turn a backup into a formality

More often than not a copy fails not because of a complex technical cause but because of an organizational mistake that is visible in advance.

• The copy sits on the same server or disk as the database: when it fails, both are lost.
• Only the database is copied, while attachments, configuration and keys are forgotten.
• The file of a production database is copied while users are working, giving an inconsistent copy.
• A "job completed" message is taken for restore testing.
• Copies stay writable from the working network: ransomware reaches them too.
• Nobody watches the chain of archived logs: one missing piece, and restoring to the required moment is impossible.
• Nobody is assigned: everyone has a copy and no one owns it.

How we organize backup

At Syntra Systems we start with a calculation: we define RPO and RTO for each database together with you, then split copies into database, files and settings, choose a method for your DBMS and place copies in different locations. Syntra Cloud servers are in a data center in Uzbekistan: a server for a website or CRM is from $30 per month.

After that, backup has to be maintained: watching the jobs and running test restores. The support page states that the plan from $250 per month includes updates, copies and monitoring, and the response time for a critical failure depends on the plan and is fixed in an appendix to the contract. For more on how support and SLAs work, see the article on IT infrastructure technical support.

Frequently asked questions

Cover photo: David Yu, Pexels