目次
一筋縄では行かないNASによるバックアップ
鉄壁のバックアップ体制を築くべく、今年の3月に大枚はたいてSynologyのNASを購入しました。4ベイの中級クラスの製品です。
早く使いこなしてこれに関する記事をアップしたかったのですが、ずーっとスッキリしない状態が続き、その原因を見つけて問題点を解決するまでに半年ほどかかってしまいました。
SynologyのNASは多機能で信頼性も高い素晴らしい製品なのですが、多機能故に使いこなしがかなり難しいのも事実。巷では(Synology に限らず)NASを買えば安全確実なバックアップ体制が築けると語られることもありますが、油断は禁物。
なまじバックアップについて詳しいと自負しているような半可通(=わたしのことですが)はドツボにハマりやすいと思います。この記事では、わたしが経験したトラブルの内容と原因についてご紹介します。
トラブル発生の経緯
NASは色々と難しそうなので、導入時からアプリのインストールや設定の変更などをすべて記録していましたが、今回のトラブル解決では、以前のどの操作が悪かったのかを調べるのにこの記録がとても役立ちました。
変更したファイルがもとに戻っている
今回のトラブル発生に気づいたのは、他ならぬそのNASへの操作を記録したエクセルファイルでした。
以前修正したはずなのに、次にファイルを開いたら、それがもとに戻っている気がしたのです。そこでわたしが愛用している検索ソフトEverithingでNASのネットワークドライブも合わせて検索したところ、Dドライブの原本とSynologyのNASによるネットワークドライブを割り当てたSドライブのバックアップ各1個が存在すべきところ、加えてさらに3つのバージョンが存在していました。しかも、作成日が全部違っています!この検索結果を見て、ちょっとくらくらしてしまいました。(なお、調べてみると、ファイルがコピーされたものである場合、「作成日時」はファイルがコピーされた日付になるとのこと。よって、この場合に重要なのは「更新日時」の方だったので若干安心したのでした。)
他のファイルはどうなっているか?
他のファイルも検索してみると、一番ひどかったのはわたしがエクセルにつけている家計簿のファイルで、前項と同じ現象でで発生している5つのファイルに加え、ファイルの構造をいじった時にバックアップとして保存しておきながら消し忘れていた家計簿2という名称のファイルがやはり5つ、ついでにファイルの変更日に矛盾があって作られたらしいファイル名にconflictと入ったファイルが2個、合わせて12個も。
そう言えば、以前に思い当たることがありました。
私はファイルに連番を付けて管理しているのですが、この連番は月末などにまとめてリネームしているのでそれまでは連番のつかないファイル名で保管されています。
しかし、NASを導入した後、連番をつけ終わったファイルと連番を付ける前の状態のファイルが混在していたことが何度かあり、このときは根本原因がわからずとりあえずの処置で切り抜けたつもりになっていました。
ファイルが増えた原因を調べる
内容が込み入っていますので読むのが面倒な方は飛ばして次項へ
過去に行った操作
このファイルの増殖に関係のありそうな過去の操作は以下の通りです。
ポイントは、バックアップに使用するアプリを何度か変更し、合わせてファイルの保存先も変えていることです。
①2019年3月 アプリDriveをインストールしてデスクトップPCの自作1号をバックアップ開始
②2019年4月 Driveによるバックアップはフォルダーの細かい指定ができないので、それが可能なCloud Station Backup に乗り換える
③2019年6月Cloud Station Backupは双方向のバックアップ(つまり 同期)ができないため、自作1号のDocumentフォルダーのみ同期が可能なCloud Station Drive によるバックアップに変更。(ただし、既にアップロードしたファイルを生かすため、NASのバックアップ先は CloudStation\Backup のままとした)
④2019年7月2日 自作1号の起動ドライブをSSDに変更。クローンソフトでディスクをコピーし、問題なく終了。
⑤(タブ29) 2019年7月8日 自作1号のDocument フォルダーが6月上旬からバックアップされていないことがわかり、取り急ぎDocumentフォルダーをCloud Station Backup によるバックアップに戻す。(NAS側のバックアップ先は CloudStation\Backup のまま)
⑥(タブ30) 2019年7月13日 自作2号にCloud Station Drive をインストールし、Document フォルダーのバックアップ開始。(日にちの根拠は TD-1907048 ((IT パソコン自作))自作2号再立ち上げ手順記録.xlsx)
ところがこの操作の後、リネームソフトFlexiblerenamerを使ってファイル名を変更したはずの古い名前のファイルが湧き出してくる。
⑦(タブ30) 2019年7月13日⑥の対策として、半ば当てずっぽうでNAS側のバックアップ先を CloudStation\Backup から、Cloudstation\Drive に変更する。
⑧2019年9月1日 自作2号のファイル同期が7月13日で止まっているのを発見し、同期タスクを作り直す。
この時、Cloud Station Drive の、PC側のバックアップ先を誤って D\Document\CloudStation\ としてしまうが、そのときは気づかず。
⑨この状態でバックアップを開始するが、自作2号の文書ファイル保存先である D\Document\Googledrive 内のファイルは一向に新しくならない。
⑩状況をきちんと把握せずにもう一度同期タスクを作り直す。このときはPC側のバックアップ先を D\Document としたため、今度は想定通りD\Document\Googledrive内のファイルが新しくなった。
と書いてみましたが、これを読んでもよくわかりませんね。書いた本人でもわからなかったのですから。
バックアップアプリと特徴、標準の保存先
この特徴、大した話ではないのですがソフトのマニュアルは細かい話ばかりでこういう大枠の使い分けはどこにも書いてありません。何ヶ月か使ってやっとわかりました。(この詳細については追って別の記事でご紹介する予定です。)
ここで「NASの標準的なバックアップ先」とありますが、普通に操作していればバックアップ先はこの通りになりますが、それを自分の都合で変えてしまったのが今回の諸悪の根源でした。 この表で使用した文字の色は以下(表2)、(図1)においても共通です。
時系列で表にすると…
前項の箇条書きはとてもわかりにくいので表にしてみます。うーん、横に長すぎ。そしてまだわかりにくい。
ちなみに、丸付き数字は前項の箇条書きの番号に対応しています。
また、赤枠で囲った部分はトラブル発生の原因となった部分です。
更にこれを図にしてみると….
矢印の色はバックアップに使用したアプリを示します。また、丸付き数字は箇条書きの番号に対応しています。
何が悪かったのか?
問題が発生した操作は(表1)の赤枠で囲んだ部分ですが、これは次の二種類に分類できます。
A.バックアップ先を(表1)に示す推奨フォルダーに指定しなかった
具体的には、操作③と⑥において、バックアップのアプリはClous Station Driveを使っているのにNASのバックアップ先を標準外の\home\Cloudstation\Backup に指定している操作です。
(図1)でいうと、青いフォルダに向かっている緑の矢印( ③と⑥の二本 )です。
B. バックアップ元の設定を間違えた
具体的には、操作⑧、⑨、⑩において、自作2号のバックアップ元を間違えて自作2号\Mydocument\CloudStation に指定してしまい、それに気づいてすぐにこれを自作2号\Mydocument に戻した操作です。
詳細
わかりにくいので詳細を説明します。
以下のような現象が発生したものと思われます。ここも、結論が早く知りたい方は読み飛ばしていただいて結構です。
A. の詳細
バックアップアプリとしてCloud Station DriveとCloud Station Backupが共存している状態でCloud Station Drive によるNASのバックアップ先を\CloudStation\Backup に指定すると、バックアップをかけてもNAS側(\CloudStation\Backup内)のファイルはバックアップされなくなってしまうようです。ところがこの時、NAS→PCのバックアップは行われるため、リネームによってPCから無くなった古い名前のファイルがNAS→PCへバックアップされたものと思われます。
B. の詳細
誤って一時的にPCのバックアップ元を自作2号\Mydocument\CloudStation に指定した時に、NASの\home\Cloudstation\Driveにあったファイルが自作2号\Mydocument\CloudStationに一式コピーされてしまいました。そして、慌ててバックアップ元を自作2号\Mydocumentに戻した時に、いわば「入れ子構造」になった自作2号\Mydocument\CloudStationフォルダーがNASの側にバックアップされてしまった模様です。
つまり、
1. 自作1号にあったファイルはバックアップによってNASにコピーされますが、この時何故か自作2号にはコピーされなかった。(この原因は今に至るも不明です)
2. 異常に気づいて修正を試みるが、自作2号のバックアップ元を間違えて指定したため、自作2号\Mydocument\CloudStation の中にファイルが一式コピーされる。
3. 操作を間違ったことに気づいてバックアップ元を 自作2号\Mydocument に戻したところ、今度は自作2号\Mydocument\CloudStationがNASの\home\CloudStation@Driveにコピーされました。
4. そして、バックアップによって自作1号、自作2号にNASの中味がコピーされました。
この状態で自作1号からファイルを検索すると、PC内に2つ、NASの中には以前、アプリにDriveを使っていたときの残骸も含めて3つ、合計5つのファイルが出てきたという記事冒頭の状態になります。
傾向と対策
A. バックアップが停止してしまうのを防ぐには?
→(表1)にあるアプリに応じた推奨保存先を使用する
例えばCloud Station Driveでバックアップ元を指定する時、推奨外のフォルダーを指定しようとすると下記のような警告が出ますので、これが出たら素直にNASの指示に従いましょう。
既にバックアップした別のフォルダー が存在する場合、ついそちらを指定したくなるのですが、これをやってしまうとバックアップが止まってしまう可能性があります。
B. 入れ子構造になってしまうのを防ぐには?
→Cloud Station Driveのセットアップでチェックを入れるか、入れないかを間違えない
これは非常に間違いやすい盲点だと思います。具体的には、
Cloud Station Driveのセットアップを勧めていくと…
バックアップ元を確認する下記ような画面が出ます。ここで注意すべきはこのバックアップ元を変更する場合です。
これを変更しようとすると下記の画面になります。ここでバックアップ元を指定する際に、「空白のCloudStationフォルダを作成」というチェックボックスにチェックを入れるか入れないか、どちらかに統一しておかないといけません。
私がやってしまったのは、デフォルトで入ってくるチェックマークを消し忘れてバックアップを作動させ、間違いに気づいて今度はチェックマークを消してまたバックアップしてしまうというミスでした。
これによって上でご説明したような入れ子構造になってしまいました。
チェックマークを入れるか入れないか、どちらかに決めたら以降は変えてはならない、ということです。
まとめ
今回発生したトラブルの遠因は、バックアップに使うアプリを変更したことです。従って、
- Synology のNASを使い始めるに当たっては、後で変更しないで済むよう各バックアップ用アプリの特徴を踏まえて慎重に選択しなくてはなりません。
また、やむなくバックアップに使用するアプリを変更する場合、下記に気をつけましょう。
- NASが指定する標準的なバックアップ先を使用する
- バックアップ元を指定する際、「空白のCloudStationフォルダを作成」にチェックを入れるか、入れないかを変更しない
以上、読んでいただき、ありがとうございます。