A backup is not a security measure until you have restored it, on a clean machine, within the time you promised. Modern ransomware goes for the backup server first, so one copy must also sit outside your network.
A VPS snapshot sits on the same storage, at the same provider, under the same account. If the account is compromised or the storage fails, it disappears with the server. It helps after a botched update, but it is not one of the three copies. The untested backup is the second trap: the dump has run since Monday and nobody has ever opened it. During an incident you learn that it is truncated, that a table is missing, or that the encryption key stayed on the encrypted server.
The first copy is the server itself. The second is a daily backup to separate storage, encrypted at the source with restic or borg, which deduplicate and keep versions. The third is offsite, in another datacentre or at another provider, with write-only access from the server so an attacker cannot erase the history. You get the immutable copy through object lock on S3-compatible storage. For databases, take a logical dump or use PITR rather than copying files while they are being written.
Article 32 GDPR explicitly requires the ability to restore the availability of and access to personal data in a timely manner after an incident, and ANSPDCP checks this after any breach notification. Companies that issue e-Factura must keep the invoices sent to ANAF for the legal archiving period, so losing the XML archive is a tax problem. Entities registered with the DNSC under OUG 155/2024 have business continuity and backup among the measures required by Article 11 of OUG 155/2024.
| Element | What it means | How you implement it | How you check it |
|---|---|---|---|
| 3 copies | Production + two backups | Local daily backup + offsite | Same version in all of them |
| 2 media | Different storage systems | Local disk + object storage | One incident cannot reach both |
| 1 offsite | Another physical location | Another datacentre or provider | Test restore from the offsite copy |
| 1 immutable | Cannot be deleted from the server | Object lock or rest-server --append-only; pruning runs separately, not from the server | Deleting from the server's account fails |
| 0 errors | The restore completes fully | Monthly test on a separate machine | The application starts and the data is correct |
export RESTIC_REPOSITORY=s3:https://s3.example.ro/backup-example
export RESTIC_PASSWORD_FILE=/root/.restic-pass
export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=...
restic init
restic backup /var/www /etc /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune
restic check --read-data-subset=1/10pg_dump -Fc -U app example_db > /var/backups/db/example_db-$(date +%F).dumprestic restore latest --target /restore
createdb example_db_test
pg_restore -Fc -d example_db_test /restore/var/backups/db/example_db-2026-09-07.dumpThe XML invoice archive lived only on the application server and in the provider's snapshot. After a ransomware attack both were encrypted. The firm rebuilt the archive from SPV with great effort and moved to encrypted daily offsite copies with object lock.
The MySQL dump ran daily, but for three months it had been failing for lack of disk space and nobody received an alert. When an update went wrong, the last valid copy was three months old. A monthly restore test and an alert on failure followed the next day.
It depends on your RPO. If you can lose at most a day of data, a daily backup is enough. A shop with continuous orders needs database backups every few hours or PITR, which lets you return to any moment. Static files can be copied less often than the database.
A copy that, once written, cannot be changed or deleted until its retention expires, not even by an administrator with full rights. You get it through object lock on S3-compatible storage or append-only repositories, so an attacker who controls the server cannot destroy your history.
It is a good copy, but it is one copy, at one provider, under one account. The 3-2-1 rule asks for a copy in another location and on another medium, which you control. Keep the provider's backup as the first line and add your own offsite copy.
A production server starts getting attacked within minutes of receiving a public IP address, however small the project is. This guide ranks the controls by impact, from SSH access to incident response, with the Romanian rules that apply along the way. Every topic has its own page with a short answer, examples and ready-to-use configuration.