我已将目录更改为将容器和图像存储为<ul>
<li ng-repeat="hotel in vm.hotels">
̶<̶a̶ ̶n̶g̶-̶h̶r̶e̶f̶=̶"̶#̶/̶h̶o̶t̶e̶l̶/̶{̶{̶ ̶h̶o̶t̶e̶l̶.̶_̶i̶d̶ ̶}̶}̶"̶>̶{̶{̶ ̶h̶o̶t̶e̶l̶.̶n̶a̶m̶e̶ ̶}̶}̶<̶/̶a̶>̶
<a ng-href="#!/hotel/{{ hotel._id }}">{{ hotel.name }}</a>
</li>
</ul>
。在接下来的一年中，它可以成功运行。
但是，我重新启动系统（Ubuntu 16.04）后，磁盘分区/data/docker损坏了，该磁盘分区已装载到/dev/sdb4。损坏的分区导致系统进入紧急模式。我运行命令/data/docker对其进行修复，然后再次重新启动。
重启后，除docker以外，其他所有工作均正常。令人惊讶的是，我所有的容器和几乎所有的图像都丢失了。当我运行fsck -y /dev/sdb4时，我什么也没得到。运行docker container ls -a时，我只有一个列表docker images。但是我之前有 4个容器和一些（不止一个）图像。换句话说，它们在重新启动后就消失了。
此外，当我运行mysql 5.6 7edb93321b06 5 months ago 256MB时，我得到了：
6.8M / data / docker / volumes / b35a0a2be6a1d10693e891f0b5c7dfa6e27a34b6a61384e6db79ac06df4bde36 / _data / mysql 636K / data / docker / volumes / b35a0a2be6a1d10693e891f0b5c7dfa6e27a34b6a61384e6db79ac06df4bde36 / _data / performance_schema 116M / data / docker / volumes / b35a0a2be6a1d10693e891f0b5c7dfa6e27a34b6a61384e6db79ac06df4bde36 / _data 116M / data / docker / volumes / b35a0a2be6a1d10693e891f0b5c7dfa6e27a34b6a61384e6db79ac06df4bde36 4.0K / data / docker / volumes / 4bfb7ca010e869edd409ee14aa3a8b9ec70ec144a1b1586e792a8f87f9d5a9b2 / _data 8.0K / data / docker / volumes / 4bfb7ca010e869edd409ee14aa3a8b9ec70ec144a1b1586e792a8f87f9d5a9b2 4.0K / data / docker / volumes / d24ddf0126cef08bc3ff8bf75e79e76375b1e6cfa70c646d3173554d78555aeb / _data 8.0K / data / docker / volumes / d24ddf0126cef08bc3ff8bf75e79e76375b1e6cfa70c646d3173554d78555aeb 4.0K / data / docker / volumes / c22f29c1ab50c2973e6e1cc3e1ea64ad7a253741d44a290df3789fbf1e4c3a05 / _data 8.0K / data / docker / volumes / c22f29c1ab50c2973e6e1cc3e1ea64ad7a253741d44a290df3789fbf1e4c3a05 4.0K / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 / _data /＃innodb_temp 84K / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 / _data / sys 32K / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 / _data / mysql 84K / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 / _data / test 1.4M / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 / _data / performance_schema 165M / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 / _data 165M / data / docker / volumes / 985f51b406657eacbd70dfe7d0bd0502287c783a389ae34fa36d70b5c98e94a3 3.1G / data / docker / volumes / b445468b292cff4531429b7a9883a825fc794327a46672ec518e7765050437e5 / _data / newProject 6.8M / data / docker / volumes / b445468b292cff4531429b7a9883a825fc794327a46672ec518e7765050437e5 / _data / mysql 387M / data / docker / volumes / b445468b292cff4531429b7a9883a825fc794327a46672ec518e7765050437e5 / _data / project 636K / data / docker / volumes / b445468b292cff4531429b7a9883a825fc794327a46672ec518e7765050437e5 / _data / performance_schema 4.0G / data / docker / volumes / b445468b292cff4531429b7a9883a825fc794327a46672ec518e7765050437e5 / _data 4.0G / data / docker / volumes / b445468b292cff4531429b7a9883a825fc794327a46672ec518e7765050437e5 4.2G / data / docker / volumes
这意味着某些数据不会丢失。
如何修复并找到它们？