復元に関する問題

discourse_docker リポジトリに基づいて、Vagrant マシン内でそれを使用するための自動化スクリプトを少し書きました(実際に何が行われているかを確認するには set -x で実行してください)

バックアップを間違った場所にコピーしてしまいましたか?

また、以下のログ行

Making sure /var/www/discourse/tmp/restores/default/2020-05-13-190832 exists...

の意味は何ですか?

~/infra/discourse on  master! ⌚ 21:14:07
$ pwd
/home/pihentagy/infra/discourse
~/infra/discourse on  master! ⌚ 21:01:14
$ ./wl.sh start
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ init
+ printf 'Checking out and updating repo…\n'
Checking out and updating repo…
+ cd ..
+ git clone https://github.com/discourse/discourse_docker.git discourse
fatal: destination path 'discourse' already exists and is not an empty directory.
+ printf 'Repo already there\n'
Repo already there
+ cd discourse
+ printf 'Updating repo…\n'
Updating repo…
+ git pull -r
remote: Enumerating objects: 6, done.
remote: Counting objects: 100% (6/6), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 6 (delta 2), reused 5 (delta 2), pack-reused 0
Unpacking objects: 100% (6/6), done.
From https://github.com/discourse/discourse_docker
   3e465a2..49ed141  master     -> origin/master
Created autostash: 36aae80
HEAD is now at 3e465a2 Remove all pg12 traces so pg_wrapper doesn't get confused
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 49ed14152971f7f4a7437657987952be44c33c0a.
Applying autostash resulted in conflicts.
Your changes are safe in the stash.
You can run "git stash pop" or "git stash drop" at any time.
+ printf 'Copying config file…\n'
Copying config file…
+ cp ../resources/discourse.yml containers/
+ echo 'Starting Vagrant machine...'
Starting Vagrant machine...
+ vagrant up
Bringing machine 'dockerhost' up with 'virtualbox' provider...
==> dockerhost: Checking if box 'ubuntu/xenial64' is up to date...
==> dockerhost: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> dockerhost: flag to force provisioning. Provisioners marked to run always will still run.
+ vagrant ssh -c 'cd /vagrant;sudo ./launcher start discourse'
2627afdfbaac
Nothing to do, your container has already started!
Connection to 127.0.0.1 closed.
+ exit 0

