# How to securely decommission a LXD deployment #### IMPORTANT This process will erase all data associated with your LXD deployment. Make copies of any data that you need to preserve before proceeding. Refer to [How to back up instances](https://canonical.com/lxd/docs/latest/howto/instances_backup/index.html.md#instances-backup) and [How to back up custom storage volumes](https://canonical.com/lxd/docs/latest/howto/storage_backup_volume/index.html.md#howto-storage-backup-volume) for relevant details. This guide walks you through the steps to decommission a LXD cluster. You can also follow this guide to decommission a standalone server, though the steps regarding cluster members will not apply in such cases. If you only need to decommission a single member of a cluster, first [remove that member from the cluster](https://canonical.com/lxd/docs/latest/howto/cluster_manage/index.html.md#cluster-manage-delete-members). After removing the member, [update the certificate](https://canonical.com/lxd/docs/latest/howto/cluster_manage/index.html.md#cluster-manage-update-certificate) on the cluster remaining in production. Then, return to this guide, skip ahead to [Remove the LXD snap](#howto-decommission-remove-lxd), and follow the instructions in the sections that follow. Unless otherwise noted, you can run the commands in this guide on any online cluster member. ## Remove offline cluster members Run this command with the `--force` flag to [remove any offline cluster members](https://canonical.com/lxd/docs/latest/howto/cluster_manage/index.html.md#cluster-manage-offline-members) (you will remove online cluster members later in the process): ```bash lxc cluster remove --force ``` ## Revoke remote access List all identities that have access to LXD, then delete each one: ```bash lxc auth identity list lxc auth identity delete / ``` To decommission a deployment [configured for single sign-on with OIDC](https://canonical.com/lxd/docs/latest/howto/oidc/index.html.md#howto-oidc), remove the corresponding profile from your OIDC identity provider. ## List projects Replicators, instances, profiles, custom volumes, and buckets are scoped by [project](https://canonical.com/lxd/docs/latest/projects/index.html.md#projects). By default, LXD commands only affect project-scoped entities on the currently active project; you can specify a different project by using the `--project` flag. If your deployment has more than one project, this means that you must repeat project-scoped commands with the `--project` flag to delete entities across projects. Note that you do not need to use the `--project` flag to delete entities on the currently active project (for example, `default`). Run this command to get a list of all projects: ```bash lxc project list ``` #### NOTE You can also delete a project (except the `default` project) and all of its project-level entities with: ```bash lxc project delete --force ``` ## Delete replicators and cluster links For each project, list all replicators, then delete each one: ```bash lxc replicator list --project lxc replicator delete --project ``` #### IMPORTANT Deleting a replicator does not delete the replica project on the remote cluster. To prevent unauthorized data recovery, you must decommission both clusters. Likewise, list all cluster links, then delete each one (cluster links are not scoped by project, so you do not need to use the `--project` flag): ```bash lxc cluster link list lxc cluster link delete ``` To fully revoke the trust relationship established by cluster links, delete any corresponding cluster links or identities on the other clusters. See the [guide to deleting cluster links](https://canonical.com/lxd/docs/latest/howto/cluster_links_manage/index.html.md#howto-cluster-links-delete) for details. ## Delete data #### IMPORTANT Data deleted by LXD physically remains on disks and can be recovered by users with access to the disks. To prevent unauthorized data recovery, you must [destroy and sanitize your data](#howto-decommission-destroy-data). ### Stop and delete instances For each project, stop all instances: ```bash lxc stop --all --project ``` Next, for each project, list all instances, then delete each one: ```bash lxc list --project lxc delete --project ``` If you are unable to stop or delete an instance, use the `--force` flag: ```bash lxc stop --force --project lxc delete --force --project ``` ### Delete profiles For each project, list all profiles: ```bash lxc profile list --project ``` Each project has a `default` profile that cannot be deleted. Delete all other profiles: ```default lxc profile delete --project ``` ### Remove disk devices from `default` profiles You cannot delete a storage pool used by an instance, profile, or custom volume. You must, therefore, remove any disk devices used by `default` profiles in order to delete any storage pools or custom volumes referenced by those devices. For example, if you configured a new storage pool during the [interactive initialization process](https://canonical.com/lxd/docs/latest/howto/initialize/index.html.md#initialize) with `lxd init`, then the `default` profile of the `default` project will have a disk device named `root` that references a storage pool. Remove this device with: ```bash lxc profile device remove default root --project default ``` To check for additional disk devices, view information about the `default` profile of each project: ```bash lxc profile show default --project ``` Remove any remaining disk devices that reference storage pools: ```bash lxc profile device remove default --project ``` ### Delete custom volumes and buckets You must specify storage pools to delete [custom volumes](https://canonical.com/lxd/docs/latest/explanation/storage/index.html.md#storage-volume-types) or [buckets](https://canonical.com/lxd/docs/latest/explanation/storage/index.html.md#storage-buckets). First, list all storage pools across projects: ```bash lxc storage list ``` Next, list the custom volumes on each storage pool. Use the `--all-projects` flag to view all custom volumes across projects: ```bash lxc storage volume list type=custom --all-projects ``` Then, for [Ceph Object](https://canonical.com/lxd/docs/latest/reference/storage_cephobject/index.html.md#storage-cephobject) pools only, list all buckets: ```bash lxc storage bucket list --all-projects ``` Use the `PROJECT` column in the output to identify the project associated with each custom volume or bucket. Finally, delete all custom volumes and buckets, specifying both the storage pool and the project: ```bash lxc storage volume delete --project lxc storage bucket delete --project ``` ### Delete storage pools List all storage pools, then delete each one (storage pools are not scoped by project, so you do not need to use the `--project` flag): ```bash lxc storage list lxc storage delete ``` ### Delete monitoring data Delete data from any external systems that you used to [monitor events](https://canonical.com/lxd/docs/latest/howto/security_events/index.html.md#howto-security-events) or [monitor metrics](https://canonical.com/lxd/docs/latest/metrics/index.html.md#metrics), such as [Loki](https://grafana.com/oss/loki/), [Prometheus](https://prometheus.io/), or [Grafana](https://grafana.com/). Refer to the documentation for those systems for details. ## Remove remaining cluster members After deleting data, you can remove the online cluster members from the cluster. List all cluster members, then remove each one: ```bash lxc cluster list lxc cluster remove ``` ## Remove the LXD snap #### IMPORTANT Run these commands on **every** machine that you decommission. Removing LXD **does not** erase dedicated disks/partitions, [ZFS pools (zpools)](https://canonical.com/lxd/docs/latest/reference/storage_zfs/index.html.md#storage-zfs), [LVM volume groups](https://canonical.com/lxd/docs/latest/reference/storage_lvm/index.html.md#storage-lvm), or [remote storage](https://canonical.com/lxd/docs/latest/reference/storage_drivers/index.html.md#storage-drivers-remote). To securely decommission LXD, you must [destroy and sanitize your data](#howto-decommission-destroy-data). Remove the LXD snap. Use the `--purge` flag, or a snapshot of your data will be preserved: ```bash sudo snap remove lxd --purge ``` Verify that the snap and associated data were removed. The following commands should report that LXD is not installed and that the `/var/snap/lxd/` directory does not exist: ```bash snap list lxd ls /var/snap/lxd/ ``` #### NOTE If you followed a different method to [install LXD](https://canonical.com/lxd/docs/latest/installing/index.html.md#installing), use your package manager to remove LXD. Then, delete the data in `/var/lib/lxd/`. ## Destroy and sanitize data Data deleted by LXD remains readable and can be recovered by users with access to disks used in your deployment. To prevent unauthorized recovery, you must physically overwrite the data. Follow your data destruction policy to securely erase and destroy disks used by LXD, as well as disks on machines used to monitor LXD events or metrics. Consult storage providers for details about how to securely sanitize data on [remote storage](https://canonical.com/lxd/docs/latest/reference/storage_drivers/index.html.md#storage-drivers-remote). For deployments [configured for single sign-on with OIDC](https://canonical.com/lxd/docs/latest/howto/oidc/index.html.md#howto-oidc), consult your OIDC identity provider for the steps to remove any associated data. Likewise, if you used [ACME services to issue server certificates](https://canonical.com/lxd/docs/latest/authentication/index.html.md#authentication-server-certificate), refer to the service provider for the steps to remove any associated data. #### IMPORTANT Sanitized data is irreversibly destroyed and cannot be recovered.