IT関連情報

2017/03/25

FreeNAS Corral の命名の理由?

FreeNAS 10.0 が FreeNAS Corral と名前を改めたことは先週の記事でお知らせしましたが,この命名の由来については,FreeNAS Forum で尋ねられたにも関わらず,明確なことは明らかにされていません.

しかし,Corral 本来の意味は,アメリカ西部開拓時代に野営をする際に馬車で野営地を取り囲むように円陣を組んだ,というものです.さらに,FreeNAS Corral になってから毎度お決まりのように出てくる六角形の囲いのシンボルが,まさにこの円陣を表していると思われることから,NAS のみならず Docker などの仮想化プラットフォームすべてを内包した新たなコンピューティング・プラットフォームという意味で Corral という命名をしたのではないかと思われます.つまり,かなり野心的に風呂敷を広げてプロモーションを開始したと見て取れます.

映画好きの人にとって,この Corral という単語は “OK 牧場の決闘” という繰り返し映画化されたモチーフ(*1 *2 *3 *4)に使われていることで有名で,いわばアメリカ版忠臣蔵のようなお話です.日本語では “牧場” と訳されていますが,これは本来は “牛囲い” とでもいうべきもので,町はずれの,カウボーイたちが町にやってきたときに一時的に牛を預かっておくための囲い,という意味なのですが,この単語が IT の分野で使われるようになったというのは,非常に感慨深いものがあります.

| | コメント (0) | トラックバック (0)

2017/03/20

FreeNAS Corral Out

Windows Home Server 2011亡き後,ハードウェアはそのままに “FreeNAS” というフリーのNAS OSをインストールして試用しています.これまで “FreeNAS 9.10.2-U2” というFreeBSD 10.3ベースのバージョンをインストールし,クライアントのバックアップ用として便利に使ってきました.

開発中だった新しいバージョン “FreeNAS 10 Corral” が3月中旬にリリースされたのでさっそくインストールしてみたのですが,


  • Volume の設定がちゃんと引き継がれていないように見える

  • SMBNFSなどのServiceの設定がうまく引き継がれない

  • ファイルやディレクトリのPermissionの設定方法がよくわからない

という状態で,NFSマウントができなかったり,Windowsのシステムイメージのバックアップ先にSMBマウントしたData Setを指定すると,Windows が “0x8078006F” というエラーを吐いてバックアップできないなどという症状なので,元の “9.10.2-U2” に戻してしまいました.Corral-U1が出るまでは静観するつもりです.

システムを設定するためのGUIが大幅に変更になったこともあり,特にPermissionの設定法がよくわからないままです.ベースOSが “FreeBSD 11.0” になったり,Dockerなどの仮想化機能が強化されたりしていますので,プラットフォームとしては非常に魅力的なのですが,設定方法の変化があまりに大きすぎてちょっとついて行けません.

もうしばらくすると解説記事が出回るだろうと思いますので,それを読んで勉強したいと思います.

| | コメント (1) | トラックバック (1)

2017/01/09

IOC List v7.1 Released

IOC World Bird List v7.1 が2017年1月8日にリリースされました.前回 v6.4 のリリースが2016年10月22日だったのですが,今回は通常の3か月のピッチよりもやや早く出されています.これは担当の委員が旅行に出る必要があるため,前倒しされたのだそうです.

そのせいもあってか,今回の変更は少なめです.今回収録されたのは,科が 238,科が未確定の属が 2,属が 2,294,現主種が 10,660,絶滅種が 155,亜種が 20,358 です.ただし今回アナウンスされた重要な点は,最新の研究の進展に伴い,旧来の鳥類分類体系を書き換える時期に来ていること,そのため,2017年中を目標に新たな分類体系に移行する予定であることです.このための前準備なのでしょうか,これまで記載がなかった上目 (Superorder) の PALEOGNATHAE(古顎類)NEOGNATHAE(新顎類)や,系統群であるNEOAVES がリストにこっそりと載っています.

