Nadeeja NirmalaIT Manager

Disaster recovery built around a four-hour target

At FIBC Lanka, backups already ran, but nobody could say how long it would take to get the business working again. So we set the targets first, built a 3-2-1 design to meet them, and test it on a schedule.

By Nadeeja NirmalaIT Manager, FIBC LankaUpdated 10 October 2026
  1. Live

    The ERP and production data the business runs on. The targets: back in service within four hours, losing at most 24 hours of data.

  2. Copies

    Three copies in three places: local RAID for the fastest restore, a cloud copy on a separate medium, and an encrypted off-site copy away from the primary site.

  3. Restore

    When the primary fails, data comes back from the nearest good copy. Restores are tested on a schedule, because that is the only way to know the four-hour target holds.

Fig. 1  The 3-2-1 design, and a restore. Scroll to follow the data.

What the plan has to protect

A backup only matters if it gets people working again. The real questions are how fast, and how much work you can afford to lose.

The plan covers the Tally Prime ERP data, the production files, and the configuration needed to rebuild the servers. We set two targets: back in service in under four hours, and no more than 24 hours of data lost. With those agreed, how often to back up, where to keep the copies and what to restore first stopped being guesses.

Recovery time objectiveUnder 4 hours
Recovery point objective24 hours
Storage model3-2-1

How the 3-2-1 design works

Three copies of the important data, on two kinds of storage, with one copy kept away from the site. Each copy does a different job.

  1. Local RAID copy: on a Synology NAS in the building, the quickest restore for everyday problems, such as a failed disk or a deleted folder.
  2. Cloud copy: a second copy on a different kind of storage, outside the building’s own systems.
  3. Encrypted off-site copy: kept away from the site for the bad days, such as a fire, a flood or a theft.

Three copies on the same hardware, or in the same building, can all be lost in the same incident. What matters is how separate the copies are, not just how many there are.

Why restores get tested

A green backup job tells you data was written somewhere. It doesn’t tell you the data will come back into a system people can use.

So restores are tested on a schedule. Each test checks that the data is intact, that it can be reached, that things come back in the right order, and that the written procedure still matches the systems we run today. I also make sure the passwords, configuration and other pieces a restore depends on are available when the main system isn’t.

What I carry into recovery work

  • Start with the services the business has to get back, then work out their data.
  • Agree the RTO and RPO before choosing tools or schedules.
  • Keep copies on different media and in different places.
  • Keep credentials and configuration safe and recoverable, along with the data.
  • Test restores, and write down what each test teaches you.
ScopeERP data, production files, configuration, and what recovery depends on
Each restore test checksIntegrity, access, restore order, and a service people can use

Further reading

NIST’s contingency planning guide is the general reference. The targets and the design above are specific to this factory.

Work with me

I work across backups, servers and networks, and the small operational details that decide whether a restore works.

Get in touch
Nadeeja NirmalaIT Manager at FIBC Lanka, CCNP and CCNA certified. View experience and credentials.