Allow downloading and restoring backups of a container #2302

Closed
vistoyn opened this Issue Aug 21, 2016 · 5 comments

Comments

Projects
None yet
4 participants

vistoyn commented Aug 21, 2016

Sometimes need to backup and restore container in tarball.
For example i want make tarball of container and upload it on Amazon S3 as backup.
I can't find in official documentation simple way to do it.

I wrote bash scripts that do this.
https://github.com/vistoyn/lxd_backup

May be add this commands as official lxc commands?

Example like this:

lxc export {container_name} {backup_path} --exclude=/somedir --format=bz2
lxc export {container_name}/{snapshot} {backup_path}
lxc import {container_name} {backup_path}

or

lxc backup {container_name} {backup_path} --exclude=/somedir --format=bz2
lxc backup {container_name}/{snapshot} {backup_path}
lxc restore {container_name} {backup_path}
Owner

stgraber commented Aug 21, 2016

We may consider implementing something like this in LXD itself at some point, but it'd need careful thinking about how to do it in a way that works with all the different storage backends, especially when considering snapshots.

@stgraber stgraber changed the title from How to backup and restore container in tarball? to Allow downloading and restoring backups of a container Aug 21, 2016

@stgraber stgraber added this to the later milestone Aug 21, 2016

Contributor

cryptofuture commented Aug 23, 2016

I didn't tested it yet. But it looks nice. Sometimes you need to share container with friend, but you don't want to give access to your remote location, or setup extra intermediate remote just for it. I'll try to find time to test it today. I think this is not a problem to add gpg support for this scripts.

UPD:
I checked this scripts. Not impressed at all (even statical backups path used). There are no real reason to use this instead lxc image and I'm against including this in lxd, even like extra utils package.

vistoyn commented Aug 23, 2016

I wrote this scripts to solve simple task: everydays backup containers to Amazon S3, and restore it if need.
One way create backup's through my bash scripts.

It can be done another way:

  1. mount users data to outside containers folder, and every day backup it.
  2. realese new version of container through lxc image if container change, and backup it to cloud storage.
    But I should backup make two backups: images and users data, it's more difficult. May be more safe. If I accidentally delete container, users data will be remain. But if I use first way I can restore users data too.

I can't found way how to update existing container from new image. I can't understand why doesn't exists comand to update container. Propose to remove the container and recreate it. #2303

What do you think, what is the easiest way to everydays backup containers to Amazon S3/Dropbox/other cloud storage and restore it if need?

bungle commented Aug 24, 2016

Hi,

I have also been looking answer for that.

What I have and what I have not:

  1. I have a dir based LXD host with a few containers (on ext4)
  2. the containers can be running on-going processes in various states (e.g. mariadb, redis etc)
  3. I don't have a second server, but I do have backup space on FTP

I'm looking for a right procedure to make a self containing backup of a LXD container that I can later on restore on another host in case that original host dies (with as little down-time as possible).

I have read @vistoyn's script and others, but some concepts are still somewhat confusing to me.

@vistoyn backups scripts aka backup container offline:

  1. lxc stop container
  2. tar (what are the proper tar parameters?)
  3. lxc start container
  4. ftp tar.gz
  5. delete local tar.gz

(repeat, say every day)

Here are some other ways:

Image:

  1. lxc publish container --force
  2. lxc image export fingerprint tar
  3. lxc image delete fingerprint
  4. ftp tar.gz
  5. delete tar.gz

Snapshot Offline:

  1. lxc stop container
  2. lxc snapshot container
  3. lxc start container
  4. tar container/snap0 (what are the proper tar parameters?)
  5. lxc delete container/snap0
  6. ftp tar.gz
  7. delete tar.gz

Snapshot Online:

(here we need to run say mysqldump in a container before making a snapshot in case of something corrupts with online snapshot?)

  1. lxc snapshot container
  2. tar container/snap0 (what are the proper tar parameters?)
  3. lxc delete container/snap0
  4. ftp tar.gz
  5. delete tar.gz

I kinda like the first one with Image as there you are basically just calling lxc commands. No need to figure out the right tar parameters etc. Maybe a one command that does that would be nice, eg.

lxc export [remote:]<source container> [tarball]

And other way to import:

  1. lxc image import
  2. lxc launch imported-image

That could go like this:

lxc import <tarball> [remote:]<name>

So backing up:

# creates my-container.tar.gz on current directory (optionally on remote?)
lxc export my-container

And restoring on another host:

# imports my-container.tar.gz image and launches my-container container
lxc import my-container.tar.gz my-container

And this procedure should probably take care of doing this by default or optionally (and have that info inside a package):

# during export
lxc config show my-container > old-config
# during import
lxc config edit my-container < old-config

What do you think?

@stgraber stgraber modified the milestones: later, lxd-2.7 Nov 20, 2016

Owner

stgraber commented Dec 6, 2016

Closing this since we now have "lxd import" and serialized version of container config on the filesystem. So backing up your underlying storage is now sufficient to re-import the containers.

@stgraber stgraber closed this Dec 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment