技術的なことをメインにいろいろ書いてくサイトです
MSSQL Always on構成で、バックアップソフトを使ってデータベースバックアップを行っている場合、リストア/リカバリをどのように行うのか、わかりにくかったのでメモ。
(1) SQLマネージメントスタジオでAlways on設定から該当データベースを削除
(2) フェールオーバークラスタマネージャーにてSQLの役割を全て停止（一部だけだとうまくいかないケースあり)
(3)バックアップソフトからリストア実施
(4)フェールオーバークラスタマネージャーにてSQLの役割を開始
(5)SQLマネージメントスタジオでAlways on設定に該当データベースを追加
テスト環境としてWindows Server 2019 Indiser Preview Build 17623をインストールしている環境が使用期限切れを迎えたので、Windows Server 2019 Indiser Preview Build 17692に更新してみた。
再インストールしろ、ってあったが、CドライブにISOイメージを置いて、その中のsetupを実行してみると、アップデートが完了した。
しかし、ライセンス認証ができていない。
「Windows ライセンス認証 サーバーに到達できません」というエラーとなっている。
“設定”の”ライセンス認証”にある「プロダクトキーを変更します」だと、サーバーに到達できずエラーとなる。
よく見てみるとプロダクトキーの末尾５文字が、元の環境で使用していたものとは異なるものになっている。
コマンドで設定する方法がないか確認してみると「slmgr」コマンドで設定できることを発見。
今回使用しているのはStandard Editionなので、ダウンロードページにある下記記述を元にコマンドを実行
Datacenter Edition 6XBNX-4JQGW-QX6QG-74P76-72V67
Standard Edition MFY9F-XBN2F-TYFMP-CCV49-RMYVH
「slmgr /ipk MFY9F-XBN2F-TYFMP-CCV49-RMYVH」を実行
Microsoft Windows [Version 10.0.17692.1000]
(c) 2018 Microsoft Corporation. All rights reserved.
C:\Users\Administrator>slmgr /ipk MFY9F-XBN2F-TYFMP-CCV49-RMYVH
C:\Users\Administrator>
これで、無事更新できました。
Veritas NetBackupではGUIインタフェースにJavaを使用しており、インストールディレクトリにJREも含まれている。
NetBackup 7.7以降では、このJREをアップデートするためのコマンド nbcomponentupdate が用意され、JREのアップデートを個別で行うことができるようになった。
「NetBackup 8.1.1 Command Reference Guide – nbcomponentupdate」
「Updating JRE for NetBackup and OpsCenter」
しかし、日本語のWindows環境では２つの原因により素直に実行できない。
・空き容量チェックをdirのコマンドに表示される「XXX Byte free」という文字列で行っている。
日本語環境では「XXX バイトの空き容量」となるため、空き容量検出に失敗する
・nbcomponentupdate内でNetBackupサービスの停止を行っているが、やはり英語文字列を見ている。
日本語Locate Packを適用したNetBackupではコードページを変えても常に日本語文字列で出力するため
サービスの停止確認に失敗する
これを回避するためには、以下の手順で実行する必要がある。
C:\Windows\system32>"\Program Files\Veritas\NetBackup\jre\bin\java.exe" -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b11\3, mixed mode)
C:\Windows\system32>
C:\Windows\system32>"\Program Files\Veritas\NetBackup\bin\bpdown.exe" /f /v
NetBackup 8.0 -- 停止ユーティリティ
サービスの停止中
> NetBackup Bare Metal Restore Master Server
> NetBackup Bare Metal Restore Master Server -- 停止状態
> NetBackup Web Management Console
> NetBackup Web Management Console -- 停止状態
> NetBackup Indexing Manager
> NetBackup Indexing Manager -- 停止状態
> NetBackup Service Monitor
> NetBackup Service Monitor -- 停止状態
> NetBackup Agent Request Server
> NetBackup Agent Request Server -- 停止状態
> NetBackup Storage Lifecycle Manager
> NetBackup Storage Lifecycle Manager -- 停止状態
> NetBackup Key Management Service
> NetBackup Key Management Service -- 停止状態
> NetBackup Vault Manager
> NetBackup Vault Manager -- 停止状態
> NetBackup Service Layer
> NetBackup Service Layer -- 停止状態
> NetBackup Policy Execution Manager
> NetBackup Policy Execution Manager -- 停止状態
> NetBackup Job Manager
> NetBackup Job Manager -- 停止状態
> NetBackup Request Daemon
> NetBackup Request Daemon -- 停止状態
> NetBackup Compatibility Service
> NetBackup Compatibility Service -- 停止状態
> NetBackup Database Manager
> NetBackup Database Manager -- 停止状態
> NetBackup Audit Manager
> NetBackup Audit Manager -- 停止状態
> NetBackup Authorization
> NetBackup Authorization -- 無効状態
> NetBackup Authentication
> NetBackup Authentication -- 停止状態
> NetBackup CloudStore Service Container
> NetBackup CloudStore Service Container -- 停止状態
> NetBackup Deduplication Engine
> NetBackup Deduplication Engine -- 無効状態
> NetBackup Deduplication Manager
> NetBackup Deduplication Manager -- 無効状態
> NetBackup Remote Manager and Monitor Service
> NetBackup Remote Manager and Monitor Service -- 停止状態
> NetBackup Device Manager
> NetBackup Device Manager -- 停止状態
> NetBackup Volume Manager
> NetBackup Volume Manager -- 停止状態
> NetBackup Resource Broker
> NetBackup Resource Broker -- 停止状態
> NetBackup Enterprise Media Manager
> NetBackup Enterprise Media Manager -- 停止状態
> NetBackup Relational Database Manager
> NetBackup Relational Database Manager -- 停止状態
> NetBackup Event Manager
> NetBackup Event Manager -- 停止状態
> NetBackup Deduplication Multi-Threaded Agent
> NetBackup Deduplication Multi-Threaded Agent -- 停止状態
> NetBackup Discovery Framework
> NetBackup Discovery Framework -- 停止状態
> NetBackup SAN Client Fibre Transport Service
> NetBackup SAN Client Fibre Transport Service -- 無効状態
> NetBackup Client Service
> NetBackup Client Service -- 停止状態
> NetBackup Legacy Client Service
> NetBackup Legacy Client Service -- 停止状態
> NetBackup Legacy Network Service
> NetBackup Legacy Network Service -- 停止状態
ロボット制御デーモンの停止中
停止が正常に完了しました。
C:\Windows\system32>
C:\Windows\system32>chcp 437
Active code page: 437
C:\Windows\system32>
今回は、c:\Program Files\Java\jre1.8.0_171 にインストールされているJRE 1.8.0 Build 171を指定した。
C:\Windows\system32>"\Program Files\Veritas\NetBackup\bin\goodies\nbcomponentupdate.exe" -Product NetBackup -component jre -path "c:\Program Files\Java\jre1.8.0_171"
Command line: C:\Program Files\Veritas\NetBackup\bin\goodies\nbcomponentupdate.exe -Product NetBackup -component jre -path c:\Program Files\Java\jre1.8.0_171
Java Runtime Envrionment(JRE) version installed with product 'Veritas NetBackup' : 1.8.0_101 (64bit)
Java Runtime Envrionment(JRE) version found at path 'c:\Program Files\Java\jre1.8.0_171' : 1.8.0_171 (64bit)
This utility will update the Java Runtime Envrionment(JRE) binaries present at 'C:\Program Files\Veritas\NetBackup\jre' path
This utility may start and stop all (or some) services depending upon the present state of services.
Do you want to continue (Y[es]/N[o]): y
Performing upgrade steps ...
[1/4] Pre-installation step is in progress
[1/4] Pre-installation step is completed successfully
[2/4] Installation step is in progress
[2/4] Installation step is completed successfully
[3/4] Post-installation step is in progress
[3/4] Post-installation step is completed successfully
[4/4] Commit and Cleanup step is in progress
[4/4] Commit and Cleanup step is completed successfully
After upgrading, Java Runtime Envrionment(JRE) version installed with product 'Veritas NetBackup' : 1.8.0_171 (64bit)
Successfully upgraded Java Runtime Envrionment(JRE) for Veritas NetBackup.
The log file generated for this operation is C:\Users\ADMINI~1\AppData\Local\Temp\2\logs\nbcomponentupdate\nbcomponentupdate_20-06-2018_17.17.37.log
C:\Windows\system32>
なお、NetBackupサービスはバージョンによっては自動的に起動されたりするようだ。
自働起動しなかった場合は「bpup」を実行して起動する
C:\Windows\system32>"\Program Files\Veritas\NetBackup\jre\bin\java.exe" -version
java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)
C:\Windows\system32>
2021/04/26追記
Oracle JRE 1.8.0u291にアップデートをかけてみたところ、NetBackup Web Management Consoleが起動できなくなるという問題が発生しました。
このため「nbcomponentupdate.exe -Product NetBackup -component jre -revert」を実行し、以前のバージョンに戻してみたところ正常に動作しました。
NetBackup 8.1.1のデフォルトは1.8.0 u151で、手持ちの古いバージョンのうちOracle JRE 1.8.0u172とOracle JRE 1.8.0u241はnbcomponentupdateでアップデートして動作しました。
AZULのZulu Open JRE 1.8.0 はデフォルトインストール先が C:\Program Files\Zulu\zulu-8-jre\ で、バージョンが入ってないからダメだそうで・・・
AdoptOpen JDK 1.8.0 のデフォルトインストール先は C:\Program Files\AdoptOpenJDK\jre-8.0.292.10-hotspot\ で、こちらもやはり使用できませんでした。
ちなみにインストール先を「C:\Program Files\Zulu\jre1.8.0_292」とか「C:\Program Files\Java\jre1.8.0_292」に変更してみましたが同じエラー
java -versionの結果を比較すると「java version」ではなく「openjdk version」に切り替わっているので失敗していた模様
というわけで、NetBackup 8.1.1/8.1.2などではOracle以外のJavaに切り替えることはできない模様です。
BackupExec 20.1を使ってHyper-V上のWindows Serverのバックアップを行った。
最初、Hyper-V経由で仮想マシンとしてのバックアップにしようと考えていたのだが、BackupExecでは特定のドライブのバックアップを取らないという設定が出来ず、必ず全ドライブをバックアップする必要があることが分かった。
このため、対象サーバにBackupExec Agentをインストールして、エージェント経由でのバックアップを取ることにした。
で、Windows ADKを使用したSDR起動ディスクを作って、フルリストアのテストを行ったところ問題発生。
NICが２つついている場合、片側につけたIPアドレス設定がリカバリされない。
いろいろ条件をかえて試してみたけど、必ず発生している。
どうやら仕様らしい。
Veritasのサイト上だとNetBackup / vSphere環境での話として、「After restore a Windows Virtual Machine to original or alternate location, Virtual NIC settings may be changed or lost.」というのが掲載されている。
回避方法はなく、手動で再設定しろ、だそうな
hpeのProLiantサーバにWindows Server 2016をインストールする場合、通常はIntelligent Provisioning を使う。
しかし、Administratorパスワードが不明な場合、Windows Server 2016の標準ISOイメージのレスキューモードで起動することになるのだが、Smart Array B140i用のドライバが含まれていないため、内蔵ディスクが見えない。
対処するためにはISOイメージ内のsources\boot.wim にDSIMコマンドを使ってAdd-driverすることになる。
手順は「Windows インストールメディアにドライバーを追加する」にあるものをほぼそのまま使い、下記の様に実施した。
1. 作業用Windows10を用意
2. Windows ADK 1709の「Deployment Tools」と「Windows Preinstallation Environment (Windows PE)」をインストール
3. メニューの登録されている「展開およびイメージング ツール環境」を選択してコマンドプロンプトを起動
4. 「copype amd64 c:\work\pe_x64」（今回、C:\work を作業用ディレクトリとした)でWindows PE環境を展開
5. C:\work\iso にWindows Server 2016 ISOの中身をコピー
6. マウント用ディレクトリ c:\work\offline を作成
7. 「dism /get-imageInfo /imagefile:”C:\work\iso\sources\boot.wim”」でインデックス番号を確認
インデックス1とインデックス2があることを確認
レスキューの際にどちらを使うかわからないので、とりあえず両方使う
8. まずインデックス1をc:\work\offlineにマウント
「dism /mount-image /imagefile:”C:\work\iso\sources\boot.wim” /index:1 /mountdir:”C:\work\offline”」
9. smart array b140i用のドライバをc:\work\hpedriver に展開
10. ドライバを追加。複数ある場合も考慮して、/recurseオプション付きで実行
「dism /add-driver /image:”c:\work\offline” /driver:”c:\work\hpedriver” /recurse」
11. ドライバが追加されたことを確認
「dism /get-drivers /image:”c:\work\offline”」
12. アンマウントする
「dism /unmount-image /mountdir:”c:\work\offline” /commit」
13. 今度はインデックス2に対して実行
「dism /mount-image /imagefile:”C:\work\iso\sources\boot.wim” /index:2 /mountdir:”C:\work\offline”」
14. ドライバを追加。複数ある場合も考慮して、/recurseオプション付きで実行
「dism /add-driver /image:”c:\work\offline” /driver:”c:\work\hpedriver” /recurse」
15. ドライバが追加されたことを確認
「dism /get-drivers /image:”c:\work\offline”」
16. アンマウントする
「dism /unmount-image /mountdir:”c:\work\offline” /commit」
17. oscdimgコマンドを実行してISOイメージの作成
「oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bc:\work\PE_x64\fwfiles\etfsboot.com#pEF,e,bc:\work\PE_x64\fwfiles\efisys.bin c:\work\iso c:\work\win2016-new.iso」
(2025/2/5追記 Windows Sevrer 2022向けでADK 10.1.26100.2454 実施したところfwfilesからbootbinsに変更されていました「oscdimg -m -o -u2 -udfver102 -bootdata:2#p0,e,bc:\work\PE_x64\bootbins\etfsboot.com#pEF,e,bc:\work\PE_x64\bootbins\efisys.bin c:\work\iso c:\work\win2022-new.iso」
これで、作成したISOイメージをFAT32でフォーマットしたUSBメモリにコピーしようとしたところ、install.wimのコピーで失敗した。
原因はinstall.wimのサイズがFAT32制限である4GB以上の約6GBであるためです。
NTFSもしくはexFATでフォーマットしなおしたところ、コピーはできたものの、サーバ側で起動ディスクとして認識せず、起動できなかった。
確認したところ、 UEFIの場合、ファイルシステムがFAT32であること、という前提があった。 この制限については、マイクロソフトの「起動可能な USB フラッシュ ドライブを作成します。」に記載がされている。
サーバー プラットフォームが Unified Extensible Firmware Interface (UEFI) をサポートする場合は、NTFS ではなく FAT32 として、USB フラッシュ ドライブをフォーマットする必要があります。 フォーマットするパーティションを FAT32 として、次のように入力します。 format fs=fat32 quick、し、[入力] をクリックします。
ブート可能な USB フラッシュ ドライブの作成
この記事を書くきっかけとなった件ではiLO Advancedライセンスがあったため、isoイメージをiLOからマウントすることで、DVDを作成する必要はなく対応することができた。
しかし、USBメモリを使ってWindows Server 2016のインストールを行う手法があるかどうか
つまりは4GBを超えてしまったinstall.wimをダイエットすることができるのか、分割することはできるのか、という点は不明なままであった・・・
2018/03/13追記
Microsoftの公式記述を発見した。
手法１「WinPE: Store or split images to deploy Windows using a single USB drive」
USBメモリにパーテーションを２つ作り、FAT32のメイン領域と、NTFSのinstall.wimのみをおく領域を作る、というもの
手法２「Split a Windows image file (.wim) to span across multiple DVDs」
Dism /Split-Imageコマンドを使ってinstall.wimをinstall.swmに分割するというもの
Dism /Split-Image /ImageFile:C:\work\iso\sources\install.wim /SWMFile:C:\work\iso\sources\install.swm /FileSize:4000
(上記ページだと4700となっているけど、4GB超えてて大丈夫なの？と心配なので余裕をもって)
これを再度hpe dl360 gen10環境で実施する必要があったので確認した。
(1) FAT32フォーマットのUSBドライブ(Eドライブにマウント)にISOの中身(Dドライブにマウント)を全部コピーするも install.wim のみエラー
(2) コマンドプロンプト開いて「 dism /split-image /imagefile:d:\sources\install.wim /swmfile:e:\sources\install.swm /filesize:4000」を実行
(3) e:\sources\ にinstall.swm とinstall2.swm ができていることを確認
(4) できたUSBメモリで起動