また,これも下準備なのかもしれませんが,これまで,分類のトップバッターだったTINAMIFORMES(シギダチョウ目)が,CASUARIIFORMES(ヒクイドリ目)の後ろに来るなど,並べ方の順序も波乱が予想されます.


IOC 本家の Master List を編集して,Refsort/Ruby 用の辞書ファイルを作りましたので,このブログサイトと,Microsoft One Drive 上に設けた “IOC List Archive„ にアップロードしておきます.

今回もこの辞書ファイルの正式なエンコーディングは UTF-8 です.従って,Linux 上で使う分には問題は生じませんが,Windows 上で使う際には,入力ファイルは UTF-8 でエンコードされ(辞書ファイルと入力ファイルのエンコーディングを揃える),かつ最初の行に

#!E -*- coding: UTF-8 -*-

というおまじないを書いておかないとエンコーディングの解釈がうまくいきませんのでご注意ください.

しかし,Windows 上でのデフォルトのエンコーディングである US-ASCIIWindows-31J でも手間なく使えるように,エンコーディング指定なしの汎用 US-ASCII 版もアップしておきます.これはどのようなプラットフォームであっても,そのプラットフォームのデフォルトの Locale が無条件で US-ASCII を解釈できることを利用したものです.ただし,欧文のアクセントウムラウトを含む文字は,それらを含まない最も近い文字に置き換えられています.正版はあくまで UTF-8 なので,特に人名を含む種や,種の Authority を見るときにはご注意ください.


このオリジナル英語版の辞書ファイルに続いて,和名追加版と,IOC Master List の Excel ファイルに和名を追加したものも同時にリリースしました.和名追加版の辞書ファイルについても,UTF-8 でエンコードしてあるものが正版ですが,Windows などでの使い勝手を考慮して Windows-31J でエンコードしたものも同時にアップしてあります.ただし人名や地名のアクセントやウムラウトなどは,それらを含まない最も近い文字に置き換えてありますのでご注意ください.

和名追加版の辞書ファイルのうち,UTF-8 でエンコードしてある ioclist_v71ju.ref は,Linux などで UTF-8 でエンコードした入力ファイルをソートするときに使うことを想定しています.Linux 上で使う際には,入力ファイルの最初の行に上記のようなエンコーディング指定を書く必要はありませんが,Windows 上で使う場合には,入力ファイルは UTF-8 でエンコードされ(辞書ファイルと入力ファイルのエンコーディングを揃える),かつ入力ファイルの最初の行に

#!E -*- coding: UTF-8 -*-

というエンコーディングを指定しておく必要があります.

逆に,Windows 上で Shift-JIS や Windows-31J でエンコードされた入力ファイルを,Windows-31J でエンコードされた辞書ファイル ioclist_v71jw.ref を用いてソートする際には,入力ファイルの冒頭にエンコーディングの指定は必要ありませんが,この辞書ファイルを Linux 上で使う場合には,入力ファイルは Windows-31J でエンコードされ(辞書ファイルと入力ファイルのエンコーディングを揃える),かつ入力ファイルの冒頭に

#!E -*- coding: Windows-31J -*-

とエンコーディングを指定しておく必要があります.要するに,どのような場合でも辞書ファイルと入力ファイルのエンコーディングを揃え,かつそれぞれの入力ファイルのエンコーディング指定を冒頭に書いておくのが無難です.

これらのファイルをダウンロードするには,従来通りこのブログの右側のコラムで “自作ソフト„ の中から個々のファイルをクリックしても良いのですが,前述のとおり,Microsoft One Drive 上に設けた IOC List 専用のフォルダからもダウンロードできます.それには,このブログ右側のコラムの最上段の “Archive„ の中の “IOC List Archive„ をクリックしてください.そうすると One Drive のフォルダに入ることができますので,あとは適当に選んでダウンロードしてください.今後は One Drive のみに集約していく予定です.


I am pleased to announce that I have posted reference files for Refsort/Ruby compiled directly from the latest IOC World Bird List v7.1. It contains 10,660 extant species, 155 extinct species and 20,358 subspecies, respectively. Please try it out, and enjoy its capability and speed.

