Most backup advice assumes steady electricity and a fast, reliable internet link. In many Libyan offices neither can be taken for granted. Power drops without warning, links go down for hours, and the backup job that was supposed to run overnight quietly fails, or worse, is cut off halfway and leaves a corrupted file nobody notices until the day it is needed.
This article describes a backup plan designed for those conditions: how to apply the well-known 3-2-1 rule, how to make backups tolerate interruptions, and how to test that you can really recover.
Why power cuts and weak links break ordinary backups
Backups fail in unglamorous ways, and local conditions make them more likely:
- Sudden power loss during a write. A server or backup disk that loses power mid-job can leave a damaged backup set, or damage the filesystem the backup lives on.
- Jobs that depend on the link. A cloud or remote-site backup that needs a stable connection for six hours will often fail if the link drops twice. Many tools restart from zero instead of resuming.
- Backups on the same power circuit, in the same room. If the backup disk sits beside the server, a fire, a flood, a power surge or a theft takes both.
- Nobody reads the report. A job that has failed for three weeks looks the same as one that works, until someone tries to restore.
None of this is exotic. It is simply what happens when a backup design copied from a different environment meets local reality.
The 3-2-1 rule, adapted
The 3-2-1 rule is a long-standing industry guideline: keep three copies of your data, on two different types of media or storage systems, with one copy kept off-site. It also appears in US-CERT (CISA) backup guidance. For our region we would add a few practical notes to each part:
- Three copies: the live data, a fast local backup for everyday restores, and a second copy elsewhere. The live data counts as one.
- Two media types: for example a backup appliance or NAS plus either tape, removable disks or cloud storage. The point is that one failure mode (a firmware bug, a power surge, ransomware on the network) should not hit both.
- One off-site: a different building, ideally in a different part of the city or in another city. A branch office, a second data center or an approved cloud location can all serve, depending on your data-sovereignty requirements.
Modern guidance often extends this to 3-2-1-1-0: one copy that is offline or immutable (it cannot be changed or deleted, even by an administrator account), and zero errors after verification. That extra copy is what protects you from ransomware that tries to erase backups.
Make the local side tolerate power loss
The cheapest improvement is usually protecting the backup system itself:
- Put the backup server, NAS and switches on an online UPS sized for the real load, with enough runtime for a clean shutdown at minimum. Check that the UPS software actually triggers an orderly shutdown; many installations have the UPS but never connected the signal cable or agent.
- Replace UPS batteries on schedule. A UPS with exhausted batteries gives a false sense of safety. Record the install date on the unit.
- Use a filesystem and storage that survive crashes. Backup targets with journaling or copy-on-write filesystems and battery- or flash-protected write caches recover far better from sudden power loss.
- Do not run the only backup disk in the same cabinet as the server. Separate power feeds where you can, and keep at least one copy physically away from the machine it protects.
- Consider a generator or a clean transfer arrangement for sites where outages last long enough to exhaust UPS runtime, and make sure the backup system is on the protected circuit.
Make the off-site side tolerate link outages
For the off-site copy, design around the assumption that the link will drop:
- Use tools that resume. Choose backup software that resumes interrupted transfers and sends only changed blocks, not entire files, after the first full copy.
- Seed the first copy physically. The first full upload is the hardest. Where the data volume is large, copy it to a disk or storage device and carry it to the off-site location, then let the network handle only the daily changes.
- Schedule for the quiet hours and set bandwidth limits so backups do not starve the business of a link that is already limited.
- Keep a local copy that does not depend on the link at all. Everyday restores, such as a deleted file or a broken database, should work without the internet.
- Alert on missed runs. If last night's off-site copy did not finish, someone should know the next morning.
For organisations with several branches, a hub-and-spoke pattern works well: each branch backs up to a local device, the devices replicate to head office, and head office keeps the off-site or offline copy.
Decide what matters most: RPO and RTO
Two numbers shape the whole design, and they are business decisions, not technical ones:
| Term | Question it answers | Example conversation |
|---|---|---|
| RPO (recovery point objective) | How much recent data can we afford to lose? | "If the system fails at noon, is restoring last night's copy acceptable?" |
| RTO (recovery time objective) | How long can we be without the system? | "Can finance wait a day, or must it be back within hours?" |
Different systems deserve different answers. A core database or patient-records system may need frequent backups and a fast restore path, while an archive of old documents can be backed up weekly. Writing the answers down stops you from paying for the same protection everywhere, or underprotecting the one system the business cannot lose.
Test restores, not just backups
A backup you have never restored is an assumption. Build testing into the routine:
- Monthly: restore a few random files and open them.
- Quarterly: restore a whole server or database to a spare machine or a test environment, and time it against your RTO.
- After any major change: a new server, a new application or a new storage system should be added to the backup scope and tested.
- Keep a written runbook with the order of restoration, the people responsible, and the passwords or recovery keys stored securely outside the systems being restored.
Encrypt backups, especially anything leaving the building, and keep the keys separately. Losing the key is the same as losing the backup.
A checklist you can use this month
- Backup server, NAS and network gear are on a UPS that shuts them down cleanly
- UPS battery install dates are recorded and replacements scheduled
- At least three copies of critical data, on two kinds of storage
- One copy is off-site, and one is offline or immutable
- Off-site transfers resume after link drops and are limited to quiet hours
- Backups are encrypted and the keys are stored separately
- RPO and RTO are written down per system and agreed with management
- Failed or missed jobs raise an alert to a named person
- A test restore has been completed and timed this quarter
- A recovery runbook exists and is stored somewhere that is not the server
Where to start
If you can only do two things this month, put the backup system on a properly working UPS and perform one real restore test. They are inexpensive in effort, and they reveal most of the problems that would otherwise appear during an emergency.
Our engineers design backup and recovery as part of data center and managed IT work for organisations across Libya, with 24/7 monitoring that watches the jobs so that a failed backup is noticed the same day. Planning a backup or recovery project? Tell us what you need — an engineer will reply with a plan.