Calculating acceptable losses
For each system we record how long the company can be down and how much data it can afford to lose. Everything else is calculated from that.
Six blocks. The first is the calculation, and the other five are built around the resulting figures rather than the other way round.
For each system we record how long the company can be down and how much data it can afford to lose. Everything else is calculated from that.
A schedule, retention depth, an off-site copy and a monthly restore test on a test environment.
Monitoring of servers, links, disk space and services. The alert reaches us before it reaches a user.
A second link from a different operator with automatic failover. For retail and warehousing this is essential.
A UPS with graceful server shutdown, spares for critical components and extended warranty on the key units.
The document you open on the day of an incident: the steps, the responsible people, the contacts and the system priorities.
The five most common scenarios. Each has its own countermeasure, and one does not substitute for another.
Measure: backups and spare hardware. The most common scenario, and the most predictable in recovery time.
Measure: a copy outside the network. It finds ordinary backups and destroys them along with the original, which is why independent access is needed.
Measure: backup retention depth. A deletion is not noticed immediately, so you need versions from more than just yesterday.
Measure: a second operator. Two links from the same provider usually run along the same route and fail together.
Measure: a UPS with automatic shutdown. An abrupt server shutdown damages the database more than the outage itself.
A backup exists not when the copy is made but when it restores successfully. In our experience roughly one in three configured schemes does not restore: the job has been failing for months, the wrong folder is being copied, or the archive is under a forgotten password. Testing takes a day.
The question is not whether backups exist but when they were last restored and how long it took. Start with a test: we take your copy and restore it on a test environment against the clock. The result either confirms the scheme or shows what to fix, and both are useful.
It depends on the target figures. Recovery within a business day is inexpensive; within an hour costs noticeably more because a standby site is required. That is why the first step is calculating acceptable downtime: it often turns out that a cheap scheme is enough for half the systems.
We do, under the contract and the SLA. The recovery plan is written so your own employee can follow it if our engineer is unavailable for any reason. The document stays with you.
Yes, that is exactly what a test restore is. Once a month we restore a copy on an isolated environment and time it. Once a year it is worth running a drill involving your own staff, which shows where the plan diverges from reality.
We will review your current backup scheme, try restoring a copy and measure the real recovery time for each system.
Request received
We can already see it. We will reply within one business day, and for urgent matters we will bring in the on-duty engineer right away.
City not found. Please check the spelling.