前言

故事发生在一个夜黑风高的晚上，一通看着不怎么寻常的电话过来，说是业务赶着上线，但他们的API包上传不了到公司的maven私库，领导叫我支撑下看怎么解决。经过多年不怎么靠谱的直觉，应该是磁盘满了。于是利索地敲下

df -lh

果然磁盘满了，其中/var/lib/docker/overlay 这个玩意儿基本上把磁盘占满。接着输入

docker system df

查看docker所占的磁盘大小。在思考是申请流程单叫运维扩容下磁盘，还是手动清理下磁盘的时候，电话再次过来，说找到问题没，能不能赶紧解决。接完电话后，心情莫名烦躁，于是敲下了如下命令

docker system prune

这个命令可以用于清理磁盘，删除关闭的容器、无用的数据卷和网络，以及dangling镜像(即无tag的镜像)。接着一通电话又过来，说gitlab访问不了，我当时给的答案是磁盘满了，gitlab应该是停止了，我稍等重启下gitlab容器，就在我打算重启gitlab时，敲下命令

docker ps -a

想捞一下gitlab容器，然后完犊子了，docker ps -a 看不到任何容器。因为之前gitlab的容器是前架构师安装，我压根就不清楚他当时是以什么形式安装，于是就把这个问题反馈给领导，通过领导拿到当时启动gitlab的docker-compose.yml.样例如下

version: '2'

services:
  redis:
    restart: always
    container_name: gitlab_redis
    image: sameersbn/redis:latest
    command:
    - --loglevel warning
    volumes:
    - /usr/local/docker/gitlab/redis:/var/lib/redis:Z
    network_mode: bridge

  postgresql:
    restart: always
    container_name: gitlab_postgresql
    image: sameersbn/postgresql:9.6-2
    volumes:
    - /usr/local/docker/gitlab/postgresql:/var/lib/postgresql:Z
    environment:
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production
    - DB_EXTENSION=pg_trgm
    network_mode: bridge

  gitlab:
    restart: always
    container_name: gitlab
    image: sameersbn/gitlab:10.4.2-1
    links:
    - redis
    - postgresql
    network_mode: bridge
    ports:
    - "10080:80"
    - "10022:22"
    volumes:
    - /usr/local/docker/gitlab/gitlab:/home/git/data:Z
    environment:
    - DEBUG=false

    - DB_ADAPTER=postgresql
    - DB_HOST=postgresql
    - DB_PORT=5432
    - DB_USER=gitlab
    - DB_PASS=password
    - DB_NAME=gitlabhq_production

    - REDIS_HOST=redis
    - REDIS_PORT=6379

    - TZ=Asia/Shanghai
    - GITLAB_TIMEZONE=Beijing

    - GITLAB_HTTPS=false
    - SSL_SELF_SIGNED=false

    - GITLAB_HOST=gitlab.common.com
    - GITLAB_PORT=
    - GITLAB_SSH_PORT=10022
    - GITLAB_RELATIVE_URL_ROOT=

看了一下文件，我看到有做文件目录挂载，然后我就去挂载的文件目录下，看文件有没有在，还好文件都在，于是我就放心敲下

docker-compose -f gitlab.yml up -d

这命令一敲下，复盘之路华丽的拉开了序幕…

正文

在我敲下命令，看到容器都显示正常启动，打算继续清理磁盘之时，突然微信接到好几个开发人员的信息，说他们gitlab登陆，都显示用户或者密码无效，于是我也用我的账号，我的账号可是管理员账号，哈哈，一股王八之气，在界面上输入我那耳熟能详的用户名和密码，出乎意料的提示我的用户名或者密码无效，心里莫名有点慌，感觉我干了一件挺了不得的大事。

事情有点超出我的认知，在我看来如果有做了挂载，正常不会出现数据丢失才对，于是就找朋友救急，后面和他交流一下，就是先用备份数据还原，如果有备份的话。然后我在挂载gitlab的目录下，看到backups目录，看到里面的tar，突然有一种挖到宝藏的感觉，但宝藏有了，开宝藏的钥匙在哪里，我要如何把备份的数据恢复回来呢。因为我对sameersbn也不了解，于是就去他们的github找了下，他们的github链接如下

https://github.com/sameersbn/docker-gitlab

通过他们的github找到如下介绍

When using docker-compose you may use the following command to execute the restore.

docker-compose run --rm gitlab app:rake gitlab:backup:restore # List available backups
docker-compose run --rm gitlab app:rake gitlab:backup:restore BACKUP=1515629493_2020_12_06_13.10.0 # Choose to restore from 1515629493

照猫画虎，敲下如下命令

docker-compose -f gitlab.yml run --rm gitlab app:rake gitlab:backup:restore

大约过了一首歌的时间，我再次打开gitlab登录界面，怀着忐忑的心情，输入用户名密码，很惊喜的发现登录成功了，看一下仓库，都还在

总结

罗里吧嗦说了一堆，其实总结出来就几句话，就是备份，备份，备份，重要的事情说三遍，其次在做一些可能删数据或者改变数据的命令，要小心，小心，再小心。最后遇到问题，如果谷歌百度都找不到答案，记得去官方网站或者他们的github网站找找答案，比如sameersbn-gitlab链接
https://github.com/sameersbn/docker-gitlab