Backups: how to set them up so data is never lost

There are only two kinds of company: those that verify their backups, and those that discover the backups do not work on the day of the disaster. A ticked "backups enabled" box in the hosting panel does not mean you have a backup — it means you have a ticked box. Let us build a scheme that actually saves you.

The 3-2-1 rule and why it still holds

Three copies of the data, on two different media, one of them off-site. The logic is simple: the first copy protects against an accidentally deleted file, the second against a disk failure, the third against fire, equipment seizure or the compromise of the entire hosting account. The most common failure is all three copies living in one account with one provider. If the account is suspended for non-payment or the panel is breached, you lose everything at once.

What exactly to back up

• The database — a full dump, not just the user tables.
• User uploads: images, documents, attachments. These make up most of the volume and cannot be restored from the repository.
• Configuration files for the web server, the environment and cron jobs.
• SSL certificates and keys, if they are not issued automatically.
• The DNS zone in text form — rebuilding it by hand from memory takes hours.
• A list of installed packages and versions — without it, assembling "the same server" takes a week.

Retention depth: why one copy is not enough

A daily copy that overwrites itself is useless against the two most common scenarios. The first is ransomware: it works quietly, you notice the problem several days later, and every copy has already been overwritten with encrypted data. The second is silent data corruption from a bug in the code: a faulty import damaged a field in the database and you find out two weeks later. A workable retention scheme is 7 daily copies, 4 weekly and 12 monthly. For most projects this fits into tens of gigabytes and costs a few hundred roubles a month.

The two numbers that define the scheme

RPO is how much data you are prepared to lose, measured as the interval between copies. RTO is how quickly you must be back up. For a brochure site an RPO of a day and an RTO of 4 hours are acceptable. For an online store or ERP losing a day of orders is unacceptable: you need continuous transaction log archiving and an RPO measured in minutes. These two numbers determine the budget, not the other way round. First calculate the cost of an hour of downtime, then choose the solution.

Encryption and access

A database backup is your customer base in the most convenient possible form for an attacker. It must be encrypted before it is sent to storage, and the key kept separately from the copies themselves. A separate requirement: the account that writes the backups must not have the right to delete them. Otherwise an attacker who gets onto the server wipes the archives first. Under 152-FZ, backups containing personal data are subject to the same localisation rules as the primary database — more on this in the security section.

The main thing: test restores

A copy you have never restored from is not a copy, it is a hope. Once a quarter, deploy the archive to a test environment in full, with a stopwatch running. You will learn your real RTO instead of your assumed one, and you will discover that the database dump breaks halfway through or that the contracts directory was never included in the backup. An hour of work once every three months against a day of panic is an obvious trade.

A minimal scheme to start with

• A daily automated dump of the database and files on a schedule.
• Upload to object storage at a different provider with a write-only key.
• Retention of 7/4/12 and encryption of the archive.
• An email alert when a job fails — silence does not mean success.
• A calendar reminder for a quarterly test restore.

If there is nobody to set this up, or you would rather hand it to a team, we run setups like this as part of ongoing maintenance. You can discuss the parameters for your project through the form.