Backup strategy?
jordanh opened this issue · 13 comments
Hi! First of all, love dokku-rethinkdb
. We've been using it on our staging environment (and, soon to be production!) for our app for many months. This is a question, more than an issue.
How were you planning on facilitating hot backups?
It looks like that may be planned functionality for rethinkdb:export
and rethinkdb:import
. Is that right?
If so, how were you considering tackling this? Perhaps I can help?
In lieu of these commands being implemented, I was looking if I could work around it by entering the container and using $ rethinkdb dump
. But, I got:
root@1ae84fc29971:/data# rethinkdb dump
Error when launching 'rethinkdb-dump': No such file or directory
The rethinkdb-dump command depends on the RethinkDB Python driver, which must be installed.
If the Python driver is already installed, make sure that the PATH environment variable
includes the location of the backup scripts, and that the current user has permission to
access and run the scripts.
Instructions for installing the RethinkDB Python driver are available here:
http://www.rethinkdb.com/docs/install-drivers/python/
The same goes for export...
It looks like either:
- this project should switch to a container image that contains the python driver
or - should perhaps document a strategy like https://github.com/TaxiStockholm/rethinkdb-backup
What do you think?
Is there an official way to do imports and exports of rethinkdb databases? If so, that is what we'll use. If not, I am uninterested in supporting anything else in the plugins. I'd rather not have to switch out implementations at some point in the future.
Yes, there is. Via the rethinkdb
command. However, the official rethinkdb container does not include the Python driver to make the full functionality of the command available. It's a bummer.
In the past 30 minutes or so, I did some more research and found this: https://github.com/petecoop/rethinkdb-driver
I then went and quickly wrote two bash scripts using this image:
rethinkdb-backup.sh
:
#!/bin/bash
# see: https://github.com/petecoop/rethinkdb-driver
now=$(date +"%Y_%m_%d_%H_%M_%S")
docker run --rm \
--link dokku.rethinkdb.rethinkdb:rethinkdb \
-v $(readlink -e $1):/backup \
petecoop/rethinkdb-driver rethinkdb-dump -c rethinkdb -f /backup/rethinkdb_backup_$now.tar.gz
and rethinkdb-restore.sh
:
#!/bin/bash
# see: https://github.com/petecoop/rethinkdb-driver
docker run --rm \
--link dokku.rethinkdb.rethinkdb:rethinkdb \
-v $(dirname $(readlink -e $1)):/backup \
petecoop/rethinkdb-driver rethinkdb-restore -c rethinkdb --force /backup/$(basename $(readlink -e $1))
Using petecoop/rethinkdb-driver
might be a good avenue to provide backup and restore capability.
Otherwise, we could always ask rethinkdb to publish an official rethinkdb-driver image...
I like the rethinkdb-driver method, that seems to work. I'd also lobby to have the driver added to the official image.
Did either of you ever contact the RethinkDB team to get the driver added to the official image?
I'd love to see this supported. 😄
I did not, but if you wish to, their repository is here.
It looks like this has been addressed: rethinkdb/rethinkdb-dockerfiles#6
The python driver is too much baggage.
Does dokku
provide any tool for backing up a container?
If so, would there be any downsides in using that over rethinkdb dump/restore
?
We don't provide a "tool" for container data backup, we simply use the functionality provided by the image we use. If you'd like to implement rethinkdb backups, pull requests are welcome, but I'm extremely unlikely to do so unless it was paid work.
We don't provide a "tool" for container data backup, we simply use the functionality provided by the image we use.
Which means without rethinkdb dump/restore
, you would probably use Docker volumes. But that would force you to shutdown RethinkDB before backup/restore, while rethinkdb dump/restore
can be done while RethinkDB is still running. So I guess I'll be using petecoop/rethinkdb-driver. 😉
Should dokkupaas/s3backup really be installed by default?
@aleclarson I don't think you understand what dokkupaas/s3backup is for. We use that to output the service's backup files into a tarball that is then uploaded to s3. How those files are generated have no bearing on that particular image.
@josegonzalez Yeah I get that, but why assume that S3 is being used to store backups?
Because thats what someone paid me to build.
Closing this. It appears the official rethinkdb container isn't being maintained since the company went out of business, but if someone wants to make a pull request that would implement backups, I'd be happy to merge that change-set.
If you'd like to sponsor my work on this feature, feel free to reach out via email/slack for consulting.