https://github.com/runejuhl/lxd-backup-server
LXD utility for using LXC snapshots to create consistent backups from running containers
https://github.com/runejuhl/lxd-backup-server
Last synced: 3 months ago
JSON representation
LXD utility for using LXC snapshots to create consistent backups from running containers
- Host: GitHub
- URL: https://github.com/runejuhl/lxd-backup-server
- Owner: runejuhl
- License: agpl-3.0
- Created: 2020-11-12T21:25:45.000Z (over 4 years ago)
- Default Branch: master
- Last Pushed: 2020-11-12T21:32:25.000Z (over 4 years ago)
- Last Synced: 2025-02-28T17:08:40.168Z (3 months ago)
- Language: Go
- Size: 41 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.org
- License: LICENSE
Awesome Lists containing this project
README
* LXD backup server
LXD utility for using LXC snapshots to create consistent backups from running
containers.
** Note
This was written in 2017. The LXD API has changed quite a bit since then and I'm
not sure if this code will even compile anymore.
In any case: the idea was good enough (and the tool worked fine enough) that it
should be publicly available – so here it is.
~/runejuhl~
** Design
This program implements a small HTTP server with the intention of providing a
safe way to expose LXC commands to running containers.
While LXD does have a REST API that can be used (and is indeed used here as
well, though the Golang lxd library) it doesn't have any support for
authentication or access control so any client able to connect can do anything
to other containers.
The idea is that this tool is used to backup a stateful process running in an
LXC container.
*** Usage example
Consider a MySQL database. To ensure consistency of a database dump it needs to
be locked while the database is written out to disk. Since writing the file out
can take a while this is often not a good way to go about it.
With LXD we can take a snapshot of a running container, and any changes to the
copy will not affect the parent container.
This means that instead of pausing a production system for however long enough
to create a backup, we can instead issue a lock to the production system, create
an LXD snapshot, unpause the production system and then use the cloned container
to create our backup. After the backup completes the backup is written back into
the production container and the clone is destroyed.
*** Endpoints
**** POST =/backup=
Start a backup job. Takes a JSON body like the following:
#+BEGIN_SRC json
{
"name": "test",
"ephemeral": true,
"command": [
"bash",
"-c",
"sleep 10; echo /etc/debian_version"
],
"profiles": [
"-default",
"default-nonic"
]
}
#+END_SRC
This does the following when:
+ copies the LXC =name=
+ removes the =default= profile, adds the profile =default-nonic=
+ starts the copy
+ runs the specified command in the copy
+ copies the result (in this case =/etc/debian_version= in the copy) into
=FILE_DESTINATION=
+ stops the copy (and since it's ephemeral it also gets destroyed
**** GET =/backup=
Requires a header =Request-Id= with the request ID returning in the header from
the job creation.
Returns status of a backup job. As long as it's still running the result is a
=423 Locked=. When it's done the resulting status is either =200 OK= or =500
Internal Server Error= and the job is deleted.
**** GET =/backup/list=
Returns a JSON array of current backup jobs. Jobs are not necessarily still
running, but their status hasn't been read yet.
** Running
#+BEGIN_SRC bash
FILE_DESTINATION=/var/lib/backups ./lxd-snapshot-server
#+END_SRC
** Example
#+BEGIN_SRC bash
curl -i localhost:3000/backup -d '{"name": "test", "ephemeral": true, "command": ["bash", "-c", "sleep 10; echo /etc/debian_version"]}'
curl -i localhost:3000/backup/list
curl -i -H 'Request-Id: 679078d84ae43521' localhost:3000/backup
#+END_SRC
** Future improvement
If the command only outputs to one file, it would be trivial to just output it
to stderr and avoid a file copy.