Note that the reference file "ioclist_v71u.ref" is encoded in UTF-8 in order to retain all European accents and umlauts with complete fidelity as they are in the IOC Master List. Therefore, your input file should be encoded in UTF-8 as well, and should contain a line of text below on the top of the file.

#!E -*- coding: UTF-8 -*-

For those who want to use Refsort/Ruby in universal ASCII environments, I have posted another reference file "ioclist_v71a.ref" encoded in pure ASCII. Note that characters with accents and umlauts have been simplified to their nearest neighbors. So please be careful in particular when you refer to authorities of species.

I have also posted two reference files (encoded in UTF-8 and Windows-31J, respectively) which include Japanese names. If you want to refer to Japanese names, please see those files. In order to sort a list properly using these reference files, you need to align the encoding of the input file to that of the reference file, and you should add a line specifying the encoding of the input file on the first line, such as UTF-8, US-ASCII or Windows-31J.

A master list in Excel format containing a column of Japanese names has been posted as well. This would be more convenient.

You can download an appropriate file by clicking a link listed on the right column of this page, but you can also access files and folders built in my area of Microsoft One Drive by clicking "IOC List Archive" on the right column.

| | コメント (0) | トラックバック (0)

2016/12/30

バックアップ体制を刷新

パソコンを使っていると,ごくたまにですがHDDが突然故障したり,バックアップを取っておいたつもりのフロッピーディスクやHDDが読めなくなっていたりするものです.このときは本当に泣きたい気分になるのですが,その時に泣かずに済むようにするには,普段からバックアップを取っておくしかありません.

私の自宅のPC環境のバックアップの変遷を書くと以下のようになります.

最初期
フロッピーディスクを20枚ほど用意し,バックアップ用のユーティリティソフトウェアを使ってユーザデータのみをバックアップ.システムやアプリケーションのバックアップは取らず.これが毎週日曜日夕方のルーチンワークだった.

MO期
大容量(最初は128MB/枚,最終的には1.3GB/枚)の光磁気ディスク数枚を使って,ユーザデータのみをバックアップ.ここでもシステムやアプリケーションのバックアップは取らず.光磁気ディスクの書き込みの遅さにイライラした.

リムーバブルHDD期
最初のころは40GB程度,現在では1TB程度のリムーバブルHDDを使って,主としてユーザデータをバックアップ.可能であればシステムやアプリケーションの設定のバックアップも取る.速度の問題はなかったが,毎回USBケーブルを持ち出してつないだり外したりが億劫.これは今も続く.

試行錯誤期
様々なデバイスと接続方法を試行錯誤していた時期.最初はWindows Home Server 2011を主なバックアップ先として,システムとユーザデータをすべてバックアップ.さらに大事をとって,ユーザーデータは300GB程度のリムーバブルHDDにすべてバックアップ.

ところが,WHS 2011のサポートが2016年4月で終了したため,サーバーに使っていたマシンにFreeNASをインストールし,バックアップ用のNASとして使い始めるも,効率的な使い方は今も試行錯誤中.

さらに,内臓HDDを2台追加して,Windowsに備わっている仮想プロビジョニング対応の記憶域プールを双方向ミラーで構成し,これを自動Scrubbing対応のReFSでフォーマット.そしてこれをファイル履歴用のドライブとして運用開始.これでユーザデータを履歴も含めて自動的にバックアップ.MacOSのタイムマシン相当の機能.

さらにさらに,余っていた5インチベイに,SATA接続の2.5インチと3.5インチの2台のHDDを着脱可能なアダプタを取り付け,現在は2.5インチのHDD 1台を接続し,毎週1回,深夜に自動で全ユーザデータとアプリケーションの設定,さらにWindowsのシステムイメージをバックアップ中.

現状
上記の記憶域プールへファイル履歴を常時取得.Scrubbingも自動なので非常に楽.ただしごく稀にバックアップできないファイルがあり,万能ではない.

FreeNASへ全ユーザデータとシステムイメージを定期的に手動でバックアップ.手動なので面倒.自動化したい.

