web-dev-qa-db-ja.com

バックアップDockerボリューム-単純なtarアーカイブでは不十分ですか？

3つのマシンで複数のDockerコンテナーを実行して、Swarmクラスターを構成しています。

永続データを格納する一部のコンテナ（DB、Redisなど）はデータボリュームを使用します。 （私は可能な限りbind-mountの使用を避けようとしました）

このようなデータボリュームは/ var/lib/docker/volumes /にあり、すべてのボリュームにはランダムシーケンスIDではなくカスタマイズされた名前が割り当てられています。

# ls /var/lib/docker/volumes/
redis-data   postgres-data   fluentd-data ...

これらのボリュームを定期的に、たとえば毎日バックアップして、マシンの障害が発生したときに復元して後で修正できるようにしたいと考えています。

ただし、Googleで見つけたすべてのドキュメントは、新しいLinuxコンテナとtarの使用方法を示しています。

https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes

$ docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata

どうして？単純にアーカイブしても問題ありません/var/lib/docker/volumes/VOLUMEディレクトリを作成し、他のマシンにコピーしますか？たとえば、許可、uid、gidなどですか？

$ tar -zcvf redis.tgz /var/lib/docker/volumes/redis-data

追伸.

tarを使用したバックアップでは、アーカイブ中のデータの変更が原因でデータの不整合が発生する場合があります。たとえば、DBがまだ実行中で、insertsまたはupdatesが実行されているときにDBデータディレクトリをアーカイブする...しかし、この問題は両方のアプローチに同じように適用されると思います。

dockerbackupdocker-volume
16
gypark

名前付きボリュームは、/ var/lib/dockerの外部にデータを格納できます。例えば。名前付きバインドマウントは次のコマンドで作成できます。

  $ docker volume create --driver local \
      --opt type=none \
      --opt device=/home/user/test \
      --opt o=bind \
      test_vol

または、NFSマウントの場合は次のようになります。

  $ docker volume create --driver local \
      --opt type=nfs \
      --opt o=nfsvers=4,addr=nfs.example.com,rw \
      --opt device=:/path/to/dir \
      foo

これらのシナリオでは、tarバックアップはコンテナーと同じ方法でデータにアクセスするため、名前付きボリュームの作成方法に関係なくバックアップを実行します。また、他のコンテナーだけでなく、アプリケーションの移動先でも使用できる共通の形式にデータを効率的にエクスポートします。

より直接的なバックアップのために、ボリュームの内容をより詳細に制御する必要がある場合は、名前付きバインドマウントは名前付きボリュームとホストマウントの中間点です。ディレクトリをコンテナーへの名前付きボリュームとして扱いますが、含まれるデータはバックアップするホスト上の別のディレクトリとして扱います。

個人的には、/ var/lib/dockerをブラックボックスとして扱う傾向があります。内容は非常に読みやすいですが、Dockerはバージョン間で自由に移行したり変更したりできますが、ユーザーが使用するAPIの一貫性は維持する必要があります。コンテナー化されたイメージ管理のようなものに移行する場合、変更する必要のあるものが少なければ少ないほど良いです。

4
BMitch

実際、これはパターンです。データのみのコンテナです。

アイデアは、ストレージ専用のDockerイメージとアプリケーション専用のDockerイメージを用意することです。データが物理的に保存される場所に注意を払うことは、落とし穴です。

データがDocker化されたインフラストラクチャに正しく保存されていることを知っている必要があります。どこではない。そして、Dockerを使用してデータのダンプを作成します。 cpやtarコマンドを直接使用することはできません。

[〜＃〜]編集[〜＃〜]

データのみのコンテナーは、Dockerボリュームが完全に問題がある場合に便利なパターンでした。ただし、考え方は同じです（この種のインフラストラクチャでは、データの保存場所に注意する必要はありません）。

Docker Volumes を参照してください：

ボリュームは、データを永続化するための推奨メカニズムです...

3
Max

結果に気づき、システムの内部に依存することによってリスクを取る意思がある限り、問題はありません。しかし、それほど複雑ではない同じ操作を実現するための文書化されたアプローチがあるときに、なぜそのリスクを冒したいのでしょうか。

私があなただったら、文書化されたアプローチを使用して、製品が進化するにつれてメンテナンスサイクルを回避します。

Dockerがマウントポイントの場所を変更するか、構成可能なオプションとして提供することにした場合、文書化されていないバックアップデータへのアプローチは失敗します。

1
shnkr