Algeria AgencyIT & infrastructure
Backups and continuity: what actually gets a business running again
A backup that has never been restored is not a backup. It is an assumption.
Every business we audit has a backup. Almost none has restored it to check that it works, and that is the only thing that counts: a backup is judged by the restore, not by the existence of a file.
This article sets out what to back up, how often, where, and above all how to know it will work on the day you need it. It also describes what breaks a backup without anyone noticing.
A warning about the figures: there is no published Algerian statistic on incidents or data loss. The numbers quoted here are global and come from surveys aggregated by security vendors — that is, by companies that sell the remedy.
We use them for the shape they agree on, never for an amount. Each chart carries that caveat beneath it.
The question is not if, but when and how much
A disk failure, human error, a stolen laptop, water damage and ransomware are not alike, but they produce the same result: data you can no longer reach and work that stops.
So the right way to frame the problem is not "could this happen to us" but two numeric questions. How long can we be down? And how much work can we accept redoing?
Those two answers determine everything else — frequency, medium, budget. A business that can be down two days and re-enter one day of data does not need the same setup as a shop whose till cannot stop for an hour. Most bad setups come from never having asked either question.
Those two questions have technical names you will meet if you ask for a quotation, and it helps to recognise them: acceptable downtime and the amount of work you accept losing. A supplier who does not ask them is sizing at random, or more precisely sizing according to what they are used to selling.
A way to make those two numbers concrete, if stating them in the abstract is hard: ask yourself what you would do on Monday morning if the server did not come back. Who do you call, what do you tell the day’s customers, from what point does it become a problem you can no longer absorb. The answer to that last question is your acceptable downtime.
What the surveys say, and what they are worth
Surveys aggregated by security vendors converge on a few proportions. Ransomware appears in a large majority of incidents affecting small organisations — 88% according to the most quoted compilations, against 39% at large ones.
They also indicate that around 35% of small businesses do not back up regularly, and that 47% have no incident response plan at all.
Take those figures for what they are: self-reported surveys, on self-selected samples, published by companies that sell the remedy. We do not quote them as measurements; we quote them because they agree on an order of magnitude and nothing better exists.
A clarification on the first of these proportions, because it is often quoted the wrong way round: it does not say 88% of small businesses are attacked. It says that among the incidents recorded at such organisations, a large majority involve ransomware. The base is the incident, not the business, and the distinction changes the whole reading.
Security vendor compilations, 2025 — global surveys, self-selected samples
The encouraging figure nobody quotes
The same compilations report that 97% of organisations whose data was encrypted eventually recovered it, and that 53% fully recovered within a week.
That number is rarely put forward, because it sells less well than fear. It is nonetheless the most useful: complete and permanent catastrophe is rare, and what separates businesses is not suffering an incident but how long they take to restart.
And that time depends almost entirely on one thing: the existence of a restore that has already been tested. That is the whole subject of this article.
One thing these surveys do not measure and worth keeping in mind: they cover organisations still in a position to answer a survey. Businesses that close after an incident do not fill in a questionnaire the following year, which probably makes these recovery rates slightly optimistic. The general sense holds; the precision does not.
A consequence of these methodological caveats for your own decision: do not size your setup on these percentages. They serve to establish that the risk exists and is unremarkable, not to choose a backup frequency. That is deduced solely from the two questions asked at the opening, which are about your business and no other.
Security vendor compilations, 2025 — global surveys, self-selected samples
Paying does not restore
The compilations report that 68% of affected businesses recovered their data from backups, while 56% gave in and paid — and that among those who paid, only 60% actually got their data back.
In other words, the backup restores better than the ransom. That is not a moral argument, it is a success rate: paying buys a promise from somebody whose trade is not keeping promises.
The practical conclusion is simple. Budget spent on a tested backup is budget that spares you that conversation, and it is the only one whose return is known in advance.
Add the practical reason payment fails so often: getting data back assumes the attacker kept a working key, sends it, and that the decryption tool works across all the files. Each of those three steps fails regularly, and none of them is under your control once the transfer has left.
One point these figures do not make and that weighs more than all of them: paying closes nothing. The attacker now knows you pay, knows your setup, and nothing stops them coming back. Restoring from an isolated backup shuts the door rather than leaving it ajar.
| Route | Share who took it | Data actually recovered |
|---|---|---|
| Restore from backups | 68% | Depends on backup quality |
| Paying the ransom | 56% | 60% of those who paid |
Security vendor compilations, 2025 — global surveys, self-selected samples
The rule of three copies
Three copies of the data, on two different media, one of them off site. It is the oldest formulation in the field and it still holds because each term answers a distinct failure mode.
Three copies covers file corruption. Two media covers the failure of one kind of hardware — two disks from the same batch bought the same day often fail the same week. One off-site copy covers fire, flood and theft, that is, everything that destroys a whole premises.
The most commonly missed part is the third. An external disk kept in the drawer of the office it backs up is not an off-site copy: it is a second copy in the same room, and it burns with everything else.
A modern variant of the third copy deserves a mention, because it needs no extra hardware: a remote space whose credentials are not the working session’s. It fills the same role as the disk taken home, without depending on somebody remembering to take it every Friday.
What most setups forget to back up
Documents and the business software database are nearly always covered. The rest almost never is, and the rest is what costs the most time to reconstruct.
Email first, when it is hosted elsewhere: many businesses assume the provider backs up, which is true for the provider’s own outages and false for a deletion made by an employee.
Then configuration: server settings, firewall rules, licences, user accounts, folder structure and permissions. Data restores in a few hours; reconstructing a configuration from memory takes days, and it is the item that most lengthens the restarts we have seen.
A fourth common omission: the machine belonging to whoever does the accounts. Many businesses back up the server scrupulously and not the computers, while part of the work lives on a local desktop, in files nobody ever filed on the share. Ask to see what is on those machines before concluding the scope is complete.
The backup that gets encrypted along with everything else
An external disk left permanently connected, or a network folder reachable from the workstations, is seen by ransomware exactly like any other folder. It encrypts the backups along with the data, and that is the scenario that turns an incident into a closure.
The protection comes down to one word: one copy has to be unreachable from the network in normal operation. Physically disconnected, or in a remote space with credentials that are not the working session’s.
That is the difference between a backup and a copy. A copy protects against deletion; only an isolated backup protects against something that has taken control of the network.
A clarification is needed about so-called immutable copies: some systems allow a backup to be written that cannot be modified or deleted for a fixed period, including by an administrator. It is the cleanest answer to this problem where it is available, because it depends on no repeated human action.
A way to check this point with no equipment: disconnect the backup medium and try to reach it from a workstation. If it is still visible in the file browser, it is visible to everything running on that workstation, including what you do not want running on it.
The restore, the only proof that counts
A backup is not verified by a green light. It is verified by restoring, onto a machine that is not the original, and opening the restored files.
The faults this test reveals are always the same and show up nowhere else: a database backed up while it was writing and therefore unusable, a folder added two years ago and never included in the job, an archive protected by a password nobody still has, an unreadable medium.
Do it once a quarter and write down the date. It is the only line in the IT file that proves anything, and it is the one missing everywhere.
Let us be precise about what "restore" means, because the ambiguity is expensive: it is not checking that a file exists in the archive. It is bringing it back onto a machine and opening it in the software that uses it. A database can be present, complete and unreadable, and only the second operation reveals it.
The plan fits on one page
A continuity plan for a small business is not a forty-page document. It is one sheet setting out who calls whom, in what order systems are brought back, where the media and passwords are, and what is said to customers meanwhile.
It has to exist on paper. A plan stored only on the failed server is a plan nobody can read at the moment it is needed.
Recall the figure: 47% of small organisations report having no plan. That page costs an hour and halves downtime, because most of the delay in a restart is not technical — it is the time spent deciding who does what.
Add something that costs nothing and nobody does: the list of people to call, in order, with numbers not stored solely on a work phone synchronised to the failed system. It sounds excessive until the day the failed system is precisely the one holding the directory.
Have it done by somebody who did not install the system, if you can. The person who configured the backup knows where to click and unknowingly routes around the places where the procedure is badly documented; somebody who does not know finds exactly the gaps you are looking for.
A last commonsense point: a backup does not replace security, it is its net. Preventing an incident and being able to get out of one are two distinct expenses, and the second is the only one still working when the first has failed — which is, statistically, the case worth planning for.
The mistakes that recur most
The backup that failed silently eight months ago. Nobody reads the reports while everything is fine, and a scheduled job that stops does not announce it. A two-minute monthly check is enough, provided it is assigned to somebody.
The rotation that is not one: a single medium overwritten every night. If the problem is not found the same day — a corrupted file, a folder deleted by mistake — the last clean version has already been overwritten.
And the single person. A setup only one person understands is a point of failure; the day they are away, what you have is not a backup but their telephone number.
A fourth mistake, subtler, deserves naming: the backup that works perfectly and whose encryption password nobody knows. A protected, unrecoverable archive is exactly as useful as an absent one, and it is the only case where the work was done properly and the result is nil.
One last thing, organisational rather than technical: give this monthly check a name and an owner, and put it where your other recurring tasks live. A task belonging to nobody in particular belongs to whoever has the most time, which is to say nobody, and that is how a backup stops for eight months.
Where to start, with no budget
Today: open your backup report and look at the date of the last successful run. It is free, it takes two minutes, and it surprises people more often than you would think.
This week: restore a file at random, onto another machine, and open it. Then write the plan page — who calls whom, in what order, where the passwords are.
This month: make sure one copy is off site and unreachable from the network. Then finally answer the two questions from the start — how much downtime, how much rework — and you will know whether your current setup matches what you actually decided.
One last thing, while you are at it: write today’s date next to each check. That log, even kept by hand on a sheet of paper, is what turns the backup from an intention into a verifiable fact — and it is the first document we ask to see when an infrastructure is handed to us.
What we do, and what we verify in front of you
We start with the two questions from the opening, and we ask them of you rather than of your hardware: how long can you be down, and how much work do you accept redoing. Those two answers decide everything else, and a quotation drawn up without them is one drawn up from what the supplier is used to selling.
We then establish the real scope, which is almost always wider than the one in place: the business software database, email if it is hosted elsewhere, the machines where work lives that nobody filed on the share, and the configuration — firewall, accounts, permissions, licences — which is the item that most lengthens a restart.
We put the three copies in place, one of them unreachable from the network in normal operation, and we document where they are and with which credentials. Then we run the restore in front of you, onto a machine that is not the original, and open the restored files. Without that last step you would have bought an assumption.
Finally we write the plan page — who calls whom, in what order, where the media and passwords are — and hand it to you printed. It is not an impressive deliverable, and it is the one that halves downtime on the day the rest is needed.
Frequently asked questions
Does the cloud back up automatically?
It replicates, which is not the same thing: a deleted or encrypted file is replicated deleted or encrypted. Check your provider’s version retention period — that is what decides what you can recover.
How often should we back up?
According to how much work you accept redoing. A daily backup means losing at most one day of data entry; if that is unacceptable, you need to back up more often.
Should we pay a ransom?
Survey compilations indicate that among those who pay, about 60% actually recover their data. Restoring from a tested backup has a better success rate and a cost known in advance.
Is an external disk enough?
As a second copy, yes. Not as the only copy, and not if it stays plugged in: a permanently connected medium is encrypted along with everything else.
Are there Algerian figures on this?
None published that we know of. The figures in this article are global and come from vendor-aggregated surveys, which is flagged under each chart.
What should we back up first on a limited budget?
The business software database and the configuration. Documents can often be found elsewhere; a configuration rebuilt from memory is what most lengthens a restart.
Where we come in
The date of the last successful backup reassures. Restoring a document onto a different machine reassures nobody, and the second act is the one that teaches you something.
- We ask you how many hours and how many days you can afford to lose.
- We look for what is backed up nowhere, starting with your management software.
- We put one copy beyond the reach of a compromised machine.
If your company can genuinely close for three days with no consequence, say so: we will not install something you have no reason to pay for.
Read next
The restore test: the one day you know the backup exists
A backup never restored is a hypothesis. The test is scheduled, timed and recorded — twice a year, onto a machine that is not the original.Cloud hosting: what costs is not the storage
The line everybody compares is the cheapest on the invoice. The other three get paid on the day you need them most.The account, not the server: what you actually lose in the cloud
Everything you keep there passes through one login, one mailbox and one card. What breaks that chain, and in what order.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.