USB接続のリムーバブルHDDへ,全ユーザのデータとシステムイメージを定期的に手動でバックアップ.これも面倒なので,出来るだけ廃止したいが,非常時にサッと持ち出せるバックアップも必要なので,悩みどころ.

5インチベイに常時取り付けてあるリムーバブルHDDに,全ユーザーデータとシステムイメージを自動でバックアップ.これが上記の悩みを解決してほしいと期待している.

こうやって整理してみると,まあ,いろいろと試行錯誤してきたことがわかります.しかも,この試行錯誤はまだまだ続きます.もっと手間を省き,しかも確実にバックアップが取れるようにしたいからです.現在は,安全のためにかなり冗長なバックアップ体制を取っています.これをどこまで自動バックアップに任せても大丈夫かを検証していく必要があります.現在週末ごとに手動で行っているバックアップをできるだけ早く廃止するのが次の目標です.

現在では2.5インチのHDDも非常に安くなり,1TBが6,000円程度で買えるようになったので,USBインターフェース付きのケースに入れても8,000円でおつりがくるほどになりました.20年ほど前にフロッピーディスクをとっかえひっかえドライブに入れていた頃からは想像もできない容量をバックアップしているのですが,本質的には問題は解決していません.バックアップの悩みはコンピュータの歴史が始まると同時に発生したはずで,きっと将来も悩み続けることでしょう.

| | コメント (0) | トラックバック (1)

2016/12/25

Ruby 2.4.0 Released

毎年クリスマスの定番となっていますが,Ruby の最新版 2.4.0 がお約束通り12月25日にリリースされました.今回のリリースではいくつかの改訂が行われ,非常に大きな整数を扱うクラスが Integer に統合されるなどの話題があったのですが,実は文字列リテラルが変更不可となるという非常に大きな過去との断絶が 3.0.0 で予定されています.

これはすでに半年以上前に予告されていたことで,大きな議論を巻き起こしましたが,Rails ではこのほうが都合がよいという理由からか,押し切られた形になっています.このため,文字列リテラルを変数で指し示している場合,その内容を変更したい場合には,あらかじめ String#dup などで複製を作っておく必要があります.

これがデフォルトとなる 3.0.0 が出るのはまだ当分先のこととたかをくくっていられますが,すでに 2.3.0 からこの制約を先行的に試すことができるオプションが実装されており,それは今回の 2.4.0 でも同様です.

それ以外の変更は従来の機能拡張の範囲なので,上位互換と言ってよいのではないでしょうか?多くのバグが潰され,いくつかのメソッドのスピードが向上し,全体としては進歩が感じられる改訂となっていると思います.

| | コメント (0) | トラックバック (0)

2016/10/29

IOC List v6.4 Released

IOC World Bird List v6.4 が2016年10月22日にリリースされました.前回 v6.3 のリリースが2016年7月20日だったのですが,今回もそれから3か月で新しい版 v6.4 が出てきました.非常に几帳面に更新を続けています.

今回収録されたのは,科が 240,属が 2,294,種が 10,815,亜種が 20,358 です.IOC 本家の Master List を編集して,Refsort/Ruby 用の辞書ファイルを作りましたので,このブログサイトと,Microsoft One Drive 上に設けた “IOC List Archive„ にアップロードしておきます.

今回もこの辞書ファイルの正式なエンコーディングは UTF-8 です.従って,Linux 上で使う分には問題は生じませんが,Windows 上で使う際には,入力ファイルは UTF-8 でエンコードされ(辞書ファイルと入力ファイルのエンコーディングを揃える),かつ最初の行に

#!E -*- coding: UTF-8 -*-

というおまじないを書いておかないとエンコーディングの解釈がうまくいきませんのでご注意ください.

しかし,Windows 上でのデフォルトのエンコーディングである US-ASCIIWindows-31J でも手間なく使えるように,エンコーディング指定なしの汎用 US-ASCII 版もアップしておきます.これはどのようなプラットフォームであっても,そのプラットフォームのデフォルトの Locale が US-ASCII を解釈できることを利用したものです.ただし,欧文のアクセントウムラウトを含む文字は,それらを含まない最も近い文字に置き換えられています.正版はあくまで UTF-8 なので,特に人名を含む種や,種の Authority を見るときにはご注意ください.


