現在位置: ホーム / その他の製品サポート情報 / MIRACLE System Savior 注意事項

MIRACLE System Savior 注意事項

MIRACLE System Savior 注意事項

MIRACLE System Saviorでのシステムバックアップに関して、以下の場合の対処方法もしくは対応状況をご案内します。

【重要】バックアップが完了し、リストアが失敗するケース

 

リストア関連

 

バックアップ関連

 

起動関連

 

リカバリディスク関連

 

バックアップ保存先マウント関連

 

別LUNリストア時

 

仮想OS関連

 

その他

 

【重要】バックアップが完了し、リストアが失敗するケース

ディスクラベルがMS-DOSの2TB丁度のLUNのリストアに失敗する

対象 2TB丁度のLUN(HDD)をバックアップする場合になります。
現象・原因 V1R4に含まれるpartedコマンドの不具合で、MS-DOSディスクラベルのLUNが2TB丁度の場合、バックアップ中に以下のエラーが発生し、バックアップの継続確認が出力されます。このバックアップデータでリストアした場合、リストアが失敗します。
エラー: msdos labels do not support devices that have more than 4294967295 sectors.
対処 V2R1で修正しております。

8TB以上の大規模パーティションのリストアに失敗する

対象 MSS V2R4(2.4.0291)以前のバージョンで、8TBより大きいパーティションをバックアップする場合になります。
現象・原因 大規模パーティションのバックアップの場合正常にバックアップされませんが、MSSのバックアップは正常終了します。このバックアップデータでリストアした場合、リストアが失敗します。V1R4時点のバックアップエンジン(PartClone)の制限により、バックアップ対象のパーティションは最大サイズ8TBが条件となります。
対処 MSS V2R4 のアップデート版 2.4.0291 で対応済みとなっております。
不正なバックアップデータから正常なバックアップデータを生成することは出来ません。
不正なバックアップデータをリストアした場合、リストアが失敗し、システム復旧が出来ません。

Windows Serverでスパンボリュームを作成し、バックアップ/リストアを行うと、リストア後にスパンボリュームが認識されない

対象 スパンボリュームのあるWindows Serverの環境に当てはまります。
現象・原因 MSSからスパンボリュームを連続したひとつのファイルシステムと認識できないため。
対処 V2R3以降で以下の対応を行なってください。
■ Dynamic MBR Disk の場合
Dynamic MBR Diskは、ブートパラメーターに以下を追加することでddでバックアップ可能です。
ocs_sr_save_extra_opt="--mss-whole-disk-with-dd“
※Dynamic GPT Diskに関してはご相談ください。

 

リストア関連

パーティション単位でバックアップを行い、リストアを行う際の動作

対象 パーティション単位でバックアップを行い、ディスクにリストアを行う場合となります。
現象・原因

リストア先のディスクにパーティションが作成されているか、作成されていないかによって動作が異なります。

  1. リストア先のディスクにパーティションが作成されている場合
    パーティションのリストアの際にパーティションの再作成は行われず、バックアップしたパーティションのみリストアされます。
  2. リストア先のディスクにパーティションが作成されていない場合
    パーティションのリストアに失敗してしまいます。
対処 現時点では仕様となっております。 リストア先のディスクにパーティションが作成されていない場合、バックアップ環境と同じ構成となるようにパーティションを作成してからリストアを行ってください。

ローカルディスク(Linux/ LVM) + FCマルチパスの混在環境でリストアに失敗する

対象 ローカルディスクがLinux / LVM + FCマルチパス接続の環境、かつボリュームグループが複数のディスクにまたがっている環境
現象・原因 ローカルディスク (Linux / LVM) でFCマルチパスがある場合、バックアップ・リストア時に正しく複数のディスクにまたがっているボリュームグループ (VG) が認識できません。
対処 V2R1アップデート(2.1.0244以降)で修正しております。

ローカルディスク (LVM) + FC接続の外部ディスク(FCマルチパス, LVMなし)の環境でリストアに失敗する

対象 ローカルディスクがLVM + FC接続の外部ディスク (FCマルチパス, LVMなし) の環境
現象・原因 ローカルディスク (Linux / LVM) でFCマルチパスがある場合、ローカルディスクのLVM領域がリストアされません。
対処 V2R1アップデート(2.1.0244以降)で修正しております。

Linux環境でSwap領域のリストアが実施されない

対象 RAIDコントローラーがHPE SmartArrayで、Linux環境の場合になります。
現象・原因 V2R1の不具合により、Linux環境をバックアップ、リストアした際に、Swapが作成されません。(mkswapが実行されない)
対処

※V2R1アップデート(2.1.0241以降)で修正しております。
OSリストア後、再起動し、以下の手順でSwapを作成してください。

1. /etc/fstabの情報からswap領域のUUIDを確認
# cat /etc/fstab

2-1. swap領域にUUIDが登録されている場合
# mkswap –U UUID デバイス名
例)# mkswap -U 92e4895d-a9c2-4a70-8f02-b8f67372e506 /dev/sdb2

2-2. swap領域にUUIDが登録されていない場合
# mkswapデバイス名
例)# mkswap /dev/sdb2

3. OS再起動
# shutdown –r now

 

バックアップ関連

バックアップ時に一部のディスクが見えない

対象 ローカルディスクと外部ディスクの合計が25個以上存在する環境の場合になります。
現象・原因 MSSの仕様で、外部ディスクデバイスがマルチパスを含めて25個以上見える環境の場合、HPE SmartArray配下のローカルディスクがバックアップ対象としてMSSから選択できなくなります。
対処 V2R1で修正しております。

“bitmap free count err”が出て、バックアップが失敗する

対象 すべての環境に当てはまります。
現象・原因 "bitmap free count err"はバックアップ対象のファイルシステムに不整合がある場合に、発生します。
対処 対象OSを起動し、当該パーティションにファイルシステムのチェック(FSCK)を実施して下さい。MSSからFSCKを実施する手順についてはサポートサービスまでご相談ください。

 

起動関連

インテル® GM45 グラフィックチップで起動がとまる

対象 対象機器がGM45グラフィックチップの場合になります。
現象・原因 GM45グラフィックチップでは、MSSでのデフォルトメニューである800x600フレームバッファに対応していません。
対処 V2R1で修正しております。

HPE iLO3のVirtualMediaからのブート

対象 複数HBAが接続した環境でHPE iLO3を使用する場合になります。
現象・原因 HPE iLO3にてVirtualMediaからMSSを使用した場合に、タイミングによってMSSからデフォルトメニューを選択し起動する途中で止まる現象があります。
対処 MSSの起動画面にて以下のメニューからFailSafeモードを選択し、ブートします。
⇒「Other modes of MIRACLE System Savior」
⇒「MIRACLE System Savior (Original kernel and Failsafe mode)
V2R1で修正しております。

 

リカバリディスク関連

リカバリディスク・イメージ作成時のFAT32の制限

対象 バックアップアップ保存先がFAT32ファイルシステムの場合になります。
現象・原因 FAT32ファイルシステムの制限により、4GB以上のファイルを作成することができません。リカバリディスク・イメージを作成する領域がFAT32でフォーマットされている場合に、このFAT32の制限によりイメージ作成途中で失敗します。
対処 現時点では対処方法はございません。

パーティション単位でバックアップしたイメージをリカバリメディアでリストアする際の動作

対象 パーティション単位でバックアップを行った後リカバリメディアを作成し、リカバリメディアからリカバリを行った場合になります。
現象・原因 パーティションが切られていないディスクにリストアした場合、ディスクに新しくパーティションが作成されますが、(1) /dev/sdaX などに直接スワップパーティションを作成した場合、OSは起動しますが、スワップパーティションが使用されません。あるいは (2) バックアップを行っていないパーティションを /etc/fstab で UUID を指定してマウントしていると、パーティションが未フォーマットのため OS が起動しません。
対処

saveparts でバックアップしたデータをリカバリメディアでリストアする際、空のディスクに対してはパーティションの作成が行われますが、以下の情報は復元されないため、手動で設定しなおす必要があります。
(1) スワップパーティションの UUID、LABEL
OS 起動後にスワップパーティションがマウントされているか cat /proc/swaps で確認し、マウントされていない場合は /etc/fstab を編集する必要があります。
(2) バックアップを行っていないパーティションの UUID
レスキューモードで起動し、/etc/fstab を編集する必要があります。

 

バックアップ保存先マウント関連

サブディレクトリへバックアップファイルを保存できない

対象 バックアップ保存先として、ローカルディスクまたは外部ディスクのサブディレクトリを選択する場合になります。[V2R5]
現象・原因 サブディレクトリを保存先に選択すると、マウントできないというメッセージを表示して、バックアップ処理を実行できません。
対処 V2R5(2.5.0331)で修正しております。

local_devでNTFSの領域をマウントできない

対象 バックアップ保存先をローカルサーバのNTFSファイルシステムの領域を指定した場合に発生する可能性があります。
現象・原因 マシン機種依存でローカルサーバのNTFSファイルシステム領域がマウント出来ません。
対処 V2R1で修正しております。

Windows7共有フォルダにマウント出来ない

