Data Protection
Keep critical data recoverable when anything fails.
Data protection is more than keeping extra copies. Hardware fails, software breaks, people make mistakes, and ransomware can make perfectly replicated data perfectly useless. The protection model has to account for how data can be lost, corrupted, or made unavailable.
Petabox combines replication, versioning, immutability, backups, and tested recovery procedures to protect both the storage layer and the managed services around it — from a single deleted object to a lost data center. The architecture can be tuned to the value of the data, the required RPO and RTO, and the failure scenarios the customer actually needs to survive.
Multi-DC replication & failure isolation
Petabox can distribute data across independent clusters in multiple data centers so that the failure of a server, cluster, or entire data center does not result in the loss of critical data. Each cluster remains a separate failure domain, while replication connects them at the data layer without turning the entire infrastructure into one massive storage cluster.
Different workloads can use different protection models: from asynchronous replication for less critical data to synchronous cross-DC replication with RPO 0 where losing an acknowledged write is not acceptable.
Independent clusters across multiple data centers- Synchronous and asynchronous cross-DC replication
- RPO 0 for critical workloads
- Failure isolation at cluster and data-center level
Versioning & recovery from accidental changes
Not every data loss event starts with an outage. An object can be deleted by mistake, overwritten with the wrong version, or corrupted by an application error. Versioning preserves previous object states so data can be recovered without restoring an entire backup.
For workloads where data changes frequently, this provides a fast way to roll back to the required version and reduce the scope of recovery.
- Previous versions retained on versioned buckets
- Recovery from accidental deletion or overwrite
- Targeted rollback without a full restore
- Lifecycle rules for previous versions
Object Lock & immutable data
Replication and versioning do not protect against every failure scenario. If an attacker, application, or administrator can delete or overwrite every available copy, the data is still vulnerable. Object Lock / WORM adds a separate protection layer by preventing objects from being modified or deleted for a defined retention period.
This is especially important for backups, regulatory records, and other critical data that must survive ransomware, privileged-user mistakes, or intentional deletion. In compliance mode, no one — including Petabox engineers — can delete locked data before its retention period expires.
- Governance and compliance retention modes
- No modification or deletion before the lock period expires
- Immutable backup copies for critical data
- Legal hold for investigations and audits
Protected data services
Managed data services follow the same protection model. PostgreSQL databases, Elasticsearch indexes, ClickHouse data, and other stateful workloads can be backed up to Petabox Object Storage, where backup copies are made immutable and replicated to another data center or an approved external S3, following the classic 3-2-1 model.
Recovery is designed around each service rather than forced into a single model: point-in-time recovery for PostgreSQL, snapshots and backups for Elasticsearch and ClickHouse, and replication and recovery policies for Kafka. Restores are tested, not assumed.
- Classic 3-2-1 backup architecture
- Backup copies protected with immutable Object Storage
- Service-specific recovery: PITR, snapshots, backups, replication
- Regularly tested restores
Retention & lifecycle protection
Different data needs to be kept differently. Some data requires long, immutable retention; some should move quickly to a cheaper storage tier; and some must be deleted automatically once its retention period ends.
Petabox lifecycle policies manage data as it ages: they move objects between storage tiers, offload cold data to an external S3 target approved by the customer, and delete objects only after their retention period expires. Tiered objects stay in the same namespace and remain accessible through the same S3 API.
- Retention rules for different classes of data
- Automatic movement between storage tiers
- Cold objects offloaded to an approved external S3
- Deletion only after the retention period ends
Recovery is part of the architecture
Having a replica, snapshot, or backup does not mean the platform will actually recover after a failure. That is why recovery scenarios are designed and tested together with Object Storage and Managed Data Services, instead of remaining a theoretical incident plan.
For storage, we test the failure of individual clusters and data centers, failover, return to normal operation, and data integrity after recovery. For managed services, each stateful service is tested against its own failure and recovery scenarios.
- Cluster and data-center failure testing
- Tested failover and failback
- Service-specific restore procedures
- Measured RPO and RTO, not just declared ones