# Sharing Docker volume w/ SQLite database file between Windows and Linux hosts

**URL:** <https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383>\
**Category:** Hosting farmOS\
**Tags:** support-request\
**Created:** [October 19, 2022, 10:21am UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383 "2022-10-19T10:21:07Z")\
**Posts on this page:** 6\
**Page:** 2

<div class="post-metadata">

**Author:** ![Farmer-Ed](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/farmer-ed/32/662_2.png) [@Farmer-Ed](https://farmos.discourse.group/u/Farmer-Ed)\
**Post date:** [October 29, 2022, 5:41am UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383/22 "2022-10-29T05:41:23Z")

</div>

I actually wonder now if this process may have actually worked for your sqlite to PG migration as I do not think it is DB specific and uses drush to dump/unload/ reload the data-base. DB settings in settings.php would need to be changed between export and import. (I wouldn’t try it in the same instance just in case)

---

<div class="post-metadata">

**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\
**Post date:** [October 29, 2022, 1:11pm UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383/23 "2022-10-29T13:11:56Z")

</div>

@perfectinfo Assuming you have it set up exactly as recommended here [Installing farmOS | farmOS](https://farmos.org/hosting/install/#farmos-in-docker)…

There are two things that needs to be backed up:

1. Your database.
2. Your `sites` directory.

The database (1) can be backed up just like any other SQL database running in Docker. There is nothing specific about farmOS. It’s always a good idea to understand the details so you can apply it to your specific scenario correctly - so I would recommend searching for “backing up docker postgresql database” to learn the general concepts first.

If you are running PostgreSQL in a Docker container, there are two easy ways to back it up. One is to simply turn off the containers and create a tarball of the `db` directory:

`sudo tar -czf db.tar.gz db`

This will create a full “file system backup” of the PostgreSQL data directory, just like it is described in the official PostgreSQL documentation: [PostgreSQL: Documentation: 11: 25.2.&nbsp;File System Level Backup](https://www.postgresql.org/docs/11/backup-file.html)

Restoring from this is as simple as deleting (or moving) the `db` directory and unpacking the saved tarball:

`sudo tar -xzf db.tar.gz`

The other option is to make an SQL dump of the database, as described in the official PostgreSQL docs: [PostgreSQL: Documentation: 11: 25.1.&nbsp;SQL Dump](https://www.postgresql.org/docs/11/backup-dump.html)

This stack overflow post has example commands:

> <https://stackoverflow.com/questions/24718706/backup-restore-a-dockerized-postgresql-database>

Experiment with that until you feel comfortable with it, and feel free to ask specific questions if you run into issues.

The rule of thumb for backups is: they are only as good as your ability to restore them. TEST this and learn! It’s _your_ responsibility to understand how it works. We can provide general guidance, but ultimately this is standard database management that is not specific to farmOS.

The `sites` directory (2) will contain all uploaded files, as well as `settings.php`. It’s important to back these files up as well. A simple tarball works for this too.

Apart from that, the CODE of farmOS will be contained in the Docker image, so you don’t need to back that up, assuming you are following the official install instructions and ONLY mounting the `sites` directory, not the whole `/opt/drupal` codebase (which is only recommended for development).

Hope that helps. Good luck in your learning!

---

<div class="post-metadata">

**Author:** ![mstenta](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/mstenta/32/4_2.png) [@mstenta](https://farmos.discourse.group/u/mstenta)\
**Post date:** [October 29, 2022, 1:16pm UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383/24 "2022-10-29T13:16:29Z")

</div>

@Farmer-Ed The `drush` SQL commands are handy, but I haven’t worked with them myself. Also @pcambra discovered this issues, which you might want to be aware of: [https://www.drupal.org/project/farm/issues/3213397](https://www.drupal.org/project/farm/issues/3213397)

I tend to prefer using `pg_dump` and `psql` directly, just to avoid any middle-men or surprises. But if it’s working for you great! 🙂

> I actually wonder now if this process may have actually worked for your sqlite to PG migration as I do not think it is DB specific and uses drush to dump/unload/ reload the data-base.

This will _not_ work, as far as I understand it. Drush simply uses `psql` and `sqlite3` commands behind the scenes, so if you do `drush sql-dump` on an SQLite3 database it will create an SQLite3-specific dump file, which cannot be directly imported into PostgreSQL (as far as I know). There isn’t anything special about the Drush SQL commands - it doesn’t create SQL-type agnostic dumps. They are still only good against the type of database they were exported from.

---

<div class="post-metadata">

**Author:** ![Farmer-Ed](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/farmer-ed/32/662_2.png) [@Farmer-Ed](https://farmos.discourse.group/u/Farmer-Ed)\
**Post date:** [October 29, 2022, 1:26pm UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383/25 "2022-10-29T13:26:31Z")

</div>

> [@mstenta](#):
>
> here isn’t anything special about the Drush SQL commands - it doesn’t create SQL-type agnostic dumps. They are still only good against the type of database they were exported from.

Ah , good to know @mstenta  
maybe I’ll have another look at my own backup plan too.

---

<div class="post-metadata">

**Author:** ![Symbioquine](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/symbioquine/32/284_2.png) [@Symbioquine](https://farmos.discourse.group/u/Symbioquine)\
**Post date:** [October 29, 2022, 3:46pm UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383/26 "2022-10-29T15:46:21Z")

</div>

I also use `drush sql-dump` since it has a convenient configuration mechanism for backing up only the structure of certain tables with cache/ephemeral data in them. See [Drush configuration - Drush](https://www.drush.org/latest/using-drush-configuration/#non-options)

So far I haven’t had any problems with it and I test my backup restoration path pretty regularly since it is also the means by which I initialize my staging/development environment with test data. (Obviously, all the aforementioned caveats apply regarding the resulting backup being PG specific and potentially having issues with `psql` version mismatches.)

---

<div class="post-metadata">

**Author:** ![perfectinfo](https://avatars.discourse-cdn.com/v4/letter/p/7ba0ec/32.png) [@perfectinfo](https://farmos.discourse.group/u/perfectinfo)\
**Post date:** [November 3, 2022, 6:48am UTC](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383/27 "2022-11-03T06:48:47Z")

</div>

thanks everyone for replying, i will now try the stuff and revert if face any issues !

[Previous page](https://farmos.discourse.group/t/sharing-docker-volume-w-sqlite-database-file-between-windows-and-linux-hosts/1383.md?page=1)