対象 バックアップ保存先としてWindows7上の共有フォルダを使用する場合になります。
現象・原因 バックアップ保存先として、Windows7上の共有フォルダを選択した場合、”cifs mount Cannot allocate memory”エラーメッセージと共に、CIFSマウントに失敗します。
Windows7依存の問題になります。
対処 以下のようにWindowsのシステム・レジストリを作成し、対応する方法が有ります。自己責任で作業を行ってください。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters\IRPStackSize
[ DARD値、値の名前:IRPStackSize、値:15(10進) ]

 

別LUNリストア時

RHEL5系, 6系リストア時のWWN変更の対応

対象 RHEL5系(RHEL5.x, ML5.x, CentOS5.x)、RHEL6系(RHEL6.x, ML6.x, CentOS6.x)のSANBoot/マルチパス環境で別LUNにリストアする場合になります。
現象・原因 SANBoot構成では、/etc/grub.conf, /etc/mutipath.conf, initrdイメージ内でWWN情報を持っています。別LUNにリストアすることで、WWNが変更され、上記のファイル内のWWNと不整合が発生し、rootfsマウントに失敗します。RHEL5系はrootfsマウント失敗でKernel Panicで起動しません。RHEL6系では、rootfsはUUIDで指定されているため、シングルパスで起動はします。
対処 initrdイメージを展開し、initrdイメージ内のinitファイル、mutipath.confファイルのWWNを新しいものに修正し、ブートさせます。具体的な対処方法は煩雑になりますので、サポートサービスまでご相談ください。
RHEL5系は別LUNリストア後もシングルパスで起動出来るように、予め/etc/grub.conf, /etc/fstabをUUID指定に変更して置くことを推奨します。

VMwareESX 3.5, 4.xリストア時のLUN ID変更の対応

対象 VMware ESX3.5, 4.x環境で別LUNにリストアする場合になります。
現象・原因 ESXはNAA ID(LUN IDに依存)のパス指定しているサービスコンソールの仮想ディスクを起動時にマウントします。NAA IDが変更されると、サービスコンソールの仮想ディスクのマウントに失敗します。
対処 Troubleshooting modeから新しいパスでvmfsボリュームを再読し、設定修正します。
対応方法は以下のVMware社Knowledge情報を参照しご対応ください。
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1012142

VMwareESXi 4.1, 5.0リストア時のLUN ID変更の対応

対象 VMware ESXi 4.1, 5.0環境で別LUNにリストアする場合になります。
現象・原因 NAA ID(LUN IDに依存)が変更されると、VMFSのヘッダに書かれているNAA IDと不整合が発生し、当該データストアが読み込めなくなります。
対処 コンソールで当該データストア(VMFSボリューム)の再署名を実施し、対応します。
対応方法は以下のVMware社Knowledge情報を参照しご対応ください。
http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1011387

 

仮想OS関連

VMwareESXの仮想OSのバックアップ(ネットワークアダプタ)

対象 VMwareESXの仮想OSで”vmxnet”を使用している場合になります。
現象・原因 VMwareESXの仮想バックアップ時に、仮想ディスクのネットワークアダプタが”vmxnet”を選択している場合は、MSSで認識できません。
対処 V2R1で修正しております。

VMwareESXの仮想OSのバックアップ (SCSIコントローラー)

対象 VMwareESXの仮想OSで”Buslogic”を使用している場合になります。
現象・原因 VMwareESXの仮想OSバックアップ時に、仮想ディスクのSCSIコントローラタイプに"Buslogic"を選択している場合は、MSSで認識できません。
対処 バックアップ取得時にSCSIコントローラタイプを"LSI Logic"に変更いただく必要があります。

Hyper-Vの仮想OSのバックアップ(ネットワークアダプタ)

対象 Hyper-Vの仮想OSでバックアップ保存先がファイルサーバの場合になります。
現象・原因 Hyper-V環境では、標準ネットワークアダプタはMSS(Linux系OS)から認識することが出来ません。
対処 仮想OSの設定で、レガシネットワークアダプタを追加することにより、MSSより認識出来るようになります。

 

その他

10ポート以上のネットワークカードが認識されない

対象 バックアップ対象のマシンに接続されているオンボードと増設したネットワークカードを合わせて10ポート以上のネットワークカードをシステムに接続している場合になります。
現象・原因 10ポート分は認識されますが、11ポート以上のポートが認識されません。
対処 V2R1アップデート (2.1.0256以降) で修正しております。

 

[更新履歴]
2017年12月6日 更新
2016年9月2日 更新
2015年8月5日 更新
2011年11月10日 新規作成