プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

Rainloop の設定変更

こちらの記事に書いたように、メールアカウントの POP3 -> IMAP4 移行に伴い、Rainloop を導入しました。

で、しばらく使って、困ったことがあり、それに伴いいくつか設定を見直したので、メモとして残しておきます。

※ なお、実はこの記事の内容は 2019/11/6 時点での設定で、ブログに投稿しようと思って、大雑把にメモってそのまま忘れ去られていました。先日、下書きが残っているのに気づいたので、改めて公開した次第です。

Rainloop のバージョンは v1.13.0 になります。

多数のフォルダの処理ができない

フォルダ数が多いと下記のような警告が出て、表示されていないフォルダの操作ができなくなりました。

f:id:junichim:20191105140503p:plain

解決策

下記にあるように application.ini の設定値を変更すれば対応できます。

Where to set limit for "You have too many folders!" option · Issue #978 · RainLoop/rainloop-webmail · GitHub

application.ini は rainloop/data/_data_/_defaul_/configs にあります。

修正前

[labs]
; Experimental settings. Handle with care.
; 
(中略)
imap_folder_list_limit = 200
(後略)

修正後

[labs]
; Experimental settings. Handle with care.
; 
(中略)
imap_folder_list_limit = 300
(後略)

フォルダ数が多い場合は、フォルダ毎の未読がチェックされない

Rainloop ではフォルダ数が 50 (設定ファイルで変更可能です)以上の場合、フォルダ毎の未読数が表示されません(パフォーマンスのため)。

How can the unread message count on folders be refreshed? · Issue #803 · RainLoop/rainloop-webmail · GitHub

このため、フォルダ数が 50 以上の場合に、未読数の表示を有効にするためには、フォルダ管理画面より、『新しいメッセージをチェックする/しない』を設定する必要があります。ちなみに、デフォルトはシステムフォルダ以外はすべてチェックしないとなっています。

[question] Unread messages · Issue #611 · RainLoop/rainloop-webmail · GitHub

こんな感じで設定していきます。

f:id:junichim:20201202104329p:plain

この例の場合だと、 Junk E-mail フォルダは未読数をチェックしませんが、画面内の他のフォルダはチェックになっています。また、太字のフォルダはシステムフォルダです。

なお、すべてのフォルダの未読数を表示する上限は、 application.ini の下記の値を変更すればよいそうです(試してないので、うまくいくかどうかは不明です)。

[labs]
; Experimental settings. Handle with care.
; 
(中略)
folders_spec_limit = 50
(後略)

ログを残すようにする

デフォルトでは、ログは作成されません。ログファイルを残すには、 application.ini の [logs] セクションの設定を変更します。

Activate logging and find logs for {Rainloop in Nextcloud} - PAB's blog

修正前

[logs]
; Enable logging
enable = Off

; Logs entire request only if error occured (php requred)
write_on_error_only = Off

; Logs entire request only if php error occured
write_on_php_error_only = Off
(後略)

修正後

[logs]
; Enable logging
enable = On

; Logs entire request only if error occured (php requred)
write_on_error_only = On

; Logs entire request only if php error occured
write_on_php_error_only = On
(後略)

先頭の enable = On でログが有効になります。その他の設定は、エラー時のログだけ残したいので設定しました。ほかにも設定オプションがあるので、気になる方はご自分で調べてみてください。

ちなみに、ログファイルの保存先は、 rainloop/data/_data_/_default_/logs フォルダ以下になります。

管理画面のURL

Rainloop の管理画面のURLですが、デフォルトだと、

https://サーバー名/?admin

になっています。でも、デフォルトのままだと不安ですよね?これも変更できます。

admin panel security · Issue #976 · RainLoop/rainloop-webmail · GitHub

変更方法は application.ini の admin_panel_key を変更すればOKです。

修正前

