Yes, it is a pretentious title. 🙂 If you’ve been working with computers, you probably already know this – better than you would have liked. However, in my experience with computers and their users (well over 3 decades now), there is no more important aspect that gets more neglected than backups. So it definitely is worth repeating and writing about it. I’ll try to be brief and go straight to the point:
I originally wrote and published this article on HostingForums. This version servers primarily as my own backup copy. 🙂
A separate article explains the differences between the full, differential, and incremental backups.
1. Do I really need backups?
What would you do if your computer(s), smartphone(s), or website-hosting servers just died today? Do you have a backup plan (pun intended) for at least only one of those getting “dead” right at this moment?
If you do, you are among the 1% of cautious computer users (in my opinion & experience). Most people rely on: “it can’t happen!” Yes, it will. It does. Every day.
You must have experienced it sometimes in the past – think hard. Was there at least one occasion that a document you were working on gets corrupt, poorly saved, or gone for some other reason? Have you lost some stored data due to a drive malfunction or a virus at least once in your life?
Computer users can be divided into two groups:
- Those who have lost their data.
- Those who will lose their data.
Backups won’t make you 100% safe, but having them will make you about a million times safer than relying on luck and wishful thinking.
2. How often should I make backups?
The answer is simple:
How many hours of work are you willing to lose?
For example, I’ve just made a backup copy of this article’s draft right after having finished the first part (before the above-displayed heading 2). I hate doing the same work twice.
Sure, I have a UPS (Wiki link) and reliable computer equipment, but things can break down at any time for whatever reason.
3. How many backup copies should I have?
I’m glad you asked! 🙂
Sorry for this slight touch of sarcasm, but I’m using it for educational purposes and to stress the importance of having multiple backup copies.
Very few people make any backups, so having one backup copy is a million times better than having no backups. However, for backups, it is safe to say: “one is none!”
Yes, stuff gets broken down, corrupt, etc. Make sure to have at least two separate backups, in two separate locations, for anything that is important to you. Theft, fire, malfunction – it happens more often than we’d like to think.
Think of it this way: any single storage device will fail. It’s not a question of if, but when. Drives have a finite lifespan measured in years (and often fail without any prior warning). Human error, malware, or a spilled coffee can strike at any time. If your data exists in only one place, you are guaranteed to lose it eventually. Having two independent backups means both would have to fail simultaneously for you to lose everything – a drastically lower risk. Adding a third, off-site (i.e. remote) copy (the 3-2-1 rule) protects you against localized disasters, making catastrophic data loss so unlikely it’s not worth worrying about.
The famous 3-2-1 rule
To spell it out, this is called “3-2-1” backup system:
- 3 coppies,
- on at least 2 different types of media,
- with at least 1 remote (“off-site”) copy.
4. For how long should I keep my backups?
It’s a good idea to have at least one monthly backup copy for each of the last three months. In my experience, viruses and hacks don’t always get caught right away, so having a “pre-hacked-time” backup copy can be a lifesaver! I’ve seen this used more often than I’d like to admit. It’s not ideal, but it’s still a whole lot better than doing everything from scratch.
Going as far back as one year is not an overkill, in my opinion and experience. Especially if you structure your older backups to save some space. For example:
- Keep 3 daily backups for the last three days.
- 3 weekly backups for the last three weeks.
- 3 monthly backups for the last three months.
- 3 quarterly backups for the quarters before the monthly backups.
This sums to a total of 12 backup copies, covering an entire year. It adds up, it’s not ideal, but you’ll admit it is a lot less than 365 backup copies, while still having frequent-enough “snapshots” of your previous work.
This is important for the backups of data you change or update, or to which you add more data to. Of course, you needn’t save daily and quarterly backups of your 8th birthday pictures or similar.
You should still have a local backup, and a remote backup (so at least two, preferably three backup copies), as explained in section “3. How many backup copies should I have?“
5. Where should I store those backups?
I wrote in great detail about cloud and backup storage options (BikeGremlin site link). Use whatever is convenient and fits your budget, but make sure to really make backup copies in at least two separate locations.
My favourites are Hetzner Storage Box, and Backblaze B2 (BikeGremlin site links). With a local copy on my external storage drive.
Up-to-date: My (backups) Storage stack
The costs do add up, but I compare them against the costs of losing all my work.
In a separate article I wrote about hard disks, they are convenient for storing large amounts of data.
6. Test your backups
Often neglected, yet very important!
If you don’t make at least one test run of restoring your data from your backups, you should not rely on those backups (not until they are tested and confirmed to be working).
Yes, it’s a hassle and a choir. I mean, based on my experience, this whole article is among the most useless articles I’ve ever written. 🙂
No one cares about this stuff until a problem occurs. And then, guys like me get a call to try and save the day (and we often fail miserably, ’cause we ain’t magicians!).
7. Automation
Automate your backup creation. It’s the safest way to ensure that backups are being created. There are a ton of things you need to worry about on a daily basis, so it’s normal to forget.
However, and this is probably the most controversial part of this whole article: don’t overdo it! Have at least one backup copy be manually created. Why?
If something goes hacked or corrupt, having super-fast auto-replicating backup copies will, in fact, ensure that all your backups get corrupt. For example, I make local copies 100% manually. I.e. the cloud-based host has no access to push the backups to my external local storage – I need to make a pull request manually. Colour me paranoid, conservative or experienced (the fact is I’m just old, LOL 🙂 ).
8. Backup myths and misconceptions
Below, I tackle the few most prevalent backup related myths. To sum it all up in one sentence:
A proper backup is one-way, versioned, and immutable (or at least not automatically altered by clients) – everything else is just convenience, not a backup.
Myth 1: SaaS doesn’t need any worries about the backups
Yes, most SaaS (wiki link – Software As A Service) providers will assure you your data is safe “on their cloud.” Well, no!
For one: “the cloud” doesn’t really exist – it’s just someone else’s computer (in a server room – which is a nice name for an air-conditioned basement… joking a bit, but not too much).
Secondly: always have your own backup copy, which you have tested the restoration procedure from. Many (most?) SaaS companies don’t let you make your own backups, much less copy them. So, if they mess it up, your data is done for. Keep that in mind for the really important stuff.
Myth 2: RAID is a backup
RAID (Wiki link) is a nice way to ensure your stuff stays online in case of a drive failure, but it is not a replacement for having backups.
For example:
When a drive in a (hot-swappable) FTP server fails, I can pull it out, insert a new drive, let the RAID rebuild itself – while other colleagues can keep using FTP for all that time as if nothing happened.
However, restoration from a RAID drive sometimes fails, and you can still lose all your data. So, I repeat: RAID is a tool for improving service availability (and/or performance), but it is not a backup. Don’t rely on it for that.
For our example:
I still need to make a separate backup copy of the FTP server.
Myth 3: One cloud copy is enough
As I have mentioned above, “the cloud” is just a fancy name for someone else’s computer. That’s what it boils down to. It’s not a 100% reliable, safe and secure magic wand.
It’s great in practice, but make sure to not only have one backup copy, even if it’s “in the cloud.”
Myth 4: Cloud sync is a backup
This is now a very common way of thinking. You use a cloud storage service and configure your computer (or several computers) to sync say a backup directory.
To make matters worse, most of these services work as a two-way-sync: so if you delete a file on one computer, that gets synced to the cloud and deleted off any other synced computer when it gets online and syncs.
In addition to accidental deletion, this method is very vulnerable to ransomware attacks (your ransomware-encrypted files will get sync-copied to the cloud, replacing the “old” unencrypted files).
Yes, some cloud services offer file versioning and similar, but still don’t rely on this for backups. Sync, like raid, is for convenience, but not a real backup. Make a proper one-way upload copy for your cloud backups.
9. Filenames – what no one tells you
This is very important, so much that I thought it went without saying – and boy, was I wrong. Let’s talk about filenames. Decades in DOS, Windows, UNIX, Linux, cloud storage… the same rule keeps repeating. Follow this advice to make your backups robust and reliable – because filesystems and storage drives are never perfect!
In filenames or directory names never ever use:
- Special characters like š, đ, and similar (in my native), or Cyrillic ж, џ etc, or umlauts like ä, ö, and ü – or other exotic stuff, and accented letters (
café.jpg). - Emojis.
- Blank spaces.
- MiXeD Cases.
Different systems and tools handle encoding differently, and sooner or later something will choke: a sync client, a cloud provider, a script, or even your own backup restore.
In theory, “modern systems” support all characters. In practice, I still see failures caused by filenames such as “konačno - my holiday🚀.jpg“. Some tools normalize the name, others reject it, others silently rename or skip it.
Also remember: Windows is case-insensitive; Linux is case-sensitive.
Mixing uppercase and lowercase can result in overwrites or duplicate files vanishing when moved between systems.
Safe, portable, future-proof filenames follow a simple pattern:
- a–z
- 0–9
- hyphens (
-) - underscores (
_)
Everything else is optional trouble. If you stick to these rules, your backups and restores will always behave predictably.
Good example
Here’s a good, boring, 100% safe example:
directory-a/subdirectory-b/filename_b_2025-12-03.doc
Bad example (what to avoid)
Here’s a bad example:
Directory A/Subdirectory B/FileName B 2025.12.03.doc
Fun facts
Windows (and DOS before it) popularised user-friendly naming, normalised using spaces in filenames, and pushed GUI metaphors like “folders” instead of “directories.”
This encouraged “anything goes” filenames compared to UNIX’s stricter, shell-oriented culture – and spread it to hundreds of millions of non-technical users, which cemented this behaviour as “normal.”
Now, companies would rather see you lose your data than enforce some “money-losing,” “anti-marketing” limits (admit that you do not enjoy the idea of using a strict file and directory naming scheme – no one does, whenever I talk about this 🙂 ).
For reasons beyond common sense (where marketing plays a big part), even great tools like Obsidian refuse to sanitize filenames according to these rules – and I can’t count the number of times I’ve seen these things cause problems…
Relja Novović,
In Novi Sad,
– the first version was written in 2022
Last updated:
Originally published:
