Someone in accounts opens an attachment at eight in the morning, and within twenty minutes every file in the shared folder is encrypted. The sync app on the team’s machines does its job faithfully: it uploads the encrypted copies to the cloud and replaces the healthy files on every device with them. That incident sums up the most common mistake in business storage: confusing a place where you keep and share files with a backup you go back to when everything breaks. In this article we build business cloud storage layer by layer: encryption and who holds its keys, permissions and sharing, versions and ransomware recovery, the 3-2-1 rule and data residency, and what has to happen on the day an employee leaves.
01Sync is not backup
Sync services, such as OneDrive or a shared folder synced to the team’s machines, make sure you see the same copy on every device. That is exactly their problem when something goes wrong: delete a file and it disappears from every device; let ransomware encrypt it and the encrypted copy syncs everywhere. A backup is a separate, dated copy that new changes don’t touch, and you go back to it to get to before the mistake.
| Question | Sync and sharing | Backup |
|---|---|---|
| Purpose | One current copy on every device | Earlier states you can return to |
| When you delete a file | The deletion syncs everywhere | The file stays in earlier backups |
| When ransomware hits | The encrypted files sync | You restore what came before the infection |
| Retention | Usually a recycle bin for days or weeks | A retention policy you set |
| Who controls it | Each user, over their own files | The administrator, with separate permissions |
That’s why Illevante’s Nexus Cloud is designed as backup, not sync: it automatically backs up Microsoft 365 mail, OneDrive and SharePoint, SaaS applications, the team’s devices, and the company’s servers with their databases and shared files, to an encrypted vault kept apart from them. The service is listed as “coming soon” on Illevante’s site, with a 14-day free trial.
02Encryption: where, and whose key?
The word “encrypted” on its own isn’t enough. Ask three questions:
- In transit: Does every connection go over TLS 1.2 at least, and preferably TLS 1.3? That protects the data from interception between your machine and the data centre.
- At rest: Are files encrypted on disk with an algorithm such as ? That protects them if a disk is stolen or reused.
- Who holds the key: This is the real difference. If the provider keeps the keys, it’s technically able to read your data, or hand it over if asked. In a design the keys are derived from something only you hold, so the provider reads nothing. The price: if you lose both the key and the recovery codes, nobody can bring your data back.
Nexus Cloud states AES-256 encryption for data at rest and in transit, a vault built on the Zero-Knowledge principle that no one but you can read, and sign-in where a password alone isn’t enough, thanks to multi-factor authentication. So agree inside your company who keeps the recovery keys and where, before you need them, not after.
03Permissions and sharing
Most file leaks don’t come from a breach; they come from a sharing link left open, or the account of an employee who left and was never closed. The rules that reduce them:
- Permissions by role, not by person: accounts sees its folders, sales sees its folders, and only the administrator restores and deletes backups.
- External sharing links with an expiry date and a password, and read-only unless there’s a clear reason to edit.
- Multi-factor authentication on every account, administrator accounts first.
- An activity log of who opened what and when, which you review after an incident and an auditor will ask for.
Nexus Cloud provides unified, central user management, role-based access permissions and detailed activity logs.
04Versions and ransomware recovery
keeps each file’s state at successive points in time, so you can return a whole folder to how it was minutes before an incident. Three numbers decide how much it’s worth:
- Frequency: How often a restore point is taken. A point every hour means you lose an hour’s work at worst.
- Retention: How many days the points are kept. Ransomware can lie dormant for weeks before it encrypts, so keep daily points for at least thirty days, and weekly or monthly points for longer.
- Protection from deletion: An attacker who reaches the administrator account deletes the backups first. An can’t be deleted by anyone before its retention period ends, not even the administrator.
Nexus Cloud takes restore points every hour, brings back what was deleted from a folder without losing what was added after the deletion, and sends you a report on the backups every morning. As for retention length and immutable copies, set them in your policy and ask about them with any service you choose.
And if an infection does happen, this is the order:
- 01Disconnect the infected machines from the network, and pause sync so the encrypted files spread no further.
- 02Change the passwords of the affected accounts, administrators first, and make sure multi-factor authentication is on.
- 03Pin down the moment of infection from the activity log, and choose a restore point before it.
- 04Restore to a clean location first, and check a sample of files before you hand them back to the team.
05The 3-2-1 rule and data residency
The 3-2-1 rule is the simplest design that survives most incidents: three copies of your data, on two different storage media, at least one of them off-site. An example for a law firm in Latakia:
| Copy | Where | Protects against |
|---|---|---|
| The original | The shared folder and the office server | Nothing on its own |
| Second copy | A local backup disk you can restore from quickly | A device failure or an accidental deletion |
| Third copy | A cloud backup service in another data centre | A fire, a theft, or ransomware that hit the whole office |
Many now add two digits, making it 3-2-1-1-0: one copy that is immutable or offline, and zero errors in the last restore test. That zero isn’t assumed; it’s measured, as in this test on a Linux file server:
# Before any incident: record a SHA-256 fingerprint for every file in the contracts foldercd /srv/share && find contracts -type f -print0 | xargs -0 sha256sum > /root/contracts.sha256# After restoring the folder to /srv/restore/contracts: check every file against its fingerprintcd /srv/restore && sha256sum --quiet -c /root/contracts.sha256 && echo "0 errors"
is the second question. The country where your backups are stored applies its laws to them: if some of your customers live in the EU, the General Data Protection Regulation (GDPR) restricts transferring their personal data outside it, and some sectors, such as banking and health, have regulators that require a specific country. Ask the provider which data centre will hold your backups, and get the answer in writing.
06When an employee leaves
An account left open after its owner leaves is more dangerous than a weak password. Make offboarding a written procedure the administrator carries out on the day of departure:
- 01Disable the account rather than deleting it straight away, since in some services deleting it deletes their files and backups too.
- 02Transfer ownership of their files and folders to their manager.
- 03Revoke the sharing links they created, and remove their devices from the service.
- 04Change any shared passwords they knew, and the recovery keys if they held any.
- 05Keep a copy of their mail and files according to your retention policy, then delete the account when the period ends.
07Before you decide
Write a one-page policy before you pick any service: what gets backed up, how often, how long it’s kept, where, and who restores. Then choose the service that carries it out, not the other way round. Start with what you can’t recreate: contracts, accounts, databases and email.
And if your company runs on Microsoft 365, remember that Microsoft keeps the service available, while protecting your data from deletion and ransomware is your responsibility, under the shared responsibility model it publishes. That gap is exactly what Nexus Cloud is designed to cover, so when it launches, try it during the trial on a real folder: delete a file on purpose and restore it, before you rely on it.
