What is the best backup approach?

I’ve started using DevKinsta on Windows 10 and have downloaded one of my live Kinsta-hosted websites and I’m now developing this website further on my local machine. So far it works fine but I’m wondering what the easiest approach is for making sure I always have recent backups of my local work.

I do have incremental backups for the whole Windows machine in this case but I would like to add something that only does backups of my local web development work, which can then also easily be restored if data is lost or if I mess something up:)
For just the files I suppose I could do a continuous sync of the website files with Dropbox but that seems like a bad idea performance-wise.

Any suggestions for an elegant and efficient solution which keeps backups of all files and databases while not (too) negatively impacting performance?

1 Like

Welcome to DevKinsta @GoldyOnline ! I’m happy to help.

Depending on your experience with Docker, you can find several resources on Google for creating a Docker backup. We don’t have a personal recommendation on backing up a Docker container but here’s one I did find.

Not a bad idea at all. The only thing to note is that it won’t backup the database. It shouldn’t affect the performance of the website itself either.

Let me know which direction you end up with.

Hi @michael
Thanks for the feedback. For the files I might just go with Dropbox sync as you are saying it shouldn’t impact performance.
For the db I think a docker container backup (and restore) sounds good. I just did some reading about it and tried it out but I’m running into some issues.

First of all, I wasn’t entirely sure which container to backup to make sure I backup any database changes/updates. I assumed this is the “devkinsta_db” container (which is running the mariadb:10.5.5 image), is that correct?

I can make a snapshot of it using this command in Windows Powershell:
docker commit -p devkinsta_db devkinsta_db_backup

I can save it to the drive of my Windows machine for example then using:
docker save -o C:\Temp\devkinsta_db_backup.tar devkinsta_db_backup

After that, I got stuck though when trying a restore. First, I stopped and removed the current container using:
docker stop devkinsta_db
docker rm devkinsta_db

Then I wanted to run the container again from my “backup image”. (in reality you might need to restore the image first from the .tar file but I skipped that step for now as a first test)

I tried the following, to run it detached and with the correct container name:
docker run -d --name devkinsta_db devkinsta_db_backup

Which didn’t work in the sense that the local test website was not loading after that and returning an error page related to no connection to mysql/mariadb.

I thought the issue might be in the port config and I tried also:
docker run -d --name devkinsta_db devkinsta_db_backup -p 0.0.0.0:15100:3306/tcp

which also didn’t work, with this latter command it seemed that the container didn’t even start properly as it doesn’t show when using:
docker ps

After that I also tried simply to close DevKinsta after removing the devkinsta_db container via Powershell, and then restarting DevKinsta after that. It then starts/runs automatically the devkinsta_db container again and the local website is loading again. However, it is loading including my most recent change, which was a simple update in one post in Wordpress to see if I could restore to the state of the db from before I made that change.

My questions are:

  1. Is taking a snapshot of the “devkinsta_db” container and restoring it the right approach to backup and restore the database?
  2. What is the correct run command to properly run the container when restoring from a backup image?
  3. Anything else that I’m doing wrong?

Hi @GoldyOnline . It may be best to backup the database by itself rather than the entire container. Adminer can be used to produce an export. It’s the Database Manager button when viewing a site on DevKinsta.

From there, you can do an export here:

This backup will be better to hold onto as it can be used to restore onto any platform and not an entire Docker container.

Hi @michael

Thanks for the feedback but I was hoping to make it work with a Docker container backup, as per your own suggestion. It’s an elegant solution in my opinion and it would allow going back to a previous state/version with a few simple clicks or commands.

Can you provide some feedback on my questions related to that please as well?

While it does work, I don’t believe it’s as elegant nor as portable as the Adminer straight sql backup method which can then be restored anywhere. It’s best to have DevKinsta create the container so any updates on DevKinsta can also occur on the containers.

It’s an approach, though not sure if it’s the right approach if the only information you require is of the database itself. It’s not the easiest approach.

docker container run should do it.

Thanks for the further comments. I do understand the argument regarding keeping the backup portable, however, for my needs this is not important as I’m just looking to backup and restore to the same environment.
Having said that, I appreciate your suggestions and maybe I will implement a mysql export, but then preferably an automated one (using an extra tool I guess) rather than manual, and as far as I’ve seen so far with Adminer I can’t do it automated.

In the meantime though I found a solution for backup and restore of the data of the container itself. It turns out that the devkinsta_db container is using a volume mount, which means that the data persists even if the container is removed. So restoring just the container is not going to do much at all as the data is not in the container itself.

In Windows 10 the data of the container can be found here (paste the path in explorer):
\wsl$\docker-desktop-data\version-pack-data\community\docker\volumes\devkinsta_db_data

I have tested backup and restore of the full content of this folder via Windows and this seems to work fine. When making a change in the db and then restoring the data (from before the change) I get back a working environment with the old (unchanged) data.
And this is of course also something that can be automated easily.
NOTE: the backup and restore steps should be done when the container is not running.

Having read your answers I’m not sure if you approve of the above approach but I thought I’d share it here as it does answer some of my initial questions and it does seem to work fine so far.

1 Like

I’m glad that works for you @GoldyOnline and appreciate you sharing with everyone else here!

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.