# Migrate date from all-in-one docker to Kubernetes with managed PostgreSQL and MinIO

**URL:** https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555
**Category:** Technical Help
**Created:** [November 13, 2024, 8:11am UTC](https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555 "2024-11-13T08:11:02Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![jjmurre](https://community.baserow.io/letter_avatar_proxy/v4/letter/j/ea666f/32.png) [@jjmurre](https://community.baserow.io/u/jjmurre)
#### Post date: [November 13, 2024, 8:11am UTC](https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555/1 "2024-11-13T08:11:02Z")

</div>

Please fill in the questionnaire below.

## Technical Help Questionnaire

Have you read and followed the instructions at: [\*READ ME FIRST\* Technical Help FAQs - #2 by nigel](https://community.baserow.io/t/read-me-first-technical-help-faqs/17/2) ?

**Answer:** Yes

#### How have you self-hosted Baserow.

All-in-one docker

#### What are the specs of the service or server you are using to host Baserow.

```auto
               total used free shared buff/cache available
Mem: 15Gi 1.8Gi 7.9Gi 43Mi 5.9Gi 13Gi
Swap: 979Mi 0B 979Mi

```

#### Which version of Baserow are you using.

1.26.1 - enterprise

#### How have you configured your self-hosted installation?

```auto
#!/bin/sh
docker run
-d
–name baserow
-e BASEROW_PUBLIC_URL=“xxx”
-e BASEROW_CADDY_ADDRESSES=“xxx”
-e EMAIL_SMTP=true
-e EMAIL_SMTP_HOST=“xxx”
-e EMAIL_SMTP_PORT=“xxxx”
-e FROM_EMAIL=“noreply@eduxs.eu”
-v baserow_data:/baserow/data
-v “$PWD/Caddyfile:/baserow/caddy/Caddyfile”
-p 80:80
-p 443:443
–restart unless-stopped
baserow/baserow:1.26.1

```

#### What commands if any did you use to start your Baserow server?

See above.

### Describe the problem

We are use the docker all-in-one Baserow at the moment. For backup/restore, we are using the approach provided in the docs which is copying all the data from the mounted volume in the docker container.

Now we want to move our Baserow instance to a Kubernetes cluster with a managed Postgresql and MinIO. So, we do not have access to the volumes where the PostgreSQL and MinIO data is stored. What would be the recommended approach to move our data to the new environment?

---

<div class="post-metadata">

### Author: ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)
#### Post date: [November 13, 2024, 3:46pm UTC](https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555/2 "2024-11-13T15:46:44Z")

</div>

Hey @jjmurre, I recommend checking out the instructions here [Install with Docker](https://baserow.io/docs/installation%2Finstall-with-docker#backup-all-of-baserow). The first step about taking a backup results in a `tar` containing a PostgreSQL and uploaded media files dump.

When you’ve deployed your Baserow Kubernetes cluster, you can connect directly to the PostgreSQL database and restore the dump there. Same for the media files in the MinIO S3 bucket. This should then restore your complete instance.

If you’re using AWS, Azure, or another cloud provider, then I recommend using their managed PostgreSQL, S3, and Redis from there. That typically comes with additional backup, scaling, and monitoring capabilities.

---

<div class="post-metadata">

### Author: ![jjmurre](https://community.baserow.io/letter_avatar_proxy/v4/letter/j/ea666f/32.png) [@jjmurre](https://community.baserow.io/u/jjmurre)
#### Post date: [November 13, 2024, 3:56pm UTC](https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555/3 "2024-11-13T15:56:11Z")

</div>

Hi @bram Tx. Ah, I see, I assume I need to use the " Backup only Baserow’s Postgres database" in our case (because we do not have access to the filesystem of the managed postgres).

As for MinIO, I assume we can dump the baserow MiniIO buckets of our docker all-in-one and push those into a bucket on the managed MinIO?

---

<div class="post-metadata">

### Author: ![bram](https://community.baserow.io/letter_avatar_proxy/v4/letter/b/9d8465/32.png) [@bram](https://community.baserow.io/u/bram)
#### Post date: [November 13, 2024, 6:48pm UTC](https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555/4 "2024-11-13T18:48:54Z")

</div>

Hey @jjmurre, in this case I think you would still need to use the “Backup all of Baserow” because if you’re migrating to another instance you would need to the PostgreSQL dump and also the uploaded files. The uploaded files are the files that the user uploads in the file field, for example. In the all-in-one image, this is just stored in a folder, not on MinIO.

Basically, the MinIO dump you would like to take from the all-in-one image, is already included if you use the “Backup all of Baserow” method to make the backup.

Once you have the two, then you can work on restoring the PostgreSQL dump into the PostgreSQL database and uploaded user files into the MinIO deployments in the Kubernetes cluster.

I hope that makes sense.

---

<div class="post-metadata">

### Author: ![jjmurre](https://community.baserow.io/letter_avatar_proxy/v4/letter/j/ea666f/32.png) [@jjmurre](https://community.baserow.io/u/jjmurre)
#### Post date: [November 14, 2024, 6:28am UTC](https://community.baserow.io/t/migrate-date-from-all-in-one-docker-to-kubernetes-with-managed-postgresql-and-minio/6555/5 "2024-11-14T06:28:59Z")

</div>

The problem is in the restore process:

```auto
docker run --rm -v new_baserow_data_volume:/results -v $PWD:/backup ubuntu bash -c "mkdir -p /results/ && cd /results && tar xvf /backup/backup.tar --strip 2"

```

The filesystem where the PostgreSQL data lives needs to be mounted. However, because we are using a managed (by another department) PostgreSQL instance, we are not able to mount the data volume of that instance.
