新マシンに移行した。
旧マシンはしばらく使わないつもりで置いておく。
引き揚げ忘れたデータとかが眠っているかもしれないから。
でも、たぶん引き揚げ忘れたデータが本当にあったとしたら、それは忘れる程度のデータなので消えても構わないと思う。
実は、半年ほど前に旧マシンに Windows を再インストールしており、その際に「移行しやすいように」データ整理をしていたので、移行はスムーズにいった。
でも、若干の予想外もあった。
我が家では NAS に家族の写真・ビデオをたっぷりとため込んであって、この NAS は重要なので外付けハードディスクに定期バックアップもとっている。
しかし、それとは別に Google Photos にも写真を送ってバックアップしている。
「画質が落とされるのでバックアップにはならない」という人もいるのだけど、上に書いたように十分なバックアップは取った上の話だ。
Google のものは、万が一火事などで機材一切が滅失した際に、思い出写真として見られるのに十分なものがあればよい、という程度と考えている。
で、問題はこの Google に対するバックアップだ。
Google Drive を扱うツールは NAS のプラグインや Linux にもあるのだけど、Google Photos で「無制限」に写真を送るためのツールは Win / Mac 版しか用意されていない。
ここらへんで説明が必要な人も多いだろう。
Google Drive と Google Photos は、シームレスにつながるサービスだ。
Google Drive はネットワーク越しにデータを預かってくれるサービスで、Google Photos は写真を預かってくれるサービス。
でも、Photos の保存領域は、実は Drive のものだ。
ただし、Photos では「十分に小さな写真」は、Drive の容量として計上しないことになっている。
だから、今く使えば容量無制限で写真をバックアップできる。
ここで「十分に小さな」というのは、過去に何度か改定されてきている。
最初は、2048x2048画素以内、とされていた。実際にはバグがあって、ぎりぎりサイズはダメだったのだけど。
Google は、当時は Google Picasa というソフトを Windows 用に配布していて、このソフトからアップロードすると、自動的に 1600px まで縮小してアップロードしてくれた。
（当時は、Google Photos ではなく Picasa Web という名前だった）
のちに、Picasa は開発終了し、写真のバックアップだけを行う Google Photo Uploader が作られた。
そしてさらに、Google Drive バックアップと同期、というソフトに変わった。
同時に、保存できるサイズも大きくなってきている。
現在は「1600万画素、かつ 75MByte」までとなっている。4000x4000 なら、ちょうど 16000万画素なのでそのままアップロードできる。（75MByte の制限はあるのだけど）
ただ、この制限に適合するようにアップロードしてくれるソフト、「バックアップと同期」が、Windows / Mac 版しか作られていないのだ。
今までは、Windows 版のソフトを動かし、NAS をバックアップ元に指定して Google にアップロードさせていた。
今回もそれをやったら…これ、ノートにさせるような作業じゃないね？
今まではデスクトップマシンでイーサネット接続だったので、NAS から写真を取得して、リサイズして再圧縮して Google に送信、というタスクを動かしていても気にならなかった。
でも、WiFi 接続だとイーサより遅いし、WiFi の電波帯域は家族で共有しているので迷惑になりそう。
いや、イーサだって共有なのだけど、WiFi を使う機材とイーサを使う機材で棲み分けていた、という感じ。
（その WiFi はイーサにつながっているのだけど、一番通信量の大きい、僕のマシンと NAS の間、というのと、WiFi ステーションとネットワークルータの間、というのは、スイッチングハブによって切り分けられている）
ひとまず、ノートマシンにイーサケーブルつないで凌いでいるのだけど、どうにかしたい。
Linux サーバーはあるので、Linux から Google Photos にアップロードできればいいのだけど…と調べたのだけど、相変わらずそのためのソフトはない。
じゃぁ、Windows を仮想化してサーバーに入れるか。
幸い、メインマシンの Windows はライセンスを購入したもので、PC 付属の OEM ではない。
＃PC 付属の OEM 版は、別のマシンで使用することは禁じられている。
今まで使っていたメインマシンは、もともと Windows 7 マシンだったのだけど、8 にバージョンアップする際にライセンスを購入し、このライセンスは Windows 10 に無償バージョンアップされた。
Windows には「Hyper-v」という仮想化技術があるのだけど、これは実は Xen が開発したもの。
Xen は Linux で生まれた仮想化技術で、現在は KVM に引き継がれている、と考えて間違いない。
＃Xen 自体はまだあるのだけど、今から使うメリットはあまりない。
うちのサーバーは KVM が入れてあるので、この上に Windows を入れることは可能だ。
実は、Google Drive 同期とバックアップは、外部の NAS のデータを送信する際は、Windows がスリープして NAS との通信が切断するたびに一時停止する、という問題がある。
まぁ、問題というか仕様なのだけど、仮想化サーバーに入れておけばこの問題も解決する。
というわけで、Windows 仮想化が本命だなーと思いつつ、じつはまだサーバーの整備が終わっていないし、旧マシンもしばらく置いておきたいのでライセンスの関係もあってすぐには仮想化できない。
サーバー整備は、去年から少しづつやっているもの。
Xen サーバーの仮想マシンを KVM に移行したいのだけど、この意向を簡単に行うソフトが曲者で、一筋縄ではいかないとわかってきたところ。
「単純だけど本格運用には不満がある」仮想化マシンなら簡単に移行させてくれるのだけど、本格運用を目指した設定のマシンだと移行できないという…
まぁ、本格運用を目指した、というのは標準的でない設定をたくさん使っているという意味であり、仕方がないことでもあるのだけど。
同じテーマの日記(最近の一覧)
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |