LS-WH2.0TGL/R1へのリストアでタイムスタンプが保持できない

この記事は2014/05/31に投稿の旧ブログ記事に掲載していたものです。一部修正、追記しています。

自宅のNAS LS-WH2.0TGL/R1 の障害発生でリストア作業を行い、その手順について書きました。

ところが罠があったのです…。

タイムスタンプが違う

バックアップ用 USBHDD からデータを戻したところ、タイムスタンプが保持されていません。

LinkStation のバックアップ機能で USBHDD（FAT32)にコピーされたデータは
作成日時：バックアップデータが作成された日時
更新日時：元ファイルの最終更新日時を保持（多分）
になっているようです。

対して、LS-WH2.0TGL/R1に戻したデータは
作成日時：LS-WH2.0TGL/R1へのコピー日時
更新日時：LS-WH2.0TGL/R1へのコピー日時
です。

要するに全ファイルのタイムスタンプがバックアップを戻した日時で更新されており、タイムスタンプ管理することができなくなってしまいました。

お客様サポート > 旧製品向け「よくある質問」 > LinkStation、TeraStationにコピーしたファイルのタイムスタンプについて
によるとWindowsとLinkStation独自OSで時刻情報管理方法が異なるとのこと。

というか、LinkStation ではそもそもタイムスタンプによる管理を推奨していませんでした…。

LinkStation、TeraStationを使用する際の共通ポイント
Q:タイムスタンプ（更新日時）を基準にしたファイル管理はできますか？
A:LinkStation、TeraStationに採用されているOSの仕様上、タイムスタンプが正常に保存されない場合があります。
そのため、タイムスタンプを基準にしたファイル管理はお勧めできません。

知らなかった…。ていうかそれでいいのか。
＃差分バックアップを取ったことがなかったけど、そこら辺はどうなってるんだろう？

ですが更新日時を保持してくれないと色々不便です。なんとかタイムスタンプを保持してデータコピーする方法がないか、調べてみました。

以下、記録が間違ってたらスミマセン。

色々試してみた

結論だけでよろしければ robocopy を採用 以降を参照下さい。

Windows Explorer 標準機能でコピー

まずこれがダメでした。

Windows Explorerでは
フォルダ作成日時：LS-WH2.0TGL/R1へのコピー日時
フォルダ更新日時：LS-WH2.0TGL/R1へのコピー日時
ファイル作成日時：LS-WH2.0TGL/R1へのコピー日時
ファイル更新日時：LS-WH2.0TGL/R1へのコピー日時
になりました。

xcopyコマンドでコピー

xcopyでは
フォルダ作成日時：LS-WH2.0TGL/R1へのコピー日時
フォルダ更新日時：LS-WH2.0TGL/R1へのコピー日時
ファイル作成日時：元ファイルの更新日時
ファイル更新日時：元ファイルの更新日時
になりました。

FTP経由でコピー

FTP（FFFTP使用）では
フォルダ作成日時：LS-WH2.0TGL/R1へのコピー日時
フォルダ更新日時：LS-WH2.0TGL/R1へのコピー日時
ファイル作成日時：LS-WH2.0TGL/R1へのコピー日時
ファイル更新日時：LS-WH2.0TGL/R1へのコピー日時
になりました。

FFFTP Q&A集
アップロードしたファイルのタイムスタンプが変わらないようにしたいのですが。

アップロード時にはタイムスタンプは維持できません。これはサーバーを含めたFTPのシステムとして、タイムスタンプを維持できるような仕組みになっていないためです。
アップロードしたファイルのタイムスタンプは、サーバーが決定します。

robocopyコマンドでコピー

robocopy（オプションは /E のみ）
フォルダ作成日時：LS-WH2.0TGL/R1へのコピー日時
フォルダ更新日時：LS-WH2.0TGL/R1へのコピー日時
ファイル作成日時：元ファイルの作成日時
ファイル更新日時：元ファイルの更新日時
になりました。

robocopy（オプションは /dcopy:T /E /FFT）
フォルダ作成日時：LS-WH2.0TGL/R1へのコピー日時
フォルダ更新日時：元フォルダの更新日時
ファイル作成日時：元ファイルの更新日時
ファイル更新日時：元ファイルの更新日時
になりました。

robocopyを採用

robocopyが最も希望に近い動作をしました。

robocopyコマンドはWindows7なら標準のコマンドになっており、特に何かをインストールしなくても使うことが出来ます。

コマンドは以下の通り。書き換えてコマンドプロンプトで実行してください。”コピー元フォルダ”と”コピー先フォルダ”、ログの出力が必要なら”ログファイル”を書き換えて下さい。/LOG:”ログファイルパス”はログ出力が不要なら削って下さい。

C:\>robocopy "コピー元フォルダ" "コピー先フォルダ" /dcopy:T /E /Z /FFT /TEE /XJD /LOG:"ログファイル" 

その他のオプションを含むrobocopyのヘルプはコマンドプロンプトで robocopy /? を入力すると参照できます。

私は他にもログ関連などを更に追加して指定していますが、最低限 /dcopy:T /E /Z /XJD、バックアップデータがFAT32形式なら誤差が出るので /FFT を指定しておくのが良いでしょう。一度処理中にケーブルが抜けてしまいましたが、/Zを指定してあったものは待機してくれました。また、後述する無限ループは/XJDを追加すると対処できるようです。

robocopyの罠

他のコピー方法では分かりませんが、少なくともrobocopyには罠があって %userprofile%（C:\users\アカウント）\AppData（隠しフォルダ）のコピー時に無限ループで Application Dataフォルダを作成していきます。

原因を予想して回避方法を書いてくれているブログがありました。
robocopyがシンボリックリンクに捕まってしまってうまく動いてくれない→/XJDオプションでうまくいった

/XDでディレクトリ（フォルダ）ごと除外する方法でも良い（私は実際はそうしました）ようです。しかし他にもシンボリックリンクがあるかもしれませんから/XJDの方が良いかも。
%userprofile%（C:\users\アカウント）フォルダのバックアップ時には /XJD か /XD AppData が必須ですね。

無限ループに陥ったことに気付かずにコマンドを実行して気付かずに長時間放置しているとどんどん階層が深くなりWindows Explorerを使った削除では消すことができなくなります。対処法は以下の通りです。

1. 上位のフォルダからフォルダ名を適当な一文字（1とかaとか）にリネーム。Windows Explorerがエラーを出す階層まで行います。
2. Windows Explorerがエラーを出したフォルダの”Application Data”フォルダを削除。

私は数時間放置してしまったためそれでも削除できませんでした。

ふとrobocopyでディレクトリが作れるんだからrobocopyで削除できるんじゃないか、と空のフォルダを作成してミラーリングオプションをつけ、消したいフォルダと同期してみました。

これが上手くいき、全部とは行かないまでもExplorerで削除実行できるまで階層が浅くなり、空フォルダとのミラーリングとリネームの合わせ技で削除することが出来ました。

まとめ

今後はローカルPCからLinkStationへのバックアップもrobocopyを使うことにしました。Windows Explorerより早いようですし。

毎回コマンドを手打ちするのはミスの元なので私はバッチファイルを作成して実行しています。

関連記事