復元できない場合、バックアップは適切ではありませんというフレーズを聞いたことがあるかもしれません。 。
クラウドサーバー上で重要なファイルのバックアップを行うには、さまざまな方法があります。ただし、ローカルにこれらのファイルの更新されたコピーが常にあることも重要です。 システム。
それらをクラウドにバックアップすることは問題ありません。ただし、真のバックアップとは、常に更新された最新のコピーであり、いつでも利用できます。なんで？それはあなたのデータだからです！
この点に関して私が取り組む2つの課題は ：
- バックアップを実行するときにデータ（特にデータベース）が破損する可能性を回避するために、運用サーバーでDockerコンテナーを停止する必要があります。ライブプロダクションコンテナ上のファイルは継続的に書き込まれています。
- Dockerコンテナを停止するとダウンタイムも発生するため、特に本番環境にいる場合は、ダウンタイムを発生させる余裕がありません。
これらの問題は、単一サーバーの代わりにクラスターを使用することで解決できます。ただし、ここでは、クラスターではなく単一のサーバーに焦点を当てています クラウドサービスの支出を可能な限り低く抑えるため。
私は、上記の2つの課題にどのように対処するかを考え続けました。それから、クラウドとローカライズされたソリューションの両方を組み合わせて利用できることに気づきました。
クラウドベースのソリューションとは、Linode、DigitalOceanなどのクラウドサービスプロバイダーによって提供されるバックアップサービスを意味します。このウォークスルーでは、Linodeを使用します。
ローカライズされたソリューションとは、コマンドラインまたはGUIベースのツールを使用して、クラウドサーバーからローカルシステム/デスクトップにバックアップをダウンロードすることを意味します。ここでは、sftp（コマンドベース）を使用しました。
最初に、バックアップの実行方法について説明し、次にバックアップの復元方法についても説明します。
最初にバックアップ手順を見てみましょう。
Linode本番サーバーでバックアップを有効にします（まだ行っていない場合）
Linodeで本番サーバーを使用している場合は、最初にデプロイするたびにバックアップを有効にすることを強くお勧めします。 「nanode」と呼ばれるものは、1 GBのRAMが付属し、次のバックアッププランを提供します。
他のすべてのバックアップソリューションは、同様の機能を提供しますが、より高いレートで提供されます。有効になっていることを確認してください。
後で参照できるように日付を入力します。ここでは、「manual-snapshot-11-05-21」と呼んでいます。
クリックするとすぐに確認を求められます：
確認すると、右下に通知が表示されます：
サーバーが稼働していることを示す場所（左上）の横にある同じページで進行状況を監視できます：
完了すると、バックアップがリストの4番目に表示されます。
Linodeのパネルから（以前にスケジュールされたバックアップに基づいて）サーバーを直接複製することもできますが、上記の手順で説明したように手動バックアップを使用することをお勧めします。
したがって、作成した最新の手動バックアップに基づいてクローンの作成を続行するには、以下の手順に必ず従ってください。
Linodeパネルに移動し、「作成」をクリックします：
「Linode」を選択します：
[バックアップ]タブを選択します：
取得しているスナップショットは2GBのLinodeに基づいていることに注意してください。作成した手動スナップショットを選択します：
ここで、クローンに同じ仕様（2 GB Linodeプラン）を選択していることを確認してください：
本番サーバーのバックアップに基づいて新しいサーバーを作成すると、本番サーバーのクローンをすぐに利用できるようになります。
ssh経由でクローンにログインし、すべてのコンテナを停止します
sshを介して新しいクローンにログインする際に問題が発生することはありません。これは、本番サーバーと同じ公開キーを使用するためです。クローンの新しいIPを使用する必要があります。 sshを単独で使用し、パスワードベースの認証を無効にしていると思いますね。まだ読んでいない場合は、このsshセキュリティガイドをお読みください。
ログインしたら、データをバックアップするすべてのコンテナを停止します。通常、それぞれのアプリディレクトリに移動し、docker-composedownコマンドを使用します。通常の本番環境では、従来のdocker stopの代わりにDockerComposeを使用することが常に期待されます。 テスト中にのみ優先されるコマンド。
たとえば、Ghostを対応するデータベースコンテナで実行している場合、最初にそれぞれの情報を確認します。
[email protected]:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
6a3aafe12434 ghost:4.4.0 "docker-entrypoint.s…" 7 days ago Up 7 days 2368/tcp ghost_ghost_2
95c560c0dbc7 jrcs/letsencrypt-nginx-proxy-companion "/bin/bash /app/entr…" 6 weeks ago Up 10 days letsencrypt-proxy-companion
6679bd4596ba jwilder/nginx-proxy "/app/docker-entrypo…" 6 weeks ago Up 10 days 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp jwilder-nginx-proxy
1770dbb5ba32 mariadb:10.5.3 "docker-entrypoint.s…" 3 months ago Up 10 days ghost_db_1
ご覧のとおり、コンテナ名はghost_ghost_2です。 およびghost_db_1 それぞれリバースプロキシの下で実行されます。それらを止めましょう。
[email protected]:~$ cd ghost
[email protected]:~/ghost$ docker-compose down
Stopping ghost_ghost_2 ... done
Stopping ghost_db_1 ... done
Network net is external, skipping
[email protected]:~/ghost$
nginxリバースプロキシ構成の背後で実行されているアプリケーションが他にもある場合は、アプリケーションに設定されているそれぞれのディレクトリ名で同じ手順を使用します。それらをすべて1つずつ停止します。
gzipアーカイブとしてのボリュームと設定のバックアップ
それでは、手動のバックアッププロセスを見てみましょう。
名前付きDockerボリュームを処理するときは、ボリュームが手動で作成されたかどうか、またはアプリが最初にデプロイされた一般的なDockerCompose構成に基づいているかどうかをメモしてください。
ボリュームセクションの一般的な構成は次のようになります。
volumes:
ghost:
ghostdb:
上記のシナリオはDockerComposeによって管理されており、バックアップに必要な実際のボリューム名はghost_ghostになります。 およびghost_ghostdb 。
ボリュームがdocker volume create volume-nameを使用して手動で作成された場合 、構成は次のようになり、厳密にはghostになります。 およびghostdb 一人で：
volumes:
ghost:
external: true
ghostdb:
external: true
それでも、どちらの場合もバックアップする必要があり、ボリュームがマウントされたときにコンテナのパスも確認する必要があります。たとえば、MariaDBを使用した一般的なGhost構成では、サービス定義内のボリュームサブセクションを確認することでパスを知ることができます。これが私が何を意味するかを示すための抜粋です：
ghostdb:
volumes:
- ghostdb:/var/lib/mysql
上記の構成は、データベースサービスとそれに対応するコンテナの一部であり、デプロイされると作成されます。
同様に、ゴーストサービス自体の場合、パスは/var/lib/ghost/contentです。 ：
ghost:
volumes:
- ghost:/var/lib/ghost/content
ボリュームをバックアップするには、これらのパスを知っている必要があります。
docker volume lsを使用します クローンサーバーに存在するボリューム名を再確認するコマンド。
[email protected]:~/ghost$ docker volume ls
DRIVER VOLUME NAME
local ghost
local ghostdb
local nginx-with-ssl_acme
local nginx-with-ssl_certs
local nginx-with-ssl_dhparam
local nginx-with-ssl_html
local nginx-with-ssl_vhost
したがって、ボリュームが実際にghostであることを確認できます。 およびghostdb 。
それらをバックアップする時が来ました！本番クローンで、ユーザーディレクトリ内にバックアップディレクトリを作成しましょう：
mkdir ~/backup
次に、次のコマンドを使用して、tarアーカイブ内のボリュームの内容をバックアップします。
docker run --rm -v ghostdb:/var/lib/mysql -v ~/backup:/backup ubuntu bash -c "cd /var/lib/mysql && tar cvzf /backup/ghostdb.tar.gz ."
上記のコマンドでは、-vを使用します または--volume 、既存のDockerボリュームを新しいUbuntuコンテナーにマウントし、作成したバックアップディレクトリをバインドマウントします。後で、コンテナ内のデータベースディレクトリに移動し、tarを使用してその内容をアーカイブします。 --rm コンテナが終了したときに、コンテナを自動的にクリーンアップしてファイルシステムを削除するために使用されます（バックアップまたは復元ジョブが完了している間だけ必要なため）。
上記のコマンドの最後にあるquote（ "）が終了する前のドットに注意してください。これにより、アーカイブに/var/lib/ghost/content内の内容が確実に含まれるようになります。 単独で、パス全体をサブディレクトリとして含めません。後者は、アーカイブを新しいサーバー上の新しいボリュームに復元するときに問題を引き起こします。ですから、それを覚えておいてください。
これで、Ghostブログが使用しているMariaDBデータベースボリュームのアーカイブができました。同様に、ゴーストボリュームもバックアップする必要があります：
docker run --rm -v ghost:/var/lib/ghost/content -v ~/backup:/backup ubuntu bash -c "cd /var/lib/ghost/content && tar cvzf /backup/ghost.tar.gz ."
上記のバックアップコマンドは、最初に手動で作成された外部ボリュームに基づいていることに注意してください。 Docker Composeによって作成および管理される汎用ボリュームの場合、実際のボリューム名は代わりにghost_ghostになります。 およびghost_ghostdb それぞれ。たとえば、ghost_ghostdbの場合 、ghost プレフィックスは、DockerCompose構成ファイルとghostdbがあるアプリケーションディレクトリの名前を指します。 DockerCompose構成で設定したボリューム名を指します。
また、構成ファイルはここに保存されるため、バインドマウントを使用するか名前付きボリュームを使用するかに関係なく、ゴーストDocker作成ディレクトリをアーカイブする必要があることに注意してください。
名前のないDockerボリュームではなくバインドマウントを使用している場合、バインドマウントを含むディレクトリ全体がアーカイブされます。ここでは、これをghost-docker-compose.tar.gzと呼んでいます。 混乱を避けるために：
[email protected]:~/ghost$ sudo tar cvzf ~/backup/ghost-docker-compose.tar.gz .
バインドされたマウントされたボリュームは、DockerComposeファイルに個別のボリュームセクションを必要としません。彼らは、サービス内で定義されたときに次のことを望んでいます：
ghost:
volumes:
- ./ghost:/var/lib/ghost/content
同様に、バインドマウントされたデータベースボリュームは次のようになります。
ghostdb:
volumes:
- ./ghostdb:/var/lib/mysql
「./」は、「cd」したのと同じゴーストディレクトリ内のバインドマウントディレクトリを示します。したがって、この場合はすべてのファイル（ボリュームと構成ファイルを含む）の完全バックアップを作成します。
別の方法として、バインドマウントを個別にバックアップすることもできます。これにより、新しいサーバーにバインドをマウントするか、Dockerに名前付きボリューム構成を設定するかを選択できます。その理由は、アーカイブは上記の名前付きボリュームと同じ方法でバックアップされるためです。これを行うには、アプリケーションとデータベースのディレクトリ（バインドマウント）に1つずつ「cd」する必要があります。
cd ~/ghost/ghost
sudo tar cvzf ~/backup/ghost.tar.gz .
cd ~/ghost/ghostdb
sudo tar cvzf ~/backup/ghostdb.tar.gz .
バインドマウントと名前付きボリュームの両方に、独自の長所と短所があります。それらのどれが最も理想的であるかについての質問は、アプリケーションごとに異なります。たとえば、Nextcloud開発者は名前付きボリュームを提案しますが、Rocket.Chat開発者はバインドマウントを提案します。
次に、最後にこれらのアーカイブを取得します。
sftpを使用してアーカイブをローカルシステムにダウンロードします
sftpを使用すると、アーカイブをローカルシステムにすぐにダウンロードできます。ここでは、例としてポート4480とIP12.3.1.4を使用しています。 sshで使用されているのと同じポートを指します。
[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.4.
sftp> get /home/avimanyu/backup/ghost.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost.tar.gz to /home/user/Downloads/ghost.tar.gz
/home/avimanyu/backup/ghost.tar.gz 100% 233MB 6.9MB/s 00:34
sftp> get /home/avimanyu/backup/ghostdb.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghostdb.tar.gz to /home/user/Downloads/ghostdb.tar.gz
/home/avimanyu/backup/ghostdb.tar.gz 100% 26MB 6.5MB/s 00:03
sftp> get /home/avimanyu/backup/ghost-docker-compose.tar.gz /home/user/Downloads
Fetching /home/avimanyu/backup/ghost-docker-compose.tar.gz to /home/user/Downloads/ghost-docker-compose.tar.gz
/home/avimanyu/backup/ghost-docker-compose.tar.gz 100% 880 6.0KB/s 00:00
sftp> exit
[email protected]:~$
ここに表示されているように、get sftpのコマンド helluvaはrsyncよりもはるかに高速です または scp 。 1回 ダウンロードが完了すると、exitを入力できるsftpプロンプトが表示されます。 sftpコンソールから移動します。ダウンロードしたファイルは、/home/user/Downloadsで入手できます。 。
この時点で、Dockerアプリケーションの完全なバックアップを作成したと言えます。
しかし、もう一度言わなければならないのですが、復元できない限り、それは良くありません。
バックアップの実行方法がわかったので、次はバックアップから復元する方法を確認します。
クラウドサービスダッシュボードから新しいサーバーを作成します。これについては、バックアップセクションで説明しました。 Linodeでは、次のようになります：
サーバーの仕様は、アーカイブのバックアップ元の元のサーバーと同じにすることをお勧めします（前述）。
クラウドサービスプロバイダーに保存されているssh設定に基づいて新しいサーバーにログインできると仮定して、sftpのputを使用してファイルをサーバーにアップロードします。 コマンド：
[email protected]:~$ sftp -oPort=4480 [email protected]
Connected to 12.3.1.5.
sftp> put /home/user/Downloads/ghostdb.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghostdb.tar.gz to /home/avimanyu/ghostdb.tar.gz
/home/iborg/Downloads/ghostdb.tar.gz 100% 26MB 6.2MB/s 00:04
sftp> put /home/user/Downloads/ghost.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost.tar.gz to /home/avimanyu/ghost.tar.gz
/home/iborg/Downloads/ghost.tar.gz 100% 233MB 7.2MB/s 00:32
sftp> put /home/user/Downloads/ghost-docker-compose.tar.gz /home/avimanyu
Uploading /home/user/Downloads/ghost-docker-compose.tar.gz to /home/avimanyu/ghost-docker-compose.tar.gz
/home/iborg/Downloads/ghost-docker-compose.tar.gz 100% 880 22.6KB/s 00:00
sftp> exit
[email protected]:~$
アップロードにGUIを使用する場合でも、FileZillaを使用できます。
まず、Ghost構成のdockercomposeディレクトリを復元します。
mkdir ghost
cd ghost
sudo tar xvf ~/backup/ghost-docker-compose.tar.gz
別の方法として、--same-ownerを使用して、バインドマウントされたディレクトリ（アーカイブにすでに存在する）を復元するときに役立つ可能性のあるユーザー所有権（権限はすでに保持されています）を復元することもできます。 ：
sudo tar --same-owner -xvf ~/backup/ghost-docker-compose.tar.gz
新しいボリュームの管理をDockerComposeに依存する場合は、最初にボリュームを作成します。上記のバックアップボリュームのセクションで説明したように、明らかに必要な命名規則に従う必要があります。
docker volume create ghost_ghost
docker volume create ghost_ghostdb
Docker Compose構成内でそれらを外部として設定する場合は、名前を変える必要があります（上記の2つのコマンドを修正してください）：
docker volume create ghost
docker volume create ghostdb
GhostのMariaDBボリュームを復元するには：
docker run --rm -v ghostdb:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghostdb.tar.gz"
Ghostボリューム自体を復元するには：
docker run --rm -v ghost:/restore -v ~/backup:/backup ubuntu bash -c "cd /restore && tar xvf /backup/ghost.tar.gz"
新しいサーバーを使用しているため、IPは確実に変更されているため、ドメインに合わせて修正する必要があります。これらのnginxリバースプロキシDockerの前提条件は、これまでに説明した参考資料として確認できます。
次に、新しいサーバーで構成を再起動します。
docker-compose up -d
上記のすべての手順に注意深く従うと、バックアップに基づいて完全に復元されたDockerWebアプリケーションが作成されます。
目標が達成されたことを確認したら、テスト用に保持する場合を除いて、クローンを用意する必要はありません。したがって、これ以上不要な場合は、Linodeを削除してください（DOUBLE CHECK！）：
そのような方法を部分的に利用する解決策はすでにたくさんあります。ただし、コンテナを停止する必要があるため、ダウンタイムが必要になります。この課題は、本番サーバー自体ではなく、本番クローンからのクラウドバックアップを使用することで解決されます。
ダウンタイムのないバックアップのためのクラスターとして24時間年中無休の追加サーバーを使用する代わりに、同じことを保証するために一時的にサーバーを使用しています。これにより、より優れたFinOpsが可能になります。
バックアップのダウンロードまたはアップロードにGUIを使用する場合は、sftpを使用できます。 FileZilla経由。
本番サーバー自体ではなく、クローンサーバー上でファイルをバックアップしているため、プロセス中に発生する可能性のある予期しない問題を回避するだけでなく、貴重な稼働時間を節約できます。正直なところ、本番サーバーに触れないので、心配する必要はなく、緊張することなくいじることができます;）
プロセス全体が非常に包括的であることを否定することはできませんが、それは確かに私たちの目的を果たします。将来的には、クラウドとローカルシステムを注意深く同期することで、この手順を完全に自動化することもできます。
Dockerのバックアップとダウンタイムなしの復元についてさらに提案がある場合は、以下のセクションで考えを共有してください。その他のフィードバックやコメントは大歓迎です。