Learn about the available types of data protection in Astra Control Center, and how best to use them to protect your apps.
Snapshots, backups, and protection policies
Both snapshots and backups protect the following types of data:
The application itself
Any persistent data volumes associated with the application
Any resource artifacts belonging to the application
A snapshot is a point-in-time copy of an app that's stored on the same provisioned volume as the app. They are usually fast. You can use local snapshots to restore the application to an earlier point in time. Snapshots are useful for fast clones; snapshots include all of the Kubernetes objects for the app, including configuration files. Snapshots are useful for cloning or restoring an app within the same cluster.
A backup is based on a snapshot. It is stored in the external object store, and because of this, can be slower to take compared to local snapshots. You can restore an app backup to the same cluster, or you can migrate an app by restoring its backup to a different cluster. You can also choose a longer retention period for backups. Because they are stored in the external object store, backups generally offer you better protection than snapshots in cases of server failure or data loss.
A protection policy is a way to protect an app by automatically creating snapshots, backups, or both according to a schedule that you define for that app. A protection policy also enables you to choose how many snapshots and backups to retain in the schedule, and set different schedule granularity levels. Automating your backups and snapshots with a protection policy is the best way to ensure each app is protected according to the needs of your organization and service level agreement (SLA) requirements.
|You can't be fully protected until you have a recent backup. This is important because backups are stored in an object store away from the persistent volumes. If a failure or accident wipes out the cluster and its associated persistent storage, then you need a backup to recover. A snapshot would not enable you to recover.|
Astra Control Center supports creating immutable backups with the following platforms and bucket types:
Amazon Web Services using an Amazon S3 bucket with S3 Object Lock configured
NetApp StorageGRID using an S3 bucket with S3 Object Lock configured
Note the following when working with immutable backups:
If you back up to a write once read many (WORM) bucket in an unsupported platform or to an unsupported bucket type, you might get unpredictable results, such as backup deletion failing even if the retention time has elapsed.
Astra Control does not support data lifecycle management policies or manual deletion of objects on the buckets you use with immutable backups. Make sure that your storage backend is not configured to manage the lifecycle of Astra Control snapshots or backed up data.
A clone is an exact duplicate of an app, its configuration, and its persistent data volumes. You can manually create a clone on either the same Kubernetes cluster or on another cluster. Cloning an app can be useful if you need to move applications and storage from one Kubernetes cluster to another.
Replication between storage backends
Using Astra Control, you can build business continuity for your applications with a low-RPO (Recovery Point Objective) and low-RTO (Recovery Time Objective) using asynchronous replication capabilities of NetApp SnapMirror technology. Once configured, this enables your applications to replicate data and application changes from one storage backend to another, on the same cluster or between different clusters.
You can replicate between two ONTAP SVMs on the same ONTAP cluster or on different ONTAP clusters.
Astra Control asynchronously replicates app snapshot copies to a destination cluster. The replication process includes data in the persistent volumes replicated by SnapMirror and the app metadata protected by Astra Control.
App replication is different from app backup and restore in the following ways:
App replication: Astra Control requires the source and destination Kubernetes clusters (which can be the same cluster) to be available and managed with their respective ONTAP storage backends configured to enable NetApp SnapMirror. Astra Control takes the policy-driven application snapshot and replicates it to the destination storage backend. NetApp SnapMirror technology is used to replicate the persistent volume data. To fail over, Astra Control can bring the replicated app online by recreating the app objects on the destination Kubernetes cluster with the replicated volumes on the destination ONTAP cluster. Because the persistent volume data is already present on the destination ONTAP cluster, Astra Control can offer quick recovery times for failover.
App backup and restore: When backing up applications, Astra Control creates a snapshot of the app data and stores it in an object storage bucket. When a restore is needed, the data in the bucket must be copied to a persistent volume on the ONTAP cluster. The backup/restore operation does not require the secondary Kubernetes/ONTAP cluster to be available and managed, but the additional data copy can result in longer restore times.
To learn how to replicate apps, refer to Replicate apps to a remote system using SnapMirror technology.
The following images show the scheduled backup and restore process compared to the replication process.
The backup process copies data to S3 buckets and restores from S3 buckets:
On the other hand, replication is done by replicating to ONTAP and then a failover creates the Kubernetes resources:
Backups, snapshots, and clones with an expired license
If your license expires, you can add a new application or perform application protection operations (such as snapshots, backups, clones, and restore operations) only if the application you are adding or protecting is another Astra Control Center instance.