A backup nobody has restored is hope, not protection. We keep a local copy and one offsite, encrypted, that cannot be overwritten. Then we restore on trial and show how many hours it takes to get back to work. Backup rollout is part of IT infrastructure.
Ongoing care of the copies sits in managed IT. We run backups in Xopero and Veeam, writing to Synology and offsite.
A conversation about backup usually opens with "which software do you recommend". That is the wrong first question, because the tool follows from two numbers, not the other way round.
A copy once a day at ten in the evening means that a failure at five in the afternoon costs you a full day of data entry. For a trading company that is often acceptable; for an accounting team closing the month it is not. This number sets the interval between copies and it is the one that drives the cost hardest.
This is not the time it takes to copy files, but the time until people are doing their jobs again: restoring the machine, bringing the database up, checking integrations and letting users back in. It usually comes out several times longer than anyone assumes before the first test.
Between the failure and the return the company works somehow, and it is worth settling that on paper: whether the warehouse releases goods manually, whether accounting waits, whether production stops. That conversation takes half an hour and changes the design of the backup more often than any technical argument.
We settle both numbers with the person who owns the process, not with the IT admin, because it is a business decision about how much the company is prepared to lose and to pay. We write them into the design and then check in the restore test whether the declaration holds. If it does not, we say so plainly rather than leaving a number in a document in case nobody ever checks. The meaning of RPO and RTO, without an offer, is in the RPO and RTO entry, and the other backup and network terms are in the IT glossary.
Some companies need the copy built once and a restore they can run. Others want us to watch it every month.
A project: local copy, offsite and the first restore test. It stays with you, with documentation and a note on what to do in a failure.
We watch whether the copy ran, whether it restores, and whether ransomware can overwrite the last good version.
We do not sell software on its own. We sell the certainty that after a server fault or ransomware the data comes back.
Virtual machines, files, databases. The copy has to be complete, not whatever fitted on a disk in the server room.
The second copy sits outside the office. Fire, theft or a flooded server room does not wipe the only set of data.
We restore on trial and time it. The report says how many hours a return takes, not that backup is switched on.
The server is not the only place with data. Shares and selected workstations go into scope when the company lives on them.
Copies are encrypted. The version ransomware would like to overwrite cannot be touched. That is a condition, not an add-on.
An alert about a failed job comes to us, not to a mailbox nobody reads. We fix the job before anyone notices missing files.
A backup answers the question "how do we get back to yesterday", an archive answers "where is the invoice from 2021". Those are two different life cycles for data, and mixing them ends either with a missing document or with a bill for storing everything forever.
Tax books and the records that go with them are kept until the liability expires, which as a rule means five years counted from the end of the year in which the payment deadline fell. Employee records run to ten years for people hired from 2019 onwards and fifty for those hired earlier, unless a report shortening that period was filed with the social insurance institution.
The usual problem with old data is not a missing medium but the absence of anything that will open it: an image of a whole machine running an unsupported system, or an export from a program whose vendor no longer exists. That is why documents meant to sit for years are stored in formats readable without the original application.
When everything sits in one bucket, you either pay to hold daily copies for years or you delete them along with what was meant to stay. A short cycle for the recovery copy and a separate, cheaper place for what is kept out of obligation usually works out cheaper than one shared retention set to the longest requirement.
We are not tax advisers or a law firm and we do not decide for you what has to be kept and for how long. We do the technical part: we show where that data sits today, how much space it takes and what happens to it when the software changes, while you confirm the periods with your accountants. Along the way it usually turns out that some of it has been copied for years with no reason at all, and that is the quickest saving in the whole project, much like tidying up IT costs. The longest periods in the whole economy fall on medical practices, because patient records are kept for twenty years as a rule. Retention periods bite hardest where someone else's books are held, meaning in accounting offices. A case of its own is a project archive in an agency, where the retention period follows from client contracts rather than from any regulation.
This is the most common misunderstanding we meet. Microsoft and Google are responsible for keeping the service running and for not losing your data through their own fault. What your employee does with the data, or someone who takes over their account, is on you.
In Exchange Online deleted messages come back for fourteen days by default, thirty at most if someone raises the setting. The SharePoint and OneDrive recycle bin holds files for ninety-three days. After that there is nothing to restore, and nobody notices a missing invoice from six months ago within a week.
Once a user account is removed, the mailbox can be recovered for thirty days, and the same applies after a licence is taken away. When parting with an employee that is usually enough, but only if somebody thinks of it in time rather than six months later, when they go looking for that person correspondence with a client.
OneDrive and Google Drive faithfully carry over whatever happened on the computer. A deleted file disappears everywhere; one encrypted by ransomware is synced in that state. Version history saves individual files, but not fifteen thousand of them at once.
None of this makes the cloud worse than a server on the premises, since its availability is usually better. It means that a copy of the data in Microsoft 365 or Google Workspace is a separate item to buy, and we usually handle it with the same tool as the rest, most often Xopero. Where that data physically lands and what follows from it when you change provider is covered under cloud solutions.
We pick the tool for what already stands. We do not rip out a working copy for a brand we happen to be teaching.
A frequent choice for servers and workstations when an offsite copy and a restore without guesswork matter.
Virtual environments and servers where Veeam already sits or is meant to stay. We maintain what we deploy.
Local write to an array in the server room. From there the copy goes offsite, instead of stopping on one shelf.
First we check whether the current copy even comes up. Then the design, the rollout and a test whose result stays with you.
We check what is copied, where it goes and when anyone last restored from it. If nobody has, that is the first line of the report.
Local, offsite, retention, what must not be overwritten. The price is agreed before anyone touches production.
We set jobs, encryption and target repositories. We work so production does not wait on the first full backup at peak hours.
We restore selected systems on trial. We record time and gaps. Only then is the rollout finished.
We watch the jobs, repeat the tests and report the result. A copy with nobody watching returns to a state of probably working.
Backup without a server you can restore onto, and without people who will start it, is a half product.
Servers, High Availability and ongoing support. The copy is one layer, not the whole recovery plan.
Xopero, Veeam and Synology. The choice depends on what you already have and how restore looks.
Manufacturing, healthcare and accountancy lose differently when a copy is missing. The backup mechanism stays the same.
No. Sync deletes the file in both places when someone deletes or encrypts it. Backup keeps a separate version that ransomware and a mistake cannot overwrite.
Outside the office, encrypted. The exact place is set in the project. One condition: a flood or a theft in the server room does not wipe the only copy.
Regularly, as part of care, and always at the end of a rollout. The result goes into the report: what comes up and how long it takes. We do not leave that for the day of a failure.
In purpose and in cycle. A backup exists so you can return to the state before a failure, so it keeps few versions and overwrites them quickly. An archive exists so that years later you can find a specific document an authority or a client asks for, so it keeps one version but for a very long time. Neither replaces the other, although they often use the same tool.
Not in the sense most companies mean. Microsoft looks after the availability of the service and makes sure the data is not lost through its own fault, but recovery after a user deletes something rests on a bin with a deadline: fourteen days by default in mail, up to thirty once the setting is changed, ninety-three days in OneDrive and SharePoint. A copy independent of those deadlines has to be bought separately.
It depends mainly on how much data there is and how long it has to sit, not on the number of workstations. That is why we give a price after the review, which shows the real size and what is being copied for no reason. The review itself is free, and if it turns out the current copies are fine and only need testing, we say so plainly.
As a place for a local copy yes, as the whole answer no. A NAS standing in the same rack as the server shares its fire, flood and theft, and if it is attached with the same passwords it shares the ransomware too. We treat it as the first stop, from which the copy travels further, off the premises.
Not by restoring the copy, because restoring onto an infected environment ends in a second encryption. First the affected machines are disconnected, you establish how they got in and check that the copies have not been touched, and only then do you bring data back. We cover the first hours separately, because that is when most of the damage is done.
The first meeting takes 30 minutes and commits you to nothing. We will tell you straight whether we can help and what we would propose.
2019 - 2024 Interactive Workspace Ltd. - All rights reserved.