"How can I recover my WordPress project after reinstalling settings and losing data in Docker Compose?"

Question

[artpy@fedora GeekTech]$ docker-compose up
[+] Running 4/4
 ✔ Network geektech_default      Created                                   0.0s 
 ✔ Container geektech-adminer-1  Created                                   0.0s 
 ✔ Container geektech-db-1       Created                                   0.0s 
 ✔ Container geektech-wp-1       Created                                   0.0s 
Attaching to geektech-adminer-1, geektech-db-1, geektech-wp-1
geektech-db-1       | 2023-09-21 09:15:19+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.5.20+maria~ubu2004 started.
geektech-adminer-1  | WordPress not found in /var/www/html - copying now...
geektech-wp-1       | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.89.2.13. Set the 'ServerName' directive globally to suppress this message
geektech-wp-1       | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.89.2.13. Set the 'ServerName' directive globally to suppress this message
geektech-wp-1       | [Thu Sep 21 09:15:19.264902 2023] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.56 (Debian) PHP/8.2.6 configured -- resuming normal operations
geektech-wp-1       | [Thu Sep 21 09:15:19.264925 2023] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
geektech-db-1       | 2023-09-21 09:15:19+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
geektech-db-1       | 2023-09-21 09:15:19+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.5.20+maria~ubu2004 started.
geektech-adminer-1  | Complete! WordPress has been successfully copied to /var/www/html
geektech-adminer-1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.89.2.11. Set the 'ServerName' directive globally to suppress this message
geektech-adminer-1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.89.2.11. Set the 'ServerName' directive globally to suppress this message
geektech-adminer-1  | [Thu Sep 21 09:15:19.378429 2023] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.56 (Debian) PHP/8.2.6 configured -- resuming normal operations
geektech-adminer-1  | [Thu Sep 21 09:15:19.378454 2023] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
geektech-db-1       | 2023-09-21 09:15:19+00:00 [Note] [Entrypoint]: MariaDB upgrade not required
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] Starting MariaDB 10.5.20-MariaDB-1:10.5.20+maria~ubu2004 source revision b735ca47738a1d2e995a429f40afd620eb7d8843 as process 1
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Uses event mutexes
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Number of pools: 1
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Using Linux native AIO
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Initializing buffer pool, total size = 134217728, chunk size = 134217728
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Completed initialization of buffer pool
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=45115,45115
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: 128 rollback segments are active.
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Creating shared tablespace for temporary tables
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: 10.5.20 started; log sequence number 45127; transaction id 20
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] Plugin 'FEEDBACK' is disabled.
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] InnoDB: Buffer pool(s) load completed at 230921  9:15:19
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] Server socket created on IP: '::'.
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] Reading of all Master_info entries succeeded
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] Added new Master_info '' to hash table
geektech-db-1       | 2023-09-21  9:15:19 0 [Note] mysqld: ready for connections.
geektech-db-1       | Version: '10.5.20-MariaDB-1:10.5.20+maria~ubu2004'  socket: '/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution

I have a WordPress project that I run on a Podman container using Docker Compose, and in the past week, I encountered an issue with Podman and Docker Compose not starting up. I had to try various solutions, including uninstalling and reinstalling Podman and Docker Compose. Eventually, I resolved the problem by downgrading the version of Docker Compose to the previous one. Now, the issue is that I didn't back up my project, and I executed a commit, then deleted and reinstalled the WordPress settings in the Podman volume. Currently, my project is inaccessible, and when I start Docker Compose, it attempts to reinstall WordPress from scratch, resulting in an empty project.

How can I recover my project?

Answer 1

You're not thinking 4th dimensionally as the Doc would say!

First thing first, would be useful to provide us your docker-compose.yml code, then we can better see the configuration of how your containerised environment is being deployed.

As I can see you got 3 containers being deployed...

 ✔ Container geektech-adminer-1  Created   0.0s 
 ✔ Container geektech-db-1       Created.  0.0s 
 ✔ Container geektech-wp-1       Created  

My first question is what is adminer-1 container, is this Podman?

Right, heres a mini docker compose 101 (and this may be your problem)

1. Running docker-compose up on your directory containing your docker-compose.yml config will initially download/pull and cache all images defined in your yml container configs.
2. So everytime you run docker-compose up will build containers and volumes based on the image used in your container block.
3. If you start working on your environment, general installation and local data inputting into your running containers, this data is all being stored into the running containers.
4. If you run docker-compose stop on your docker-compose.yml directory, this will just shutdown your running environment, and any data currently for this container group cached in Docker Desktop will still be there. You could then run command docker-compose up and all your inputted data will still be as it was when you last used docker-compose stop.
5. However, if you use docker-compose down command on your project directory, this will shut down all running containers in your docker-compose.yml, and then completely delete all the container cached data in your Docker Desktop App. So next time you use docker-compose up... you'll be at square one again (all data lost).
6. To retain data from your docker deployed containers, you need to persist data. You need to map volume data from container images to your project directory containing your docker-compose.yml file. See following examples of yml volume persistent mapping configuration...

Persistent volumes in containers

So in your docker-compose.yml in the container block, add a volume config to map current image data to the directory of the compose file. See example below for Wordpress image in compose file...

version: '3.8'

services:

  # here is our mariadb container
  # https://hub.docker.com/_/mariadb
  db:
    image: mariadb:11.0.2
    restart: always
    ports:
      - "3306:3306"
    volumes:
      # our persistent volume database mapping
      - ./db:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: root
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress

  # here is our wordpress container
  # https://hub.docker.com/_/wordpress
  wordpress:
    image: wordpress:latest
    restart: always
    ports:
      - "80:80"
    depends_on:
      - db
    volumes:
      # our persistent volume sub directories mapping
      - ./themes:/var/www/html/wp-content/themes
      - ./mu-plugins:/var/www/html/wp-content/mu-plugins
      - ./plugins:/var/www/html/wp-content/plugins
      - ./uploads:/var/www/html/wp-content/uploads
    environment:

      # our docker wp config settings
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress

      # our docker wp config extra php defines
      WORDPRESS_CONFIG_EXTRA: |

        /** disable wp core auto update */
        define('WP_AUTO_UPDATE_CORE', false);

See my repo on github for Docker Compose usage with WordPress that might be helpful for persistent data and other integrations into the docker-compose.yml file.