Sync, backup, archive and DR are different
| Concept | What it does | Does not protect against |
|---|---|---|
| Sync / file sharing (OneDrive, Google Drive) | Keeps files identical across devices and shares them | Accidental deletion or encryption that syncs everywhere |
| Backup | Keeps separate, versioned copies you can roll back | Nothing, if tested and kept apart. This is the point |
| Archive | Long-term retention of data you rarely use | Not designed for quick restores |
| Replication / disaster recovery | Keeps a standby copy of systems ready to run | Replicates mistakes and malware unless versions are kept |
Two numbers to agree first
- RPO (recovery point objective): how much data can you afford to lose? One day? One hour?
- RTO (recovery time objective): how long can you be down before it really hurts?
- Set them per system. Your accounting server and a shared drive of old brochures do not need the same protection
The 3-2-1-1-0 rule
- 3 copies of your data
- On 2 different media or storage types
- 1 copy off-site
- 1 copy offline or immutable
- 0 errors after automated verification and test restores
Attackers target backups first. Immutable storage (object lock), separate credentials with MFA, and an offline copy keep one good copy out of reach.
Choosing where to store
| Target | Strengths | Watch for |
|---|---|---|
| Local NAS or disk | Fast restores, no recurring fee | Same site and same ransomware risk unless isolated |
| Cloud object storage (S3-compatible) | Off-site, scalable, supports immutability | Egress and retrieval fees; internet bandwidth for restores |
| SaaS backup for Microsoft 365 / Google Workspace | Protects mail, files and Teams/Drive content | Per-user cost; confirm what is covered |
| Hybrid (local plus cloud copy) | Fast local restore plus off-site resilience | Needs monitoring of both legs |
Microsoft and Google protect their platforms, but you are responsible for your data. Native retention is not the same as an independent backup.
Retention that makes sense
- Daily versions for 14–30 days
- Weekly for 4–8 weeks, monthly for 6–12 months
- Yearly or longer only where law or contracts require it
- Delete on schedule. Keeping everything forever raises cost and risk
Sizing and speed
Capacity depends on data size, daily change rate, compression or deduplication and retention. Restore time is roughly data size divided by sustained restore speed, plus time to prepare the target. Example: 2 TB at 100 MB/s is about 5.8 hours, before any application recovery. Use our backup calculator on the Tools page for a quick estimate, and always measure with a real restore test.
Test restores
- Restore a single file monthly
- Restore a full server or VM quarterly to an isolated network
- Time each restore and compare with your RTO
- Record who did it, what failed and what you changed
- Test the off-site and immutable copy too, not only the local one
Cloud storage and file sharing done well
- Use group-based permissions; avoid sharing from personal accounts
- Turn on version history and a recycle bin
- Control external sharing: expiry dates, view-only by default
- Enable MFA and conditional access for all users
- Label or restrict sensitive folders
- Keep an independent backup of the cloud data
India context
Personal data stored in the cloud falls under the Digital Personal Data Protection Act, 2023 (rules being phased in). Choose storage regions and providers consciously, encrypt data, and keep records of who can access what. Take legal advice for regulated sectors.
Key takeaways
- Sync is not backup
- Agree RPO and RTO per system
- Keep one offline or immutable copy and test restores
- Back up Microsoft 365 and Google Workspace independently
References and further reading
General information for orientation; it is not legal or professional advice. Specifications, products and regulations change, so verify current details before acting. Product names belong to their owners and are mentioned only as examples.