~/infra/discourse on  master! ⌚ 21:07:56
$ ./wl.sh restore /home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz
+ set -e
+ VAGRANT_MACHINE_NAME=guest
+ cd discourse
+ case "$1" in
+ shift
+ backup=/home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz
+ discourse_backup_dir=shared/standalone/backups/default
+ mkdir --parents shared/standalone/backups/default
+ rsync -P --verbose /home/pihentagy/infra/icontest-2020-05-12-033823-v20200506044956.tar.gz shared/standalone/backups/default
icontest-2020-05-12-033823-v20200506044956.tar.gz
    390,774,609 100%  317.41MB/s    0:00:01 (xfr#1, to-chk=0/1)

sent 390,870,133 bytes  received 35 bytes  156,348,067.20 bytes/sec
total size is 390,774,609  speedup is 1.00
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore'
Restore are now permitted. Disable them with `disable_restore`
Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
You must provide a filename to restore. Did you mean one of the following?

Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Starting restore: icontest-2020-05-12-033823-v20200506044956.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2020-05-13-190832 exists...
Copying archive to tmp directory...
EXCEPTION: lib/discourse.rb:90:in `exec': Failed to copy archive to tmp directory.
cp: cannot stat '/var/www/discourse/public/backups/default/icontest-2020-05-12-033823-v20200506044956.tar.gz': No such file or directory
lib/discourse.rb:100:in `execute_command'
lib/discourse.rb:90:in `exec'
lib/discourse.rb:40:in `execute_command'
/var/www/discourse/lib/backup_restore/local_backup_store.rb:42:in `download_file'
/var/www/discourse/lib/backup_restore/backup_file_handler.rb:61:in `copy_archive_to_tmp_directory'
/var/www/discourse/lib/backup_restore/backup_file_handler.rb:21:in `decompress'
/var/www/discourse/lib/backup_restore/restorer.rb:42:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Trying to rollback...
There was no need to rollback
Cleaning stuff up...
Removing tmp '/var/www/discourse/tmp/restores/default/2020-05-13-190832' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
Connection to 127.0.0.1 closed.

Vagrant はサポートされていませんが、それでもいくつかのアドバイスをします。:wink:

rsync の動作については確信が持てません。パスはスラッシュで終わる必要がありますか?ファイルが正しいディレクトリに配置された場合は、コピーされたファイルがサーバーから読み取り可能であることを確認してください。

「いいね!」 4

つまり、vagrant (VirtualBox) が何らかの問題を引き起こす可能性がありますか?

~/infra/discourse on  master! ⌚ 23:22:23
$ tree discourse/shared 
discourse/shared
└── standalone
    └── backups
        └── default
            └── icontest-2020-05-12-033823-v20200506044956.tar.gz

3 directories, 1 file

~/infra/discourse on  master! ⌚ 23:22:27
$ ls discourse/shared/standalone/backups/default 
icontest-2020-05-12-033823-v20200506044956.tar.gz

~/infra/discourse on  master! ⌚ 23:22:36
$ ls -l discourse/shared/standalone/backups/default
total 381620
-rw-r--r-- 1 pihentagy pihentagy 390774609 May 13 21:08 icontest-2020-05-12-033823-v20200506044956.tar.gz

ファイルは全員から読み取り可能で、正しい場所に配置されているようです。discourse の Docker コンテナ内から、バックアップはどこに表示されますか?私の自動化されたリストアスクリプトは正しいでしょうか、それとも Docker コンテナ内にコピーする必要がありますか?必要であれば、どこにコピーすべきですか?(Docker 外から Discourse を自動化する方法に関するガイドはありますか?)

+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore'
You must provide a filename to restore. Did you mean one of the following?

Connection to 127.0.0.1 closed.
+ vagrant ssh -c 'sudo docker exec -w /var/www/discourse -i discourse discourse restore icontest-2020-05-12-033823-v20200506044956.tar.gz'
Starting restore: icontest-2020-05-12-033823-v20200506044956.tar.gz
[

必須ではありませんが、パスの末尾にスラッシュを付けないのは悪い慣習です。なぜなら、その結果はディレクトリが既に存在するかどうかによって変わるからです。

宛先ディレクトリが既に存在する場合、スラッシュは不要で、ファイルはそのディレクトリ内にコピーされます。
宛先ディレクトリが存在せず、かつ末尾にスラッシュがない場合、ファイルは ‘default’ という名前のファイルとしてコピーされます。
宛先ディレクトリが存在せず、かつ末尾にスラッシュがある場合、ディレクトリが作成され、ファイルがその中にコピーされます。

今回の場合、コピーは(運良く)成功しているようです。

ただし、

「Did you mean one of the following?」の後に提案が表示されていないため、ファイルが正しい場所になかったと考えられます。ドライブが Docker コンテナに対して正しくマウントされていないようです。

Docker 内からバックアップ(discourse backup)を実行し、ホストファイルシステム上でどこに保存されるかを確認してみてください。

「いいね!」 3

奇妙なことに、ホストファイルシステムからは表示されません。表示されるべきでしょうか?

vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse backup
バックアップを開始しています...
[開始]
'system' がバックアップを開始しました!
バックアップを「実行中」としてマークしています...
'/var/www/discourse/tmp/backups/default/2020-05-14-121930' の存在を確認しています...
'/var/www/discourse/public/backups/default' の存在を確認しています...
メタデータを更新しています...
sidekiq を一時停止しています...
sidekiq がジョブの実行を完了するのを待っています...
データベースのパブリックスキーマをダンプしています...


pg_dump 関連の出力が大量に…

sidekiq の一時停止を解除しています...
バックアップを最終確定しています...
アーカイブを作成中: discourse-2020-05-14-121930-v20200512064023.tar.gz
アーカイブが既に存在しないか確認しています...
空のアーカイブを作成しています...
データダンプをアーカイブしています...
アップロードをアーカイブしています...
/tmp '/var/www/discourse/tmp/backups/default/2020-05-14-121930' ディレクトリを削除しています...
アーカイブを gz 圧縮しています。時間がかかる場合があります...
バックアップの after_create_hook を実行しています...
古いバックアップを削除しています...
不要なファイルを整理しています...
'.tar' の残骸を削除しています...
バックアップを「完了」としてマークしています...
ディスク統計を更新しています...
完了!
[成功]
バックアップが完了しました。
出力ファイルの場所: /var/www/discourse/public/backups/default/discourse-2020-05-14-121930-v20200512064023.tar.gz

vagrant@ubuntu-xenial:~$ find / -name discourse-2020-05-14-121930-v20200512064023.tar.gz 2>/dev/null
vagrant@ubuntu-xenial:~$ sudo docer exec -w /var/www/discourse -i discourse discourse enable_restore
sudo: docer: コマンドが見つかりません
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse enable_restore
復元が許可されました。無効化するには `disable_restore` を使用してください
vagrant@ubuntu-xenial:~$ sudo docker exec -w /var/www/discourse -i discourse discourse restore
復元するファイル名を指定する必要があります。以下のいずれかを意図しましたか?

discourse restore discourse-2020-05-14-121930-v20200512064023.tar.gz
discourse restore discourse-2020-05-14-121710-v20200512064023.tar.gz
discourse restore discourse-2020-05-14-120436-v20200512064023.tar.gz

オフ:コードブロック内の行をハイライト表示する方法はありますか?

```bash

デフォルトではテキストです。新しいインストールのデフォルトは「言語を推測する」だと考えています。

「見て、5行目が重要なんだよ!」という意味です。つまり、特定の行を強調表示することです。

通常、/var/discourse/shared/standalone/backups ディレクトリは、コンテナ内では /var/www/discourse/public/backups として表示されます(そのため shared という言葉が使われています)。あなたの rsync コマンドは、コンテナ内からアクセスできるようにするために、バックアップをそのディレクトリ内に配置しています。

逆に、コンテナが public/backups に書き込んだ場合、共有ディレクトリ上のホスト側からも表示されるはずです。

上記では /var/discourse/shared... と書きましたが、どうやらあなたは ~/infra/discourse で作業されているようなので、~/infra/discourse/shared/standalone/backups/default へコピーしていることになります。

通常、コンテナは /var/discourse/shared/... にマッピングされます。

これが問題の原因かもしれません。/var/discourse/shared が存在するか確認できますか?

いいえ。コードブロック内では、すべてがそのまま表示されるため、それはできません。

さて、今すぐバックアップを作成し、Docker マシン外からそれが見つかるか確認しましたが、見つかりませんでした。

vagrant@ubuntu-xenial:~$ sudo docker inspect -f "{{.Mounts}}" discourse
[{bind  /var/discourse/shared/standalone /shared   true rprivate} {bind  /var/discourse/shared/standalone/log/var-log /var/log   true rprivate}]

その通りですが、今はそれを無視しました。ちなみに、その rsync は Discourse を実行していた (Vagrant) マシン外で行われました。

しかし、あなたの提案通り、以下の手順を試しました:

  • Vagrant マシンに SSH で接続し、その内部から:
    • sudo docker exec -w /var/www/discourse -i discourse discourse backup でバックアップを作成
    • ファイルパスに気づきました:
      Output file is in: /var/www/discourse/public/backups/default/discourse-2020-05-14-125606-v20200512064023.tar.gz
      
    • その特定のファイルを探すため Vagrant マシン全体を検索しましたが、何も見つかりませんでした
      find / -name discourse-2020-05-14-125606-v20200512064023.tar.gz 2>/dev/null
      
    • しかし、Docker マシン内に入ると、そこにあります
      root@ubuntu-xenial-discourse:/var/www/discourse/public/backups/default# ls
      discourse-2020-05-14-120436-v20200512064023.tar.gz  discourse-2020-05-14-121930-v20200512064023.tar.gz
      discourse-2020-05-14-121710-v20200512064023.tar.gz  discourse-2020-05-14-125606-v20200512064023.tar.gz
      

つまり、私の質問は: バックアップを作成した場合、Docker 外からそれを見ることができるべきでしょうか?

その間、私は Vagrant マシンを新たに作成し、標準の /var/discourse ディレクトリ内で git clone を行いました。唯一の「奇妙な点」は、コンテナ内に app.yml ではなく discourse.yml が存在することです。

はい、これはあなたの元の問題と同じことです:
「Docker 外にバックアップがあり、それを共有ディレクトリに置いた場合、Docker 内でもそれを確認できるはずです」(しかし、できていません)。

問題は共有ディレクトリにあり、その原因はこれです:

つまり、現時点では完全に新規の Vagrant マシンを再作成し、以前のバックアップは一切コピーしていません。ブートストラップを実行し、Docker コンテナを起動してから、バックアップを取得しました。

Docker マシン外では、Vagrant マシン内には何も表示されません。

問題の箇所を見つけました。囲んでいる Vagrant マシンに、この docker-shared フォルダをマウントしていました。

config.vm.synced_folder "discourse/", "/var/discourse"

これを Vagrantfile からコメントアウトすると、バックアップが「魔法のように」表示されるようになります。

つまり、問題は Vagrant の共有フォルダ(「上」向け)と Docker の共有フォルダ(「下」向け)が競合し、無効化されてしまっていたことにありました。

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.