# About backup and restore with snapshots This topic provides an introduction to the Replicated KOTS snapshots feature for backup and restore. It describes how vendors enable snapshots, the types of data that snapshots back up, and how to troubleshoot issues for enterprise users. :::note The KOTS Snapshots feature is supported for existing cluster installations with KOTS and Replicated kURL installations only. Snapshots is not supported for Replicated Embedded Cluster installations. For more information about configuring backup and restore for Embedded Cluster, see [Disaster Recovery for Embedded Cluster](/embedded-cluster/v2/embedded-disaster-recovery). ::: :::note Replicated KOTS is available only for existing customers. For supporting installations into customer managed clusters, we recommend Helm. For more information, see [About Helm Installations with Replicated](/vendor/helm-install-overview). KOTS is a Generally Available (GA) product for existing customers. For more information about the Replicated product lifecycle phases, see [Support Lifecycle Policy](/vendor/policies-support-lifecycle). ::: ## Overview An important part of the lifecycle of an application is backup and restore. You can enable Replicated KOTS snapshots to support backup and restore for existing cluster installations with KOTS and Replicated kURL installations. When you enable snapshots for your application, your customers can manage and perform backup and restore from the Admin Console or KOTS CLI. Snapshots uses the Velero open source project as the backend to back up Kubernetes manifests and persistent volumes. Velero is a mature, fully-featured application. For more information, see the [Velero documentation](https://velero.io/docs/). In addition to the default functionality that Velero provides, KOTS exposes hooks that let you inject scripts. These scripts can execute both before and after a backup, and before and after a restore. For more information, see [Configure Backup and Restore Hooks for Snapshots](/vendor/snapshots-hooks). ### Limitations and considerations * - The snapshots feature is available only for licenses with the **Allow Snapshots** option enabled. For more information, see [Create and Manage Customers](/vendor/releases-creating-customer). - Snapshots are useful for rollback and disaster recovery scenarios. Do not use them for application migration. - - - - - Removing data from the snapshot storage itself results in data corruption and the loss of snapshots. Instead, use the **Snapshots** tab in the Admin Console to cleanup and remove snapshots. - Snapshots does not support Amazon Simple Storage Service (Amazon S3) buckets that have a bucket policy requiring the server-side encryption header. If you want to require server-side encryption for objects, you can enable default encryption on the bucket instead. For more information about Amazon S3, see the [Amazon S3](https://docs.aws.amazon.com/s3/?icmpid=docs_homepage_featuredsvcs) documentation. ### Velero version compatibility The following table lists the versions of Velero that are compatible with each version of KOTS, and the Kubernetes versions that each Velero version supports. For the full Velero Compatibility Matrix, see [Velero Compatibility Matrix](https://github.com/vmware-tanzu/velero#velero-compatibility-matrix) in the vmware-tanzu/velero repository. :::note KOTS supports Velero 1.11.0 through 1.18.x. For Velero 1.16 and earlier, KOTS uses Restic to back up pod volume data. For Velero 1.17 and later, KOTS uses Kopia. Existing Restic backups are restorable on Velero 1.17 and 1.18. Velero 1.19 is not supported. ::: | KOTS version | Velero version | Supported Kubernetes versions | |------|-------------|-------------| | TBD and later | 1.11.0 to 1.18.x | 1.33.7, 1.34.1, and 1.35.0 | | 1.125.2 and later | 1.11.0 to 1.16.2 | 1.31.4, 1.32.3, and 1.33.0 | | 1.125.0 and later | 1.11.0 to 1.16.1 | 1.31.4, 1.32.3, and 1.33.0 | | 1.124.18 and later | 1.11.0 to 1.16.0 | 1.31.4, 1.32.3, and 1.33.0 | | 1.124.0 and later | 1.11.0 to 1.15.2 | 1.28.8, 1.29.8, 1.30.4, and 1.31.1 | | 1.123.1 and later | 1.11.0 to 1.15.1 | 1.28.8, 1.29.8, 1.30.4, and 1.31.1 | | 1.117.3 and later | 1.11.0 to 1.14.1 | 1.27.9, 1.28.9, and 1.29.4 | ## About backups This section describes the backup types that the snapshots feature supports. For information about how to configure backup storage destinations for snapshots, see the [Configuring Backup Storage](/enterprise/snapshots-velero-cli-installing) section. ### Application and Admin Console (full) backups Full backups (also referred to as _instance_ backups) include the KOTS Admin Console and all application data, including application volumes and manifest files. For clusters created with Replicated kURL, full backups also back up the Docker registry. Air-gapped installations require this registry. If you manage multiple applications with the Admin Console, a full backup includes data from all applications that support backups. Each application must include a manifest file with `kind: Backup` and `apiVersion: velero.io/v1`. KOTS includes the application in full backups only when this manifest file is present. You can check for this manifest file in the Admin Console. Replicated recommends full backups because they support all types of restores. For example, you can restore both the Admin Console and application from a full backup to a new cluster in disaster recovery scenarios. Or, you can use a full backup to restore only application data for the purpose of rolling back after deploying a new version of an application. ### Application-only (partial) backups Partial backups back up the application volumes and manifest files only. Partial backups do not back up the KOTS Admin Console. Partial backups can be useful if you need to roll back after deploying a new application version. You cannot restore partial backups of the application only to a new cluster, so they are not usable for disaster recovery scenarios. ### Backup storage destinations For disaster recovery, configure backups to use a storage destination that exists outside of the cluster. This is especially true for installations in clusters created with Replicated kURL, because the default storage location on these clusters is internal. You can use a storage provider that is compatible with Velero as the storage destination for backups created with the Replicated snapshots feature. For a list of the compatible storage providers, see [Providers](https://velero.io/docs/v1.17/supported-providers/) in the Velero documentation. You initially configure backups on a supported storage provider backend using the KOTS CLI. To change the storage destination after the initial configuration, use the **Snapshots** page in the Admin Console. The Admin Console supports the following storage destinations: - Amazon Web Services (AWS) - Google Cloud Provider (GCP) - Microsoft Azure - S3-Compatible - Network File System (NFS) - Host Path kURL installers that include the Velero add-on also include a locally-provisioned object store. By default, kURL clusters are preconfigured in the Admin Console to store backups in the locally-provisioned object store. This object store is sufficient for only rollbacks and downgrades and is not a suitable configuration for disaster recovery. Replicated recommends that you configure a snapshots storage destination that is external to the cluster in the Admin Console for kURL clusters. For information about how to configure backup storage destinations for snapshots, see the [Configuring Backup Storage](/enterprise/snapshots-velero-cli-installing) section. ### What data do backups include? Full backups include the Admin Console and all application data, including KOTS-specific object-stored data. For Replicated kURL installations, full backups also back up the Docker registry. Air-gapped installations require this registry. #### Other object-stored data For kURL clusters, you might be using object-stored data that is not specific to the kURL KOTS add-on. For object-stored data that is not KOTS-specific and does not use persistentVolumeClaims (PVCs), you must write custom backup and restore hooks. For example, Rook, Ceph, and similar storage providers do not use PVCs and require custom backup and restore hooks. For more information about writing custom hooks, see [Configure Backup and Restore Hooks for Snapshots](snapshots-hooks). #### Pod volume data KOTS uses Velero's file-system backup uploader to back up pod volume data. For Velero 1.16 and earlier, the uploader is Restic. For Velero 1.17 and later, the uploader is Kopia. By default, Velero requires that you opt-in to have pod volumes backed up. In the Backup resource that you configure to enable snapshots, you must annotate each specific volume that you want to back up. For more information about including and excluding pod volumes, see [Configure Snapshots](/vendor/snapshots-configuring-backups). ## About restores {#restores} Snapshots supports the following types of restores: * Restore both the application and the KOTS Admin Console (also referred to as a _full_ restore) * Restore the KOTS Admin Console only * Restore the application only (also referred to as a _partial_ restore) When you restore an application with snapshots, KOTS first deletes the selected application. KOTS removes all existing application manifests from the cluster and deletes all `PersistentVolumeClaims`. This action is not reversible. Then, the restore process redeploys all of the application manifests. The restore process gives all Pods an extra `initContainer` and an extra directory named `.velero`. KOTS uses these for restore hooks. For more information about the restore process, see [Restore Reference](https://velero.io/docs/v1.18/restore-reference/) in the Velero documentation. When you restore the Admin Console only, the restore process makes no changes to the application. For information about how to restore using the Admin Console or the KOTS CLI, see [Restore from Backups](/enterprise/snapshots-restoring-full). ## Using snapshots This section provides an overview of how vendors and enterprise users can configure and use the snapshots feature. ### How to enable snapshots for your application To enable the snapshots backup and restore feature for your users, you must: - Have the snapshots entitlement enabled in your Replicated vendor account. For account entitlements, contact the Replicated Technical Account Manager (TAM) team. - Define a manifest for creating backups. See [Configure Snapshots](snapshots-configuring-backups). - When needed, configure backup and restore hooks. See [Configure Backup and Restore Hooks for Snapshots](snapshots-hooks). - Enable the **Allow Snapshot** option in customer licenses. See [Create and Manage Customers](releases-creating-customer). ### Understanding backup and restore for users {#how-users} After vendors enable backup and restore, enterprise users install Velero and configure a storage destination in the Admin Console. Then users can create backups manually or schedule automatic backups. Replicated recommends advising your users to make full backups for disaster recovery purposes. Additionally, full backups give users the flexibility to do a full restore, a partial restore (application only), or restore just the Admin Console. From a full backup, users restore using the KOTS CLI or the Admin Console as indicated in the following table:
Restore Type Description Interface to Use
Full restore Restores the Admin Console and the application. KOTS CLI
Partial restore Restores the application only. KOTS CLI or Admin Console
Admin console Restores the Admin Console only. KOTS CLI
Partial backups are not recommended as they are a legacy feature and only back up the application volumes and manifests. Users can restore partial backups only from the Admin Console. ### Troubleshooting snapshots To support end users with backup and restore, use the following resources: - To help troubleshoot error messages, see [Troubleshoot Snapshots](/enterprise/snapshots-troubleshooting-backup-restore). - Review the Limitations and Considerations section to make sure an end users system is compliant. - Check that the installed Velero version and KOTS version are compatible.