---
title: TeslaMate 数据备份及恢复
category: Docker备份教学
updatedAt: 2026-05-03T09:20:00+08:00
createdAt: 2025-12-28T12:41:52.743Z
---

![TeslaMate 数据备份及恢复](https://file0.52tesla.com/xtbf/f63ba567c18e4508bdd3c4f496d74f95/636bc20f?x-oss-process=image%2F%2Fquality%2CQ_30%2Fformat%2Cwebp%2Fresize%2Cw_1280%2Climit_0)

# TeslaMate 数据备份及恢复

官方文档： [Backup and Restore | TeslaMate](https://docs.teslamate.org/docs/maintenance/backup_restore)

这篇文章把我之前博客里的基础备份恢复方法，以及最近实际在用的 `bump` 备份方案整合到一起。  
如果你只是想快速上手，建议优先看前面的 `bump` 方案；如果你只是单机手动维护，也可以看后面的基础命令版。

## 一句话结论

- 目前更推荐使用 PostgreSQL 的 `custom format dump`，也就是 `pg_dump -Fc`
- 恢复时更推荐使用 `pg_restore`
- 最稳妥的做法，是备份前先停止 `teslamate` 应用容器，数据库容器保持运行
- 恢复前要清理 `public` 和 `private` 两个 schema，避免新版本迁移时出现 `private.tokens` 冲突
- 如果你更看重不停机，也可以直接在线备份，通常也能正常使用
- 除了数据库文件，最好把镜像版本、`docker-compose.yml`、`.env` 一起保存

# 一、推荐方案：使用 bump 脚本自动备份

这是我现在更推荐的方案，适合长期运行、批量管理、远程自动备份。

## 1. bump 方案在做什么

`bump` 目录里的脚本，本质上做的是下面这些事情：

1. 找到 TeslaMate 的 PostgreSQL 容器
2. 使用 `pg_dump -Fc` 生成完整数据库备份
3. 把备份文件复制到宿主机
4. 上传到 WebDAV 等远程位置
5. 多台机器时，可由总控脚本统一分发执行

相比早期直接导出 `.bck` 文本 SQL，这种方式有几个优点：

- 同时包含数据库结构和数据
- 更适合跨机器迁移
- 更适合完整恢复
- 恢复时更不容易遗漏对象
- 更适合长期自动化备份

## 2. 备份前要不要停止 TeslaMate

建议做法：停止 `teslamate` 应用容器，再执行备份。

原因：

- TeslaMate 运行时会持续写入 PostgreSQL
- 停止应用后，备份结果更稳定
- 可以减少备份过程中数据变化带来的不一致风险

推荐状态：

- `teslamate` 容器：停止
- `postgres` 容器：保持运行
- `grafana`、`mosquitto`、`wemate`：可停可不停

不过如果你不能接受短暂停机，也可以在线备份。`pg_dump` 本身支持一致性快照导出，所以不停机备份通常也是可用的，只是从运维稳妥性上略弱一些。

我现在的脚本已经支持这两种模式：

- `STOP_TESLAMATE_BEFORE_BACKUP=1`：先停应用再备份
- `STOP_TESLAMATE_BEFORE_BACKUP=0`：不停机直接在线备份

如果你只是给自己使用，并且更在意不中断服务，可以直接在线备份。  
如果你准备给别人做迁移、恢复，或者希望尽量降低恢复翻车概率，还是建议先停应用再备份。

## 3. 标准备份流程

下面示例假设：

- PostgreSQL 容器名：`teslamate-database-1`
- TeslaMate 容器名：`teslamate-teslamate-1`
- 数据库名：`teslamate`
- 数据库用户：`teslamate`
- 备份文件名：`./teslamate.dump`

### 方案 A：更稳妥，先停应用再备份

```bash
docker stop teslamate-teslamate-1
docker exec teslamate-database-1 pg_dump -U teslamate -d teslamate -Fc -f /teslamate.dump
docker cp teslamate-database-1:/teslamate.dump ./teslamate.dump
docker exec teslamate-database-1 rm -f /teslamate.dump
docker start teslamate-teslamate-1
```

### 方案 B：不停机在线备份

```bash
docker exec teslamate-database-1 pg_dump -U teslamate -d teslamate -Fc -f /teslamate.dump
docker cp teslamate-database-1:/teslamate.dump ./teslamate.dump
docker exec teslamate-database-1 rm -f /teslamate.dump
```

参数说明：

- `-U teslamate`：数据库用户
- `-d teslamate`：数据库名
- `-Fc`：使用 PostgreSQL 自定义格式导出
- `-f /teslamate.dump`：在数据库容器中生成临时备份文件

## 4. 如何确认备份成功

备份完成后，先看文件是否存在、大小是否正常：

```bash
ls -lh ./teslamate.dump
```

如果还想进一步验证备份结构，可以查看归档内容：

```bash
pg_restore -l ./teslamate.dump
```

如果输出里能看到表、schema、索引等对象，通常说明这个备份文件结构上是有效的。

## 5. 备份时建议顺手保存的内容

除了数据库备份文件，建议再额外保存：

- TeslaMate 镜像版本
- PostgreSQL 镜像版本
- `docker-compose.yml`
- `.env` 或相关环境变量文件

原因很简单：很多恢复失败，不是备份文件坏了，而是恢复时直接用了不合适的新版本。

查看镜像版本可以用：

```bash
docker ps --format 'table {{.Names}}\t{{.Image}}'
docker inspect teslamate-teslamate-1 --format '{{.Config.Image}}'
docker inspect teslamate-database-1 --format '{{.Config.Image}}'
```

推荐把这些信息和 `teslamate.dump` 放在同一个备份目录里。

# 二、推荐恢复方案：使用 custom dump 恢复

恢复时的核心原则：

- 尽量恢复到一个全新的 PostgreSQL 数据卷中
- 恢复时先不要让 TeslaMate 应用运行
- 尽量先用和备份来源相同或接近的 TeslaMate 版本启动
- 先确认旧数据恢复成功，再考虑升级到新版本

很多人恢复失败，根本原因不是“不会导入”，而是把下面三种状态混在了一起：

- 旧备份数据
- 新版本迁移结果
- 半初始化状态的数据库结构

所以更稳妥的思路是：先恢复干净数据库，再启动 TeslaMate。

特别注意：新版 TeslaMate 会使用 `private` schema 存放部分敏感表。如果目标数据库之前已经被新版本启动过，或者迁移失败过，里面可能已经有 `private.tokens`。这时再恢复旧备份，TeslaMate 启动迁移时会尝试把 `public.tokens` 移到 `private.tokens`，然后报错：

```text
ERROR 42P07 (duplicate_table) relation "tokens" already exists in schema "private"
```

解决方法不是改 compose，而是在恢复前明确清空 `public` 和 `private` 两个 schema。

## 1. 标准恢复流程

假设：

- PostgreSQL 容器已经创建并运行
- TeslaMate 应用容器先保持停止
- 你要恢复的文件是 `./teslamate.dump`

### 第一步：停止 TeslaMate

```bash
docker stop teslamate-teslamate-1
```

如果你使用的是 `docker compose`，也可以这样停：

```bash
docker compose stop teslamate grafana
docker compose up -d database
```

### 第二步：确认 dump 格式

`pg_dump -Fc` 生成的 custom dump 文件开头通常是 `PGDMP`：

```bash
head -c 5 ./teslamate.dump
echo
```

如果输出是 `PGDMP`，就用 `pg_restore`。如果输出是 `--` 或者能看到 SQL 文本，那是普通 SQL dump，参考后面的“基础命令版恢复”。

### 第三步：清理目标库的 public 和 private schema

```bash
docker exec -i teslamate-database-1 psql -U teslamate -d teslamate <<'SQL'
DROP SCHEMA IF EXISTS public CASCADE;
DROP SCHEMA IF EXISTS private CASCADE;
CREATE SCHEMA public;
CREATE EXTENSION IF NOT EXISTS cube WITH SCHEMA public;
CREATE EXTENSION IF NOT EXISTS earthdistance WITH SCHEMA public;
SQL
```

如果你使用的是 `docker compose` 服务名：

```bash
docker compose exec -T database psql -U teslamate -d teslamate <<'SQL'
DROP SCHEMA IF EXISTS public CASCADE;
DROP SCHEMA IF EXISTS private CASCADE;
CREATE SCHEMA public;
CREATE EXTENSION IF NOT EXISTS cube WITH SCHEMA public;
CREATE EXTENSION IF NOT EXISTS earthdistance WITH SCHEMA public;
SQL
```

这一步是为了避免目标库残留新版本创建的 `private.tokens`，导致恢复后 TeslaMate 迁移失败。

### 第四步：执行 custom dump 恢复

方式 A：先复制到数据库容器内再恢复：

```bash
docker cp ./teslamate.dump teslamate-database-1:/teslamate.dump
docker exec teslamate-database-1 pg_restore -U teslamate -d teslamate --clean --if-exists --no-owner --role=teslamate /teslamate.dump
docker exec teslamate-database-1 rm -f /teslamate.dump
```

方式 B：直接从当前目录管道恢复，适合 `docker compose`：

```bash
cat ./teslamate.dump | docker compose exec -T database pg_restore -U teslamate -d teslamate --clean --if-exists --no-owner --role=teslamate
```

- `pg_restore`：恢复 `pg_dump -Fc` 生成的备份
- `--clean`：恢复前按备份归档里的对象清理旧对象
- `--if-exists`：对象不存在时忽略删除报错
- `--no-owner`：不强制恢复原数据库对象 owner，跨机器迁移更稳
- `--role=teslamate`：用当前环境里的 `teslamate` 角色创建对象
- 前一步手动清理 `private`，是为了处理旧 dump 里没有 `private` schema、但目标库已经残留 `private.tokens` 的情况

### 第五步：启动 TeslaMate

```bash
docker start teslamate-teslamate-1
```

如果使用 `docker compose`：

```bash
docker compose up -d
```

### 第六步：查看日志确认启动状态

```bash
docker logs -f teslamate-teslamate-1
```

如果使用 `docker compose`：

```bash
docker compose logs -f teslamate
```

## 2. 恢复完成后的检查方法

先检查容器是否正常运行：

```bash
docker ps
```

查看 TeslaMate 最近日志：

```bash
docker logs --tail 100 teslamate-teslamate-1
```

如果要进一步检查 PostgreSQL 里的表和迁移记录：

```bash
docker exec -it teslamate-database-1 psql -U teslamate -d teslamate
```

检查表：

```sql
SELECT schemaname, tablename
FROM pg_tables
WHERE schemaname IN ('public', 'private')
ORDER BY schemaname, tablename;
```

检查迁移记录：

```sql
SELECT version FROM schema_migrations ORDER BY version;
```

## 3. 哪些情况下不建议直接恢复到现有库

以下情况，不建议直接往当前数据库硬导入：

- 当前数据库已经被新版本 TeslaMate 初始化过
- 当前数据库已经处于迁移失败状态
- 你不确定目标库是不是空库
- 目标环境已经出现 schema 和 migration 不一致的问题

更稳妥的做法是：

- 删除旧 PostgreSQL 数据卷后重新创建
- 或者新建一个全新的 PostgreSQL 容器或数据卷
- 在 TeslaMate 启动前先完成恢复

# 三、兼容旧教程：基础命令版备份与恢复

如果你只是单机手动操作，也可以继续使用以前这种基础命令方式。  
不过要注意，这种 `.bck` 方式本质是 SQL 文本导出，适合简单场景，不如 `pg_dump -Fc` 稳妥。

## 1. 备份

假设你的目录是：

```bash
cd /home/pi/teslamate
```

执行备份：

```bash
docker compose exec -T database pg_dump -U teslamate teslamate > ./teslamate.bck
```

如果当前目录生成了 `teslamate.bck`，说明备份已完成。

## 2. 恢复

先停止 TeslaMate：

```bash
docker compose stop teslamate
docker compose up -d database
```

重建 schema 和扩展。这里必须同时清理 `public` 和 `private`，否则新版本 TeslaMate 可能会因为 `private.tokens` 已存在而迁移失败：

```bash
docker compose exec -T database psql -U teslamate -d teslamate <<'SQL'
DROP SCHEMA IF EXISTS public CASCADE;
DROP SCHEMA IF EXISTS private CASCADE;
CREATE SCHEMA public;
CREATE EXTENSION IF NOT EXISTS cube WITH SCHEMA public;
CREATE EXTENSION IF NOT EXISTS earthdistance WITH SCHEMA public;
SQL
```

进入备份目录：

```bash
cd /home/pi/teslamate
```

导入备份文件：

```bash
docker compose exec -T database psql -U teslamate -d teslamate < teslamate.bck
```

如果你的文件开头是 `PGDMP`，说明它不是文本 SQL，而是 `pg_dump -Fc` 生成的 custom dump。不要用上面的 `psql < teslamate.bck`，改用：

```bash
cat teslamate.bck | docker compose exec -T database pg_restore -U teslamate -d teslamate --clean --if-exists --no-owner --role=teslamate
```

最后启动 TeslaMate：

```bash
docker compose start teslamate
```

# 四、最佳实践建议

- 每次升级 TeslaMate 或 PostgreSQL 前先做一次完整备份
- 优先使用 `pg_dump -Fc` 和 `pg_restore`
- 尽量不要长期使用 `latest` 标签
- 保留多个历史备份，不要总覆盖一个文件
- 定期做一次恢复演练，不要只备份不验证
- 如果备份比较旧，恢复后优先先用源版本启动，再考虑升级

# 五、一句话原则

使用 `pg_dump -Fc` 备份完整 PostgreSQL 数据库，恢复到干净的数据库环境中，并优先使用与备份来源一致或接近的 TeslaMate 版本启动，整体成功率会高很多。


TeslaMate 数据备份及恢复

问题：由于frpc穿透，获取到的IP地址都是127.0.0.1,在nginx配置上做以下配置

    set_real_ip_from 127.0.0.1;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;


如果 frpc 不在本机，而是从内网某台机器连到这台 Nginx，那就把 127.0.0.1 换成那台 frpc 的内网 IP（或内网网段，如 10.0.0.0/8，但越精确越安全）。
保存后重载 Nginx（宝塔面板“重载配置”即可）。

PS：此问题由cursor修复，

FRPC穿透获取真实IP

### Docker（Linux）稳妥安装说明（国内网络 / Ubuntu & Debian & CentOS）

本文提供一套 **更稳妥** 的 Docker 安装方式：**先下载脚本到本地 → dry-run 预演 → 使用国内镜像安装 →（可选）不自动启动 → 手动验证**。  
脚本来源（两选一，国内更推荐 Gitee）：
- **Gitee（你维护的镜像仓库，国内更稳）**：[`https://gitee.com/yuanfirst/install-docker/blob/master/install-docker.sh`](https://gitee.com/yuanfirst/install-docker/blob/master/install-docker.sh)（下载请用 raw 链接，见下文）
- **Docker 官方**：[`https://get.docker.com/`](https://get.docker.com/)

---

### 适用范围

- **适用系统**：Ubuntu / Debian / CentOS（脚本会自动识别发行版并选择 apt/yum/dnf）。
- **不适用**：
  - Windows 直接执行（此脚本是 Linux 安装脚本）
  - macOS（需要 Docker Desktop）

---

### 安全与稳定性说明（为什么这么做）

- **不使用 `curl | sh`**：先落盘脚本，避免“边下载边执行”不透明风险。
- **先 `--dry-run`**：只打印将执行的命令，先看清楚它会做什么（加源、导入 key、装包、启服务等）。
- **国内网络使用镜像**：脚本内置 `--mirror Aliyun` / `--mirror AzureChinaCloud`，减少下载失败/超时。
- **默认不自动启动（可选）**：用 `--no-autostart` 安装后不立刻启动服务，便于你先检查环境与端口占用。

---

### 一键（推荐）安装命令：从 Gitee 下载脚本 + 阿里云镜像 + 先预演 + 不自动启动

说明：
- 第 1 行：下载脚本到当前目录。
- 第 2 行：dry-run 预演（不改系统）。
- 第 3 行：正式安装（需要 root/sudo），并禁止自动启动。

```bash
set -euo pipefail
# 国内更推荐：从 Gitee raw 下载（注意：不要用 /blob/ 链接）
curl -fsSL https://gitee.com/yuanfirst/install-docker/raw/master/install-docker.sh -o install-docker.sh
sh install-docker.sh --dry-run --mirror Aliyun
sudo sh install-docker.sh --mirror Aliyun --no-autostart
```

---

### 备用方案 A：Azure 中国镜像（当 Aliyun 不通时）

```bash
set -euo pipefail
curl -fsSL https://gitee.com/yuanfirst/install-docker/raw/master/install-docker.sh -o install-docker.sh
sh install-docker.sh --dry-run --mirror AzureChinaCloud
sudo sh install-docker.sh --mirror AzureChinaCloud --no-autostart
```

---

### 备用方案 B：仍从 Docker 官方下载脚本（当 Gitee 不通时）

```bash
set -euo pipefail
curl -fsSL https://get.docker.com -o install-docker.sh
sh install-docker.sh --dry-run --mirror Aliyun
sudo sh install-docker.sh --mirror Aliyun --no-autostart
```

---

### 安装后：手动启动与验证（推荐）

```bash
sudo systemctl enable --now docker
docker version
docker info
```

如果你希望普通用户也能直接使用 docker（可选）：

```bash
sudo usermod -aG docker $USER
newgrp docker
docker ps
```

---

### （可选）固定版本安装（避免未来自动装到新大版本）

脚本支持 `--version <VERSION>`（例如 `23.0`）。  
注意：不同发行版仓库可用版本不同；如果指定版本不存在，脚本会报错并退出。

示例（以 23.0 为例）：

```bash
set -euo pipefail
curl -fsSL https://gitee.com/yuanfirst/install-docker/raw/master/install-docker.sh -o install-docker.sh
sh install-docker.sh --dry-run --mirror Aliyun --version 23.0
sudo sh install-docker.sh --mirror Aliyun --version 23.0 --no-autostart
```

---

### 常见问题

- **Q1：脚本提示系统已装过 docker？**
  - 脚本会提示你可以 Ctrl+C 中止，避免覆盖你已有配置。
  - 建议先确认当前版本：`docker version`，再决定是否继续。

- **Q2：安装时下载慢/超时？**
  - 先改用镜像：`--mirror Aliyun` 或 `--mirror AzureChinaCloud`。
  - 确认 DNS/网络出口正常。

- **Q3：`systemctl` 不存在/无法启服务？**
  - 可能是容器环境、精简系统或非 systemd；此时需要用对应 init 系统启动 docker，或改用 Docker 的替代安装方式。

- **Q4：安装完成但 `docker ps` 提示权限不足？**
  - 用 `sudo docker ps` 验证服务是否正常。
  - 需要非 root 使用时按上文把用户加入 `docker` 组，并重新登录/`newgrp docker`。

---

### 最佳实践建议（生产环境）

- 生产/关键机器建议按 Docker 官方文档做更可控的安装：校验 key 指纹、明确仓库与版本策略，而不是依赖一键脚本。  
- 脚本说明中也明确“不建议生产环境直接使用此脚本”。来源：[`https://get.docker.com/`](https://get.docker.com/)




Docker安装-稳妥执行命令

# 修改Docker存储目录：Docker存储路径Docker数据迁移Docker存储位置/etc/docker/daemon.json、docker占用docker容量docker迁移data-root


#### 文章目录

  * 如何更改docker默认存储路径？
  *     * 版本1（我没测试，先别用！）
    * 版本2（可行）
    *       * 1\. 停止 Docker 服务：
      * 2\. 创建新的存储目录：
      * 3\. 修改 Docker 配置文件：
      * 4\. 移动现有的 Docker 数据：
      *         * `rsync -aP /var/lib/docker/ /data/docker`命令解析
        *           * 命令解析
          * 使用场景
          * 命令功能
          * 常见用途
      * 5\. 重新启动 Docker 服务：
      * 6\. 验证修改
      * 7\. 真实验证（记录各时间点和存储占用）
      *         * Thu 11 Jul 2024 01:33:57 PM CST（`/`Available 27445M）
        * Thu 11 Jul 2024 04:04:38 PM CST（`/`Available 27444M）
        * Fri 12 Jul 2024 01:51:59 PM CST（`/`Available 27444M）
  * 为什么存在以上两种修改方法，有何异同？（修改`etc/systemd/system/docker.service.d/override.conf`和修改`etc/docker/daemon.json` ）
  * 20240830 另外一个，docker.service文件也可能对配置存储目录造成影响，这似乎是老版本配置



## 如何更改docker默认存储路径？

### 版本1（我没测试，先别用！）

默认情况下，Docker 在 Linux 上安装时会将其数据（如镜像和容器）存储在 `/var/lib/docker` 目录下，这个目录通常位于根分区 `/`。如果你的根分区 `/` 的空间不足，你可以考虑将 Docker 的数据目录移动到其他分区，或者在安装 Docker 时直接配置它使用其他分区。

要更改 Docker 的默认存储位置，你可以通过修改 Docker 的配置文件或在启动 Docker 服务时设置环境变量来指定新的数据目录。下面是一些步骤说明如何进行配置：

  1. 停止 Docker 服务：
         
         sudo systemctl stop docker
         


![2025-12-16_142315.jpg](/static/img/edd59ad3ddbe9af594a0d744b36a0a47.2025-12-16_142315.webp)
  2. 修改 Docker 配置文件（如果你使用的是 systemd）：

     * 打开或创建 Docker 的 systemd 配置文件（一开始没有这个文件是正常的）：
           
           sudo vi /etc/systemd/system/docker.service.d/override.conf
           

     * 添加以下内容来指定新的数据目录，假设你想将数据存储在 `/mnt/docker/`：
           
           [Service]
           ExecStart=
           ExecStart=/usr/bin/dockerd --data-root /mnt/docker -H fd:// --containerd=/run/containerd/containerd.sock
           

     * 保存并关闭文件。
  3. 重新加载 systemd 配置并重新启动 Docker 服务：
         
         sudo systemctl daemon-reload
         sudo systemctl start docker
         

  4. 检查 Docker 是否使用新的数据目录：
         
         docker info | grep "Docker Root Dir"
         




确保新的数据目录所在的分区有足够的空间，以避免在使用 Docker 时遇到空间不足的问题。

### 版本2（可行）

要修改 Docker 的存储路径至 `/data/docker`，您可以按照以下步骤操作：

#### 1\. 停止 Docker 服务：

打开终端，使用以下命令停止 Docker 服务：
    
    
    sudo systemctl stop docker.socket
    sudo systemctl stop docker
    

一开始只执行一条停不了：  

![2025-12-16_142424.jpg](/static/img/1c921979d2e49d5f548349f6a77f06bf.2025-12-16_142424.webp)
 
![2025-12-16_142524.jpg](/static/img/35dc26bb17a68d95d9e14c7d6548cf45.2025-12-16_142524.webp)
后面两条执行就能停了：

![2025-12-16_142603.jpg](/static/img/fd9318486e5193ba1b732094cb981e43.2025-12-16_142603.webp)

#### 2\. 创建新的存储目录：

如果 `/data/docker` 目录还不存在，使用以下命令创建它：
    
    
    sudo mkdir -p /data/docker
    

#### 3\. 修改 Docker 配置文件：

编辑 Docker 的 daemon 配置文件 `/etc/docker/daemon.json`。如果该文件不存在，您需要创建它。
    
    
    sudo vi /etc/docker/daemon.json
    

在文件中添加或修改以下内容：
    
    
    {
      "data-root": "/data/docker"
    }
    

保存并关闭文件。

* * *

注意：某些设备，比如我的盒子，打开后是这样的：

![2025-12-16_142640.jpg](/static/img/6ca446d3a1e0fa0bcda3264e5c097104.2025-12-16_142640.webp)

添加后变这样：


![2025-12-16_142701.jpg](/static/img/f09e16eae38c106093272eb2f9e1dc85.2025-12-16_142701.webp)

#### 4\. 移动现有的 Docker 数据：

如果您的 Docker 安装中已经有数据，并且您希望保留这些数据，可以将现有的数据移动到新的目录：
    
    
    sudo rsync -aP /var/lib/docker/ /data/docker
    

![2025-12-16_142733.jpg](/static/img/6eadd0e81e9948323fe45cd5ab5d9969.2025-12-16_142733.webp)

##### `rsync -aP /var/lib/docker/ /data/docker`命令解析

这个命令使用`rsync`工具来同步文件和目录，具体用法如下：

###### 命令解析

  * `rsync`: 是一种非常强大的文件和目录同步工具，常用于备份和镜像。
  * `-aP`: 这是`rsync`命令中的选项，通常组合使用来达到特定的同步效果。 
    * `-a`（–archive）: 这个选项是多个选项的组合，主要包括保持符号链接（-l），保持权限（-p），保持文件时间戳（-t），保持用户和组信息（-o和-g），以及递归复制目录（-r）。简单来说，就是以“归档模式”来复制，尽量保持原有文件的属性和结构。
    * `-P`: 这个选项是`--partial --progress`的简写，允许部分文件传输和显示传输过程中的进度信息。如果传输被中断，已传输的部分不会被删除，下次传输时会从中断处继续。显示进度信息可以让用户知道当前传输状态。



###### 使用场景

  * `/var/lib/docker/`: 这是Docker的默认数据存储目录，包括容器、镜像、卷等数据。
  * `/data/docker`: 这是目标目录，你想将Docker数据同步到这个位置。



###### 命令功能

这个命令的功能是将`/var/lib/docker/`目录中的所有内容（包括文件和子目录）同步到`/data/docker`目录中。同步过程会尽量保留所有文件的属性和结构，如文件的权限、时间戳、用户组信息等，同时在传输过程中显示进度，并允许中断后的续传。

###### 常见用途

这个命令常用于以下几种情况：

  * **数据迁移** ：当你想将Docker数据从一个硬盘迁移到另一个更大或更快的硬盘时。
  * **备份** ：定期备份Docker数据，以防数据丢失或损坏。
  * **数据同步** ：在多个系统或位置保持Docker数据的一致性。



这个命令是管理和维护Docker环境时一个非常实用的工具，可以有效地帮助管理员管理大量的容器数据。

#### 5\. 重新启动 Docker 服务：

使用以下命令重新启动 Docker 服务：
    
    
    sudo systemctl start docker.socket
    sudo systemctl start docker
    

#### 6\. 验证修改

检查 Docker 是否正确使用新的存储路径，可以查看 Docker 信息：
    
    
    docker info | grep 'Docker Root Dir'
    

![2025-12-16_142800.jpg](/static/img/92c707c3ef070a08c52941f9f97b6a26.2025-12-16_142800.webp)

现在 Docker 已经成功地使用 `/data/docker` 作为其根目录了。至于您看到的警告信息 “WARNING: No swap limit support”，这是一个常见的信息，指的是您的 Linux 系统上没有启用内存交换限制的支持。

在 Docker 中，这种警告通常不会影响 Docker 容器的正常运行，它只意味着 Docker 无法强制限制容器的交换内存使用量。这通常与 Linux 内核的某些配置有关，特别是 cgroup 的配置。

注意：如果不放心，可以执行`mv /var/lib/docker /var/lib/docker_old`备份检测下

#### 7\. 真实验证（记录各时间点和存储占用）

通过使用一下两条命令：
    
    
    date
    df -BM
    

##### Thu 11 Jul 2024 01:33:57 PM CST（`/`Available 27445M）
    
    
    root@ai-video-ecs-01:/userdata/tmp# date
    Thu 11 Jul 2024 01:33:57 PM CST
    root@ai-video-ecs-01:/userdata/tmp#
    root@ai-video-ecs-01:/userdata/tmp#
    root@ai-video-ecs-01:/userdata/tmp# df -BM
    Filesystem                        1M-blocks  Used Available Use% Mounted on
    udev                                 32078M    0M    32078M   0% /dev
    tmpfs                                 6425M    4M     6422M   1% /run
    /dev/mapper/ubuntu--vg-ubuntu--lv    38122M 8911M    27445M  25% /
    tmpfs                                32124M    0M    32124M   0% /dev/shm
    tmpfs                                    5M    0M        5M   0% /run/lock
    tmpfs                                32124M    0M    32124M   0% /sys/fs/cgroup
    /dev/loop1                              64M   64M        0M 100% /snap/core20/2318
    /dev/loop0                              64M   64M        0M 100% /snap/core20/1828
    /dev/loop2                              50M   50M        0M 100% /snap/snapd/18357
    /dev/loop3                              39M   39M        0M 100% /snap/snapd/21759
    /dev/vda2                             1946M  109M     1719M   6% /boot
    /dev/loop4                              92M   92M        0M 100% /snap/lxd/24061
    /dev/sda1                           749867M 4140M   707565M   1% /ky
    /dev/sda2                          9401234M 2884M  8924482M   1% /data
    tmpfs                                 6425M    0M     6425M   0% /run/user/1000
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/c385332babdae4ee85601ffa1dd1ebe6c36fc1f618389ace09b2051731d5fa8c/merged
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/31a24b6f39c2ea25d700754b5c9ea78574e772589690437fd60e4b60fac15c0c/merged
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/88149e56439d9bad5b2b785f12ff77b6052c5ba369f53f9e12a38698c34615ce/merged
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/b2171ae8eaa2b4b6bf61de50165b2e885f6e2d4373d02fd1e492cc1d2158bd9b/merged
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/3e9af67e01934706a6712e2a6601292b105c26d5fecf82218f8d7ef65ca30b3d/merged
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/341e8bc8f48a17d24ee4005c45cda9e121bececd2b0fea5463b337acbce64f04/merged
    overlay                            9401234M 2884M  8924482M   1% /data/docker/overlay2/6ee97fa0e1597535d0d70be41d5a3220c6f58ff033dba5388a53034afbeb8f5f/merged
    root@ai-video-ecs-01:/userdata/tmp#
    
    

##### Thu 11 Jul 2024 04:04:38 PM CST（`/`Available 27444M）
    
    
    hw@ai-video-ecs-01:~$ date
    Thu 11 Jul 2024 04:04:38 PM CST
    hw@ai-video-ecs-01:~$
    hw@ai-video-ecs-01:~$ df -BM
    Filesystem                        1M-blocks  Used Available Use% Mounted on
    udev                                 32078M    0M    32078M   0% /dev
    tmpfs                                 6425M    4M     6422M   1% /run
    /dev/mapper/ubuntu--vg-ubuntu--lv    38122M 8911M    27444M  25% /
    tmpfs                                32124M    0M    32124M   0% /dev/shm
    tmpfs                                    5M    0M        5M   0% /run/lock
    tmpfs                                32124M    0M    32124M   0% /sys/fs/cgroup
    /dev/loop1                              64M   64M        0M 100% /snap/core20/2318
    /dev/loop0                              64M   64M        0M 100% /snap/core20/1828
    /dev/loop2                              50M   50M        0M 100% /snap/snapd/18357
    /dev/loop3                              39M   39M        0M 100% /snap/snapd/21759
    /dev/vda2                             1946M  109M     1719M   6% /boot
    /dev/loop4                              92M   92M        0M 100% /snap/lxd/24061
    /dev/sda1                           749867M 4141M   707564M   1% /ky
    /dev/sda2                          9401234M 2886M  8924479M   1% /data
    tmpfs                                 6425M    0M     6425M   0% /run/user/1000
    

##### Fri 12 Jul 2024 01:51:59 PM CST（`/`Available 27444M）
    
    
    root@ai-video-ecs-01:/userdata/tmp# date
    Fri 12 Jul 2024 01:51:59 PM CST
    root@ai-video-ecs-01:/userdata/tmp#
    root@ai-video-ecs-01:/userdata/tmp# df -BM
    Filesystem                        1M-blocks  Used Available Use% Mounted on
    udev                                 32078M    0M    32078M   0% /dev
    tmpfs                                 6425M    4M     6422M   1% /run
    /dev/mapper/ubuntu--vg-ubuntu--lv    38122M 8911M    27444M  25% /
    tmpfs                                32124M    0M    32124M   0% /dev/shm
    tmpfs                                    5M    0M        5M   0% /run/lock
    tmpfs                                32124M    0M    32124M   0% /sys/fs/cgroup
    /dev/loop1                              64M   64M        0M 100% /snap/core20/2318
    /dev/loop0                              64M   64M        0M 100% /snap/core20/1828
    /dev/loop2                              50M   50M        0M 100% /snap/snapd/18357
    /dev/loop3                              39M   39M        0M 100% /snap/snapd/21759
    /dev/vda2                             1946M  109M     1719M   6% /boot
    /dev/loop4                              92M   92M        0M 100% /snap/lxd/24061
    /dev/sda1                           749867M 4154M   707550M   1% /ky
    /dev/sda2                          9401234M 2903M  8924463M   1% /data
    tmpfs                                 6425M    0M     6425M   0% /run/user/1000
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/c385332babdae4ee85601ffa1dd1ebe6c36fc1f618389ace09b2051731d5fa8c/merged
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/31a24b6f39c2ea25d700754b5c9ea78574e772589690437fd60e4b60fac15c0c/merged
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/88149e56439d9bad5b2b785f12ff77b6052c5ba369f53f9e12a38698c34615ce/merged
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/b2171ae8eaa2b4b6bf61de50165b2e885f6e2d4373d02fd1e492cc1d2158bd9b/merged
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/3e9af67e01934706a6712e2a6601292b105c26d5fecf82218f8d7ef65ca30b3d/merged
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/341e8bc8f48a17d24ee4005c45cda9e121bececd2b0fea5463b337acbce64f04/merged
    overlay                            9401234M 2903M  8924463M   1% /data/docker/overlay2/6ee97fa0e1597535d0d70be41d5a3220c6f58ff033dba5388a53034afbeb8f5f/merged
    root@ai-video-ecs-01:/userdata/tmp#
    
    

## 为什么存在以上两种修改方法，有何异同？（修改`etc/systemd/system/docker.service.d/override.conf`和修改`etc/docker/daemon.json` ）

在修改 Docker 的存储位置时，可以通过修改 `etc/docker/daemon.json` 或 `etc/systemd/system/docker.service.d/override.conf` 来实现，两种方式都是正确的，但它们有不同的用途和适用情况：

  1. **修改`/etc/docker/daemon.json`**：

     * 这种方法通过 Docker 的配置文件来设置 Docker 的默认行为，包括存储位置、日志级别、网络配置等。
     * 要修改存储位置，你可以在 `daemon.json` 文件中设置 `data-root` 属性，指向新的存储路径。例如：
           
           {
             "data-root": "/new/path/to/docker-data"
           }
           

     * 这种方法的优点是配置简单，且直接通过 Docker 自己的配置文件进行管理，易于理解和维护。
  2. **修改`/etc/systemd/system/docker.service.d/override.conf`**：

     * 这种方法适用于在使用 systemd 管理 Docker 服务的系统上。通过 systemd 的配置覆盖文件来修改 Docker 服务的启动参数。
     * 你可以通过创建或修改 `override.conf` 文件，添加一个新的 `ExecStart` 行，指定新的存储位置。例如：
           
           [Service]
           ExecStart=
           ExecStart=/usr/bin/dockerd --data-root /new/path/to/docker-data
           

     * 注意，需要先清空原有的 `ExecStart` 设置（`ExecStart=`），然后重新定义。这样可以确保使用你的自定义设置启动 Docker。
     * 这种方法允许你对 Docker 的启动过程进行更细粒度的控制，但相对复杂，需要对 systemd 的配置有一定了解。



**总结** ：选择哪种方法取决于你的具体需求和你对系统的控制级别。如果你希望通过 Docker 自身的配置来管理，使用 `daemon.json` 是更直接的方法。如果你需要更复杂的配置或者想要控制服务的启动参数，使用 systemd 的 `override.conf` 方法会更合适。

## 20240830 另外一个，docker.service文件也可能对配置存储目录造成影响，这似乎是老版本配置



修改Docker存储目录：Docker存储路径Docker数据迁移Docker存储位置/etc/docker/daemon.json、docker占用docker容量docker迁移data-root_docker修改存储路径-CSDN博客