Proposal: add a restore command

samos123 / docker-drupal

Drupal image based official php image, database information should be passed by environment variables or linked container. Drush is included

34 stars 10 forks source link

Proposal: add a restore command #13

Closed funkyfuture closed 1 year ago

funkyfuture commented 9 years ago

i have no concrete concept for this, but some thoughts on a way to restore the content and configuration of another instance in a fresh container. it aims to be a simple backup-helper and help pulling the state of a production-instance to a development-environment.

it could rely on Backup and Migrate
it looks for backups in /var/www/private/backup and /backup for the latest backup by default while the latter mountpoint precedes
later it may restore one of several backups selected by timestamp and relative by counting from the last backup
it would be called by docker run/exec <container> restore [[args]] or invoked on run if a configuration environment is set
it may have a backup-counterpart

any fresh thoughs are appreciated.

(be aware that a fully supported docker cp is coming. :smiley:)

samos123 commented 9 years ago

i don't think this is needed. Why not use docker commit instead to create a new image based on current image and attach a tag. Later run from this new image to restore.

funkyfuture commented 9 years ago

i wouldn't rely on committing a db-container since you couldn't know that the db is at a consistent state.

also, it could be more flexible, e.g. only restore db or files, no code.

also, we keep backups in a SAN, in order to backup there we would have to run a registry to store images there. but really, i wouldn't do that with database-files.

samos123 commented 9 years ago

Ok if you have a use case for it yourself, there may be others who would like it too. Although I still think there are enough tools that can do it already without too much effort. For database you can do a mysqldump for drupal container you can do a commit and if you use volumes you can backup volumes through docker.

When I said committing the container I was talking about the drupal container. I tend to scope the db out of this drupal image.

On Thu, Mar 26, 2015 at 12:56 AM, funkyfuture notifications@github.com wrote:

i wouldn't rely on committing a db-container since you couldn't know that the db is at a consistent state.

also, it could be more flexible, e.g. only restore db or files, no code.

— Reply to this email directly or view it on GitHub.

samos123 commented 9 years ago

Having a 2nd thought about this. Adding backup functionality would be nice but should be a user defined thing imo. The user can install the Backup and Migration module, but this is specified in his customized image. We should not push any modules in this core extendable image. Some user may not wish to have the Backup and Migrate module enabled for their own reasons(security, having as less as possible enabled). If most users require this functionality we can enable it as an parameter but it should not be enabled by default.

funkyfuture commented 9 years ago

i thought a simple thing would be to have the bootstrapping look at a certain path (which is recommended to be host-mounted) and if there's a b&r-tarball it get's imported. and there could be simple bash-aliases to drush-commands that are invoced by docker exec <drupal-container> full-backup, … content-backup etc.

this is not to be considered as a backup-solution for host-failures, but a convenience for manual processes.