Gecko [ www.jdcpatala.org ]

Name	Size	Permission
explanation	[ DIR ]	drwxr-xr-x
howto	[ DIR ]	drwxr-xr-x
reference	[ DIR ]	drwxr-xr-x
tutorial	[ DIR ]	drwxr-xr-x
api-extensions.md.txt	108.13 KB	-rw-r--r--
api.md.txt	886 B	-rw-r--r--
architectures.md.txt	2.14 KB	-rw-r--r--
authentication.md.txt	11.86 KB	-rw-r--r--
backup.md.txt	6.08 KB	-rw-r--r--
cloud-init.md.txt	13.2 KB	-rw-r--r--
clustering.md.txt	1.45 KB	-rw-r--r--
config-options.md.txt	194 B	-rw-r--r--
container-environment.md.txt	3.2 KB	-rw-r--r--
contributing.md.txt	7.48 KB	-rw-r--r--
daemon-behavior.md.txt	1.2 KB	-rw-r--r--
database.md.txt	1.74 KB	-rw-r--r--
debugging.md.txt	6.34 KB	-rw-r--r--
dev-lxd.md.txt	5.06 KB	-rw-r--r--
doc-cheat-sheet-myst.md.txt	4.15 KB	-rw-r--r--
environment.md.txt	2.48 KB	-rw-r--r--
events.md.txt	25.55 KB	-rw-r--r--
faq.md.txt	7.4 KB	-rw-r--r--
getting_started.md.txt	1.93 KB	-rw-r--r--
guest-os-compatibility.md.txt	7.31 KB	-rw-r--r--
image-handling.md.txt	3.93 KB	-rw-r--r--
images.md.txt	1003 B	-rw-r--r--
index.md.txt	3.45 KB	-rw-r--r--
installing.md.txt	14.52 KB	-rw-r--r--
instance-exec.md.txt	8.96 KB	-rw-r--r--
instances.md.txt	2.42 KB	-rw-r--r--
internals.md.txt	727 B	-rw-r--r--
metrics.md.txt	13.74 KB	-rw-r--r--
networks.md.txt	2.06 KB	-rw-r--r--
operation.md.txt	1.09 KB	-rw-r--r--
production-setup.md.txt	1.35 KB	-rw-r--r--
profiles.md.txt	9.96 KB	-rw-r--r--
projects.md.txt	823 B	-rw-r--r--
remotes.md.txt	3.17 KB	-rw-r--r--
requirements.md.txt	2.2 KB	-rw-r--r--
rest-api.md.txt	9.03 KB	-rw-r--r--
restapi_landing.md.txt	385 B	-rw-r--r--
server.md.txt	3.06 KB	-rw-r--r--
storage.md.txt	1.26 KB	-rw-r--r--
support.md.txt	2.23 KB	-rw-r--r--
syscall-interception.md.txt	5.34 KB	-rw-r--r--
userns-idmap.md.txt	3.72 KB	-rw-r--r--

Code Editor : backup.md.txt

(backups)=
# How to back up a LXD server

```{youtube} https://www.youtube.com/watch?v=IFOZpAxckPo
```

In a production setup, you should always back up the contents of your LXD server.

The LXD server contains a variety of different entities, and when choosing your backup strategy, you must decide which of these entities you want to back up and how frequently you want to save them.

## What to back up

The various contents of your LXD server are located on your file system and, in addition, recorded in the {ref}`LXD database <database>`.
Therefore, only backing up the database or only backing up the files on disk does not give you a full functional backup.

Your LXD server contains the following entities:

- Instances (database records and file systems)
- Images (database records, image files, and file systems)
- Networks (database records and state files)
- Profiles (database records)
- Storage volumes (database records and file systems)

Consider which of these you need to back up.
For example, if you don't use custom images, you don't need to back up your images since they are available on the image server.
If you use only the `default` profile, or only the standard `lxdbr0` network bridge, you might not need to worry about backing them up, because they can easily be re-created.

## Full backup

To create a full backup of all contents of your LXD server, back up the `/var/snap/lxd/common/lxd` (for snap users) or `/var/lib/lxd` (otherwise) directory.

