Backup and recovery strategy
A document stating, for each system, the acceptable downtime and data loss, the steps to take and who is responsible. This is what you open on the day of an incident instead of improvising.
Three services answering three different questions: how to back up, where to store it and what to do when everything breaks.
We decide exactly what to back up: databases, file shares, server configurations, email. We set the schedule, the retention depth and failure alerts so a failed copy does not go unnoticed.
Copies go off site into separate storage with independent access. A fire, a stolen server or ransomware on the local network does not touch that copy.
A document stating, for each system, the acceptable downtime and data loss, the steps to take and who is responsible. This is what you open on the day of an incident instead of improvising.
Before choosing a backup tool you have to answer two questions for each system: how long you can afford to be down and how much data you can afford to lose.
Downtime 4 hours, data loss 1 hour. Frequent transaction log backups are needed, not just a nightly copy.
Downtime 1 day, data loss 1 day. A nightly copy outside working hours is enough.
Downtime 4 hours, data loss 1 hour. A copy of the mail database plus a separate message archive.
Downtime 1 hour, data loss 1 hour. A standby site is required, otherwise the target cannot be met.
Downtime 1 day, data loss 1 day. Achievable only if the data is not stored on the computer itself.
A copy sitting on the same server is not a backup. A disk failure, ransomware or an accidental deletion destroys it along with the original. The minimum workable scheme is two copies on different media and one off site.
Setup takes a few days, but the value appears at the fourth step, which is the one most often skipped.
We find where the important data actually lives. We regularly discover databases on workstations and documents that exist only in email.
For each system we agree the acceptable downtime and data loss with you. The cost of the solution follows from that.
Schedule, retention depth, backup encryption and a second location. Alerts are configured to report both success and failure.
Once a month we restore a copy on a test environment and time it. That is the only proof the scheme works.
The question is not whether backups exist but when they were last restored. 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 protected by a password nobody remembers. Testing takes a day and costs little.
Only if the copies are not reachable from the same network with the same credentials. Modern ransomware deliberately hunts down and destroys backups. That is why you need a copy in separate storage with independent access and protection against modification.
A typical scheme: daily copies for two weeks, weekly for two months, monthly for a year. That depth lets you roll back not only after an incident but also after a mistake noticed a month later. For accounting databases the periods are usually longer.
It depends on the volume and the link. A 50 GB 1C database restores from a local copy in an hour to an hour and a half; from the cloud it takes longer, depending on bandwidth. We measure the real time during a test restore and record it in the strategy so you know the figure in advance.
We will review your current scheme, try restoring a copy and tell you honestly whether it will work on the day of an incident.
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.