私は写真ファイルをはじめとして大切なファイルを RAID で管理して、かつ定期的にクラウド (AWS) に自動バックアップする運用をしていますが、ある時 NAS 上で実行する NAS → S3 Glacier のバックアップジョブがうまく動作しなくなりました。自分では原因を特定することは出来なかったのですが、QNAP サポートチームの分析によってその原因はシンボリックリンクを使っていることだ、と分かりました。一時的に解決はできたものの再発してしまったため、それをようやく半ば強引にシンボリックリンクを解消した、というほとんどの人には関係の無い作業メモです。ただし、QNAP (もしかしたら他の Linux ベースの NAS でも) ユーザーはチラッと頭の片隅に置いておいても損はない情報だと思います。
<2022/12/20 追記>
強引な対応実施後しばらく問題はなかったのですが、NAS の再起動後問題 (Backup Job は fail する) が再発したため、これが恒久的な対応だと思われる対応をして追記しました。
- 私のバックアップ運用 - QNAP NAS と AWS S3 Glacier によるバックアップ
- S3 Glacier へのバックアップジョブが動かなくなった - 原因はシンボリックリンクらしい
- バックアップジョブ失敗の原因のシンボリックリンクを解消する (#1, 暫定対応)
- バックアップジョブ失敗の原因のシンボリックリンクを解消する (#2, (多分)恒久対応)
- 初心者でも気をつけること
私のバックアップ運用 - QNAP NAS と AWS S3 Glacier によるバックアップ
私は重要なファイルは RAID 1 構成の NAS (QNAP TS-453Be ) に置き、そのバックアップを定期的に AWS Glacier に取得しています。ざっくり毎月 AWS に 1$/1TB月 くらい支払っていますが、万一大地震で NAS が壊れても、週一回バックアップしている S3 からリストアできると思えば安いものでしょう。今時のサブスクに比べれば安いものです。
S3 Glacier へのバックアップジョブが動かなくなった - 原因はシンボリックリンクらしい
そんなクラウドバックアップで安心をしていたのですが、今年に入ってから二つあるバックアップジョブのうち一方だけに問題が発生しました。
「たまに」"Source folders do not exist. " でバックアップジョブがエラーになる
QNAP では問題を報告するとアドバイスをもらえるサポートがあり (英語)、何回か利用していました。自分が書いた履歴を見ると、年初 (2022/02) からたまに "Source folders do not exist. Check the job configuration." とのメッセージを残してバックアップジョブが失敗することがありました。 NAS 側で問題判別のための詳細な資料が取れるので、それを QNAP の窓口に送付したりやりとりしていたのですが原因がわからず、4月にQNAP のテクニカルサポートチームから私の NAS に直接アクセスしてもらい、直接確認してもらうことになりました ("Help Center" アプリに "Help Desk" という機能があります）。
QNAP のリモートサポートで判明したこと
いくらテクニカルサポートとは言え、個人の NAS の内部にアクセスするのですから、特定の id に権限を与えるなどセキュリティ上の儀式が必要です。さらにこの時は TeamViewer アプリを用いて、実際にテクニカルチームが何を操作しているかこちらでもわかる状態で作業していました（「見える」というだけで具体的な作業内容までは理解できませんでしたが）。
この時点では、
*This folder'symbolic link has problem ,so we fix it. *
ということで再びバックアップジョブは動くようになりました。TeamViewer ではチャットしながらのやり取りで、私の拙い英語力では十分に詳細までは理解できませんでしたが、どうやら私の NAS の設定には "Multimedia" というシンボリックリンクが設定されていること、私が "Multimedia" としてアクセスしていたのは別の名前のフォルダであった、ということだけは私も確認し、そのシンボリックリンク自体は残ったままとなりました。
根本原因は NAS セットアップ時におかしな設定をしてしまったかも
どのようなシンボリックリンクかというと、多分私が作成したと考えられる "/MultimediaBeOK" というパス (実フォルダ) に対して、"Multimedia" というシンボリックリンクが設定されていたのです。
自分でもはっきり覚えていませんでしたが、旧 NAS (TS-431p) から現在の NAS (TS-453Be) にデータ移行する際に、同じ "Multimedia" というパスだとコピー元と先が分かりにくいので、わざわさコピー先 NAS のモデル名の一部 "Be" をフォルダ名に含めたような気がします。そして共有フォルダとして設定する際に、"/MultimediaBeOK" に対して "Multimedia" と設定してしまった可能性があります。
これにより、実フォルダとして初期設定時から存在していた "/Multimedia" とは別に、別フォルダを指し示す同名の "Multimedia" というシンボリックリンクが同時に存在することになったのだと思います。
バックアップジョブが正常終了したりエラーになったり、という intermittent な現象になった理由は説明できません。しかし、シンボリックリンク "Multimedia" の下にあるファイルをバックアップしようとしたジョブが、実フォルダ "Multimedia" の下を見に行ったら対象のサブフォルダやファイルが見つからずに "Source folders do not exist." となってしまった、という話には納得ができます。
バックアップジョブ失敗の原因のシンボリックリンクを解消する (#1, 暫定対応)
とりあえずはバックアップジョブがちゃんと動くようになったので、シンボリックリンク "Multimedia" の存在自体はしばらくどうしたものか？と思いつつ放置していました。ところが 7月からまたそのジョブがエラーとなり、その後は何度実行してもエラーのままとなってしまいました。
Web UI ではシンボリックリンクの変更は出来なさそう
実際に ssh で NAS にアクセスし、コマンドでシンボリックリンクを解消したりするのが本筋の解決方法だと思いますが、あまり自分のスキル以上のチャレンジしても不安があるので、QTS と呼ばれる QNAP の管理 UI でできる範囲の対応をしようと思いました。しかし、QTS のコントロールパネルでは実フォルダ名とは異なる名称（シンボリックリンクが設定されている）ことは確認できますが、表示がグレイアウトされているため変更をを加えることはできません。
仕方がないので、別にシンボリックリンクを使わない共有フォルダを作りそこで運用するようにしようかと思いました。試しに共有フォルダ "Multimedia0" を作成する UI 上で実パスを設定するドロップダウンを見ると、実フォルダ "/Multimedia" が選択できるではないですか。本当は "Multimedia0" という実フォルダを作成しようと思っていたのですが、試しに実フォルダ "/Multimedia" を選択してみました。
強引に path "/Multimedia" を削除したらジョブが正常実行できた
さて、コントロールパネルの共有フォルダで確認すると、問題のある "Multimedia" はグレイアウトされているのに "Multimedia0" はグレイアウトされていません。ということはこれに対する変更が行えるわけで、これを選択した上で "Remove" を行ってみました。
すると Remove することができてしまいました。つまり共有フォルダ "Multimedia0" とともに 実フォルダ "/Multimedia" も削除されてしまったのです！
この状態で今までエラーになっていたバックアップジョブを実行するとちゃんと S3 Glacier Deep archive にバックアップを取ることができました！
やはりシンボリックリンクと物理フォルダで、同じ名称が別の物理フォルダを指している状況が解消されることで問題は発生しなくなった、と考えてよさそうです。
次回 (?) のために --- デフォルトの共有フォルダーの復元
これ以上の問題は無いことを祈りたいですが、もし物理フォルダ "/Multimedia" を消してしまった影響が出た場合には、以下の方法を試そうと思います。一旦 "Multimedia (path "/MultimediaBeOK") 内部のデータをどこかにバックアップしてからですが、こいつを削除する UI メニューはなさそうなのでそのまま下記の手順を実行する物理フォルダ "Multimedia" を共有フォルダとするものが設定されるはずです。もちろん物理フォルダ "/Multimedia" を復元しようとしても今あるシンボリックリンクの "Muktimedia" と競合するのでは無いかと思いますが、UI からこれ以上何かを行うとしたらこのくらいしか作戦はなさそうです。
1.［コントロールパネル］ > ［権限］ > ［共有フォルダー］ > ［共有フォルダー］に進みます。
2.デフォルトの共有フォルダーの復元］をクリックします。
警告メッセージが表示されます。
3.［OK］をクリックします。
バックアップジョブ失敗の原因のシンボリックリンクを解消する (#2, (多分)恒久対応)
3週間ほど上記の暫定対応で問題なく定期的なバックアップも取得できていたのですが、NAS の Firmware アップデートで restart したせいか、それ以降問題が再発してしまったので、「次回のために」とメモしておいた「デフォルトの共有フォルダーの復元」を行い、Job が正しく動き、かつ NAS を restart しても Job の実行に問題がないことを確認しました。
バックアップジョブ失敗が再発
先日、年末大掃除を兼ねて NAS の久しぶりの reboot と firmware の更新をしました。するとどちらの影響かわかりませんが、再び "Source folders do not exist." でバックアップジョブが fail していました。
もしかしたら NAS の再起動で削除したはずのデフォルトの "/Multimedia" のフォルダが復活したのかと思いましたが、存在しませんでした（shared folder 設定の "Enter Path Manually" で確認）。もうこうなったら私にできることは前回メモした「デフォルトの共有フォルダーの復元」つまり、実態のフォルダ "/Multimedia" を復元するとともに共有のための名称もそのまま "Multimedia" とするしかありません。
既存のシンボリックリンク "Multimedia" を解消する
実はこのための方法は明確に思い浮かばず、前回手をつけられなかったのですが、以下の操作をしたらうまくいきました。
現状
フォルダ "/Multimedia" --- 存在せず
フォルダ "/MultimediaBeOK" --- 存在し、これに対するシンボリックリンクが "Multimedia"
以下の操作を実施
新たに共有フォルダ "MultimediaBeOK" を作成し、path manually でフォルダ "/MultimediaBeOK" を指定
「デフォルトの共有フォルダーの復元」を実行(コンパネ).
状態の確認. 上記 2 実施の直後に File Station で共有フォルダの状況を確認すると、下記二つの共有フォルダの存在が確認できた。
共有フォルダ "MultimediaBeOK" --- 中身は既存の "Multimedia"
共有フォルダ "Multimedia" --- 中身無し
ファイルの移動. File station で "MultimediaBeOK" の中身を "Multimedia" に "Move to" で移動。
既存のバックアップジョブの実行 実行前にバックアップの Source folders を確認すると、"Multimedia" の(に移動された) フォルダが選択されたままになっていた。ちなみに "MultimediaBeOK" は選択されていなかった。この状態でジョブを実行し OK。念の為 NAS を reboot しても OK であることを確認。
初心者でも気をつけること
確実なスキルが無い私の納得のレベルであれこれ細かいことを書きましたが、一般ユーザーレベルで気をつけなくてはならない範囲で注意点をまとめると、
デフォルトの共有フォルダ(注)名 と同じ名称の共有フォルダを新たに作成してはいけない。
注) Multimedia, Public, Homes, Web
ということでしょうか。
さらにいうと、共有フォルダ作成の際にはできるだけ "specify path automatically" を選択するようにし、どうしても手動で既存のフォルダを指定したいのであればそのことをしっかり覚えておくこと、間違っても Multimedia, Public, Homes, Web を指定してはならない、ということでしょうか。このルールを破ったから即時にエラーが発生するわけではないと思いますが、何かしらのジョブにこれらの共有フォルダを指定した時の動作には予想し難い結果が伴う可能性があります。