[security]
; Enable CSRF protection (http://en.wikipedia.org/wiki/Cross-site_request_forgery)
(中略)
; Access settings
admin_panel_key = "admin"

修正後

; Enable CSRF protection (http://en.wikipedia.org/wiki/Cross-site_request_forgery)
(中略)
; Access settings
admin_panel_key = "my-new-admin-url-query"

変更後は、https://サーバー名/?my-new-admin-url-query でアクセスして表示されるログイン画面から、正しいユーザー名とパスワードを入れることでログインできるようになります。

なお、 https://サーバー名/?admin でもログイン画面が表示されますが、正しいユーザー名とパスワードを入れてもログインできなくなります。

添付ファイルサイズ制限を緩める

デフォルトはこれでした。

f:id:junichim:20191112090416p:plain

Rainloop 側の制限は 25M でしたが、PHP側でアップロード 2M, ポスト 8M の制限がかかっています。

なので、php側の制限を変更して、大きめのファイルを送信できるようにします。

php.ini を編集する必要があるので、もし、どの php.ini を使っているのか不明であれば、管理画面の『セキュリティ』にある『PHP情報を表示』からphpinfoの情報を見て確認します。

f:id:junichim:20201202111644p:plain

『Loaded Configuration File』をみれば、現在読み込んでいるphp.iniの場所がわかります。

修正前

; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
post_max_size = 8M

および

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 2M

修正後

; Maximum size of POST data that PHP will accept.
; Its value may be 0 to disable the limit. It is ignored if POST data reading
; is disabled through enable_post_data_reading.
; http://php.net/post-max-size
post_max_size = 30M

; Maximum allowed size for uploaded files.
; http://php.net/upload-max-filesize
upload_max_filesize = 30M

変更後は、apache を再起動しておきます。

管理画面で確認すると、無事変更されていました。

f:id:junichim:20201202111924p:plain

まとめ

Rainloop フォルダ周りの機能があまりないとか、不満もありますが、一か所でいろんなメールを確認できる環境はなかなか便利です。 IMAP なので、Rainloop 側でのバックアップも設定ファイルを残しておくだけでいいので、そんなに気にしないで済むのもありがたいです。

気になる方は一度試してみるといいかもしれませんよ。

Mac 版 SourceTree で SSH による Bitbucket のリポジトリが clone できない問題への対応

しばらく前に、 iOS アプリの仕事が入ったため Mac を調達することになりました。納期との関係でそろそろハードウェアを手配しないといけなくなったのですが、タイミング的に、 M1 搭載の機種だと、納品までに動作検証が確実にできるかちょっとわからなかったので、ここは泣く泣く Intel 版の Mac を購入しました。

で、今月 11 月のとある日に、納品されたので、あれこれとセットアップを始めたのですが、 SourceTree のセットアップ(というより SSH まわりの設定)でハマったので、メモを残したいと思います。

ちなみに、やりたかったことはシンプルで、

SourceTree を設定し、 Bitbucket のリポジトリに SSH でアクセスする

というだけです。

SourceTree のインストール

まず、 SourceTree のバイナリをダウンロードしてきます。

(ちなみに、ここで、Mac版 SourceTree のインストールの説明とか見ても、『 zip ファイルを解凍』などというのが見られるのに、 Safari でダウンロードすると .app ファイルしかないというところから、違和感たっぷりです。しばらくしてから zip ファイルは(安全なファイルとみなされるファイルというべきかな?)自動的に解凍されるという Safari のデフォルト設定があるのがわかって、やっと納得しました。)

解凍したファイルをダブルクリックして、あとはインストーラの指示に従ってセットアップを進めます。

この時、Windows 版と同様に、Atlassian アカウントを入力しています。

あとは細かく覚えてませんが、特に問題なくセットアップが終わりました。

リポジトリのクローン

インストール後 SourceTree を起動すると、先ほど入力した Atlassian カウントに紐づくリポジトリの一覧が表示されます。

さて、ここで疑問です。現在、 Bitbucket のリポジトリは、2段階認証を導入しているので、 SSH でのアクセスが必須です(下記参照)。

Enable two-step verification | Bitbucket Cloud | Atlassian Support

でも、 SSH のプライベートキーの設定など、何もやってない、というか、そもそも Mac 上にキーファイルのコピーすらしてないので、リポジトリが表示されるのはいいんだけど、さて、クローン出来るんだろうか?とおもってやってみると、やはりうまくできません。

で、 SSH キーを設定しようとしました。SourceTree の『環境設定』を開いて、『アカウント』タブを表示すると、インストール時に作った覚えがないんですが、何やら Bitbucket 用のアカウントが設定されています。

これを開くと、SSHキーの作成 はできそうなのですが、既に運用中の既存の SSH のプライベートキー を設定しようと思ったら、やり方がよくわからないです。

ついでに、Windows 版の SourceTree の設定と比べてみると、この部分(Windows版 3.3.8 だと、『ツール』->『オプション』->『認証』タブに該当しそうです)には特にアカウントが設定されていません。

ということで、一旦、既に登録済みのアカウントを削除して、SSH キーを設定してみることにしました。

既存の SSH キーを設定(公式の設定方法)

まあ、SourceTree の Mac 版で SSH キーが設定できないのは話にならないので、設定方法は簡単に見つかるだろうと思い、実際、ちょっと調べると、Atlassian のサイトに設定方法が載ってました。

Set up an SSH key | Bitbucket Cloud | Atlassian Support

さっそくやってみます。ただし、既にキーは持っているし、Bitbucketのサーバー側にパブリックキーも登録済みなので、上記記事の Step 1 と Step 3 は省略して、 Step 2 を実行します。

mor@JunichinoMac-mini ~ % cd .ssh 
mor@JunichinoMac-mini .ssh % eval `ssh-agent`
Agent pid 2958
mor@JunichinoMac-mini .ssh % ssh-add -K ~/.ssh/bitbucket.openssh.private
Identity added: /Users/mor/.ssh/bitbucket.openssh.private (/Users/mor/.ssh/bitbucket.openssh.private)
mor@JunichinoMac-mini .ssh % 
mor@JunichinoMac-mini .ssh % touch config
mor@JunichinoMac-mini .ssh % chmod 600 config 
mor@JunichinoMac-mini .ssh % vi config
mor@JunichinoMac-mini .ssh % cat config
Host *
    UseKeychain yes
mor@JunichinoMac-mini .ssh % 

設定後、一度 SourceTree で Bitbucket 上のリポジトリをクローンすると、うまくできました!

これで、一安心。

トラブル

と思いきや、一度ログアウトしてから、再度ログインして pull などを試すとうまくできません。

f:id:junichim:20201130152754p:plain

上記公式の説明の Step 3 にある確認方法を試すと、

mor@JunichinoMac-mini ~ % ssh -T git@bitbucket.org
git@bitbucket.org: Permission denied (publickey).
mor@JunichinoMac-mini ~ % 

となり、アクセスできないのが確認できました。 どうしたものかと思い、トラブルシュートがあるのでそれを見てみると、キーが登録されているか確認する、とあります。試します。

mor@JunichinoMac-mini ~ % ssh-add -l
The agent has no identities.
mor@JunichinoMac-mini ~ % 

なにも出てこないですね・・・

はい、もう一度やり直しですね。

理由

上記の公式の手順を試した際に、

mor@JunichinoMac-mini ~ % eval `ssh-agent`

って、何だろうと?違和感があったのですが、そのまま調べずに進めていました。改めて、 man ssh-agent を読むと、ssh-agent は ssh を利用するコマンドを最初に利用する際に、起動される、とあります。デーモンじゃないんだ!

ということは、登録したキーもログインセッション中のみ有効ということのようです。これで、ログインしなおしたら、リポジトリにアクセスできなくなる理由がわかりました。

SSH キーを恒久的に登録

毎回、公式の説明にあるような

ssh-add -K プライベートキーファイル

を実行するわけにはいきません。

たぶん、同じように困っている人はたくさんいるだろうからと思い、ちょっと調べてみると、

macos - SourceTree SSH options on OS X - Super User How can I permanently add my SSH private key to Keychain so it is automatically available to ssh? - Ask Different

にある方法でうまくいきそうです。

まとめると要は ~/.ssh に config ファイルを設定すればよいというものです。

mor@JunichinoMac-mini ~ % cd .ssh
mor@JunichinoMac-mini .ssh % vi config 
mor@JunichinoMac-mini .ssh % cat config
Host bitbucket.org
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/bitbucket.openssh.private
mor@JunichinoMac-mini .ssh % 

UseKeychain yes がキーチェーンを使う(プライベートキーのパスワードをキーチェーンから取得する)ということであり、AddKeysToAgent が ssh-agent の起動のたびにプライベートキーを IdentityFile から取得する、という設定になります。

これで実行できるか一度ログアウトして試してみると、問題なく、プルなどができました!

なお、 .ssh/config の書き方は、下記記事などを参考にしました。

Using the SSH Config File | Linuxize

参考1:毎回プライベートキーを入力する方法(失敗)

なお、 ~/.ssh/config の UseKeychain を no にして、毎回プライベートキーのパスワードを入力させようと思ったのですが、どうも SourceTree 側が対応していないようで、 passphrase 入力用のダイアログなどが表示されずに、単にエラーで終わってしまいます。

なので、当面は、Keychain に設定したプライベートキーのパスワードを利用する形で運用しようと思います。

参考2:プライベートキーの削除方法(失敗)

上記の一連の作業の結果、キーチェーンに、同じプライベートキーが2つのエントリーとして登録されてしまいました。キーチェーンアクセスで確認すると、

f:id:junichim:20201130154501p:plain

こんな感じで、2つのエントリーがあるのがわかります。ssh-add -K でパスワードファイルを指定する際のパス名違いですね。

なので、2つあるのも気持ち悪いので、これを削除する方法を調べたのですが、結局、わかりませんでした。

一応参考までに試した方法を書いておきます。

方法1

key chain の削除するには、プライベートキーに対応するパブリックキーが必要だそうです。

password - How do I remove an ssh private key from ssh-agent/keychain - Ask Different

まず、パブリックキーを生成します。

mor@JunichinoMac-mini .ssh % ssh-keygen -y -f ./bitbucket.openssh.private > bitbucket.openssh.public  
Enter passphrase: 
mor@JunichinoMac-mini .ssh % 

パブリックキーができたら、削除します。下記の記事などにあるように ssh-add -K -d のように2つのオプションを同時に指定する必要があるようです。

Stupid ssh-add Tricks - Stuff… And Things…

How To Stop macOS Sierra From Remembering Your SSH Key Passphrase - TeckLyfe

mor@JunichinoMac-mini ~ % ssh-add -K -d ~/.ssh/bitbucket.openssh.public 
Identity removed: /Users/mor/.ssh/bitbucket.openssh.public (/Users/mor/.ssh/bitbucket.openssh.public)
mor@JunichinoMac-mini ~ % 

これでうまくいっているように見えるのですが、キーチェーンアクセスから表示すると、キーチェーンが残ったままです。

もう少し細かく言うと、実は、 ssh-add -K で登録した直後なら、この方法でキーチェーンから削除できたのですが、一旦シャットダウンして、改めて過去に登録したプライベートキーのキーチェーンを削除しようとした場合は削除されませんでした。

結局、この理由がわからず、キーチェーンから削除ができませんでした。

方法2:『ローカル項目』を直接削除する

sshのプライベートキーは、キーチェーンの『ローカル項目』に入っていました。で、この『ローカル項目』は sqlite3 のデータベースファイルだそうです。 なので、このデータベースファイルから直接キーチェーンの該当項目を削除する方法が見つかりました。

How To Stop macOS Sierra From Remembering Your SSH Key Passphrase - TeckLyfe

rdar://28394826: macOS Sierra permanently remembers SSH key passphrase by default

試しに、当該ファイルのコピーを作って、確認してみると、

mor@JunichinoMac-mini tmp % cp -p ~/Library/Keychains/ハードウェアUUID/keychain-2.db .
mor@JunichinoMac-mini tmp % 
mor@JunichinoMac-mini tmp % sqlite3 keychain-2.db "select rowid, agrp from genp where agrp='com.apple.ssh.passphrases'"
71|com.apple.ssh.passphrases
92|com.apple.ssh.passphrases
mor@JunichinoMac-mini tmp % 

のように、当該レコードが存在しているようです。

ただ、この方法はちょっと怖いので、残念ながら、まだ試していません。

ということで、これについては、当面ペンディングです。

最後に

ということで、一応 SourceTree から Bitbucket へ SSH 経由でアクセスできるようになりました。 Mac ユーザーにとっては、当たり前なんでしょうが、なかなか慣れないシステムだと、前途多難です・・・

QNAP の S3 へのクラウドバックアップを設定してみました

以前から、やろうやろうと思っていましたが、のびのびになっていた、 QNAP のクラウドバックアップですが、 Hybrid Backup Sync 3 (以下、 HBS3 と略します)を使うと簡単にできそうだったので、試してみましたので、いろいろとメモっておきます。

ちなみに、参考にした元ネタは下記の記事になります。

【家庭用NAS】QNAP TS-131でファイルを自動的にS3へリモートバックアップする | Developers.IO

背景

現状、2台の NAS 間でデータフォルダの同期をさせていて、一応メインの NAS が壊れても、すぐにもう一台を使って作業を継続できる体制にしていますが、これだと、仕事場が浸水するとかしてしまうとすべてのデータがなくなる可能性があります(最近は、局地的な豪雨とかもひどいものがありますからね)。 ということで、データのバックアップをクラウド上に置いたいとかねてから思っていました( NAS を選ぶときに QNAP を選択した理由の一つでもあります)。

でも、今の今まで設定を先延ばしにしていました。

先日、 NAS 間のデータ転送でちょっと不可解な動きがあったので、問題が起きる前に改めてクラウドバックアップをやっておこうと思った次第です。

バックアップ先のクラウドとしては、何を使おうか若干迷ったのですが、ここは毎度おなじみの S3 を使うことにしました。

S3 の設定

QNAP 上でバックアップジョブの設定時に新規作成することもできるようですが、まず、 AWS のコンソール(もちろん、CLI でもなんでもOKです)から保存先となる S3 のバケットを作成しておきます。

今回作成したバケットは

  • バージョニング:なし
  • 暗号化:なし
  • ライフサイクルルール:指定なし

というシンプルなものです。当然非公開のバケットです。

QNAP 上のクラウドストレージ領域の作成

次に、作成したバケットを QNAP 上にクラウドストレージとして登録します。

QNAP のコンソールにログインして、 HBS3 を起動します。

f:id:junichim:20201127110130p:plain

左側のメニューより『ストレージ領域』を選択し、『作成』を選びます。

f:id:junichim:20201127110434p:plain

すると、クラウドストレージの一覧が表示されるので、自分が使いたいサービスのものを選択します(今回ですと S3 )。 サービスごとに設定画面が表示されるので、必要な設定を入力していきます。S3の場合は、下記にあるように、アクセスキーとシークレットアクセスキーを設定します。

f:id:junichim:20201127110616p:plain

なお、アクセスキーは、S3FullAccess の権限を持った IAM ユーザーのものになりますので、当該ユーザーがなければ、AWSのコンソールにてIAMユーザーを作成してください。

今回は、S3のアクセス権限を特定のバケットに制限する管理ポリシーについての記事を参考に、ポリシーを作成し、新しいIAMユーザーに割り当て、そのユーザーのアクセスキーとシークレットアクセスキーを用いました。

あと、バケット名としてさきほど作成したバケットを指定すれば完了です。

f:id:junichim:20201127111031p:plain

作成後はこんな感じになりました。

f:id:junichim:20201127111204p:plain

バックアップジョブの作成

クラウドストレージ領域を設定したので、次はバックアップジョブを作成します。

なお、HBS3はいろいろと機能があるので、バックアップジョブを作成する前に、こちらの紹介記事などに一通り目を通しておくと、こんなことができて、そのための設定項目なんだなと全体像がつかみやすくなるかと思います。

『バックアップ&復元』を選択し、

f:id:junichim:20201127112351p:plain

『新しいバックアップジョブ』を選択します。

バックアップの対象および保存先を設定

まずは、バックアップの対象となるローカルフォルダを指定します。

f:id:junichim:20201127112517p:plain

次に、バックアップ先を選択します。ここでは、S3 上に保存したいので、S3を選択します。S3 を選択するとさきほど作成したクラウドストレージが表示されるのでそれを選択します。

f:id:junichim:20201127112548p:plain

ストレージクラス、暗号化など、必要な設定を行います。

f:id:junichim:20201127113005p:plain

ただし、いろいろと設定を試した際の印象では『サーバー側の暗号化を使用する』のオプションを設定しても、バケット側の設定で暗号化が無効であれば、有効には切り替わらないように思えます(このあたり、正確な情報が見つけられませんでした)。

次に、必要があれば、保存先になる S3 上のフォルダを指定します。特になければ、バケットのルートで問題ないです。

f:id:junichim:20201127113256p:plain

ジョブ名を聞かれるので入力します。実はこのジョブ名を用いたフォルダが、先ほど指定した保存先フォルダ内に作成され、その内部にバックアップが作成されます。

f:id:junichim:20201127113455p:plain

スケジュールおよびその他の設定

次にジョブのスケジュールを設定します。スケジュールを設定せずにジョブだけ作成し、HBS3のコンソールから手動で実行することもできます。

f:id:junichim:20201127113710p:plain

画面下部にある『今すぐバックアップ』にチェックを入れておくと、ジョブ作成が完了したらすぐにバックアップがおこなわれます。

f:id:junichim:20201127113841p:plain

併せて、バージョン管理もここで指定します。

f:id:junichim:20201127113948p:plain

バージョン管理は、

  • 簡易バージョン管理
  • スマートバージョニング

の2種類から選択できます。前者の管理バージョン管理は、バックアップ数またはバックアップ日数による管理になります。スマートバージョニングは、日次、週次、月次のバックアップを何世代残す、というよくあるタイプの設定ができます(今回はスマートバージョニングにしました)。

次にバックアップ対象のフィルタリングなどを指定します(今回は試していません)。

f:id:junichim:20201127114527p:plain

この際、 QuDedup という機能を利用するか否かを指定します。

これは QNAP が提供するバックアップの効率化のための機能のようです。とはいえ、 QNAP が提供する機能なので、これを利用するということはバックアップファイルの復元時に、原則として QNAP の NAS が必要になることを意味します。なので、これを用いるかどうかは、バックアップしたデータをどのように復元したいかに応じて決めることになると思います(詳しくは後述します)。

もっとも、通常は QNAP の NAS 上から復元も行うと思いますので、デフォルトのままで問題ないかと思います(今回はデフォルトのQuDedup を利用する にしました)。

ここまで設定が完了すると、最後に要約が表示されます。

f:id:junichim:20201127114918p:plain

問題なければ、『作成』ボタンを押すとバックアップジョブが作成されます。

バックアップ開始

実際にジョブがスタートすると、QNAP の HBS3 上ではこのような感じで進捗状況を見ることができます。

f:id:junichim:20201127115053p:plain

S3 上の状態

さて、上記で作成したバックアップの完了後、 S3 上ではどのように保存されているかを確認してみました。

f:id:junichim:20201127132427p:plain

今回のバックアップジョブ名のついたフォルダ(disk01, daily Backup.qdff/)があるので、中を見てみると

f:id:junichim:20201127132600p:plain

こんな感じです。どんどんフォルダを掘り下げていっても、なじみのあるローカルフォルダにあったファイルは出てきません。単に、ローカルストレージのファイルがそのままS3上のオブジェクトになっているのかと思いきや、バックアップツール(今回の場合は QuDedup 機能が該当すると思います)が専用の形式にして保存しているようです。S3 は純粋なストレージ領域という扱いですね。

やはり前述したように、S3 上で直接ファイルを見ることはできないので復元には QNAP が必要になるということが、ここからもわかりますね。

バックアップができたので、次は復元も試しておきます。

バックアップジョブからの復元

復元も QNAP 上の HBS3 で行います。

HBS3 を開いて『バックアップ&復元』を選択肢、『作成』から『復元ジョブ』を選択します。

復元元のストレージとして『S3』を選択します。

f:id:junichim:20201127133218p:plain

『ソース』として『バックアップジョブ』を選択すると、下記のように複数のバックアップジョブから選択することができるようになります。ジョブを選択すると、自動的に関連する設定が有効になるそうです。

f:id:junichim:20201127133450p:plain

なお、『宛先』とあるのは日本語訳の問題のようで、ヘルプを表示させると

f:id:junichim:20201127133759p:plain

『ターゲットから復元』の意味だと思われます(『ターゲット』を『宛先』としたんでしょうね)。

バックアップジョブを選択すると、『ソースの選択』欄が表示されるので、

f:id:junichim:20201127134002p:plain

クリックすると、復元したいバックアップおよびフォルダを選択する画面になります。バージョン管理が有効な場合はどの過去バージョンを利用して復元するかも選択できます。

f:id:junichim:20201127134458p:plain

もし、バージョン管理がオフ(かつQuDedup無効)の場合はフォルダのみの選択ダイアログになります。

最後に、復元先を指定します。

あとはスケジュールで指定したタイミングで復元するか、スケジュール指定を行わずに手動で復元させるかを決めます。今回はスケジュールは指定しないが『今すぐ復元』にチェックをつけて、ジョブを作成後すぐさま復元を行うようにしました。

『ルール』では、復元時の各種設定を行うことができます(今回はデフォルトとしました)。

設定が終わったら、最後に要約画面が表示されるので、『復元』を押すと復元ジョブが作成されます。もし、『今すぐ復元』にチェックがついていれば続いて復元が実行されます。

f:id:junichim:20201127135024p:plain

復元中は下記のような感じでした。

f:id:junichim:20201127135339p:plain

復元ジョブが完了して、指定したフォルダを見ると、問題なくファイルが作成されていました。

バックアップジョブの設定内容とS3での状態

さて、バックアップジョブですが、いろいろと試してみると、

  • QuDedup 利用の有無
  • バージョン管理の有無

により、S3 上のオブジェクトの作成状況が変わるようです。

具体的には、

QuDeDup の利用 バージョン管理 S3での保存のされ方
あり あり qdff フォルダ内に専用のファイル形式
あり なし qdff フォルダ内に専用のファイル形式
なし あり qdff フォルダ内に専用のファイル形式
なし なし ローカル構成に基づいたフォルダおよびオブジェクト構成 + 管理オブジェクト

という感じでした。

qdff フォルダを利用している場合は、前述したようにローカルファイル単位でS3のオブジェクトが作られるのではなく、バックアップツールが独自の形式でローカルフォルダの内容を保存しているようです。このため、復元には QNAP もしくは後述する専用ツールが必要になります。

一方、QuDedup およびバージョン管理を共におこなわない場合は、バックアップの管理オブジェクトこそ追加されていますが、基本的にはローカルフォルダおよびファイルに対応して、S3上のフォルダ、オブジェクトが作成されていました。

このため、この方式でバックアップを保存した場合は、直接S3のオブジェクトを取得することで、ファイル単位でデータを取り出すことも可能です。ただし、S3上の最終更新日時はバックアップ時の日時となるため、取得したファイルの更新日時が元のファイルの情報を反映していないという状態になるので注意が必要です。

なお、念のために書いておきますが、QNAP の HBS3 の復元機能を使って復元すれば、この場合も正しい最終更新日時で復元することができます。

QuDedup Extract Tool による復元

あと、一つ気になったのが、S3 上で qdff フォルダを利用した形式で保存された場合、 QNAP の NAS がないとデータを一切取り出すことができないのか?という点です。 まあ、 QNAP の NAS に悪い印象は持っていないのですが、既存の QNAP の NAS が破損した場合などに、他社の NAS に乗り換えないとも言えません(何らかの事情でQNAP製品が入手困難になっていることなども想定されます)。その時、バックアップからデータが復元するすべがないとなるとかなり困ってしまいます。

実は、 QuDedup の紹介をよく読むと、 NAS がなくても、 OS 上にインストールするツール( QuDedup Extract Tool )があり、それを使うとバックアップからデータを取り出すことができるそうです。

ユーティリティ | QNAP

これがあれば、最悪何とかなりそうですね。これも試してみます。

qdff フォルダの取得

テスト用に、S3 から qdff フォルダ一式をダウンロードしておきます。

mor@DESKTOP-H6IEJF9:/mnt/c/Users/mor$ aws --profile xxxxxxxxxx s3 cp --recursive s3://my_bucket_prefix.backup.nas/tempBackup.qdff/ ./test/

(WSLで操作しています)

インストール

ツールのバイナリは、Windows、 Mac、 Ubuntu があるので、使いたいバイナリを選択します(今回はWindows)。 ダウンロードしたファイルをダブルクリックして、インストーラを起動し、画面指示に従ってインストールします。

復元

早速ツールを起動します(UIは残念ながら、英語と中国語のみのようです)。

f:id:junichim:20201127141507p:plain

初回起動時は設定画面が表示されますが、とりあえずはデフォルトのままとしておきます。起動すると、下記のような画面になるので、

f:id:junichim:20201127141537p:plain

中央の『Browse file』をクリックして、qdff フォルダを指定します。

qdffフォルダを指定すると、下記のようにフォルダ選択画面が出てきます。

f:id:junichim:20201127141633p:plain

このツールでは、フォルダ単位またはファイル単位で復元することができます。

f:id:junichim:20201127141944p:plain

復元したいものにチェックをつけて、『Extract』ボタンを押すと、

f:id:junichim:20201127142059p:plain

のように予想される復元容量に関する警告が表示されます。 『OK』を押すと、保存先を選択するダイアログが表示されるので、フォルダを指定します。

すると、ファイルがぶつかった場合の処理が尋ねられるので、

f:id:junichim:20201127142203p:plain

replace か skip かを選択します。 復元が完了したら、下記のように結果が表示されます。

f:id:junichim:20201127142314p:plain

復元先のフォルダを見ると問題なくファイルが復元されていました。

なお、QuDedup なしの場合でも、バージョン管理がありであれば、このツールで復元することができました。

一方、QuDedupもバージョン管理もない場合は、このツールでは復元することができません。一応バックアップフォルダ全体をS3からダウンロードして、このツールで読み込ませると、

f:id:junichim:20201127143556p:plain

のようにエラーにはなりませんが、ファイル・フォルダが表示されません。

要は、上述したように、バックアップ時に qdff フォルダが作成される場合は処理できて、その他は処理対象外になるということなんでしょうね。

雑感

というわけで、この QuDedup Extract Tool さえあれば、QNAP NAS がなくてもデータの復元ができそうです。もっとも、TB 単位などの巨大なバックアップを扱う場合は現実的ではないかもしれません。

ということで、バックアップデータのサイズや目的次第になりますが、qdff フォルダをローカルにさえ持ってこれれば、QNAP NAS がなくても取り出すことができるので、S3 から直接ファイルを復元する必要性を感じて、QuDedup やバージョン管理をわざわざ無効にしてバックアップを行う必要性はそんなになさそうですね。

バックアップジョブの削除

最後に、バックアップジョブを削除した場合、S3上のデータがどうなるか確認しておきます。

試してみると、 QNAP の HBS3 上からバックアップジョブを削除しても、S3の当該バケットからはバックアップデータは削除されませんでした。 まあ、バックアップデータなので、積極的に削除しないんでしょうね、きっと。

ですが、クラウド上のストレージの容量が気になるような場合は、不要なバックアップデータが残らないように手作業で消す必要があるので、その点だけ覚えておく必要がありそうです。

まとめ

クラウドバックアップ、便利ですね。なんで今まで放っておいたんだろうか?という気分です。 あとはクラウド上のストレージ容量と料金が気になるところですが、当面はデータ量も大したことないので大丈夫でしょう。

これで、データをクラウド上に残すようにでき、一安心です。よかった、よかった。