Backing Up 1C: Why a Database Copied by Simply Copying the Folder May Not Open, How Often to Make Dumps, Where to Store Them and How to Check You Can Really Restore from a Backup

For many companies in Tbilisi, especially those working with Russian-speaking accountants or keeping records in the software they're used to, the 1C database is the heart of the business: accounts, inventory, sales, payroll and several years of settlement history. Losing it means work stops, weeks of manual reconstruction from paper documents, and possible reporting problems. Yet we constantly see cases where there seemed to be a backup, but it couldn't be restored: the file was corrupted, the copy sat on the same drive as the database, or the last backup was six months old. Let's look at how to do it properly.

File-based and client-server databases

Small companies most often use the file-based version: the whole database is stored in one file in a folder on the accountant's computer or a server. Larger ones use the client-server version, where data lives in a database management system on a server. The backup methods for them differ, and rules that suit one version don't always work for the other.

The main mistake — copying the file while it's in use

The most common "method" is simply copying the database folder to a USB stick or the cloud. If someone is working in the database or the program is open at that moment, the file is copied mid-write, and such a copy may not open or may contain corruption that only shows up when you try to restore. Cloud syncing of a folder with a live database is even more dangerous: the sync client may upload a corrupted state or even cause conflicts that damage the working file itself.

How to back up properly

• Exporting the infobase with the program's own tools creates a consistent copy that can be loaded on any computer. It's done when nobody is working in the database.
• Scheduled automatic backups — at night, when users have logged out. For file-based databases, dedicated utilities or built-in mechanisms are used; for client-server ones, the DBMS's own backup tools.
• Regularity. Daily for an actively used database. Additionally, before every configuration update, period close and bulk change.
• Retention depth. Keep not just the latest backup but several: from recent days, weeks and months. Errors in data are often not spotted immediately, and you may need to go back to the state a month ago.

Where to store backups

A backup sitting on the same drive as the database protects only against software errors, not against drive failure, a stolen computer or ransomware. Backups should be kept in several places: on a separate drive or NAS in the office — one protected from changes by work computers — and off-site, in the cloud or on media kept by the manager. Backups containing accounting data should be encrypted, especially when stored in the cloud.

Before an update — always a backup

A configuration or platform update is one of the moments the database is most often damaged: the update is interrupted by a power cut, turns out to be incompatible with customisations, or freezes halfway. A backup made immediately before the update lets you return to a working state in minutes.

Testing restores

A backup that's never been test-restored is a hope, not protection. Once a month or quarter, restore a backup on a separate computer or into a test database and check that it opens, the data is current and reports run. It takes little time but gives confidence that everything will work on the day of a disaster.

If the database is already damaged

If the database won't open, throws errors or data has disappeared, don't repeatedly run testing and repair without a copy: the procedure can delete "broken" objects along with their data. First make a copy of the damaged database as it is, then attempt recovery with specialised methods. If the database file was deleted or encrypted, data recovery from the drive sometimes helps.

What our technician does

1. Finds out where and how the database runs, how many users there are and how backups are made now.
2. Sets up scheduled automatic backups with several generations of copies.
3. Arranges storage on a protected NAS and in the cloud with encryption.
4. Sets up notifications of successful or failed backups to a responsible employee.
5. Runs a test restore and leaves clear instructions for an emergency.

A real example

A trading company from Samgori kept its inventory and accounts in a file-based 1C database on the accountant's computer, and its "backup" was a daily cloud sync of the database folder. When the computer's drive began failing, the database stopped opening — and the cloud copy turned out to be corrupted too, because the sync had uploaded the damaged file. We recovered the database from the failing drive and repaired it, losing only a few documents from the last day. We then moved the database to a server and set up a nightly export keeping 30 daily and 12 monthly copies on a NAS and in encrypted cloud storage, with notifications to the accountant about the result of every backup.

Call a technician

If you want to protect your 1C database reliably, or it's already damaged, we'll help in any district of Tbilisi around the clock. Learn more on our data recovery, software installation and local network setup pages.