如何恢复Podman+Docker Compose中丢失数据的WordPress项目

[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

问题描述 #

我通过Docker Compose在Podman容器中运行WordPress项目，近期遇到Podman与Docker Compose无法启动的问题，尝试卸载重装后，通过降级Docker Compose版本解决了启动问题。但因未备份项目，执行commit后删除并重装了Podman卷中的WordPress设置，现在项目无法访问，启动Docker Compose会重新安装空白的WordPress，请问该如何恢复我的项目？

解决步骤 #

1. 确认数据库卷是否保留 #

WordPress的文章、站点设置等核心数据都存储在数据库中，先检查数据库卷是否还存在：

# 列出所有Podman卷
podman volume ls

找到名称包含db或mariadb的卷（比如geektech_db），如果存在，说明数据库数据未丢失，恢复难度较低。

2. 从已commit的WordPress镜像提取关键文件 #

你提到执行过commit操作，说明有之前WordPress容器的镜像，可从中恢复站点文件：

# 停止当前运行的容器
podman-compose down

# 删除当前空白的WordPress卷（替换为你的WP卷名）
podman volume rm geektech_wp

# 创建临时容器，挂载新WP卷并使用commit的镜像
podman run -d --name temp-wp -v geektech_wp:/var/www/html [你的commit镜像ID/名称]

# 复制关键文件到卷中：wp-content包含主题、插件、上传文件；wp-config.php是数据库配置
podman cp temp-wp:/var/www/html/wp-content /var/lib/containers/storage/volumes/geektech_wp/_data/
podman cp temp-wp:/var/www/html/wp-config.php /var/lib/containers/storage/volumes/geektech_wp/_data/

# 清理临时容器
podman stop temp-wp && podman rm temp-wp

3. 重启容器验证恢复 #

podman-compose up -d

此时WordPress会读取恢复的配置文件，连接到现有数据库，站点内容应该能正常显示。

4. 数据库卷也被删除的情况 #

如果数据库卷已丢失，尝试从commit的数据库镜像恢复数据：

# 启动临时数据库容器
podman run -d --name temp-db [你的数据库commit镜像ID/名称]

# 导出数据库备份（替换为你的数据库用户、密码、库名）
podman exec temp-db mysqldump -u root -p[数据库密码] wordpress > wp_backup.sql

# 导入备份到当前运行的数据库容器
podman exec -i geektech-db-1 mysql -u root -p[数据库密码] wordpress < wp_backup.sql

# 清理临时容器
podman stop temp-db && podman rm temp-db

完成后重复步骤2恢复WordPress文件即可。

内容的提问来源于stack exchange，提问作者Artpy