このオリジナル英語版の辞書ファイルに続いて,和名追加版と,IOC Master List の Excel ファイルに和名を追加したものも同時にリリースしました.和名追加版の辞書ファイルについても,UTF-8 でエンコードしてあるものが正版ですが,Windows などでの使い勝手を考慮して Windows-31J でエンコードしたものも同時にアップしてあります.ただし人名や地名のアクセントやウムラウトなどは,それらを含まない最も近い文字に置き換えてありますのでご注意ください.

和名追加版の辞書ファイルのうち,UTF-8 でエンコードしてある ioclist_v64ju.ref は,Linux などで UTF-8 でエンコードした入力ファイルをソートするときに使うことを想定しています.Linux 上で使う際には,入力ファイルの最初の行に上記のようなエンコーディング指定を書く必要はありませんが,Windows 上で使う場合には,入力ファイルは UTF-8 でエンコードされ(辞書ファイルと入力ファイルのエンコーディングを揃える),かつ入力ファイルの最初の行に

#!E -*- coding: UTF-8 -*-

というエンコーディングを指定しておく必要があります.

逆に,Windows 上で Shift-JIS や Windows-31J でエンコードされた入力ファイルを,Windows-31J でエンコードされた辞書ファイル ioclist_v64jw.ref を用いてソートする際には,入力ファイルの冒頭にエンコーディングの指定は必要ありませんが,この辞書ファイルを Linux 上で使う場合には,入力ファイルは Windows-31J でエンコードされ(辞書ファイルと入力ファイルのエンコーディングを揃える),かつ入力ファイルの冒頭に

#!E -*- coding: Windows-31J -*-

とエンコーディングを指定しておく必要があります.要するに,どのような場合でも辞書ファイルと入力ファイルのエンコーディングを揃え,かつそれぞれの入力ファイルのエンコーディング指定を冒頭に書いておくのが無難です.

これらのファイルをダウンロードするには,従来通りこのブログの右側のコラムで “自作ソフト„ の中から個々のファイルをクリックしても良いのですが,前述のとおり,Microsoft One Drive 上に設けた IOC List 専用のフォルダからもダウンロードできます.それには,このブログ右側のコラムの最上段の “Archive„ の中の “IOC List Archive„ をクリックしてください.そうすると One Drive のフォルダに入ることができますので,あとは適当に選んでダウンロードしてください.今後は One Drive のみに集約していく予定です.


I am pleased to announce that I have posted reference files for Refsort/Ruby compiled directly from the latest IOC World Bird List v6.4. It contains 10,815 species and 20,358 subspecies, respectively. Please try it out, and enjoy its capability and speed.

Note that the reference file "ioclist_v64u.ref" is encoded in UTF-8 in order to retain all European accents and umlauts with complete fidelity as they are in the IOC Master List. Therefore, your input file should be encoded in UTF-8 as well, and should contain a line of text below on the top of the file.

#!E -*- coding: UTF-8 -*-

For those who want to use Refsort/Ruby in universal ASCII environments, I have posted another reference file "ioclist_v64a.ref" encoded in pure ASCII. Note that characters with accents and umlauts have been simplified to their nearest neighbors. So please be careful in particular when you refer to authorities of species.

I have also posted two reference files (encoded in UTF-8 and Windows-31J, respectively) which include Japanese names. If you want to refer to Japanese names, please see those files. In order to sort a list properly using these reference files, you need to align the encoding of the input file to that of the reference file, and you should add a line specifying the encoding of the input file on the first line, such as UTF-8, US-ASCII or Windows-31J.

A master list in Excel format containing a column of Japanese names has been posted as well. This would be more convenient.

You can download an appropriate file by clicking a link listed on the right column of this page, but you can also access files and folders built in my area of Microsoft One Drive by clicking "IOC List Archive" on the right column.

| | コメント (0) | トラックバック (1)

2016/08/17

メインマシンのバックアップ体制を刷新しました

