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

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)

@perfectinfo Assuming you have it set up exactly as recommended here Installing farmOS | farmOS

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. File System Level Backup

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. SQL Dump

This stack overflow post has example commands:

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!

@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

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! :slight_smile:

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.

1 Like

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

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

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.)

2 Likes

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

1 Like