On backups

As we all know, people fall into two types: those who make backups and those who already make backups.

☝️So we won't dwell on why making backups is necessary. Even if you're in the "clouds", which occasionally burn down beautifully.

Instead, let's talk about the basic principles:

Principle #1: don't keep all your eggs in one basket.

• It's better to store them in at least three. What does that mean? There's not much sense in taking a database backup and putting it on the same server, or even in the same data center, or in another data center with the same hosting provider. Ideally it's even better to use a different jurisdiction. Depending on your level of paranoia and risk requirements, choose storage in the right place.

Principle #2: verify

• Regularly check that backups can be restored, and generally monitor the creation process. While you can verify backups once a month, you need to monitor their creation continuously, which means you need monitoring set up.

Principle #3: encrypt

• So that your data doesn't leak anywhere, it's important to encrypt backups before sending them off for storage, but you must clearly understand how you'll decrypt them when needed.

Principle #4: backup intervals must be acceptable in terms of potential losses.

• That is, if it's OK for you to lose no more than an hour of history, then the backup must be hourly.

Principle #5: Decide on a strategy (full or incremental backup)

• Depending on how often a backup is created and its size, the right choice will save you from problems like a race condition, i.e. a situation where you start creating a backup while the previous creation procedure hasn't finished yet.

👾 If your desktop runs Linux, it's convenient to use DejaDup + Gnome backups to create daily incremental backups. For server solutions, things like minio client, s3cmd, rclone are a good fit. And if you need incremental — then restic.