Beta Version
You're viewing documentation for version v1.1.0. Beta versions are subject to changes and may not represent the final stable release. Do not use in production environments.
Why Should I Back Up My SaaS?
Cloud services like Google Drive, Notion, and Dropbox provide reliable infrastructure and high availability. However that reliability doesn’t mean your data is fully protected. Understanding the distinction between service availability and data protection is critical for any organization or individual relying on cloud storage.
The Shared Responsibility Model
All major cloud providers operate under a shared responsibility model:
- Provider’s Responsibility: Infrastructure security, physical security, network architecture, hardware redundancy, and platform availability
- Your Responsibility: Access controls, user permissions, sharing settings, data retention policies, and protection of stored content
The provider ensures the platform remains operational and secure. You are responsible for how you manage, access, and protect your data within that platform.
Limitations of Provider-Level Protection
Cloud providers do not protect against:
User-Initiated Data Loss
- Accidental file or folder deletions
- Bulk operations that remove more content than intended
- Synchronization errors that propagate deletions across devices
Security Incidents
- Ransomware or malware that encrypts or corrupts synchronized files
- Compromised account credentials leading to unauthorized data access or deletion
- Insider threats from users with legitimate access
Access and Permission Issues
- Unintended public sharing of sensitive files
- Excessive permission grants that expose data beyond intended recipients
- Leaked sharing links that cannot be fully revoked
Service-Level Events
- Platform outages preventing data access during critical periods
- Account suspensions (automated or manual) that lock you out of your data
- Service discontinuation or migration requirements
- Rare provider-side data loss incidents
Compliance and Governance
- Regulatory requirements for independent backup copies and retention
- Legal holds requiring point-in-time data preservation
- Audit requirements demonstrating recovery capabilities
Version History Is Not a Backup
Many cloud providers offer version history or file versioning features. These are useful for basic recovery but have significant limitations:
Time-Limited Retention
- Most services limit version history to 30-90 days
- Older versions are automatically purged regardless of their importance
- No control over long-term retention for compliance needs
Same-Infrastructure Dependency
- Versions are stored on the same infrastructure as your primary data
- Account-level issues affect both current data and version history
- Provider-side failures can impact both data and its versions
Propagation of Malicious Changes
- File sync services replicate changes across all connected devices instantly
- By the time malicious changes are detected, they may have already propagated
- Version history doesn’t prevent the sync of corrupted or encrypted files
Limited Granularity
- Provider tools may not support granular or selective recovery
- Bulk restores can be slow or require manual intervention
- Testing recovery procedures may not be possible without affecting production
The 3-2-1 Backup Strategy
The industry-standard 3-2-1 backup rule provides a framework for resilient data protection:
- 3 copies of your data
- 2 different storage media or types
- 1 copy stored offsite or with a different provider
Applied to cloud storage:
- Production data in your primary cloud service
- First backup copy in independent storage (different provider or local)
- Second backup copy in a geographically or administratively separate location
Independent backups eliminate single points of failure inherent in relying solely on your cloud provider’s infrastructure.
Requirements for Effective Cloud Backups
Independence
Backup infrastructure must be separate from the primary cloud provider to ensure that provider-specific issues (outages, account problems, service failures) do not affect backup availability.
Verification
Backups must be verifiable to ensure data integrity. The ability to validate backups without performing full restores is essential for confidence in recovery capabilities.
Retention Control
You should determine retention policies based on business, compliance, and regulatory requirements—not be constrained by provider-imposed limits.
Point-in-Time Recovery
The ability to restore data from any snapshot within the retention window enables recovery from issues that may go undetected for extended periods.
Encryption and Security
Backup data should be encrypted at rest and in transit. Access controls must prevent unauthorized access to backup copies.
Automation
Manual backup processes are prone to failure or just forgetting to run the backup. Automated, scheduled backups with failure notifications ensure consistency and reliability.
How Plakar Addresses These Requirements
Plakar provides independent backup capabilities for cloud storage services:
- Provider Independence: Backups are stored separately from source providers, eliminating shared infrastructure risks
- Cryptographic Verification: Every snapshot is cryptographically verified for integrity
- Configurable Retention: Define retention policies that meet your specific requirements
- Snapshot-Based Recovery: Restore from any point in time within your retention period
- End-to-End Encryption: All backup data is encrypted by default
- Scheduled Automation: Configure backup schedules and receive notifications on failures
Provider Documentation
Official shared responsibility documentation:
Conclusion
Cloud storage providers deliver reliable infrastructure and high availability, but this does not guarantee data protection. The shared responsibility model places data management and protection responsibilities on you. Implementing proper backup procedures ensures business continuity, regulatory compliance, and protection against the full spectrum of data loss scenarios.
Found a bug or mistake in the documentation? Create an issue on GitHub