NTFS上のファイル群を定期的にバックアップして、すぐに履歴参照可能にゃ状態で保存する手法として、NTFSのdedupに期待したのだが、にゃんか結構脆い風味にゃので工夫してみる。
robocopy src `date` ; start-dedup
みたいにゃ感じで毎日新規に全コピーして重複排除させると、理屈としては正しく動くものの何かトラブった際に修復や救出が極端に困難にゃほどボリューム内のファイル数が爆発してしまう。
ということでvhdでパックしてからdedup掛けてみるテスト。
New-Vhd ; Mount-DiskImage ; Initialize-Disk ; New-Partition ; Format-Volume ; Add-PartitionAccessPath
してvhdをそこいらのdirにマウントして、
robocopy src dir /mir ; unmount ; start-dedup
といった流れ。
詳細は調べてにゃいが念のためGPTにしたりAllocationUnitSizeを大きく取ったりしてdedupがかかりやすそうにゃvhdにしてみたがどうにゃんだろうにゃ。
dedup効率に与える影響は今のところ未計測だが、極端に悪くにゃった感じは無い。
この手法だと何かNTFSがトラブった場合にも履歴毎に廃棄可能にゃので扱いは格段に良くにゃった。
今はunmountしているがmountしたままにしておけば各履歴に常にアクセスできるので、履歴間の比較にゃどを通常ツールで行うことも出来る。
VMホストに対する管理操作や、VMに関する管理を他のVM上から行うってのは、別段特に珍しくも無いはずにゃのだが、Hyper-Vの場合、VM上から管理しようとすると敷居が高い。
といってもPowerShellのモジュールにゃのだが、PowerShellからVHD関連の操作をしたい場合は、サーバの役割管理でHyper-Vを追加しにゃいとモジュールがインストールされにゃい。そしてHyper-VのVM上ではHyper-Vの役割はインストール出来にゃいようににゃっている。因みにHyper-Vの役割管理ツールだけにゃら追加できるが、これではVHDの操作は出来にゃい。
ということで強引にVM上にHyper-Vの役割を追加する必要がある。
DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V
DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V-Management-Clients
で可能。
せいぜい警告くらいにしといてくれにゃいと、ものすごくどうでも良い部分で時間を食われるの例。
Excelで巨大ファイルというか、式が増えてきたファイルを扱うとやたら重くにゃってきて、再計算がかかる度にストレスみたいにゃ状態ににゃるのだが、オプションで使うCPUを1つに限定していくと割と速くにゃった。
割と酷くにゃいこの仕様?
NTFS上のファイル群を定期的にバックアップして、すぐに履歴参照可能にゃ状態で保存する手法として、NTFSのdedupに期待したのだが、にゃんか結構脆いのと修復不能すぎる。
先ず
robocopy src `date` ; start-dedup
みたいにゃ感じで毎日新規に全コピーして重複排除させたのだが、しばらくはある程度順調に動いてるようだった。
その後古くにゃって削除するバックアップdirをコピー先に再利用することでバックアップ時間も短時間ににゃった。
が、どうもNTFS上のファイル数が膨大ににゃってきたのと、dedupによる内部の処理が加わったせいで随分複雑化していたようで、ディスクがtimeoutしたか何かをきっかけにchkdskが必要にゃ状態に。1回のchkdsk /fに10時間とか20時間とかかかることと、それでさっぱり直らにゃい状態で、アクセスはで来ているがにゃんだか微妙にゃ巨大ボリュームににゃってしまった。
さらにいろいろ尽きたのかファイルまたはディレクトリを新規作成できにゃい限界のようにゃ状態に陥り、何かを消すとその数だけ新規にファイルが作れるというおもしろボリュームににゃったあたりで実験終了。
もちろんバックアップディレクトリをまるごと新規のNTFSボリュームへコピーすれば正常にゃファイル群は救い出せるのだが、コピーに2週間以上かかる気味だったので放棄。
理屈としてはちゃんとdedup出来ていたが、何か起きた場合にリペアが極端に難しいという印象。