This directory contains your local storage, the LXD database, and your configuration.
It does not contain separate storage devices, however.
That means that whether the directory also contains the data of your instances depends on the storage drivers that you use.

```{important}
If your LXD server uses any external storage (for example, LVM volume groups, ZFS zpools, or any other resource that isn't directly self-contained to LXD), you must back this up separately.

See {ref}`howto-storage-backup-volume` for instructions.
```

To back up your data, create a tarball of `/var/snap/lxd/common/lxd` (for snap users) or `/var/lib/lxd` (otherwise).
If you are not using the snap package and your source system has a `/etc/subuid` and `/etc/subgid` file, you should also back up these files.
Restoring them avoids needless shifting of instance file systems.

To restore your data, complete the following steps:

1. Stop LXD on your server (for example, with `sudo snap stop lxd`).
1. Delete the directory (`/var/snap/lxd/common/lxd` for snap users or `/var/lib/lxd` otherwise).
1. Restore the directory from the backup.
1. Delete and restore any external storage devices.
1. If you are not using the snap, restore the `/etc/subuid` and `/etc/subgid` files.
1. Restart LXD (for example, with `sudo snap start lxd` or by restarting your machine).

### Export a snapshot

If you are using the LXD snap, you can also create a full backup by exporting a snapshot of the snap:

1. Create a snapshot:

sudo snap save lxd

Note down the ID of the snapshot (shown in the `Set` column).
1. Export the snapshot to a file:

sudo snap export-snapshot <ID> <output_file>

See [Snapshots](https://snapcraft.io/docs/snapshots) in the Snapcraft documentation for details.

## Partial backup

If you decide to only back up specific entities, you have different options for how to do this.
You should consider doing some of these partial backups even if you are doing full backups in addition.
It can be easier and safer to, for example, restore a single instance or reconfigure a profile than to restore the full LXD server.

### Back up instances and volumes

Instances and storage volumes are backed up in a very similar way (because when backing up an instance, you basically back up its instance volume, see {ref}`storage-volume-types`).

See {ref}`instances-backup` and {ref}`howto-storage-backup-volume` for detailed information.
The following sections give a brief summary of the options you have for backing up instances and volumes.

(secondary-backup-server)=
#### Secondary backup LXD server

LXD supports copying and moving instances and storage volumes between two hosts.
See {ref}`move-instances` and {ref}`howto-storage-move-volume` for instructions.

So if you have a spare server, you can regularly copy your instances and storage volumes to that secondary server to back them up.
Use the `--refresh` flag to update the copies (see {ref}`storage-optimized-volume-transfer` for the benefits).

If needed, you can either switch over to the secondary server or copy your instances or storage volumes back from it.

If you use the secondary server as a pure storage server, it doesn't need to be as powerful as your main LXD server.

#### Export tarballs

You can use the `export` command to export instances and volumes to a backup tarball.
By default, those tarballs include all snapshots.

You can use an optimized export option, which is usually quicker and results in a smaller size of the tarball.
However, you must then use the same storage driver when restoring the backup tarball.

See {ref}`instances-backup-export` and {ref}`storage-backup-export` for instructions.

#### Snapshots

Snapshots save the state of an instance or volume at a specific point in time.
However, they are stored in the same storage pool and are therefore likely to be lost if the original data is deleted or lost.
This means that while snapshots are very quick and easy to create and restore, they don't constitute a secure backup.

See {ref}`instances-snapshots` and {ref}`storage-backup-snapshots` for more information.

(backup-database)=
### Back up the database

While there is no trivial method to restore the contents of the {ref}`LXD database <database>`, it can still be very convenient to keep a backup of its content.
Such a backup can make it much easier to re-create, for example, networks or profiles if the need arises.

Use the following command to dump the content of the local database to a file:

lxd sql local .dump > <output_file>

Use the following command to dump the content of the global database to a file:

lxd sql global .dump > <output_file>

You should include these two commands in your regular LXD backup.

${this.title}

Code Editor : backup.md.txt