https://jp.techcrunch.com/2018/10/07/2018-10-06-microsoft-suspends-windows-10-update-citing-data-loss-reports/
Windows 10の最新版を 一般公開してから数日後、Microsoftはアップデートを中止し、データを失った複数ユーザーからの報告があったと述べた。
Windows10のOctober 2018 Updateの配信が停止された。なんでもアップデートを適用したときに、データが消えてしまう不具合がユーザから報告され、そのためアップデートの公開が停止されたようだ。いきなり公開されていた大型アップデートなので、なにかしらの不具合はあるとは思っていたけれど、データ消失系の大きな障害だったとは。とりあえず、公開日に、さくっとOctober 2018 Updateをあてたときには影響がなかった。データ消失には、何かしらの条件があるのだろう。
ちゃんと解明されて、ちゃんと公開されるのを待とう。続報がなかなか入ってこないのが厄介なところだけど。
インストールされているUbuntuのバージョンを調べるには、下記のコマンドを実行する
lsb_release -a
実際に、Windows Subsystem for LinuxのUbuntuで試してみると、
zen@PCR662:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic zen@PCR662:~$
と、表示され、Ubuntu 18.04.1 LTS がインストールされていることがわかる。
ちなみに、「/etc/os-release」を確認しても、Ubuntuのバージョンを調べることができる。
zen@PCR662:~$ cat /etc/os-release NAME="Ubuntu" VERSION="18.04.1 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.1 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic
Windowsでの時刻同期の操作はw32tmを使用する。コマンドを使うことで、NTPサーバとの時刻同期の状況を確認することができる。
同期状況を確認する
w32tm /query /peers
ポーリング感覚や状態、同期先（ピア）などを確認することができる。
実行例）
C:\WINDOWS\system32>w32tm /query /peers ピア数: 1 ピア: ntp.xenos.jp 状態: アクティブ 残り時間: 1020.0269700s モード: 3 (クライアント) 階層: 3 (二次参照 - (S)NTP で同期) ピアポーリング間隔: 10 (1024s) ホストポーリング間隔: 10 (1024s)
Windowsでの時刻同期の操作はW32tmコマンドを使用する。このコマンドを使うことで、NTPサーバとの時刻同期も手動で行うことができる（時刻同期の確認ができる）。
即座にNTPサーバと同期させる
w32tm /resync /nowait
「/resync」で再同期、「/nowait」で即座に同期を実施する。
時刻同期を行う際は、コマンドプロンプト（cmd）を管理者モードで起動し、w32tmコマンドを実行すること。管理者モードで行わないと、コマンドが拒否される。
ミスアライメントとは
ストレージ側のブロックサイズにたいして、使用しているOSのアプリケーションデータの書き始めと終わりがストレージ側のブロックの中間から始まり、複数のブロックにまたがっている状態。
ミスアライメントI/Oが発生する状況
例えば、Windowsでは、iSCSIマウントしたストレージ側のブロックサイズが16Kのときに、フォーマットしたドライブのアロケートユニットサイズを4Kにしてしまうと、ミスアライメントI/Oが発生する。
解消するには、アロケートユニットサイズをストレージ側のブロックサイズと同じ値でフォーマットする。
ミスアライメントI/Oが発生していると、データの読み書きのパフォーマンス低下につながる。
OracleがインストールされたWindowsサーバをシャットダウンし、システムバックアップを取得し、データファイルを保存している先のiSCSIディスクのバックアップも取得し、完全な静止点のバックアップを作成した。作業後、静止点のシステムバックアップからリストアを実施。リストア後、OS（Windows）は正常起動し、iSCSIについても問題はなかった。
しかし、OracleDBの接続確認したところ、「ORA-01034」が発生し、Oracle DBが正常に起動していなかった。Windowsのイベントログも確認したが、特に変なエラーはなし。唯一、Oracle DB起動時に権限系のエラーが出ていた。完全な静止点でのバックアップだったので、SCN番号も関係なし。しかも手動で`startup`すると正常にOracle DBが起動して使えるようになった。
試行錯誤で、Windows OSの再起動も試したが、事象が再現するだけ。アーカイブログモードもオフにしてみたが状況は変わらず。ドメインへの再参加も実施したが変わらず。いろいろと試したが状況は変わらず。ひとつひとつ切り分けていった結果、原因を特定した。
原因は、WindowsのOSが起動時に、iSCSIディスクがマウントされる前に、Oracle DBのサービスが起動していたため、データファイルがマウントできず、起動が失敗していた。
対応として、Oracle DBのサービスを開始遅延で設定。これで、先にiSCSIドライブがマウントされるようになり、自動起動するようになった。
今までは、たまたま起動順としてiSCSIのサービスが先に起動していただけ。それがイメージバックアップからのリストアがトリガーとなり、起動順番が変わり、Oracle DBが自動起動しなくなった、ということ。
データベース本体は暗号化せず、バックアップのみを暗号化する機能がSQL Server 2014より追加されている。SQL Server 2016もバックアップのみ暗号化を行うことができる。
バックアップの暗号化は、SQL Server 2016 Standard エディションでも使用することができる。
vSphere Clientで、データストアの仮想マシンファイルをダウンロードすると、エラーで失敗する。 必ず失敗するわけではなく、サイズが大きいものをダウンロードすると、ダウンロードが開始されてしばらくしてから、エラーが出て失敗する。
発生したエラーは下記。
Unexpected character" (code 65279 / 0xfeff) in prlog; expected '<' at [row, col(unknown-sorce)]:[1,1]
特に解決策はなく、仮想マシンのバックアップ目的だったので、OVF形式でエクスポートを行ったら正常終了したので運用回避した。いろいろと調べていくと、Windows 10とvSphere Clientの組み合わせのときに発生するようだ。
Windows10は、大型アップデートが年2回リリースされる。どのバージョンがインストールされているかにより、メニューなどが変わる。そのため、バージョン表示はコマンドが便利。コマンドプロンプトもしくは「Windowsキー＋R」でwinverを入力する。
■コマンド
winver
実行すると、ポップアップでバージョンが表示される。OSのビルド番号も表示されている。
SQL Server 2016は、デフォルト設定の場合、データベースアクセスに1433番ポートを使用する。そのため、Windows ファイアウォール（セキュリティが強化されたWindows ファイアウォール）で、TCPのポート1433番を開ける規則を作成する。
■開放するポート
プロトコル TCP
ポート番号 1433
なお、SQL Server 2005は、OS側のファイアウォールとは別に「SQL Server セキュリティ構成ツール」で開放していた。
SQL Server 2016では、ファイアウォールをオフにすると、どこからでもつなげるようになるため注意が必要。