今から2週間ちょっと前にWindowsのファイル履歴の稼働を開始したことをポストしましたが,実は,問題含みで運用を開始していました.正確には知りませんが,Windows は 8.1 の頃から新しいファイルシステム ReFS をクライアント OS にも載せるようになっていました.これは NTFS の後継ではないものの,信頼性や耐久性が要求されるサーバー OS のために開発された新しいファイルシステムで,自動修復や,ビット腐敗や書き込まれて時間が経ったセクターを自動的に書き直して鮮度を保つ機能(Scrub)など,高信頼のバックアップを求める向きには魅力的な機能を持っています.

このファイルシステムが,クライアント OS に対しても,記憶域プールであれば使用可能になっているのです.Windows 10 にアップデートした時点で早速手を出してみたのは言うまでもありません.ところが,wbadmin コマンドを用いてシステムイメージのバックアップを取ろうと思っても,ReFS への書き込みが許されていないのです.これでは一体何のためのファイルシステムなのだろう?と憤慨してみたものの,当分はそのままの仕様で運用するしかありません.

ほどなく Anniversary Update をインストールして,念のため再度確認しましたが,やはりシステムイメージを書き込むことはできません.そこで,方針を転換し,以下のようなバックアップ体制を取ることにしました.

  1. 記憶域プール(双方向ミラー)は ReFS でフォーマットし,ファイル履歴専用とする.自動修復などが可能なため,長期間の差分履歴をとるのに最も適したファイルシステムであることを生かす.
  2. システムイメージのバックアップは,NTFS でフォーマットしたリムーバブル HDD に定期的にバックアップする.
  3. ユーザのファイルも,同様にリムーバブル HDD に定期的にバックアップする.
  4. ユーザが独自にインストールしたフリーソフトなど,ローカルなアプリケーションも,同様にリムーバブル HDD に定期的にバックアップする.

そして,(2)(3)(4)はバッチファイルを組んで自動化し,それらをタスクスケジューラに登録して深夜に自動実行させる,という具合にしました.元々 (1) はバックグラウンドで自動実行されているので手間はかかりませんし,(2)-(4)も寝る前にリムーバブル HDD をスロットに突っ込んでシステムをスリープにしておけばあとは自動です.

この体制でしばらく運用してみるつもりです.ReFS については,NTFS との互換性はないので,途中で何か不都合が出てくるのかもしれませんが,まだまだ発展途上のファイルシステムなので,今後の改良も期待できると思います.

| | コメント (0) | トラックバック (1)

2016/08/15

Windows 10 をクリーンインストールし直しました

一週間ほど前に Windows 10 の Anniversary Update をインストールしたことを報告しましたが,どうも調子が悪いところが何点か見つかったので,夏休みで時間に余裕があることもあり,まっさらな状態からクリーンインストールし直しました.完全なクリーンインストールなので,種々のアプリケーションもすべてインストールし直さなければならず,非常に手間がかかる作業なのですが,アップデートでいろいろなゴミがファイルシステムの中に発生しているのは気持ち悪いし,ディスク容量もその分減るので,思い切ってやってしまいました.

一連の作業で元の環境を取り戻すにはには少なくとも丸一日,余裕を見ると2日間は必要です.そのため,部屋に閉じこもって黙々と作業を続けました.一通り完成した後でもいろいろな設定を試したりしていると時間がかかるものです.何か所か動作不審なところがあったので,とっておきのコマンド

dism /online /cleanup-image /restorehealth
sfc /scannow
を実行して修復すると,一応まともに動くようになりました.やれやれ.

インストール後に Windows Update が走ったので,ビルド番号を確認してみると,Anniversary Update 直後の 14393.10 から 14393.51 に上がっていました.へぇ?

今回のアップデートの収穫の一つは,実はコマンド・コンソールです.これまで,このコンソールのスクロールがあまりに遅くてイライラしていたのですが,今回のアップデートでは Linux のコンソールとまでは行きませんが,それに次ぐ程度に速くなりました.例えば,3万行を超えるテキストファイルをコンソールに出力させると,以前はスクロールに10秒以上もかかっていたのですが,今回のアップデート後は2秒以内で終わるようになりました.これは精神衛生上非常に好ましい変化です.派手な機能だけではなく,こういう一見地味で遺物のようなツールであっても,プログラマーにとっては重要なツールが強化されるのは大歓迎です.

| | コメント (1) | トラックバック (0)

2016/08/07

Windows 10 version 1607 build 14393.10 にアップデートしました

昨年秋の version 1511 から約10か月ぶりのアップデートで, Windows 10 が少し新しくなりました.Windows Update でダウンロードし,何度か再起動を繰り返して30分ほどで化粧直しが終わりました.

これからも Windows 10 はこのような “ちょこちょこ直し” を繰り返して変化していくことが宣言されており,まあ,これが厳密には On-Premises でありながらも SaaS (Software as a Service) に近いソフトウェアの提供形態なのでしょう.Adobe の Photoshop などはすでに数年前からこのようになっていますし,Microsoft の Office はすでに狭い意味での SaaS に移行済みですので,Microsoft の OS 系も遅ればせながらビジネスモデルを修正しつつあるということのようです.

化粧直ししたといっても,私は今回の目玉機能である Ink などを全く使っていないので,あまりご利益を感じられないのですが,しかし今後のアップデートの土台となるバージョンなので,これにしておかないわけにはいかないのです.

早速一つ不具合を発見したのですが,まだ解決策が見つかっていません.記憶域スペースに双方向ミラーのボリュームを作って,そこにファイル履歴をため込むように指定したのですが,こちらは順調のようです.

| | コメント (0) | トラックバック (1)

2016/08/01

Windows のファイル履歴がようやく稼働

今年3月末に,HDD 2台を増設して “記憶域プール” を作成してミラーリング機能を持った仮想ディスクを作り,それをターゲットにして “ファイル履歴” を取るという記事をアップしました.

Filehistorypanel

その後,Windows 10 に移行後もファイル履歴の試行を続けてきました.私自身のファイルは問題なく履歴が取れていることが確認できていたのですが,家人のファイルがどうしてもエラーとなって履歴が取れないという状態が続いていました.従って, “まるで使い物にならない!” と捨て台詞をはいてほかのバックアップソフトに走ることも何度か考えました.

この週末,少し時間に余裕が取れたので,家人のファイル・ツリーのどのフォルダ,どのファイルが悪さをしているのか,徹底的に調べてみることにしました.ファイル履歴がコケる原因はいくつか特定されており,それを知るとマイクロソフトともあろう大企業を何やら非常に情けなく感じてしまうのですが,ひらがな,全角カタカナ,半角カタカナで同一の名前のファイルを含むフォルダは履歴を取れない,同様に,全角英数字と半角英数字で同一の名前があっても同様にエラーとなる,などという症状がわかっています.

これを手掛かりに,ファイル履歴の対象からまず全てのフォルダを除外しておき,フォルダを一つずつ対象に入れてエラーが出ないか確認するという地道な作業を繰り返していきます.数時間はかかりましたが,ようやく,前記の通りの全角と半角で同一の名前のファイルがいくつかのフォルダで見つかりました.これらのファイル名を修正すると,すべてのフォルダでファイル履歴が問題なく取れることが確認できました.

これで Mac OS の Time Machineとほぼ同等の機能が Windows でも使用できることになりました.履歴を取得する間隔はデフォルトで 1 時間に設定されているので,ちょっとした作業をしてファイルを更新したとしても,その前後の履歴が取れる可能性は十分高いと言えます.

おりしも,Windows 10 リリース一周年の大型アップデート “Redstone 1” が 8 月 2 日にリリースを予定されています.このアップデートでファイル履歴が改善されるという事前予想はないのですが,たとえ無くても今のままで運用していけるはずです.

そしてもちろん,このシステムお任せのファイル履歴以外に,タスクスケジューラを用いた定期バックアップを毎日,さらに週次で手動によるオフライン完全バックアップも取っており,データの保全については何とかこれで合格点かなと思っています.

| | コメント (0) | トラックバック (2)

より以前の記事一覧