data ontap 7.3 データ保護バックアップとリカバ …...ibm system storage n シリーズ...

IBM System Storage N シリーズ

Data ONTAP 7.3データ保護バックアップとリカバリーのガイド

GC88-8110-00(英文原典：GC27-2204-03)

��

お願い本製品およびオプションに電源コード・セットが付属する場合は、それぞれ専用のものになっていますので他の電気機器には使用しないでください。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　

原典： GC27-2204-03

IBM System Storage N series

Data ONTAP 7.3

Data Protection Online Backup and Recovery Guide

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

第1刷 2009.8

© Copyright International Business Machines Corporation 2008, 2009.

著作権情報

Copyright © 1994–2008 NetApp, Inc. All rights reserved. Printed in the U.S.A.

No part of this document covered by copyright may be reproduced in any form or by

any means―graphic, electronic, or mechanical, including photocopying, recording,

taping, or storage in an electronic retrieval system―without prior written permission of

the copyright owner.

Portions copyright © 2008 IBM Corporation. All rights reserved. Printed in the U.S.A.

U.S. Government Users Restricted Rights―Use, duplication, or disclosure restricted by

GSA ADP Schedule Contract with IBM Corporation.

No part of this document covered by copyright may be reproduced in any form or by

any means― graphic, electronic, or mechanical, including photocopying, recording,

taping, or storage in an electronic retrieval system―without prior written permission of

the copyright owner.

References in this documentation to IBM products, programs, or services do not imply

that IBM intends to make these available in all countries in which IBM operates. Any

reference to an IBM product, program, or service is not intended to state or imply

that only IBM’s product, program, or service may be used. Any functionally

equivalent product, program, or service that does not infringe any of IBM’s or

NetApp’s intellectual property rights may be used instead of the IBM or NetApp

product, program, or service. Evaluation and verification of operation in conjunction

with other products, except those expressly designated by IBM and NetApp, are the

user’s responsibility.

Portions of this product are derived from the Berkeley Net2 release and the 4.4-Lite-2

release, which are copyrighted and publicly distributed by The Regents of the

University of California.

Copyright © 1980–1995 The Regents of the University of California. All rights

reserved.

Portions of this product are derived from NetBSD, copyright © Carnegie Mellon

University.

Copyright © 1994, 1995 Carnegie Mellon University. All rights reserved. Author Chris

G. Demetriou.

Permission to use, copy, modify, and distribute this software and its documentation is

hereby granted, provided that both the copyright notice and its permission notice

appear in all copies of the software, derivative works or modified versions, and any

portions thereof, and that both notices appear in supporting documentation.

© Copyright IBM Corp. 2008, 2009 1

CARNEGIE MELLON ALLOWS FREE USE OF THIS SOFTWARE IN ITS “AS IS”

CONDITION. CARNEGIE MELLON DISCLAIMS ANY LIABILITY OF ANY KIND

FOR ANY DAMAGES WHATSOEVER RESULTING FROM THE USE OF THIS

SOFTWARE.

Software derived from copyrighted material of The Regents of the University of

California and Carnegie Mellon University is subject to the following license and

disclaimer:

Redistribution and use in source and binary forms, with or without modification, are

permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notices, this list of

conditions, and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notices, this list of

conditions, and the following disclaimer in the documentation and/or other materials

provided with the distribution.

All advertising materials mentioning features or use of this software must display this

text:

This product includes software developed by the University of California, Berkeley

and its contributors.

Neither the name of the University nor the names of its contributors may be used to

endorse or promote products derived from this software without specific prior written

permission.

THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS

IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT

LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND

FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT

SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL

DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF

SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR

BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF

THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF

SUCH DAMAGE.

This software contains materials from third parties licensed to NetApp Inc. which is

sublicensed, and not sold, and title to such material is not passed to the end user. All

rights reserved by the licensors. You shall not sublicense or permit timesharing, rental,

facility management or service bureau usage of the Software.

Portions developed by the Apache Software Foundation (http://www.apache.org/).

Copyright © 1999 The Apache Software Foundation.

2 IBM System Storage N シリーズ: Data ONTAP 7.3 データ保護バックアップとリカバリーのガイド

Portions Copyright © 1995–1998, Jean-loup Gailly and Mark Adler

Portions Copyright © 2001, Sitraka Inc.

Portions Copyright © 2001, iAnywhere Solutions

Portions Copyright © 2001, i-net software GmbH

Portions Copyright © 1995 University of Southern California. All rights reserved.

Redistribution and use in source and binary forms are permitted provided that the

above copyright notice and this paragraph are duplicated in all such forms and that

any documentation, advertising materials, and other materials related to such

distribution and use acknowledge that the software was developed by the University of

Southern California, Information Sciences Institute. The name of the University may

not be used to endorse or promote products derived from this software without

specific prior written permission.

Portions of this product are derived from version 2.4.11 of the libxml2 library,

copyright © 1994–2002 World Wide Web Consortium, (Massachusetts Institute of

Technology, Institut National de Recherche en Informatique et en Automatique, Keio

University). All Rights Reserved. http://www.w3.org/Consortium/Legal/

NetApp modified the libxml2 software on December 6, 2001, to enable it to compile

cleanly on Windows, Solaris, and Linux. The changes have been sent to the

maintainers of libxml2. The unmodified libxml2 software can be downloaded from

http://www.xmlsoft.org/.

Software derived from copyrighted material of the World Wide Web Consortium is

subject to the following license and disclaimer:

Permission to use, copy, modify, and distribute this software and its documentation,

with or without modification, for any purpose and without fee or royalty is hereby

granted, provided that you include the following on ALL copies of the software and

documentation or portions thereof, including modifications, that you make:

The full text of this NOTICE in a location viewable to users of the redistributed or

derivative work.

Any pre-existing intellectual property disclaimers, notices, or terms and conditions. If

none exist, a short notice of the following form (hypertext is preferred, text is

permitted) should be used within the body of any redistributed or derivative code:

“Copyright © [$date-of-software] World Wide Web Consortium, (Massachusetts

Institute of Technology, Institut National de Recherche en Informatique et en

Automatique, Keio University). All Rights Reserved. http://www.w3.org/Consortium/

Legal/”

Notice of any changes or modifications to the W3C files, including the date changes

were made.

THIS SOFTWARE AND DOCUMENTATION IS PROVIDED “AS IS,” AND

COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES,

著作権情報 3

EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT

THE USE OF THE SOFTWARE OR DOCUMENTATION WILL NOT INFRINGE

ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER

RIGHTS.

COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT,

SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF

THE SOFTWARE OR DOCUMENTATION.

The name and trademarks of copyright holders may NOT be used in advertising or

publicity pertaining to the software without specific, written prior permission. Title to

copyright in this software and any associated documentation will at all times remain

with copyright holders.

Software derived from copyrighted material of NetApp, Inc. is subject to the following

license and disclaimer:

NetApp reserves the right to change any products described herein at any time, and

without notice. NetApp assumes no responsibility or liability arising from the use of

products described herein, except as expressly agreed to in writing by NetApp. The

use or purchase of this product does not convey a license under any patent rights,

trademark rights, or any other intellectual property rights of NetApp.

The product described in this manual may be protected by one or more U.S.A.

patents, foreign patents, or pending applications.

RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government

is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in

Technical Data and Computer Software clause at DFARS 252.277-7103 (October 1988)

and FAR 52-227-19 (June 1987).


商標情報

ここには、該当する商標帰属表示すべての一覧があります。

IBM、IBM ロゴ、AIX、および System Storage は、世界の多くの国で登録されたInternational Business Machines Corp. の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml をご覧ください。

Microsoft および Windows Media は、Microsoft Corporation の米国およびその他の国における商標です。


特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM

の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒106-8711

東京都港区六本木 3-2-12

日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

詳しくは、次の Web サイトにアクセスしてください。http://www.ibm.com/ibm/

licensing/contact/.

以下の保証は、国または地域の法律に沿わない場合は、適用されません。

IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。


http://www.ibm.com/ibm/licensing/contact/

http://www.ibm.com/ibm/licensing/contact/

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。


本書について

ここでは、本書の説明する内容、対象読者、本書で使用される特殊な用語、本書での情報の表記に使用されるコマンド、キーボード、および字体の規則など、情報の見つけ方と使い方に関する詳細を確認できます。

本書では、Data ONTAP ソフトウェアを実行するストレージ・システムの間でデータを保護、バックアップ、リストア、およびコピーする方法について説明します。本書は、ストレージ・システムのすべてのモデルに適用されます。

対象読者ここでは、本書の対象読者、および読者の事前知識と経験に関する前提について説明します。

本ガイドは、ストレージ・サブシステムのクライアント上で実行されるオペレーティング・システム (例えば、UNIX、Windows 95、Windows NT、Windows 2000) に習熟しているシステム管理者を対象にしています。

ストレージ・システムを構成する方法、および NFS、CIFS、および HTTP の各プロトコルがファイル共有またはファイル転送にどのように使用されるかについて、十分な知識が必要です。本ガイドでは、基本的なシステムまたはネットワーク管理に関するトピック、例えば IP アドレッシング、ルーティング、ネットワーク・トポロジーなどは扱いません。ストレージ・システムの特性に重点を置いて説明します。

サポートされるフィーチャーIBM® System Storage™ N シリーズ・ストレージ・システムは、Data ONTAP® ソフトウェアによって駆動されます。この製品のソフトウェア資料に記載されているフィーチャーの一部は、IBM によって提供されておらず、サポートもされていません。詳しくは、IBM 担当員または販売店にお問い合わせください。サポートされるフィーチャーに関する情報は、次の Web サイトにも掲載されています。

www.ibm.com/storage/support/nas/

現在入手可能な N シリーズの製品およびフィーチャーのリストは、次の Web サイトに掲載されています。

www.ibm.com/storage/nas/


http://www.ibm.com/storage/support/nas/

http://www.ibm.com/storage/nas/

情報、ヘルプ、およびサービスの利用ヘルプ、サービス、技術支援、または IBM 製品に関する詳しい情報が必要な場合は、IBM がさまざまな形で提供している支援をご利用いただけます。このセクションでは、IBM と IBM 製品に関する追加情報の入手先、IBM N シリーズ製品で問題が発生した場合の対処方法、およびサービスが必要になった場合の連絡先について記載しています。

依頼する前に連絡する前に、以下の手順を実行して、必ずお客様自身で問題の解決を試みてください。

v ケーブルがすべて正しく接続されていることを確認します。

v 電源スイッチをチェックして、システムの電源がオンになっていることを確認します。

v ご使用のシステムの資料に記載されているトラブルシューティング情報を参照し、システムに付属の診断ツールを使用します。

資料の使用N シリーズ・ハードウェア製品に関する情報は、印刷資料に記載されており、システムに付属の資料 CD にも収録されています。次の IBM NAS サポート Web サイトで、同じ資料を PDF ファイルとして入手可能です。


Data ONTAP ソフトウェアの資料は、次の IBM NAS サポート Web サイトでPDF ファイルとして入手可能です。


Web サイトIBM は WWW に、最新の技術情報を入手したり、デバイス・ドライバーおよび更新をダウンロードできるページを設けています。

v NAS 製品情報については、次の Web サイトを参照してください。

www.ibm.com/storage/nas/

v NAS サポート情報については、次の Web サイトを参照してください。


v AutoSupport 情報については、次の Web サイトを参照してください。


v 資料の最新版については、次の Web サイトを参照してください。





http://www.ibm.com/storage/nas/




オンライン技術サポートへのアクセスIBM N シリーズ製品のオンライン技術サポートについては、次の Web サイトを参照してください。


ハードウェアのサービスとサポートハードウェアのサービスは、IBM Integrated Technology Services を通じてご利用いただけます。サポートの電話番号については、次の Web サイトを参照してください。

www.ibm.com/planetwide/

サポートされるサーバーおよびオペレーティング・システムIBM N シリーズ製品は、さまざまなサーバー、およびさまざまなオペレーティング・システムに接続します。サポートされる接続の最新情報については、次の Web

サイトから「Interoperability Matrices」へのリンクを選択してください。


ドライブのファームウェア更新どの装置にも当てはまる推奨事項として、最新レベルのファームウェアを実行することをお勧めします。次の Web サイトにアクセスして、最新ファームウェアをダウンロードできます。


IBM に技術サポートを依頼する前に、最新レベルのファームウェアがご使用のマシンにインストールされたことを確認してください。ファームウェアの更新について詳しくは、ご使用のバージョンの Data ONTAP に対応する「Data ONTAP Upgrade

Guide」を参照してください。

Data ONTAP マニュアル・ページへのアクセスData ONTAP マニュアル (man) ページを使用して、技術情報にアクセスできます。

このタスクについて

次のタイプの情報について、Data ONTAP マニュアル・ページが用意されています。これらは、UNIX 標準の命名規則に従ってセクション別に分類されています。

情報のタイプマニュアル・ページのセクション

コマンド 1

特殊ファイル 4

ファイル・フォーマットおよび規則 5

システム管理およびサービス 8

マニュアル・ページを表示する方法は、次のいずれかです。

本書について 11


http://www.ibm.com/planetwide/



v ストレージ・システムのコマンド行で、次のコマンドを入力する。

man command_or_file_name

v FilerView® ユーザー・インターフェース内のメイン Data ONTAP ナビゲーション・ページで、マニュアル・ページのボタンをクリックする。

v 「Commands: Manual Page Reference」の Volume 1 および 2 を使用する

注: Data ONTAP のマニュアル・ページはすべて、ストレージ・システム内でストリング「na_」を接頭部とする名前のファイルに保管されています。この接頭部は、クライアントのマニュアル・ページと区別するために付けられています。接頭部の付いた名前は、ストレージ・システムのマニュアル・ページを他のマニュアル・ページと区別するために使用され、場合によってはマニュアル・ページの「NAME」フィールドに表示されますが、接頭部はコマンド、ファイル、またはサービスの一部ではありません。

用語本書で説明する概念を理解するために、ここで定義する用語の知識が必要になることがあります。

一般的なストレージ・システム用語v Data ONTAP を実行するストレージ・システムは、ファイラー、アプライアンス、ストレージ・アプライアンス、またはシステムと呼ばれる場合があります。Data ONTAP 用の FilerView グラフィカル・ユーザー・インターフェースの名前は、これらの一般的な慣用法の 1 つを反映しています。

v コントローラーまたはストレージ・コントローラーは、Data ONTAP オペレーティング・システムを実行し、ディスク・サブシステムを制御するストレージ・システムのコンポーネントを指します。コントローラーまたはストレージ・コントローラーは、ストレージ・アプライアンス、アプライアンス、ストレージ・エンジン、ヘッド、CPU モジュール、またはコントローラー・モジュールと呼ばれる場合もあります。

アクティブ/アクティブ構成の用語v アクティブ/アクティブ構成は、2 つのシステムの一方に障害が生じた場合にデータを相互に提供するように構成された、1 対のストレージ・システムです。Data ONTAP の資料やその他の情報リソースでは、アクティブ/アクティブ構成はクラスターまたはアクティブ/アクティブ・ペアとも呼ばれる場合があります。

v アクティブ/アクティブ構成では、システムはノードと呼ばれることがよくあります。一方のノードはローカル・ノードと呼ばれる場合があり、他方のノードはパートナー・ノードまたはリモート・ノードと呼ばれます。

v 標準アクティブ/アクティブ構成は、パートナー・ノードに障害が生じたときに、片方のノードがパートナーを自動的にテークオーバーするようにセットアップされた構成を指します。

v ミラーリングされたアクティブ/アクティブ構成は、標準アクティブ/アクティブ構成と同様ですが、データのコピー (プレックス) が 2 つ存在する点が異なります。これはデータ・ミラーリングとも呼ばれます。


v ファブリック接続 MetroCluster は、syncmirror_local ライセンスと cluster_remote

ライセンスを実行するアクティブ/アクティブ構成を指します。この構成では、ノードは 2 対のファイバー・チャネル・スイッチに接続され、ノード間の距離は500 メートルを超えます。

v ストレッチ MetroCluster は、syncmirror_local ライセンスと cluster_remote ライセンスを実行するアクティブ/アクティブ構成を指します。この構成では、ノード間の距離は最大 500 メートルであり、ノード間でスイッチは使用されません。この構成は、スイッチなしの MetroCluster とも呼ばれます。

v コントローラー・フェイルオーバーは、クラスター・フェイルオーバー、またはCFO とも呼ばれ、2 つのストレージ・システムが相互のデータをテークオーバーできるようにして、データ可用性を向上するテクノロジーを指します。

v リモート・ストレージは、リモート・ノードの場所にありながら、ローカル・ノードからアクセスできるストレージを指します。

ストレージ・ハードウェアの用語v ディスク用 FC HBA または FC HBA は、ノードをスイッチまたはディスクに接続するファイバー・チャネル・ホスト・バス・アダプターを指します。

v ディスク・シェルフは、ストレージ・システムのディスク・サブシステム・コンポーネントのユニットを指します。

v ESH (Embedded Switching Hub) ディスク・シェルフ・モジュールは、単一のドライブに障害が起こってもループが停止しないように、FC-AL ループをインテリジェントに管理する手段を備えたコンポーネントを指します。また、ディスク・シェルフの環境データを伝達する、格納装置サービス・プロセッサーも内蔵しています。

v ESH2 ディスク・シェルフ・モジュールは、第 2 世代の ESH モジュールを指します。

v ESH4 ディスク・シェルフ・モジュールは、第 3 世代の ESH モジュールを指します。

v AT-FCX は、一部のディスク・シェルフで使用される、拡張された FC-AL からシリアル ATA (SATA) へのブリッジを指します。

一般用語v 入力 (type) という用語は、キーボードのキーを 1 つ以上押すことを意味します。

v 入力 (enter) という用語は、キーボードのキーを 1 つ以上押してから Enter キーを押すこと、またはグラフィカル・インターフェースのフィールドをクリックしてその中に情報を入力することを意味します。

コマンド行インターフェースの代替としての FilerViewFilerView グラフィカル・ユーザー・インターフェースを使用すれば、各種の一般的な作業を実行でき、また Web ブラウザーからストレージ・システムを表示および管理できます。


Data ONTAP 管理者としての作業は、コマンドを入力することによって実行できます。コマンドは、ストレージ・システムのコンソールで入力するか、構成ファイル内に入力するか、Telnet セッションまたはリモート・シェル接続を経由して入力できます。

別の方法としては、FilerView を使用して各種の一般的な作業を実行することもできます。 FilerView はすべてのストレージ・システムに付属しており、使いやすく、Data ONTAP の機能と FilerView でその機能を使用する方法を説明するヘルプが組み込まれています。

FilerView を使用したストレージ・システムへのアクセス、および FilerView ヘルプについて詳しくは、「System Administration Guide」を参照してください。

コマンド、キーボード、および字体の規則本書では、コマンドの入力がしやすいように、コマンド、キーボード、および字体の規則を使用しています。

コマンド規則

UNIX ワークステーション上で実行されるコマンドを示す例では、ご使用の UNIX

のバージョンによって、コマンド構文と出力が異なる場合があります。

キーボード規則v キーの組み合わせを説明するときに、本書では個々のキーを区切るためにハイフン (-) を使用します。例えば、「Ctrl-D」は「Ctrl」キーと「D」キーを同時に押すことを意味します。

v 本書では、復帰を生成するキーを示すために「Enter」という用語を使用しますが、一部のキーボードではこのキーは「Return」という名前になっています。

字体の規則

次の表では、本書で使用されている字体の規則を説明します。

規則情報のタイプ

イタリック・フォント特別な注意を必要とする語句または文字。

ユーザーが指定する必要がある情報のプレースホルダー。例えば、ガイドで arp -d

hostname コマンドを入力するように述べている場合は、「arp -d」という文字を入力し、続いてホストの実際の名前を入力します。

相互参照の資料タイトル。

モノスペース・フォントコマンド名、オプション名、キーワード、およびデーモン名。

システム・コンソールまたはその他のコンピューター・モニターに表示される情報。

ファイルの内容。


規則情報のタイプ

太字モノスペース・フォントユーザーが入力する語句または文字。入力する内容は、大文字で入力する必要がない限り、常に小文字で示されます。

特別メッセージ本書には、確認を必要とする状況への注意を喚起するために、次のタイプのメッセージが記載されている場合があります。「危険」および「注意」の注記は、ハードウェア資料にのみ示されます (該当する場合)。

注: 注には、システムを効率的にインストールまたは操作するために役立つ重要な情報が記載されています。重要: 「重要」の注記には、システム破損、データ損失、または装置の損傷を防ぐために従う必要がある指示が記載されています。

危険

「危険」の注記は、生命の危険や深刻な身体傷害を引き起こす可能性がある条件や手順について警告します。

注意:「注意」の注記は、致命的でなく深刻な危険のない身体傷害を引き起こす可能性がある条件や手順について警告します。


データ保護とは

データ保護とは、データをバックアップし、そのデータをリカバリーできることを意味します。データを保護するには、データのコピーを作成して、オリジナルが使用不能になった場合でもそのデータを修復できるようにします。

データの保護が必要な理由企業には、次の理由でデータのバックアップと保護が必要です。

v ファイルの誤った削除、アプリケーションの異常終了、データ破壊、およびウィルスからデータを保護する

v データを将来の利用のためにアーカイブする

v 災害から復旧する

データ保護の方式データ保護とバックアップの要件に応じて、事故、悪意、または災害によるデータ消失を防ぐために、Data ONTAP はさまざまなフィーチャーと方式を提供しています。

データ保護フィーチャー説明

aggr copy これは、アグリゲートに保管されているデータの高速ブロック・コピーです。これを使用すると、保管されているシステム・データのブロックをアグリゲート相互間で迅速にコピーできます。

Snapshot ボリューム内のバックアップ。

このフィーチャーを使用すれば、ボリューム上にあるデータの多重バックアップ (Snapshot コピーとも呼ばれる) の作成、スケジュール、および保守を手動または自動的に行うことができます。 Snapshot コピーが使用する追加ボリューム・スペースの量は最小限で、パフォーマンス上のコストはかかりません。

Snapshot を使用可能に設定した状態でユーザーがボリューム上の重要なデータを誤って変更または削除した場合、そのデータは最近作成されたいくつかの Snapshot コピーの 1 つから容易に素早くリストアできます。

また、Snapshot コピーを使用して、FlexVol ボリュームおよび Data ONTAP LUN のクローンを作成することもできます。詳しくは、「Data ONTAP ストレージ管理ガイド」を参照してください。



SnapRestore (ライセンスが必要)

Snapshot コピーにバックアップされた大量のデータを、高いスペース効率で迅速にリストアします。

SnapRestore フィーチャーは、ボリューム全体を対象に、Snapshot コピーからの Snapshot リカバリーを要求に応じて実行します。

SnapMirror (ライセンスが必要)

ボリューム間および qtree 間の複製。

このフィーチャーを使用すると、1 つのボリュームまたはqtree にあるデータの Snapshot コピーを定期的に作成し、そのデータをパートナーのボリュームまたは qtree (通常は別のストレージ・システム上にある) に複製し、そのデータの1 つ以上の反復コピーを Snapshot コピーとして保存できます。パートナーのボリュームまたは qtree 上で複製を行うことにより、オリジナルのボリュームまたは qtree を含むストレージ・システムが使用不可になった場合に、前回のSnapshot コピーの時点から、データがすぐに使用可能になり、迅速にリストアできます。

テープへのバックアップおよびアーカイブの操作を行っている場合、SnapMirror パートナーに既にバックアップ済みのデータに対してこの操作を実行できるので、オリジナルのストレージ・システムには、この時間のかかるパフォーマンス低下を招く作業の負担がかかりません。

SnapVault (ライセンスが必要) Snapshot テクノロジーを使用した、複数ストレージ・システム上にある複数 qtree の中央バックアップ。

このフィーチャーを使用すると、複数のボリュームおよびストレージ・システム上にある qtree を、ソースの高速バックアップとリストア専用に作成される単一の SnapVault 2 次ストレージ・システムにバックアップできます。

Windows 2000、Solaris、Linux、AIX、または HP-UX システムには、Open Systems SnapVault エージェントをインストールすることもできます。このエージェントを使用すれば、SnapVault はこれらのシステムに対してもデータのバックアップとリストアを行うことができます。

テープへのバックアップおよびアーカイブの操作を行っている場合、SnapVault 2 次ストレージ・システムに既にバックアップ済みのデータに対してこの操作を実行できるので、ストレージ・システムにはこの時間のかかるパフォーマンス低下を招く作業の負担がかかりません。



テープ・バックアップのdump コマンドと restore コマンド

テープ・バックアップおよびリストア。

dump コマンドと restore コマンドを使用すると、Snapshot

コピーをテープにバックアップできます。dump コマンドは、ボリュームの Snapshot コピーを作成してから、そのデータをテープにコピーします。Snapshot コピーはアクティブ・ファイル・システムではなく、バックアップ先はテープなので、Data ONTAP はテープ・バックアップの実行中に通常の機能を継続して実行できます。

詳しくは、「Data ONTAP Data Protection Tape Backup and

Recovery Guide」を参照してください。

vol copy ボリューム相互間でのデータの高速ブロック・コピー。

vol copy コマンドを使用すると、保管データのブロック・コピーをボリューム相互間で迅速に実行できます。

SyncMirror (アクティブ/アクティブ構成が必要)

別個の 2 つのボリュームに対するデータの連続ミラーリング。

このフィーチャーを使用すると、同じストレージ・システム・ヘッドに物理的に接続された対応するボリュームに、データをリアルタイムにミラーリングできます。

一方のボリューム上でリカバリー不能なディスク・エラーが発生した場合、ストレージ・システムはミラーリングされたボリュームにアクセスを自動的に切り替えます。

このフィーチャーを使用するには、アクティブ/アクティブ構成が必要です。

vol options コマンドの nvfail

オプション不揮発性 RAM (NVRAM) の障害によるデータ破壊に対する保護。

SnapValidator (ライセンスが必要)

無効な Oracle データがストレージ・システムに書き込まれる前に、このようなデータを検出してリジェクトします。

ウィルス・スキャン・サポート

CIFS クライアントからアクセスされるファイルに対する、サード・パーティー製のウィルス・スキャン・ソフトウェアのサポート。

MetroCluster ストレッチ MetroCluster は、構内でのサイト保護を提供し、最大 500m までの複製をサポートします。ファブリック MetroCluster は、都市内でのサイト保護を提供し、FC スイッチを使用して最大 100 km までの複製をサポートします。SyncMirror 機能が拡張され、連続ボリューム・ミラーリングが可能になりました。

データ保護とは 19

関連概念

59ページの『SnapRestore を使用したデータ・リカバリー』

197ページの『SnapVault を使用するデータ保護』

303ページの『ボリューム・コピー』

353ページの『CIFS のウィルス保護』

345ページの『SnapValidator を使用したデータベース保護』次に、Data ONTAP が SnapValidator を使用して Oracle データベースを保護する方法を説明します。

関連資料

69ページの『SnapMirror を使用するデータ保護』

317ページの『SyncMirror の管理』

オンライン・バックアップおよびオンライン・リカバリーとはData ONTAP は、オンライン・データ・リカバリーを可能にするためにオンライン・データ・バックアップを作成します。オンライン・バックアップとは、テープではなくディスクに保管されているバックアップ・データを指します。

これにより、災害復旧操作が必要になった場合に、ディスクに保管されたデータを迅速にリストアできます。

オンラインのバックアップおよびリカバリーを行うソリューションには、Snapshot、SnapMirror、SnapRestore、SnapVault、SyncMirror、vol copy コマンドなどがあります。

v Snapshot フィーチャーを使用すると、週、日、または時間ごとのオンライン・バックアップのスケジュールを設定できます。Snapshot テクノロジーは、オリジナル・データと同じボリュームにオンラインのポイント・イン・タイム・コピーを作成します。これにより、ユーザーが個々に所有する削除または変更されたファイルをリカバリーでき、システム管理者による支援は必要ありません。

v SnapMirror フィーチャーを使用すると、ボリュームまたは qtree のファイル・システム Snapshot コピーを、別のボリュームまたは qtree (同じまたは別のストレージ・システム上にある) に自動的にコピーするように定期的なスケジュールを設定できます。

v SnapRestore フィーチャーは、最大限の速度とディスク・スペース効率で、ボリューム全体を事前に作成済みの Snapshot コピーに記録された状態にリストアします。 SnapVault フィーチャーは、別々のストレージ・システムに保管されている一連の Snapshot コピー内にある、1 つ以上の qtree のデータを保護します。

v SnapVault は、qtree データのオンライン非同期レプリカを永続的に読み取り専用で保守します。 SnapVault バックアップおよび Snapshot コピーの作成は、自動スケジュールに基づいて実行されます。

注: SnapVault は、ストレージ・システム上でのバックアップを実行するほかに、Windows NT、Windows 2000、Solaris、または HP-UX を実行するサーバーへの直接バックアップも実行します。


v SyncMirror は、共有またはパートナーのストレージ・システム上にある 2 つのパートナー・ボリューム間で、データの連続リアルタイム・ミラーリングを実行します。

v MetroCluster フィーチャーは、長距離 (500 メートルから 100 キロメートル) にわたる SyncMirror 連続ミラーリングを実行します。

v vol copy コマンドは、Snapshot コピーを取り込んで、ファイル・システムを別個のボリュームまたはストレージ・システムにコピーします。この操作は手動で、またはスクリプトを使用して実行します。

v ndmpcopy コマンドは、任意のストレージ・システム上にある任意の場所に、任意のサブツリーをコピーします。詳しくは、「Data ONTAP Data Protection Tape

Backup and Recovery Guide」を参照してください。

これらのオンライン・データ・バックアップおよびリカバリーのシステムは、テープ・バックアップおよびリカバリーの補完として使用できます。

関連資料


オンライン・バックアップおよびリカバリーの利点オンライン・バックアップおよびリカバリーによる保護は、テープ・アーカイブと比べていくつかの点で有利です。

v 迅速なバックアップとリストアにより、バックアップに必要な時間が大幅に短縮されます。

v バックアップが高速になるので、より頻繁にバックアップを取ることができます。

v オンライン・バックアップから、特定のファイル、ディレクトリー、またはボリュームを容易にリカバリーできます。

v オンライン・ミラーリングおよびリストアを使用すれば、災害復旧を迅速に行うことができます。

v 高速のデータ・リカバリーにより、データ可用性が高まります。

v 短時間で大量のデータをバックアップできます。

オンライン・バックアップおよびリカバリーの欠点オンライン・スナップショットによるデータ保護には、テープ・アーカイブと比べて欠点もいくつかあります。

v オンライン・データ保護は物理的にぜい弱です。ストレージ・システムおよびディスク・シェルフは、物理的な災害に対してぜい弱です。

v オンライン・データ保護を行わなければ日常の活動に使用できるディスク・スペースなどのリソースが、オンライン・データ保護によって消費されます。

オンライン・バックアップおよびリカバリーの方式いくつかの方式を使用して、オンライン・バックアップおよびリカバリーを実行できます。

v Snapshot コピーを使用して、ファイル・システムの読み取り専用イメージを同じディスク上で作成する


v SnapRestore を使用して、前の Snapshot コピーから破損したボリュームにデータをリストアする

v SnapMirrorを使用して、一方のボリュームのレプリカを別のボリューム内で維持し、一方の qtree のレプリカを別の qtree 内で維持する

v SnapVault を使用して、サーバー上でボリュームのコピーを維持し、このサーバーから個々の qtree をクライアントに常時提供する

v vol copy コマンドを使用して、ボリューム相互間でデータをコピーする

v SyncMirror を使用して、ボリュームの 2 つの同一コピーを常に維持する

関連概念

27ページの『Snapshot の管理』

59ページの『SnapRestore を使用したデータ・リカバリー』


303ページの『ボリューム・コピー』

関連資料


317ページの『SyncMirror の管理』

NVFAIL フィーチャーとはデータベースの妥当性を低下させる NVRAM の問題が発生した場合に、NVFAIL

フィーチャーは警告を出し、データベースが自動的に再始動しないようにデータベースの名前を自動的に変更できます。これにより、データベースを再始動する前にデータベースの妥当性を確認できます。

Data ONTAP は、vol options コマンドの nvfail オプションを使用してデータベース保護を提供します。

注: このフィーチャーは、ストレージ・システムにデータベースが存在する場合のみに使用します。

関連概念

341ページの『NVFAIL を使用したデータベース保護』次に、Data ONTAP が nvfail オプションを使用して提供するデータベース保護について説明します。

データ損失災害とはデータ損失災害は、ネットワーク上で 1 つの物理サイト (例えば、建物や会社構内)

からのサービスが長時間にわたって失われる状況です。

次に、災害の例を示します。

v 火災

v 地震

v サイトでの長時間にわたる電源異常

v サイトでの長時間にわたるクライアントからストレージ・システムへの接続障害


災害が発生すると、ストレージ・システム、アプリケーション・サーバー、ネットワーキング接続、クライアント接続など、すべてのコンピューティング・インフラストラクチャーに影響が及ぶ可能性があります。災害時計画を策定する際には、すべてのコンピューティング・インフラストラクチャーを考慮に入れてください。

災害を判別する方法災害が実際に発生したことを確認するために、事前定義の手順に従うことが重要です。

災害が発生したと考えられるサイトの状況を判別するには、次のいずれかの手順を使用します。

v 次の外部インターフェースを使用する

– Ping

– リモート・シェル

– FilerView

– Protection Manager

v ネットワーク管理ツールを使用して、災害が発生したサイトへの接続をテストする

v 可能な場合は、サイトを物理的に検査する

注: 災害が発生したこと、およびサービスをリストアできないことを必ず判別した後で、災害発生を宣言してください。

データ損失災害から保護するために使用するツールData ONTAP は、管理者がローカル・ストレージ・システムに保管されているデータをオフサイト・ネットワーク・ロケーションにバックアップまたは複製できる機能および製品を提供します。これにより、1 次データ・ストレージ・サイトで災害によってデータ損失が起こった場合にデータを復元できます。


機能説明

SnapVault: サイト間のSnapshot コピーのバックアップおよび復元可能性

SnapVault 2 次ストレージ装置は、バックアップする 1 次ストレージ装置から任意の距離にあるオフサイトに置くことができます。

データのリカバリー可能性: 1 次ストレージ・サイトでデータ損失災害が発生した場合、SnapVault 2 次ストレージにバックアップされているデータを、物理的な損傷を受けていないか、災害が発生したサイトまたは代替ロケーションで置き換えられた 1 次ストレージ・ユニットに復元できます。

復元の現行性: データは、前回の Snapshot コピーが 2 次ストレージ・システムで作成された時刻から復元できます。

接続要件: 1 次および 2 次ストレージ・システム間の DSL

接続またはそれより高速な接続が推奨されます。56 Kbps などの非常に低い帯域幅の接続も可能です。

ルーター、スイッチ、および DNS サーバーは、最初にアクセスを試行する 1 次ストレージ・システムが使用不可になった場合にユーザーを代替 1 次ストレージ・サイトに送るように事前構成される必要があります。

利点: 廉価な集中型オフサイト・バックアップ

SnapMirror: サイト間のSnapshot コピーのバックアップ、可用性、および復元可能性

SnapMirror 宛先ストレージ装置は、ボリュームをミラーリングするソース・システムから任意の距離にあるオフサイトに置くことができます。

データの可用性: ソース・サイトでデータ損失災害が発生した場合、宛先サイトにある SnapMirror データを宛先サイトで素早く使用可能にすることができます。

データのリカバリー可能性: SnapMirror データを、物理的な損傷を受けていないか、災害が発生したサイトまたは代替ロケーションで置き換えられたソース・ストレージ・ユニットに復元できます。

復元の現行性: データは、前回のソースから宛先へのSnapMirror Snapshot コピー転送の時刻から復元できます。

接続要件: ソースと宛先の間の DSL 接続またはそれより高速な接続が推奨されます。56 Kbps などの非常に低い帯域幅の接続も可能です。ルーター、スイッチ、および DNS サーバーは、アクセスを試行するソースが使用不可になった場合にユーザーを宛先ストレージ・サイトに送るように事前構成される必要があります。

利点: オフサイト保護と可用性の組み合わせ


機能説明

MetroCluster: サイト間のリアルタイム・バックアップ、可用性、および復元可能性

同期的にミラーリングされた MetroCluster ストレージ・システムは、相互に最大 100 km 離れた別々のサイトに置くことができます。

データの可用性: 1 つのサイトでデータ損失災害が発生した場合、パートナー・サイトにミラーリングされているデータを素早く使用可能にすることができます。

データのリカバリー可能性: このデータを、物理的な損傷を受けていないか、災害が発生したサイトまたは代替ロケーションで置き換えられたソース・ストレージ・ユニットにもミラーリングすることができます。

復元の現行性: データは、前回の NVRAM チェックポイントの時刻から復元できます。

接続要件: スイッチおよび DSL またはそれより高速な接続で補足された Data ONTAP クラスター接続が推奨されます。ルーター、スイッチ、および DNS サーバーは、最初にアクセスを試行するクラスター・システムが使用不可になった場合にユーザーを MetroCluster パートナーに送るように事前構成される必要があります。

利点: リアルタイムのオフサイト保護および可用性の組み合わせ

関連概念


27ページの『Snapshot コピーとは』A Snapshot コピーは、ある時点でのファイル・システムの状態を取り込んだ、従来型のボリューム、FlexVol ボリューム、またはアグリゲートの凍結された読み取り専用イメージです。

関連資料


SAN 環境でデータを保護する方法ストレージ・エリア・ネットワーク (SAN) 環境への統合に対応するために作成されたストレージの論理装置 (LUN) がボリュームに含まれている場合、本書で後述するフィーチャーを使用するデータ保護を実装するために、手順を変更して実行する必要があります。

Data ONTAP LUN を含むボリューム上でのデータ・バックアップとリストアについては、「Data ONTAP ブロック・アクセス管理ガイド (iSCSI および FC 用)」を参照してください。


Protection Manager を使用したポリシー・ベースの自動データ保護通常、データおよびリソースの管理は時間のかかる作業です。これは、記憶容量、ネットワーク帯域幅、スケジュール、保存ポリシーなど、インフラストラクチャーの可変要素を手動で分析し、管理する必要があるからです。Protection Manager は、構成ポリシー (複数のストレージ・システム、ボリューム、または qtree に割り当てることが可能) および便利なウィザードを採用し、データ保護構成のいくつかの側面を自動的に検証することによって、この作業を単純化しています。

保護アプリケーションは、次のアクションを実行できます。

v 保護ポリシーを使用して、基本データ、ストレージ、およびバックアップとミラーの関係を管理する。

v ローカルおよびリモートのバックアップとミラー・コピーを管理する。

v ユーザーが割り当てたポリシーに基づいて、バックアップとミラー・コピー用の2 次ストレージを提供する。

v 災害復旧機能を使用可能にする (ライセンス対象の災害復旧オプションをインストールした場合)。

v 規格適合チェッカーを使用して、バックアップおよび災害復旧構成を自動的に検証する。

詳しくは、「Provisioning Manager and Protection Manager Administration Guide」を参照してください。


Snapshot の管理

Snapshot コピーとはA Snapshot コピーは、ある時点でのファイル・システムの状態を取り込んだ、従来型のボリューム、FlexVol ボリューム、またはアグリゲートの凍結された読み取り専用イメージです。

Snapshot コピーは、データをバックアップおよびリストアするための最初の防衛線です。従来型のボリューム、FlexVol ボリューム、またはアグリゲートについては、「Data ONTAP ストレージ管理ガイド」を参照してください。

Snapshot コピーの作成時: Data ONTAP は、ボリュームごとに Snapshot コピーを自動的に作成および削除する、構成可能な Snapshot スケジュールを維持します。Snapshot コピーは、手動で作成および削除することもできます。

各ボリューム上に、一度に最大 255 の Snapshot コピーを保管できます。

Snapshot コピーが占有できるディスク・スペースの比率を指定できます。デフォルト設定は、ディスクの合計スペース (使用済みと未使用の両方) の 20% です。

関連概念

34ページの『Snapshot スケジュールの作成』Data ONTAP は、ボリュームごとにデフォルトの Snapshot スケジュールを提供します。要件に合うようにスケジュールを構成できます。

41ページの『Snapshot ディスク消費量とは』Data ONTAP は、Snapshot コピーが作成された時点で現在使用中のディスク・ブロックすべてのポインターを保存します。ファイルが変更されたとき、Snapshot コピーはそのファイルが変更前に格納されていたディスク・ブロックをそのまま指し示し、変更内容は新規ディスク・ブロックに書き込まれます。

Snapshot コピーがファイル・アクセス権を処理する方法Snapshot ファイルは、オリジナル・ファイルと同じアクセス権および inode 番号を保持するので、セキュリティー・システムの保全性が損なわれません。

inode は、ストレージ・システム上のファイルに関する情報 (アクセス権の情報を含む) を保持するデータ構造です。ファイル・システム内のファイルはすべて、同じファイル・システム内では inode によって一意的に識別されます。

注: Snapshot コピー内のファイルの inode 番号は、アクティブ・ファイル・システム内で対応するファイルの inode 番号と同じです。このため、UNIX クライアント上のプログラムの一部は、2 つのファイルが同一であると見なします。例えば、GNU diff プログラムの旧バージョンを使用して 2 つのファイルを比較すると、これらのファイル間で相違が検出されない場合があります。ただし、GNU diff の新しいバージョンは正しく動作します。場合によっては、Snapshot コピーからファイルをリストアしようとすると、次のようなエラー・メッセージが表示されることがあります。


cp:.snapshot/xxx and xxx are identical.

コピーまたは比較の前に 2 つのファイルの inode 番号を異なるものにするには、一方のファイルを別の名前でコピーしてください。

Snapshot コピーを使用してできることSnapshot コピーを使用して、システム管理者およびエンド・ユーザーは、バックアップとリカバリーの際に重要な作業を実行できます。

Snapshot コピーを使用して、システム管理者は次の作業を実行できます。

v 瞬間的なバックアップを作成する

v FlexVol ボリュームのクローンを作成する

v Data ONTAP LUN のクローンを作成する

Data ONTAP LUN のクローン作成については、「Data ONTAP ブロック・アクセス管理ガイド (iSCSI および FC 用)」を参照してください。

FlexVol ボリュームのクローン作成については、「Data ONTAP ストレージ管理ガイド」を参照してください。

Snapshot コピーを使用して、エンド・ユーザーは次の作業を実行できます。

v 誤って変更または削除された、ファイルの以前のバージョンまたはセットをリカバリーする。

v システム管理者がテープからファイルをリストアする必要がなく、ユーザー自身が所有するファイルをリストアする。

Snapshot コピーへのユーザー・アクセスについてデフォルトでは、すべてのボリュームに .snapshot という名前のディレクトリーが含まれており、このディレクトリーを介してユーザーはそのディレクトリーにあるファイルの旧バージョンにアクセスできます。ユーザーは、使用されているファイル共有プロトコル (NFS または CIFS) に基づいて、 Snapshot コピーにアクセスできます。 Snapshot コピーへのアクセスはオフにすることができます。

スナップショット・ファイルは、オリジナル・ファイルと同じ読み取りアクセス権を引き継ぎます。ボリューム内のファイルを読み取るためのアクセス権を持っているユーザーは、Snapshot コピー内でもそのファイルを読み取ることができます。ボリュームに対する読み取りアクセス権のないユーザーは、Snapshot コピー内でもそのファイルを読み取ることができません。Snapshot コピーに書き込みアクセス権は設定できません。

NFS による Snapshot コピーへのアクセス次の図に、toaster という名前の vol0 ボリュームが /n/toaster ディレクトリーにマウントされている状態での、NFS クライアント上のディレクトリー構造を示します。


この例では、ユーザーは /n/toaster/.snapshot ディレクトリー内で Snapshot コピーにアクセスできます。 .snapshot ディレクトリーは、マウント・ポイントのみに表示されることに注意してください。実際には、このディレクトリーはツリー内のすべてのディレクトリーに存在しますが、ユーザーに対しては .snapshot ディレクトリーはマウント・ポイントでのみ表示されます。つまり、.snapshot ディレクトリーは、各ディレクトリー内では名前によってアクセス可能ですが、マウント・ポイントで実行した ls コマンドの出力にのみ表示されます。

例えば、ファイル・システムのマウント・ポイントでは、ディレクトリー・リストは次のように表示されます。

systemA> ls -a. .. .snapshot dir1 dir2

マウント・ポイントより下のディレクトリー内で同じコマンドを入力すると、.snapshot ディレクトリーは表示されません。次に例を示します。

systemA> cd dir1systemA> ls -a. .. file1 file2

ディレクトリー名 .snapshot を指定して ls コマンドを入力すると、dir1 ディレクトリーに対する Snapshot コピーごとに、ディレクトリーが 1 つずつ表示されます。

図 1. NFS クライアントのディレクトリー構造

Snapshot の管理 29

systemA> ls .snapshot

hourly.0 hourly.4 nightly.0 nightly.4hourly.1 hourly.5 nightly.1 nightly.5hourly.2 hourly.6 nightly.2 weekly.0hourly.3 hourly.7 nightly.3 weekly.1

.snapshot ディレクトリー項目がすべてのディレクトリーに表示されると、多くのコマンドが誤動作を起こすことになります。例えば、ファイルを削除するための再帰コマンドはすべて失敗します。これは、.snapshot ディレクトリーより下の項目はすべて読み取り専用であるからです。再帰コマンドによって、Snapshot コピーの内容すべて、およびアクティブ・ファイル・システム内のファイルがコピーされます。find コマンドが生成するリストは、予想を大幅に上回る長さになります。

CIFS による Snapshot コピーへのアクセスデフォルトでは、CIFS ユーザーには .snapshot ディレクトリーが表示されません。 .snapshot ディレクトリーが表示されるようにするには、cifs.show_snapshot

オプションを使用します。詳しくは、na_options(1) のマニュアル・ページを参照してください。

CIFS ユーザーに対しては、.snapshot ディレクトリーは共有のルートにのみ表示されます。例えば、ユーザーのホーム・ディレクトリーが bill という名前の共有であり、この共有は /vol/vol0/home/bill ディレクトリーに対応している場合は、/vol/vol0/home/bill/.snapshot ディレクトリーのみが表示されます。このユーザーがホーム・ディレクトリーの内容を表示すると、.snapshot ディレクトリーは、オペレーティング・システムが長いファイル名をサポートしている場合は~snapshot と表示され、オペレーティング・システムが短いファイル名のみをサポートしている場合は ~SNAPSHT と表示されます。

注: クライアント・オペレーティング・システムが隠しファイルを表示するように構成されている場合は、ディレクトリー・リストまたは Windows エクスプローラーの画面に .snapshot ディレクトリーを表示できます。

共有に含まれる各ディレクトリー内には、スナップショット・ディレクトリーは存在しますが、クライアントに対して表示されません。例えば、クライアント・オペレーティング・システムが長いファイル名をサポートしている場合、そのオペレーティング・システム上のアプリケーションは、ディレクトリー名として.snapshot、~snapshot、または ~SNAPSHT を使用して、共有の各レベルで Snapshot

コピーを使用できます。ただし、ユーザーはどのリストにもディレクトリー名を表示できません。

CIFS クライアントからの Snapshot コピーへのアクセスCIFS クライアントから Snapshot コピーにアクセスできます。

Windows NT 4 または他の Windows クライアント (Windows 95 以降) からSnapshot コピーにアクセスするには、「スタート」 > 「ファイル名を指定して実行」メニューをクリックし、コマンド \\systemname\share\.snapshot (または~snapshot あるいは ~SNAPSHT) を入力します。systemname は、使用しているストレージ・システムの名前です。


share は、アクセスする Windows 共有の名前です。 \\systemA\home\.snapshot 共有の中でこれより下位にある Snapshot コピーにも、下位ディレクトリーのパスを指定すればアクセスできます。どのシステムでも、DOS を使用して Snapshot コピーにアクセスできます。このためには、~SNAPSHT ディレクトリーに移動します。

Snapshot コピーへのクライアント・アクセスを使用不可または使用可能にする

例えば、セキュリティー上の理由で、あるいは破損ファイルやウィルス感染ファイルへのアクセスを防止するために、特定のボリューム内にある Snapshot コピーへのクライアント・アクセスを使用不可に設定したり、使用可能に設定したりする必要が生じることがあります。

タスクの結果

ボリューム内の Snapshot コピーへのクライアント・アクセスを使用不可または使用可能に設定するには、次の手順で行います。

目的... 手順...

Snapshot コピーへのクライアント・アクセスを使用不可に設定し、.snapshot ディレクトリーがクライアントに表示されないようにする

コマンド vol options volume_name

nosnapdir on を入力します。volume_name

は、クライアントからの Snapshot コピーへのアクセスを使用不可に設定するボリュームの名前です。

Snapshot コピーへのクライアント・アクセスを使用可能に設定し、.snapshot ディレクトリーがクライアントに表示されるようにする

コマンド vol options volume_name

nosnapdir off を入力します。volume_name

は、クライアントからの Snapshot コピーへのアクセスを使用可能に設定するボリュームの名前です。

iSCSI または FCP ネットワークでの Data ONTAP Snapshot コピーの動作

ファイル・システム上で実行されているアプリケーションのスナップショットが原因で、Snapshot コピーのデータが不整合になる可能性があります。これを回避するには、Snapshot コピーを作成する前にディスク上のデータを論理的に整合させるための手段をとる必要があります (例えば、Snapshot コピーを作成する前にアプリケーションを静止する)。

このタイプのアプリケーションの Snapshot コピーを作成するには、ファイルが閉じていて変更できないようにしてください。アプリケーションを静止するかオフラインにすることによって、Snapshot コピーの作成前にファイル・システム・キャッシュがコミットされるようになります。 Snapshot コピーの完了にかかる時間は 1 秒未満で、その後はアプリケーションの通常の操作を再開できます。

アプリケーションの静止に長い時間が必要な場合は、アプリケーションがしばらくの間は使用不可になることがあります。このシナリオを回避するために、一部のアプリケーションには組み込みのホット・バックアップ・モードが備わっています。このモードを使用すれば、アプリケーションがパフォーマンス制限付きの低下モードで動作している間に、Snapshot コピーまたはバックアップを実行できます。


Data ONTAP は、ロー・デバイス・パーティションを操作する機能があるアプリケーションの Snapshot コピーを作成することはできません。バックアップ・ソフトウェア・ベンダーから提供されている、この種のアプリケーション専用に作成されたモジュールを使用することをお勧めします。

ロー・パーティションをバックアップするには、バックアップ操作の期間中はホット・バックアップ・モードを使用することが最もよい方法です。 IBM SAN 構成を使用したデータベースのバックアップとリカバリーについて詳しくは、IBM NAS

サポート・サイトで該当するデータベースについてのテクニカル・レポートを参照してください。

関連情報


SAN 環境での Snapshot コピーの使用LUN 内のデータが整合した状態である場合、Snapshot コピーを SAN 環境で使用できます。


Data ONTAP は、アプリケーションが LUN 内のデータにアクセスしている場合、LUN 内のデータが整合した状態であるかどうかを確認できません。そのため、Snapshot コピーを作成する前に、LUN を使用しているアプリケーションまたはファイル・システムを静止してください。このアクションにより、ホスト・ファイル・システムのバッファーがディスクにフラッシュされます。静止すると、Snapshot コピーの整合性を確保できます。

例えば、ストレージ・システムへの管理アクセス権限を持つホストでバッチ・ファイルおよびスクリプトを使用できます。これらのスクリプトを使用して、ここで説明するステップを実行できます。

1. LUN 内のデータをアプリケーションと整合させます。データベースを静止したり、アプリケーションをホット・バックアップ・モードにしたり、アプリケーションをオフラインにします。

2. スクリプトで rsh または ssh コマンドを使用してストレージ・システムにアクセスし、snap コマンドを使用して Snapshot コピーをストレージ・システムに作成します (ボリュームのサイズまたは使用量に関係なく、わずか数秒間で終わります)。

3. アプリケーションを通常動作に戻します。

次のタスク

Snapshot スクリプトを指定の間隔で実行するようにスケジュールできます。Windows ホストでは、Windows タスクスケジューラを使用できます。 UNIX ホストでは、cron またはその他のユーティリティーを使用できます。また、SnapDrive

を使用して、ホスト・ファイル・システムのバッファーの内容をディスクに保存し、Snapshot コピーを作成することもできます。詳しくは、「SnapDrive Installation

and Administration Guide」を参照してください。



LUN と Snapshot コピーの関係LUN の Snapshot コピーを作成する場合、最初に Snapshot コピーのデータによってバッキングされます。Snapshot コピーが作成された後、LUN に書き込まれたデータをアクティブ・ファイル・システムで使用することができます。

Snapshot コピーを作成した後、それを使用して LUN クローンを作成し、アプリケーションまたはデータベースのデータまたはスクリプトをテストするためのプロトタイプとして一時的に使用できます。LUN クローンは Snapshot コピーによってバッキングされているため、クローンを分割するまで Snapshot コピーを削除することはできません。

LUN を Snapshot コピーから復元するには、SnapRestore を使用します。ただし、復元された LUN には Snapshot コピーの作成後に書き込まれたすべてのデータが含まれていないことに注意してください。

使用可能なスペースを管理する方法については、「Data ONTAP Block Access

Management Guide」を参照してください。

スペース予約によって Snapshot コピーの作成が妨げられる場合があります。LUN

を作成すると、デフォルトでスペース予約が使用可能になります。つまり、LUN への書き込み操作が保証されるように十分なスペースが予約されます。予約されるスペースが多いほど、使用可能な空きスペースが少なくなります。ボリューム内の空きスペースが一定のしきい値を下回る場合、Snapshot コピーを作成できません。

使用可能なスペースを管理する方法については、「Data ONTAP Block Access

Management Guide」を参照してください。

Snapshot コピーからのファイルの復元ファイルが誤って消去または破壊された場合、ファイルを Snapshot コピーから復元しなければならないことがあります。SnapRestore オプションを購入した場合、1 つのコマンドによってファイルまたはボリュームを Snapshot コピーから自動的に復元できます。

1. 元のファイルがまだ存在していて、それを Snapshot ファイルで上書きしたくない場合、UNIX または Windows クライアントを使用して元のファイルを名前変更するか、別のディレクトリーに移動します。

2. 復元するファイルのバージョンが入った Snapshot コピーを見つけます。

3. ファイルを .snapshot ディレクトリーからファイルが元々入っていたディレクトリーにコピーします。


関連概念

60ページの『SnapRestore の使用に適した状況』SnapRestore は、データ破壊からのリカバリーのために使用します。1 次側のストレージ・システム・アプリケーションがボリューム内のデータ・ファイルを破壊した場合は、そのボリューム、またはボリューム内の指定ファイルを、データ破壊の起こる前に作成された Snapshot コピーに戻すことができます。

関連タスク

64ページの『選択された Snapshot コピーへのファイルの復帰』snap restore を使用して単一ファイルを選択した Snapshot コピーに復帰することは、ファイルが非常に大容量で、以前のファイル・バージョンを Snapshot コピーからアクティブ・ファイル・システムにコピーできない場合に実用的な方法です。

Shadow Copy Client ツールを使用する Snapshot の復元Windows Shadow Copy Client を使用して Data ONTAP Snapshot ファイルにアクセスし、ファイルを復元することができます。Shadow Copy Client の「プロパティ」メニューには「以前のバージョン」タブがあり、そこで Data ONTAP Snapshot イメージを表示および復元することができます。

Shadow Copy Client software for Windows 2003 は、Previous Versions Client と呼ばれています。Microsoft から入手可能なダウンロードにより、Shadow Copy Client ツールを Windows の大半の旧バージョンで使用できます。 Shadow Copy Client または Previous Versions Client ソフトウェアについて詳しくは、Microsoft 資料を参照してください。

Snapshot スケジュールの作成Data ONTAP は、ボリュームごとにデフォルトの Snapshot スケジュールを提供します。要件に合うようにスケジュールを構成できます。

このスケジュールによって、Snapshot コピーが自動的に作成され、古い Snapshot

コピーはあらかじめ決められた時間が経過した後に削除されます。

ストレージ・システムに Data ONTAP をインストールすると、デフォルトのSnapshot スケジュールが作成されます。デフォルト Snapshot スケジュールによって、月曜から日曜まで深夜 12 時に 1 回行われる夜間 Snapshot コピーと、午前 8

時、正午、午後 4 時、および午後 8 時に 4 回行われる時間ごとの Snapshot コピーが作成されます。Data ONTAP は、最新の夜間 Snapshot コピーを 2 つ、最新の時間ごとの Snapshot コピーを 6 つ保存し、新しい Snapshot コピーが作成されたときは最も古い夜間および時間ごとの Snapshot コピーを削除します。

関連タスク

38ページの『Snapshot スケジュールの変更』特定のボリュームに対する自動的な Snapshot スケジュールを変更できます。

ユーザー指定の Snapshot スケジュールsnap sched コマンドを使用して自動的に実行されるようにセットアップできるスケジュールには 3 つのタイプがあります。


次の表で 3 つのタイプについて説明します。

タイプ説明

週ごと Data ONTAP は、これらの Snapshot コピーを毎週日曜日の深夜 12

時に作成します。

週ごとの Snapshot コピーの名前は weekly.n です。ここで、n は整数です。最新の週ごとの Snapshot コピーは weekly.0 で、weekly.1

は次に新しい週ごとの Snapshot コピーです。

夜間 Data ONTAP は、これらの Snapshot コピーを毎晩深夜 12 時に作成します。ただし、週ごとの Snapshot コピーが同じ時刻に行われるようにスケジュールされている場合は除きます。

夜間 Snapshot コピーの名前は nightly.n です。ここで、n は整数です。最新の夜間 Snapshot コピーは nightly.0 で、nightly.1 は次の新しい夜間 Snapshot コピーです。

時間ごと Data ONTAPは、これらの Snapshot コピーを正時または指定された時間に作成します。ただし、夜間または週ごとの Snapshot コピーが同じ時刻に行われるようにスケジュールされている場合は除きます。

時間ごとの Snapshot コピーの名前は hourly.n です。ここで、n は整数です。最新の時間ごとの Snapshot コピーは hourly.0 で、hourly.1 は次の新しい時間ごとの Snapshot コピーです。

注: Data ONTAP が週ごと、夜間、または時間ごとの Snapshot コピーを作成すると、週ごと、夜間、または時間ごとのすべての Snapshot コピーの n の値が調整されます。n の値が高いほど、Snapshot コピーは古いものです。

Snapshot スケジュールの競合SnapMirror または SnapVault のどちらかのフィーチャーが snap sched アクティビティーと同時に Snapshot 管理を実行するようにスケジュールが設定されていると、snap sched コマンドを使用してスケジュールに入れられた Snapshot 管理操作が、syslog メッセージを出して失敗する場合があります。

syslog メッセージは、次のとおりです。

Skipping creation of hourly snapshot

および

Snapshot already exists

この状態を回避するには、snap sched 操作が Snapshot コピーの作成を試みるときとまったく同じ時刻に SnapMirror アクティビティーが開始または終了しないように、Snapshot 更新スケジュールをずらしてください。また、snap sched Snapshot コピーが SnapVault アクティビティーと競合する場合は、snapvault snap sched コマンドを使用して同等なスケジュールを構成してください。


コマンド行での Snapshot スケジュールの表示ボリュームの Snapshot スケジュールを表示できます。

ボリュームの Snapshot スケジュールを表示するには、次のコマンドを入力します。snap sched [volume_name]

注: ボリューム名を指定しない場合、snap sched は、ストレージ・システム上の各ボリュームの Snapshot スケジュールを表示します。

systemA> snap sched vol1Volume vol1: 2 6 8@8,12,16,20

FilerView を使用する Snapshot スケジュールの表示FilerView を使用してボリュームの Snapshot スケジュールを表示できます。

1. FilerView で、左側のリストの「Volumes (ボリューム)」をクリックします。

2. 「Volumes (ボリューム)」のリストで、「Snapshots (Snapshot)」をクリックします。

3. 「Snapshots (Snapshot)」のリストで、「Configure (構成)」をクリックします。

snap sched コマンド引数の意味次の図で、snap sched コマンド出力例の引数を説明します。

Snapshot スケジュールの結果: このスケジュールは、最新の週ごとの Snapshot コピーを 2 つ、最新の夜間 Snapshot コピーを 6 つ、および毎日午前 8 時、正午、午後 4 時、および午後 8 時に作成される最新の時間ごとの Snapshot コピーを 8

つ保持します。Snapshot スケジュールが特定タイプの新しい Snapshot コピーを作成するたびに、最も古いものが削除され、既存のものが名前変更されます。正時に、システムは hourly.7 を削除して、hourly.0 を hourly.1 に名前変更し、以下同様になります。

図 2. snap sched コマンド出力例の引数


注: 時間ごとの Snapshot コピーの時間を指定する @ 引数を省略すると、Data

ONTAP は 1 時間ごとに Snapshot コピーを作成します。夜間および週ごとのSnapshot コピーは常に深夜 12 時に作成されます。

Snapshot スケジュールを作成するための戦略以下に、Snapshot コピーのスケジュールおよび保存に関する戦略を示します。

v ユーザーがファイルを失うことがほとんどないか、多くの場合はファイルの損失に直ちに気付く場合、デフォルトの Snapshot スケジュールを使用します。このスケジュールは、週ごとの Snapshot コピーを作成せず、毎晩 Snapshot コピーを作成して 2 つを保持し、午前 8 時、正午、午後 4 時、および午後 8 時に時間ごとの Snapshot コピーを作成して 6 つを保持します。デフォルトの Snapshot コピー・コマンドは次のとおりです。snap sched volume_name 0 2 6@8,12,16,20

v ユーザーがよくファイルを失ったり、ファイルの損失に直ちに気付かない場合、デフォルト・スケジュールを使用する場合よりも低い頻度で Snapshot コピーを削除します。

この状況に推奨される Snapshot スケジュールは次のとおりです。2 つの週ごとのSnapshot コピー、6 つの夜間 Snapshot コピー、および 8 つの時間ごとのSnapshot コピーを保持します。snap sched vol1 2 6 8@8,12,16,20

多くのシステムでは 1 週間に 5% または 10% のデータが変更されるため、6 つの夜間および 2 つの週ごとの Snapshot コピーで構成される Snapshot スケジュールはディスク・スペースの 10% から 20% を消費します。Snapshot コピーの利点を考慮すると、このディスク・スペースの量を Snapshot コピー用に予約する価値はあります。

v ストレージ・システム上のさまざまなボリューム用に異なる Snapshot スケジュールを作成することができます。アクティブ性が非常に高いボリュームでは、Snapshot コピーを 1 時間ごとにスケジュールして、それらをわずか数時間にわたって保持し、Snapshot コピーをオフにします。例えば、次のスケジュールでは、Snapshot コピーが 1 時間ごとに作成され、最新の 3 つが保持されます。snap

sched vol2 0 0 3

このスケジュールでは、多くのディスク・スペースが消費されず、ユーザーが数時間以内に間違いに気付けば最新の Snapshot コピーからファイルをリカバリーできます。

v 新しいボリュームを作成する場合、新しいボリュームはルート・ボリュームからSnapshot スケジュールを継承します。しばらくボリュームを使用した後、Snapshot コピーが消費するディスク・スペースの量とユーザーが損失ファイルをリカバリーする必要がある頻度を調べて、必要に応じてスケジュールを調整します。


関連概念

41ページの『Snapshot ディスク消費量とは』Data ONTAP は、Snapshot コピーが作成された時点で現在使用中のディスク・ブロックすべてのポインターを保存します。ファイルが変更されたとき、Snapshot コピーはそのファイルが変更前に格納されていたディスク・ブロックをそのまま指し示し、変更内容は新規ディスク・ブロックに書き込まれます。

Snapshot スケジュールの変更特定のボリュームに対する自動的な Snapshot スケジュールを変更できます。

特定のボリュームに対する自動的な Snapshot スケジュールを変更するには、次のコマンドを入力します。snap sched volume_name weekly nightly hourly@n,n,....

volume_name は、Snapshot コピー用の特定のボリュームの名前です。weekly は、保持する週ごとの Snapshot コピーの数です。nightly は、保持する夜間 Snapshot コピーの数です。hourly は、保持する時間ごとの Snapshot コピーの数です。n,n,... は、時間ごとの Snapshot コピーを作成する時間を指定します。

注: 3 つのスケジュール (weekly、nightly、hourly) をゼロに設定すると、その間隔の Snapshot コピーは使用不可になります。

デフォルトの snap schedule コマンドの結果

これは、デフォルトの自動的な Snapshot スケジュールです。snap sched volx 0 2

6 @8,12,16,20 次の例では、デフォルト・スケジュール (1 月 11 日が日曜日) を使用して作成された Snapshot コピーをリストします。

ls -lu .snapshottotal 64drwxrwsrwx 1 root 4096 Jan 14 12:00 hourly.0drwxrwsrwx 1 root 4096 Jan 14 08:00 hourly.1drwxrwsrwx 1 root 4096 Jan 13 20:00 hourly.2drwxrwsrwx 1 root 4096 Jan 13 16:00 hourly.3drwxrwsrwx 1 root 4096 Jan 13 12:00 hourly.4drwxrwsrwx 1 root 4096 Jan 13 08:00 hourly.5drwxrwsrwx 1 root 4096 Jan 14 00:00 nightly.0drwxrwsrwx 1 root 4096 Jan 13 00:00 nightly.1

注: 日ごとの Snapshot コピーは日曜日を除く毎日の深夜 12 時に作成され、週ごとの Snapshot コピーは日曜日の深夜 12 時に作成されます。一度に 1 つの Snapshot

コピーのみが作成されます。例えば、週ごとの Snapshot コピーが作成中の場合は、日または時間ごとの Snapshot コピーはスケジュールされていても作成されません。

自動 Snapshot コピーを使用不可または使用可能にする自動 Snapshot スケジュールを変更することなく、一時期、自動 Snapshot コピーを使用不可にすることができます。

1. 自動 Snapshot コピーを使用不可にするには、次のコマンドを入力します。vol

options volume_name nosnap on volume_name は、自動 Snapshot コピーを使用不可にするボリュームの名前です。


注: また、Snapshot コピーがスケジュールされないように Snapshot スケジュールを変更することによって、自動 Snapshot コピーを使用不可にすることもできます。これを行うには、次のコマンドを入力します。snap sched volume_name 0

0 0

2. 自動 Snapshot コピーを使用可能にするには、次のコマンドを入力します。vol

options volume_name nosnap off volume_name は、自動 Snapshot コピーを使用可能にするボリュームの名前です。

Snapshot コピーの作成snap sched コマンドにより、Snapshot スケジュールの事前設定された間隔で自動的に Snapshot コピーが作成されます。また、いつでも手動で Snapshot コピーを作成できます。

手動で Snapshot コピーを作成するには、次のコマンドを入力します。snap create

volume_name snapshot_name

volume_name は、Snapshot コピーを作成するボリュームの名前です。snapshot_name は、Snapshot コピーに付ける名前です。

注: snap create コマンドは、スラッシュ (/) を含む Snapshot 名を受け付けません。そのため、Snapshot ファイルの特定のパスを入力することはできません。

FilerView を使用する Snapshot コピーの作成FilerView を使用して手動で Snapshot コピーを作成できます。

1. FilerView で、左側のリストの「Volumes (ボリューム)」をクリックします。

2. 「Volumes (ボリューム)」のリストで、「Snapshots (Snapshot)」をクリックします。

3. 「Snapshots (Snapshot)」のリストで、「Add (追加)」をクリックします。

特定の Snapshot コピーへのアクセスが必要になる理由ファイルが変更、破壊、または消去され、そのファイルの Snapshot コピーが 1 つ以上作成されるまでその問題に気付かなかったために、特定の Snapshot コピー (ファイルの特定時点でのバージョン) にアクセスする必要が生じることがあります。必要なファイルのバージョンを探す際には、まず Snapshot コピーのアクセス時刻を手掛かりにして調べます。

ファイルのバージョンとは、Snapshot コピーが作成される前にファイルが最後に変更された時点を指します。ファイルのアクセス時刻は、ファイルの Snapshot コピーの作成時刻であり、そのファイルに変更が加えられたかどうかは関係ありません。

Snapshot コピーに保存されている特定ファイルのバージョンすべてを見付けるには、NFS クライアントから ls コマンドを使用するか、Windows で「検索」機能を使用する方法が最も便利です。


必要な Snapshot コピーの NFS クライアントからの検索Snapshot コピーで保持されている特定のファイルのすべてのバージョンを検索する最適な方法は、NFS クライアントから ls コマンドを使用することです。

Snapshot コピーの特定のファイルのすべてのバージョンを検索するには、次のコマンドを入力します。ls -l filename .snapshot/*/file_name 要求されたファイルのすべてのバージョンのリストが表示されます。

NFS クライアントの例:ls -l myfile.txt .snapshot/*/myfile.txt

-rw-r--r-- 1 smith 0 Jan 14 09:40 myfile.txt-rw-r--r-- 1 smith 0 Jan 13 18:39 .snapshot/nightly.0/myfile.txt-rw-r--r-- 1 smith 0 Jan 12 19:17 .snapshot/nightly.1/myfile.txt

アクティブ・ファイル・システム内の myfile.txt のバージョンの最終変更日時は1 月 14 日ですが、Snapshot コピーで使用可能な古いバージョンは 1 月 13 日と 1

月 12 日に変更されています。ユーザーは標準的な UNIX コマンドを使用してmyfile.txt の保存されたバージョンを読み取ることはできますが、.snapshot ディレクトリー内のすべてのものは読み取り専用であるため、これらの古いバージョンを変更または削除することができません。

NFS クライアントからアクセス時刻を判別する方法Data ONTAP が Snapshot コピーを作成する際に、Snapshot コピー内の各ファイルのアクセス時刻は、Snapshot コピーの作成時刻に更新されます。

Snapshot コピーが作成された時刻を判別するには、NFS クライアントからコマンドls -lu filename .snapshot/*/file_name を入力します。

例ls -lu myfile.txt .snapshot/*/myfile.txt-rw-r--r-- 1 smith 0 Jan 14 09:40 myfile.txt-rw-r--r-- 1 smith 0 Jan 14 00:00 .snapshot/nightly.0/myfile.txt-rw-r--r-- 1 smith 0 Jan 13 00:00 .snapshot/nightly.1/myfile.txt

注: UNIX クライアント上では、ls -lu の代わりに ls -l を使用して Snapshot コピーの作成時刻をリストすると、必ずしもすべて異なる時刻が表示されない場合があります。 ls -l によってリストされる時刻は、各 Snapshot コピーの時点でのディレクトリーの変更時刻を反映しており、Snapshot コピーが作成された時刻とは関連していません。

必要な Snapshot コピーの CIFS クライアントからの検索Snapshot コピーで保持されている特定のファイルのすべてのバージョンを検索する最適な方法は、Windows の「検索」機能を使用することです。

1. Snapshot コピーの特定のファイルのすべてのバージョンを検索するには、Windows の「スタート」メニューから「検索」を選択して、「ファイルとフォルダ」を選択します。ディレクトリーおよびファイルの名前を求める検索ウィンドウが開きます。


2. 検索ウィンドウで、~snapshot ディレクトリーで検索するファイル名を入力します。

CIFS クライアントの例

ホーム共有をドライブ F: にマップして、Snapshot コピー内の myfile.txt のすべてのバージョンを検索する場合、Windows の「スタート」メニューから「検索」を選択して、f:¥~snapshot フォルダー内の myfile.txt を検索することができます。

CIFS クライアントからアクセス時刻を判別する方法ファイルのプロパティーを調べることによって、CIFS クライアントからファイルのアクセス時刻を判別できます。

Snapshot ディスク消費量とはData ONTAP は、Snapshot コピーが作成された時点で現在使用中のディスク・ブロックすべてのポインターを保存します。ファイルが変更されたとき、Snapshot コピーはそのファイルが変更前に格納されていたディスク・ブロックをそのまま指し示し、変更内容は新規ディスク・ブロックに書き込まれます。

Snapshot コピーによるディスク・スペースの消費Data ONTAP は、Snapshot コピーが作成された時点で現在使用中のディスク・ブロックすべてのポインターを保存します。ファイルが変更されたとき、Snapshot コピーはそのファイルが変更前に格納されていたディスク・ブロックをそのまま指し示し、変更内容は新規ディスク・ブロックに書き込まれます。

ファイル全体ではなく個々のディスク・ブロックを保存することによって、ディスク消費量を最小限にすることができます。アクティブ・ファイル・システム内のファイルが変更または削除された場合に限って、Snapshot コピーは追加スペースを消費し始めます。この場合にも、オリジナルのファイル・ブロックは 1 つ以上のSnapshot コピーの一部として保存されます。ただし、アクティブ・ファイル・システム内では、変更されたブロックはディスク上で別々の場所に再書き込みされるか、アクティブ・ファイル・ブロックとして完全に削除されます。この結果、変更されたアクティブ・ファイル・システム内のブロックが使用するディスク・スペースに加えて、オリジナル・ブロックが使用するディスク・スペースも、変更前のアクティブ・ファイル・システムの状況を反映するために引き続き予約されます。


ファイル内容の変更によるディスク・スペースの消費次の図に、Snapshot コピーがファイルの内容を変更する前後にディスク・スペースをどのように消費するかを示します。

myfile.txt ファイルの内容を変更すると、myfile.txt に書き込まれた新規データを現在の内容と同じディスク・ブロックに格納できない状態になります。これは、Snapshot コピーがこれらのディスク・ブロックを使用して myfile.txt の旧バージョンを保管しているからです。代わりに、新規データは新規ディスク・ブロックに書き込まれます。次の図に示すように、ディスク上には myfile.txt の 2 つのコピーが別々に存在します。アクティブ・ファイル・システム内にある新規コピーと、Snapshot コピー内にある前のコピーです。

図 3. ファイル myfile.txt を削除する前後の Snapshot コピーによるディスク・スペースの消費


Snapshot のディスク消費量のモニターdf コマンドは、ディスク上のフリー・スペースの量を表示します。Snapshot コピーは、アクティブ・ファイル・システムとは異なるパーティションとして扱われます。

Snapshot のディスク消費量に関する情報を表示するには、コマンド df を入力します。

systemA> dfFilesystem kbytes used avail capacity/vol/vol0 3000000 2000000 1000000 65%/vol/vol0/.snapshot 1000000 500000 500000 50%

サンプル出力の説明: この例で、kbytes 列が示している内容は、アクティブ・ファイル・システム用のディスク・スペースとして 3,000,000 KB (3 GB)、Snapshot コピー用の予約済みディスク・スペースとして 1,000,000 KB (1 GB)、合計で4,000,000 KB (4 GB) のディスク・スペースが vol0 ボリュームに含まれていることです。この例では、アクティブ・ディスク・スペースの 66% が使用済みで、33%

が使用可能です。容量の割合が 65% に切り捨てられていることに注意してください。Snapshot コピー用の 1,000,000 KB (1 GB) のディスク・スペースは、ボリューム容量の 25% に相当し、そのうち 500,000 KB (0.5 GB) が使用済み、500,000 KB

(0.5 GB) が使用可能なので、Snapshot コピー用のスペースは 50% の容量です。

注: 50% という数値は、ディスク・スペースの 50% ではなく、Snapshot コピー用に割り当てられたスペースの 50% です。この割り振られたスペースを超過した場合、この数値は 100% を上回ります。

図 4. ディスク上にある myfile.txt の 2 つ別々のコピー


重要な点として、/vol/vol0/.snapshot の行は、Snapshot コピー内にのみ存在するデータのカウントであることに注意してください。Snapshot の計算には、アクティブ・ファイル・システムと共有される Snapshot データは含まれません。

Snapshot のディスク消費量統計の表示snap list コマンドは、指定されたボリュームで Snapshot コピーによって消費されているディスク・スペースの量を表示します。このコマンドにより、それぞれのSnapshot コピーが使用しているディスク・スペースの量を表示でき、適切なSnapshot 予約量を判別する上で役立ちます。また、snap list コマンドは、Snapshot

コピーが現在バックアップに使用されているかどうか、および再開可能なダンプまたは別のバックアップ・アプリケーションで必要かどうかを表示します。

ボリュームの Snapshot 統計を表示するには、次のコマンドを入力します。snap

list volume_name volume_name は、統計を表示するボリュームの名前です。以下に、snap list コマンド出力の例を示します。コマンドでボリューム名を指定しない場合、出力には、システム内の各ボリュームに関する統計が表示されます。

systemA> snap list vol0

Volume vol0%/used %/total date name---------- ---------- ------------ --------0% ( 0%) 0% ( 0%) Jan 19 08:01 hourly.01% ( 1%) 1% ( 1%) Jan 19 00:01 nightly.02% ( 2%) 2% ( 2%) Jan 18 20:01 hourly.13% ( 2%) 2% ( 2%) Jan 18 16:01 hourly.23% ( 2%) 3% ( 2%) Jan 18 12:01 hourly.35% ( 3%) 4% ( 3%) Jan 18 00:01 nightly.17% ( 4%) 6% ( 4%) Jan 17 00:00 nightly.28% ( 4%) 7% ( 4%) Jan 16 00:01 nightly.310%( 5%) 9% ( 4%) Jan 15 00:01 nightly.4

snap list 出力の計算方法snap list 出力は、多くの方法で計算されます。

「%/used」列には、Snapshot コピーによって消費されたスペースが、ボリュームで使用されているディスク・スペースのパーセントとして表示されます。最初の数値はこれまでにリストされたすべての Snapshot コピーの累積であり、2 番目の数値は指定された Snapshot コピーのみの値です。

v 最初の数値は下記のとおりです。

v 2 番目の数値は下記のとおりです。


「%/total」列: 「%/total」列には、Snapshot コピーによって消費されたスペースが、ボリュームの合計ディスク・スペース (使用済みのスペースと使用可能なスペースの両方) のパーセントとして表示されます。

v 最初の数値は下記のとおりです。

累積の Snapshot スペースは、この Snapshot コピーおよびその他すべての最近のSnapshot コピー (snap list 出力でこの Snapshot コピーより前にあるもの) によって使用される合計スペースです。

v 2 番目の数値は下記のとおりです。

snap list コマンド出力の要約: 「%/used」の数値は、ファイル・システムが満杯になるにつれて一定のままである可能性が高いため、Snapshot 予約量を計画する上で役立ちます。

この情報は、5 つの夜間 Snapshot コピーおよび 4 つの時間ごとの Snapshot コピーを保持するボリュームを示しています。

出力例に Snapshot コピーのオーバーヘッドがわずか 10% であることが示されているため、デフォルトの Snapshot 予約量の 20% はディスク・スペースの無駄であると考えられます。この変化のパターンが持続する場合、アクティブ・ファイル・システムが満杯になったときにファイルを削除してディスク・スペースを確実に解放するには、12% から 15% の予約量が安全なマージンです。

個々の Snapshot コピーによって使用されているスペースを示す括弧内の値は、ファイル・システムが満杯になった場合に削除する特定の Snapshot コピーを識別する上で有用です。ただし、特定の Snapshot コピーを削除しても必ずしも示されているディスク・スペースの量が解放されるわけではありません。その他の Snapshot コピーが同じブロックを参照している可能性があるためです。

関連概念

47ページの『Snapshot 予約量とは』Snapshot 予約量は、Snapshot コピー用のディスク・スペースの一定比率を指定します。デフォルトでは、Snapshot 予約量はディスク・スペースの 20% です。

累積の Snapshot 値の使用法すべての Snapshot コピーによって消費されるディスク・スペースの量が、使用済みディスク・スペースの一定の比率を超えないようにしたい場合は、snap list 出力の累積値を使用して、どの Snapshot コピーを削除するか判断します。

使用済みディスク・スペースの 5% を超える量が Snapshot コピーによって消費されないようにしたい場合は、snap list 出力の中で nightly.1 より下にリストされてい


るすべての Snapshot コピー、つまり nightly.2、nightly.3、および nightly.4 を削除します。これらの Snapshot コピーを削除した後、nightly.1 およびその他すべての最近作成された Snapshot コピーが消費する量は、使用済みディスク・スペースの 5%

です。

Snapshot コピーの使用法および依存関係の表示Snapshot コピーがアプリケーションによってアクティブに使用されている場合、snap list コマンドは、Snapshot コピーの名前の後に「busy (使用中)」の表記を示します。

次のコマンドを入力します。snap list vol0

Volume vol0%/used %/total date name-------- ------ ------------ --------0% ( 0%) 0% ( 0%) Jan 19 08:01 hourly.0 (busy)1% ( 1%) 1% ( 1%) Jan 19 00:01 nightly.0(snapmirror)2% ( 2%) 2% ( 2%) Jan 18 20:01 hourly.1 (busy,snapmirror)3% ( 2%) 2% ( 2%) Jan 18 16:01 hourly.23% ( 2%) 3% ( 2%) Jan 18 12:01 hourly.35% ( 3%) 4% ( 3%) Jan 18 00:01 nightly.1 (backup[9])7% ( 4%) 6% ( 4%) Jan 17 00:00 nightly.28% ( 4%) 7% ( 4%) Jan 16 00:01 nightly.310%( 5%) 9% ( 4%) Jan 15 00:01 nightly.4

また、アプリケーションが現時点または後の時点で Snapshot コピーを必要とする場合、snap list コマンドは、Snapshot コピー名の横にアプリケーションの名前を表示します。例えば、Snapshot コピーが、中断されて再開可能な dump コマンド転送の結果である場合、Snapshot コピー名の横に「backup (バックアップ)」が表示されます。「backup (バックアップ)」に続く番号は、backup status コマンドによって割り当てられたバックアップ ID です。 Snapshot コピー名の横の「snapmirror」という表記は、SnapMirror がソースと宛先の関係を維持するために Snapshot コピーを保持していることを意味します。

注: 使用中の Snapshot コピーの所有権情報は、進行中のアクティビティーを停止するかどうか決定する上で役立ちます。例えば、snap list コマンド出力にリソース制約を引き起こすロック済みの Snapshot コピーが表示されている場合、そのSnapshot コピーを削除してスペースを解放することができます。

snap restore ファイル操作の後の snap list のパフォーマンスsnap restore コマンドを使用してファイルを復元した後で snap list コマンドを発行する場合、snap list コマンドが完了するまでに数分かかる可能性があります。

この状態は、通常の Snapshot 保存期間の終わりに達した後でファイルの復元元となった Snapshot コピーがシステムから消去されるまで持続します。


関連タスク


Snapshot 予約量とはSnapshot 予約量は、Snapshot コピー用のディスク・スペースの一定比率を指定します。デフォルトでは、Snapshot 予約量はディスク・スペースの 20% です。

Snapshot 予約量は Snapshot コピーのみが使用でき、アクティブ・ファイル・システムは使用できません。つまり、アクティブ・ファイル・システムがディスク・スペースを使い切った場合に、Snapshot 予約量の中でまだ残っているディスク・スペースをアクティブ・ファイル・システムが使用することはできません。

注: アクティブ・ファイル・システムが、Snapshot コピー用に予約されたディスク・スペースを消費することはできませんが、Snapshot コピーは Snapshot 予約量を超えることができ、アクティブ・ファイル・システムによって通常は使用されるディスク・スペースを消費できます。

Snapshot 予約量管理タスクSnapshot 予約量管理には以下のタスクが関与します。

v Snapshot コピーとして確保される十分なディスク・スペースを確実に用意して、アクティブ・ファイル・システムのスペースが消費されないようにします

v Snapshot コピーによって消費されるディスク・スペースが常に Snapshot 予約量を下回るように維持します

v Snapshot 予約量が大きすぎず、アクティブ・ファイル・システムが使用できたはずのスペースを無駄にしていないことを確認します

削除済みのアクティブ・ファイル・ディスク・スペースの使用Snapshot 予約量に Snapshot コピーで使用可能なディスク・スペースが十分にある場合、アクティブ・ファイル・システムのファイルを削除すると、新しいファイル用にディスク・スペースが解放されますが、それらのファイルを参照する Snapshot

コピーは Snapshot 予約量のわずかなスペースしか消費しません。


ディスクが満杯のときに Data ONTAP が Snapshot コピーを作成した場合、アクティブ・ファイル・システムからファイルを削除しても空きスペースは作成されません。アクティブ・ファイル・システム内のすべての内容が新しく作成されたSnapshot コピーによっても参照されるためです。Data ONTAP は、新しいファイルを作成する前にその Snapshot コピーを削除する必要があります。

例

次の例は、アクティブ・ファイル・システムのファイルを削除することによって解放されたディスク・スペースが最終的に Snapshot コピーでどのようになるかを示しています。


アクティブ・ファイル・システムが満杯のときに Data ONTAP が Snapshot コピーを作成して、Snapshot 予約量にまだスペースが残っている場合、ボリューム上のディスク・スペースの量に関する統計を表示する df コマンドの出力は次のようになります。

Filesystem kbytes used avail capacity/vol/vol0/ 3000000 3000000 0 100%/vol/vol0/.snapshot 1000000 500000 500000 50%

100,000 KB (0.1 GB) のファイルを削除すると、これらのファイルによって使用されていたディスク・スペースはアクティブ・ファイル・システムの一部ではなくなるため、このスペースは代わりに Snapshot コピーに再割り当てされます。

Data ONTAP は、100,000 KB (0.1 GB) のスペースをアクティブ・ファイル・システムから Snapshot 予約量に再割り当てします。 Snapshot コピー用の予約スペースがあったため、アクティブ・ファイル・システムからのファイルの削除によって新しいファイルようにスペースが解放されました。df コマンドを再び入力すると、次のような出力が表示されます。


予約量を超える可能性がある Snapshot コピーSnapshot コピーが予約された量より多いディスク・スペースを消費するのを防止できる方法はありません。そのため、Snapshot コピー用に十分なディスク・スペースを予約して、新しいファイルの作成や既存ファイルの変更のためにアクティブ・ファイル・システムを常に使用できるようにすることが重要です。

例

次の例で、アクティブ・ファイル・システム内のすべてのファイルが削除された場合に何が起こるか検討してください。削除前の df 出力は次のとおりです。


削除の後、df コマンドは次の出力を生成します。


アクティブ・ファイル・システムの 3,000,000 KB (3 GB) の全体は、以前にSnapshot コピーによって使用されていた 500,000 KB (0.5 GB) と共に引き続きSnapshot コピーによって使用され、Snapshot データは合計で 3,500,000 KB (3.5

GB) になります。Snapshot コピー用に予約されていたスペースよりも 2,500,000 KB

(2.5 GB) 多くなります。そのため、アクティブ・ファイル・システムで使用可能であったはずの 2.5 GB のスペースが使用不可になりました。アクティブ・ファイル・システムに保管されているファイルがないにも関わらず、削除後の df コマン


ドの出力には、この使用不可のスペースが「used (使用済み)」としてリストされます。

ファイル・システムで使用するためのディスク・スペースの復元Snapshot コピーが Snapshot 予約量の 100% を超えて消費するときはいつでも、システムが満杯になる危険性があります。この場合、十分な量の Snapshot コピーを削除した後でのみ、ファイルを作成できます。

例

上記の例で 500,000 KB (0.5 GB) のデータがアクティブ・ファイル・システムに追加された場合、df コマンドは次の出力を生成します。

Filesystem kbytes used avail capacity/vol/vol0 3000000 3000000 0 100%/vol/vol0/.snapshot 1000000 3500000 0 350%

Data ONTAP が新しい Snapshot コピーを作成するとすぐに、ファイル・システム内のすべてのディスク・ブロックが一部の Snapshot コピーによって参照されます。そのため、アクティブ・ファイル・システムから削除するファイルの数に関係なく、これ以上追加する余裕はまだありません。この状況から復旧する唯一の方法は、十分な量の Snapshot コピーを削除してさらに多くのディスク・スペースを解放することです。snap list コマンドを使用して削除する Snapshot コピーを判別する方法について詳しくは、『Snapshot のディスク消費量統計の表示』を参照してください。

関連タスク

44ページの『Snapshot のディスク消費量統計の表示』snap list コマンドは、指定されたボリュームで Snapshot コピーによって消費されているディスク・スペースの量を表示します。このコマンドにより、それぞれのSnapshot コピーが使用しているディスク・スペースの量を表示でき、適切なSnapshot 予約量を判別する上で役立ちます。また、snap list コマンドは、Snapshot


Snapshot 予約量の変更Snapshot コピーがディスク・スペースを消費する方法および Snapshot 予約量が機能する方法について理解した後、必要に応じて Snapshot 予約量を変更できます。

始める前に

Snapshot コピーがディスク・スペースを消費する方法および Snapshot 予約量が機能する方法について理解する必要があります。

Snapshot 予約量に使用されるディスク・スペースのパーセントを変更するには、次のコマンドを入力します。snap reserve volume_name percent

volume_name は、ボリュームの名前です。percent は、Snapshot コピー用に予約するディスク・スペースのパーセントです。snap reserve vol0 25


ファイル・フォールディングの意味とディスク・スペースの節約効果ファイル・フォールディングとは、最新の Snapshot コピー内のデータを検査して、そのデータが現在作成中の Snapshot コピーと同一ならば、同じデータを新規Snapshot コピーに書き込んでディスク・スペースを占有する代わりに、前のSnapshot コピーを単に参照する処理のことです。

ファイルのアクティブ・バージョンと、最新の Snapshot コピー (存在する場合) 内にあるファイルのバージョンの間で未変更のファイル・ブロックを共有することによって、ディスク・スペースが節約されます。

ファイル・フォールディングを行う際にシステムはブロックの内容を比較する必要があるので、パフォーマンスとスペース使用効率の間にトレードオフが生じます。

フォールディング処理がメモリー使用量の最大限度に達すると、処理は中断されます。メモリー使用量が限度を下回ると、一時停止していた処理が再開されます。

ファイル・フォールディングを使用可能または使用不可にするお客様の要件に応じて、ファイル・フォールディングを使用可能または使用不可にすることができます。

1. フォールディングをオンにするには、次のコマンドを入力します。options

cifs.snapshot_file_folding.enable on

2. フォールディングをオフにするには、次のコマンドを入力します。options

cifs.snapshot_file_folding.enable off

注: このリリースでは、NFS ユーザーはこのオプションを使用できません。

2 つの Snapshot コピー間におけるデータの変更率の表示ボリューム内の 2 つの連続した Snapshot コピー間の変更率を表示できます。Data

ONTAP は、ボリューム内の連続した Snapshot コピー間の変更率を表示します。

ボリュームのデータ変更率を表示するには、次のコマンドを入力します。snap

delta vol_name

vol_name は、Snapshot コピーが入ったボリュームの名前です。

注: ボリューム名を省略することによって、すべてのボリュームの変更率を表示できます。次の表に、連続した Snapshot コピー間の変更率を表示します。


system> snap delta vol0Volume vol0 working...From Snapshot To KB changed Time Rate (KB/hour)------------- ------------------ ---------- ---------- --------------hourly.0 Active File System 149812 0d 03:43 40223.985hourly.1 hourly.0 326232 0d 08:00 40779.000hourly.2 hourly.1 2336 1d 12:00 64.888hourly.3 hourly.2 1536 0d 04:00 384.000hourly.4 hourly.3 1420 0d 04:00 355.000nightly.0 hourly.4 1568 0d 12:00 130.666hourly.5 nightly.0 1400 0d 04:00 350.000nightly.1 hourly.5 10800 201d 21:00 2.229Summary...From Snapshot To KB changed Time Rate (KB/hour)------------- ------------------ ---------- ---------- --------------nightly.1 Active File System 495104 204d 20:43 100.697

Snapshot コピーとアクティブ・ファイル・システムの間のデータ変更率の表示

最も古い Snapshot コピーとアクティブ・ファイル・システムの間の変更率の要約を表示できます。詳しくは、na_snap(1) マニュアル・ページを参照してください。

2 つの Snapshot コピー間のデータ変更率を表示するには、次のコマンドを入力します。snap delta vol_name snap1 snap2

vol_name は、Snapshot コピーが入ったボリュームの名前です。snap1 および snap2 は、2 つのSnapshot コピーの名前です。

例

次の表に、最も古い Snapshot コピーとアクティブ・ファイル・システムの間の変更率の要約を示します。

次のコマンドは、ボリューム vol0 の nightly.0 と hourly.1 の間の変更率をリストします。

system> snap delta vol0 nightly.0 hourly.1

Volume vol0 working...From Snapshot To KB changed Time Rate (KB/hour)------------- ---------- ---------- ---------- --------------hourly.2 hourly.1 2336 1d 12:00 64.888hourly.3 hourly.2 1536 0d 04:00 384.000hourly.4 hourly.3 1420 0d 04:00 355.000nightly.0 hourly.4 1568 0d 12:00 130.666Summary...From Snapshot To KB changed Time Rate (KB/hour)------------- ---------- ---------- ---------- --------------nightly.0 hourly.1 6860 2d 08:00 122.500

自動的な Snapshot コピーの削除Snapshot コピーを自動的に削除するポリシーを定義して使用可能にすることができます。

次のコマンドを入力します。snap autodelete vol_name option value

削除する Snapshot コピーを定義するには、snap autodelete コマンドで以下のオプションおよび対応する値を使用します。


オプション値

commitment Snapshot コピーがデータ保護ユーティリティー (SnapMirror またはNDMPcopy) あるいはデータ・バッキング・メカニズム (ボリュームまたは LUN クローン) にリンクされているかどうかを指定します。

v try ― データ保護ユーティリティーおよびデータ・バッキング・メカニズムにリンクされていない Snapshot コピーのみを削除します。

v disrupt ― データ・バッキング・メカニズムにリンクされていない Snapshot コピーのみを削除します。

v destroy ― データ・バッキングおよびデータ保護メカニズムのためにロックされた Snapshot コピーのみを破棄します。

このオプションは、snapshot-clone-dependency 値が on に設定されているボリュームに対して設定できます。snapshot-clone-dependency オプションが off に設定されているボリュームに対してこのオプションを設定すると、エラー・メッセージが返されます。

trigger 自動的な Snapshot コピーの削除を開始する時期を定義します。

v volume ― ボリュームが容量しきい値パーセントに達し、ボリュームの snap reserve のスペースを超過した場合に、Snapshot コピーの削除を開始します。

v snap_reserve ― Snapshot 予約量が容量しきい値パーセントに達した場合に Snapshot コピーの削除を開始します。

v space_reserve ― ボリュームで予約されているスペースが容量しきい値パーセントに達し、ボリュームの snap reserve のスペースを超過した場合に、Snapshot コピーの削除を開始します。

Data ONTAP 7.3.1 以降、容量しきい値パーセントは次のようにボリューム・サイズに基づいています。

v 0 バイトから 20 GB のサイズのボリュームは 85% の容量で起動します。

v 20 GB から 100 GB のサイズのボリュームは 90% の容量で起動します。

v 100 GB から 500 GB のサイズのボリュームは 92% の容量で起動します。

v 500 GB から 1 TB のサイズのボリュームは 95% の容量で起動します。

v 1 TB 以上のサイズのボリュームは 98% の容量で起動します。

target_free_space Snapshot コピーの削除を停止する時期を決定します。パーセントを指定してください。例えば、30 を指定すると、ボリュームの 30 パーセントが解放されるまで Snapshot コピーは削除されます。

delete_order v newest_first ― 最初に一番最近の Snapshot コピーを削除します。

v oldest_first ― 最初に最も古い Snapshot コピーを削除します。


オプション値

defer_delete 以下のいずれかのタイプの Snapshot コピーを最後に削除します。

v user_created ― 自動スケジュールされていない Snapshot コピー

v prefix ― 指定された prefix_string を持つ Snapshot コピー

prefix 特定の接頭部を持つ Snapshot コピーを最後に削除します。最大 15

文字を指定できます (例えば、sv_snap_week)。このオプションは、defer_delete オプションで接頭部を指定する場合にのみ使用してください。

destroy_list 以下のいずれかのタイプの Snapshot コピーを破棄します。以下の値を指定できます。

v lun_clone ― LUN クローンのためにロックされた Snapshot コピーの破棄を許可します。

v vol_clone ― ボリューム・クローンのためにロックされたSnapshot コピーの破棄を許可します。

v cifs_share ― Snapshot コピーが CIFS 共有のためにロックされていても Snapshot コピーの破棄を許可します。

v none ― デフォルトのオプションです。ロックされた Snapshot

コピーは破棄されません。

オプションを指定しない自動的な Snapshot コピーの削除オプションを指定しない場合に Snapshot コピーを自動的に削除するポリシーを定義して使用可能にすることができます。

次のコマンドを入力します。snap autodelete vol_name on on により、Snapshot コピーの autodelete ポリシーが使用可能になります。

注: オプションを使用する場合は on を指定しないでください。snap autodelete vol0 on

関連タスク

54ページの『デフォルトの Snapshot コピーの autodelete 設定の復元』デフォルトの Snapshot コピーの autodelete 設定を復元できます。

現在の Snapshot コピーの autodelete 設定の表示現在の autodelete 設定を表示できます。

現在の autodelete 設定を表示するには、次のコマンドを入力します。snap

autodelete vol-name show

ボリュームの Snapshot コピーの autodelete 設定が次のように表示されます。

v state

v commitment

v trigger

v target_free_space

v delete_order

v defer_delete

v prefix


v destroy_list

デフォルトの Snapshot コピーの autodelete 設定の復元デフォルトの Snapshot コピーの autodelete 設定を復元できます。

デフォルトの Snapshot コピーの autodelete 設定を復元するには、次のコマンドを入力します。snap autodelete vol-name reset vol-name は、ボリュームの名前です。Snapshot コピーの autodelete 設定が以下のデフォルトに戻されます。

v state ― off

v commitment ― try

v trigger ― volume

v target_free_space ― 20%

v delete_order ― oldest_first

v defer_delete ― user_created

v prefix ― 接頭部は指定されません

v delete_list ― none

Snapshot コピーの autodelete ポリシーを使用不可にするautodelete ポリシーを使用不可にすることができます。

Snapshot コピーの autodelete ポリシーを使用不可にするには、次のコマンドを入力します。snap autodelete vol-name off vol-name は、ボリュームの名前です。ボリュームがほぼ満杯のときに Snapshot コピーは自動的に削除されません。

削除された Snapshot コピーから再利用されたスペースの表示ボリューム内の 1 つ以上の Snapshot コピーを削除することによって再利用できるスペースの量を表示できます。ボリュームへの書き込み、Snapshot コピーの作成、または Snapshot コピーの削除によって、再利用される量が変化するため、表示されるスペースの量は概算です。

Snapshot コピーを削除することによって再利用できるスペースの量を表示するには、次のコマンドを入力します。snap reclaimable vol_name snap1 [snap2 ...]

vol_name は、削除する可能性がある Snapshot コピーが入ったボリュームです。snap1 [snap2 ...] は、削除する可能性がある Snapshot コピーの名前です。名前はスペースで区切ります。

注: Data ONTAP が解放されたスペースの量を表示するまで、少し時間がかかる場合があります。Ctrl-C を押してコマンドを中断することができます。

例

次のコマンドは、ボリューム vol1 の hourly.4、hourly.5、および nightly.0 のSnapshot コピーを削除することによって再利用されるスペースの量を表示します。


system> snap reclaimable vol1 hourly.4 hourly.5 nightly.0

Processing (Press Ctrl-C to exit) ...snap reclaimable: Approximately 240 kbytes would be freed.

削除する Snapshot コピーをサイズに基づいて判別する方法ディスク・スペースを最大限に空けるためにどの Snapshot コピーを削除すればよいか判別するには、まず Snapshot コピーをリストする必要があります。

snap list コマンドの出力を使用して、ディスク・スペースを最大限に空けるためにはどの Snapshot コピーを削除すればよいか判別できます。

『Snapshot のディスク消費量統計の表示』に示した snap list コマンドのサンプル出力では、Snapshot コピーによって使用される累積のディスク・スペースは、上から下に進むにつれて徐々に増加しています。

例えば、「%/used」列では、hourly.1 によって使用される累積のスペースは 2%

で、hourly.2 によって使用される累積のスペースは 3% です。常にこのようになるとは限りません。

大きな Snapshot ファイルを削除してスペースを節約しようとする前に、snap list 出力にある累積値を検討してください。 2 つの隣接する Snapshot ファイルの累積値にあまり差がない場合、これらの Snapshot コピーが参照するデータのほとんどは同じです。この場合、これらの Snapshot コピーのどちらかのみを削除しても、あまり多くのディスク・スペースを空けることはできません。

多くの場合、デフォルトの Snapshot スケジュールとデフォルトの Snapshot 予約量を使用できます。これらの設定はほとんどの環境に適しています。新規ボリュームを作成する際に、その新規ボリュームはルート・ボリュームから Snapshot スケジュールを継承します。ボリュームを数日間使用した後、Snapshot コピーがボリューム内で消費しているディスク・スペースの量を確認してください。量が多いようなら、Snapshot コピーが保存される時間を短くするか、Snapshot 予約量を増やします。

Snapshot コピーを使用する際に、時間の経過に伴う統計の変化を継続的に監視してください。これらの統計により、Snapshot コピーがディスク・スペースをどのように使用しているかを正しく把握できます。

重要: 一般的な規則としては、snap sched コマンドが生成したものではないSnapshot コピーは削除しないようにします (例えば、SnapMirror または SnapVault

のコマンドによって生成された Snapshot コピー)。これらの Snapshot コピーを削除すると、SnapMirror または SnapVault の処理が停止する可能性があります。例外として、現在は維持する必要がない SnapMirror 関係によって残された Snapshot コピーは削除して構いません。


関連タスク

44ページの『Snapshot のディスク消費量統計の表示』snap list コマンドは、指定されたボリュームで Snapshot コピーによって消費されているディスク・スペースの量を表示します。このコマンドにより、それぞれのSnapshot コピーが使用しているディスク・スペースの量を表示でき、適切なSnapshot 予約量を判別する上で役立ちます。また、snap list コマンドは、Snapshot


手動による Snapshot コピーの削除特定の状況で、ディスク・スペースを増やすために、または手動 Snapshot コピーが不要になっても自動的に削除されないために、事前に設定された間隔の前にSnapshot コピーを削除する場合があります。

Snapshot コピーを特定のボリュームから手動で削除するには、次のコマンドを入力します。snap delete volume_name snapshot_name

volume_name は、削除する Snapshot コピーが入ったボリュームの名前です。snapshot_name は、削除する特定の Snapshot コピーです。

注: ボリューム上のすべての Snapshot コピーを削除するには、次のように -a パラメーターを使用します。snap delete -a volume_name

Snapshot コピーが使用中またはロックされている場合の手動による Snapshot コピーの削除

snap delete コマンドは、使用中の Snapshot コピーの所有権情報を表示します。

この情報は、特定の Snapshot コピーが使用中である理由や、進行中のアクティビティーを停止するかどうかを判別する上で役立ちます。例えば、snap delete コマンド出力にリソース制約を引き起こすロック済みの Snapshot コピーが表示される場合、その Snapshot コピーを削除してスペースを解放することができます。

Snapshot コピーがロック済みの場合、snapmirror release または snapvault release コマンドを使用して Snapshot コピーをアンロックするまで、snap delete 操作は失敗します。Snapshot コピーがロック済みであるのは、SnapMirror または SnapVault が次回の更新のためにこれらのコピーを維持しているためです。ロック済みのSnapshot コピーを削除すると、SnapMirror または SnapVault は、ユーザーによってセットアップされたスケジュールで指定されているようにファイルまたはボリュームを複製できなくなります。

ロック済みの SnapMirror Snapshot コピーの削除方法

次の例は、SnapMirror が更新のために必要としていたことが原因でロックされていた SnapMirror Snapshot コピーを削除する方法を示しています。


systemA> snap delete vol0 oldsnapCan't delete oldsnap: snapshot is in use by snapmirror.Use 'snapmirror destinations -s' to find out why.systemA> snapmirror destinations -s vol0Path Destination/vol/vol0 systemB:vol0systemA> snapmirror release vol0 systemB:vol0systemA> snap delete vol0 oldsnap

ロック済みの SnapVault Snapshot コピーの削除方法

次の例は、SnapVault が更新のために必要としていたことが原因でロックされていたSnapVault Snapshot コピーを削除する方法を示しています。

systemA> snap delete vol0 oldsnap Can't delete oldsnap: snapshot is in use by snapvault.Use 'snapvault status -l' to find out why.systemA> snapvault status -lSnapVault client is ON.Source: systemA:/vol/vol0/qt3Destination systemB:/vol/sv_vol/qt3...systemA> snapvault release /vol/vol0/qt3systemB:/vol/sv_vol/qt3systemA> snap delete vol0 oldsnap

関連タスク

239ページの『SnapVault 関係の解放』1 次 qtree とその 2 次 qtree バックアップ (最初に snapvault start コマンドで定義された) の間の SnapVault 関係が両方向で不要になった後、この関係を解放することができます。

165ページの『SnapMirror 関係からのパートナーの解放』ボリュームまたは qtree のソースと宛先ペアの間の SnapMirror 関係を永続的に終了するには、ソースと宛先のストレージ・システムで異なるコマンドを使用する必要があります。

Snapshot コピーの名前変更snap sched コマンドによって生成された Snapshot コピーに保存するデータが入っている場合、名前変更できます (snap sched コマンドは、定期的にスケジュールされた Snapshot コピーを上書きして削除します)。snap rename コマンドを使用して、希望のデータが入った Snapshot コピーを保存することができます。

Snapshot コピーを名前変更するには、次のコマンドを入力します。snap rename

volume_name from_name to_name

volume_name は、名前変更する Snapshot コピーが入ったボリュームの名前です。from_name は、名前変更する Snapshot コピーの現在の名前です。to_name は、Snapshot コピーに付ける新しい名前です。

注: 名前変更した Snapshot コピーを保持するには、Snapshot コピーの名前が標準的な接頭部 (weekly、nightly、hourly、または min) で始まらないように名前変更する必要があります。そうでないと、Data ONTAP は、それ以降も名前変更されたSnapshot コピーを削除します。snap rename vol0 hourly.2 MyDataSave


SnapRestore を使用したデータ・リカバリー

SnapRestore について使用可能でなくなったデータをリカバリーしたり、ボリュームまたはファイルをテストしてそのボリュームまたはファイルをテスト前の状態に復元する場合、Data

ONTAP SnapRestore 機能を使用します。

注: SnapRestore は、ライセンス・フィーチャーです。使用する前に、ライセンス・コードを購入してインストールする必要があります。

SnapRestore の機能SnapRestore を使用すれば、ストレージ・システム上のローカルのボリュームまたはファイルを、特定の Snapshot コピーが作成された時点の状態に迅速に戻すことができます。ほとんどの場合、ファイルまたはボリュームの復帰は、テープからのファイルのリストアや、Snapshot コピーからアクティブ・ファイル・システムへのファイルのコピーよりもはるかに高速です。

SnapRestore の動作: 元に戻す Snapshot コピーを選択した後、ストレージ・システムは、指定したファイルまたはボリュームを、選択した Snapshot コピーが作成された時点の内容であったデータとタイム・スタンプに戻します。選択した Snapshot コピーが作成された後に書き込まれたデータは失われます。

注: 元に戻す対象として選択したボリュームがルート・ボリュームである場合、ストレージ・システムはリブートします。

SnapRestore によって復帰するもの: SnapRestore は、ファイル内容のみを復帰します。ボリュームの属性は復帰しません。例えば、Snapshot スケジュール、ボリューム・オプション設定、RAID グループ・サイズ、およびボリュームあたりのファイルの最大数は、復帰後も変更されないままです。

SnapRestore の使用に適した状況: SnapRestore は、データ破壊からのリカバリーのために使用します。1 次側のストレージ・システム・アプリケーションがボリューム内のデータ・ファイルを破壊した場合は、そのボリューム、またはボリューム内の指定ファイルを、データ破壊の起こる前に作成された Snapshot コピーに戻すことができます。

Snapshot コピーからのコピー操作の代わりに SnapRestore を使用する利点:: 管理者が、リストアするボリューム、qtree、ディレクトリー、または大容量ファイルをSnapshot システムからアクティブ・ファイル・システムに手動でコピーするよりも、SnapRestore を使用した方が Snapshot リストアが迅速に実行され、使用するディスク・スペースは少なくなります。 SnapRestore フィーチャーを使用すれば、大容量ボリュームのディレクトリーのリストアを数秒で実行できます。

スペースに制約があるために Snapshot コピーからのコピー操作によるリストアができない場合であっても、SnapRestore は大容量のボリュームまたはファイルをリストアできます。


SnapRestore の使用に適した状況SnapRestore は、データ破壊からのリカバリーのために使用します。1 次側のストレージ・システム・アプリケーションがボリューム内のデータ・ファイルを破壊した場合は、そのボリューム、またはボリューム内の指定ファイルを、データ破壊の起こる前に作成された Snapshot コピーに戻すことができます。

ファイルまたはボリュームを復帰するために SnapRestore を使用するかどうか決定する際には、いくつかの考慮事項、前提条件、および一般的な注意事項を考慮する必要があります。

関連タスク


62ページの『選択された Snapshot コピーへのボリュームの復帰』特定の状況では、SnapRestoreを使用して、選択した Snapshot コピーにボリュームを復帰する必要があります。

67ページの『復帰後の正確な増分バックアップの取得』復帰したボリューム内のすべてのファイルには、Snapshot コピーの作成時と同じタイム・スタンプが付いています。復帰操作の後、ファイルまたはボリュームでの増分バックアップおよびリストア操作では、タイム・スタンプを使用してバックアップまたはリストアが必要なデータを判別することはできません。

SnapRestore を使用する前の考慮事項ファイルまたはボリュームを復帰するために SnapRestore を使用するかどうか決定する際には、いくつかのことを考慮する必要があります。

v リストアする必要があるボリュームがルート・ボリュームである場合は、Snapshot

コピーからファイルをコピーするか、テープからファイルをリストアする方が、リブートをしなくて済むので SnapRestore を使用するより簡単です。ルート・ボリューム上の破損したファイルをリストアする必要がある場合は、リブートは不要です。

v ルート・ボリューム全体を復帰する場合は、Snapshot コピーが作成された時点で有効であった構成ファイルを使用して、システムがリブートします。

v リカバリーするデータが大量にある場合は、SnapRestore が推奨される方式です。これは、大量のデータを Snapshot コピーからコピーしたり、テープからリストアしたりするには長い時間がかかるからです。

v リカバリーするファイルが必要とするスペースが、アクティブ・ファイル・システム内のフリー・スペースの量を上回る場合は、Snapshot コピーからアクティブ・ファイル・システムへのコピーによってファイルをリストアすることはできません。例えば、10 GB のファイルが破損している場合に、アクティブ・ファイル・システムに存在するフリー・スペースが 5 GB のみならば、Snapshot コピーからファイルをコピーしてファイルをリカバリーすることはできません。一方、こうした条件では SnapRestore を使用すればファイルを迅速にリカバリーできます。アクティブ・ファイル・システム内で使用可能なスペースを増やす手間は必要ありません。


重要: SnapRestore を使用すれば、前のリリースの Data ONTAPで作成されたSnapshot コピーへの復帰が可能です。ただし、このようにするとバージョンの互換性がなくなる可能性があり、システムが完全にブートせず、問題が生じるおそれがあります。

SnapRestore を使用するための前提条件SnapRestore を使用する前に、いくつかの前提条件を満たしている必要があります。

v ストレージ・システム上で SnapRestore のライセンスを有効にする必要があります。

v 復帰対象として選択するシステムには、少なくとも 1 つの Snapshot コピーが存在している必要があります。

v 復帰するボリュームがオンラインになっている必要があります。

v 復帰するボリュームは、データ複製に使用されていてはなりません。

SnapRestore の使用に関する一般的な注意事項SnapRestore を使用する前に、次のことを理解しておいてください。

v SnapRestore は、ファイルまたはボリューム内のすべてのデータを上書きします。SnapRestore を使用して選択した Snapshot コピーへの復帰を行った後、その復帰を取り消すことはできません。

v SnapMirror Snapshot コピーより前に作成された Snapshot コピーに復帰した場合、 Data ONTAP は snapmirror update コマンドを使用したデータのインクリメンタル更新を実行できなくなります。

ただし、SnapMirror ソースと SnapMirror 宛先の間に共通の Snapshot コピー(SnapMirror Snapshot コピーまたはその他の Snapshot コピー) が存在する場合は、snapmirror resync コマンドを使用して SnapMirror 関係を再同期する必要があります。

SnapMirror ソースと SnapMirror 宛先の間に共通の Snapshot コピーが存在しない場合は、SnapMirror 関係を再初期化する必要があります。

v Snapshot コピーの削除を復元することはできません。 Snapshot コピーを削除した場合、SnapRestore を使用して Snapshot コピーをリカバリーすることはできません。

v 選択した Snapshot コピーにボリュームを復帰した後、選択した Snapshot コピーより後に作成された Snapshot コピーはすべて失われます。

v snap restore コマンドを入力した時点から復帰が完了する時点までの間、Data

ONTAP は Snapshot コピーの削除と作成を停止します。

v Snapshot コピーからファイルを復帰する場合は、復帰元の Snapshot コピー以外の Snapshot コピーを削除できます。

v SnapRestore フィーチャーを使用して、ベース Snapshot コピーから FlexClone をリストアする場合は、FlexClone とその親との間のスペース最適化関係は失われます。詳しくは、「Data ONTAP ストレージ管理ガイド」を参照してください。

SnapRestore を使用したデータ・リカバリー 61

ルート・ボリュームの復帰に関する注意事項ルート・ボリュームの /etc ディレクトリーにはシステムに関する構成情報が含まれているので、ルート・ボリュームを復帰すると構成が変更される可能性があります。

また、ルート・ボリュームをリストアすると、システム全体のオプション設定が、Snapshot コピーの作成時点で有効になっていた設定にリストアされます。ルート・ボリュームを復帰するには、システムのリブートが必要です。

構成ファイルの保持データを保持するには、すべての構成ファイル・データをルート・ボリューム以外のボリュームに保管する必要があります。

復帰する必要があるすべてのデータをルート・ボリューム以外のボリュームに保管します。こうすると、ルート・ボリュームを復帰する必要が確実になくなります。

SnapRestore を使用する前のルート・ボリュームの復帰復帰するデータがルート・ボリュームにある場合、SnapRestoreを使用する前に /etc

ディレクトリーを別のボリュームまたは別のストレージ・システムにバックアップします。ルート・ボリュームを復帰した後、/etc ディレクトリーを復元してリブートします。

/etc ディレクトリーを別のボリュームにバックアップした場合、次のコマンドを使用して、そのボリュームをルート・ボリュームにしてシステムをリブートすることができます。vol options volume root この方法では、復帰中にシステムがリブートするときに /etc ディレクトリーの正しい設定を使用できます。

SnapRestore ライセンスのインストールSnapRestore はライセンス・フィーチャーであるため、このフィーチャーを使用する前にライセンス・コードを購入し、インストールする必要があります。

サーバー上で、コマンド license add xxxxxxx を入力します。xxxxxxx は、購入したライセンス・コードです。この設定は、再起動しても持続します。

選択された Snapshot コピーへのボリュームの復帰特定の状況では、SnapRestoreを使用して、選択した Snapshot コピーにボリュームを復帰する必要があります。

1. ネットワーク・ユーザーに、ボリュームを復帰するため、ボリューム内の現在のデータが選択された Snapshot コピー内のデータに置き換えられることを通知します。

注: NFS ユーザーは、復帰前にボリューム内のファイルおよびディレクトリーをアンマウントする必要があります。ファイルおよびディレクトリーをアンマウントしない場合、ボリュームの復帰の前に「stale file handle (失効ファイル・ハンドル)」エラー・メッセージを受け取る可能性があります。


2.

状況処置

復帰する各ボリュームの Snapshot コピーの名前が分かっている

ステップ 6 に進みます。

復帰に選択可能な Snapshot コピーのリストから Snapshot コピーを選択する


3. 次のコマンドを入力します。snap restore -t vol volume_name

-t vol は、復帰するボリューム名を指定します。

volume_name は、復帰するボリュームの名前です。完全なパスではなく、名前のみを入力してください。ボリューム名は 1 つしか入力できません。

-f オプションは、ボリュームの復帰に関するユーザーの決定を確認する警告メッセージおよびプロンプトを回避するために使用します。詳しくは、na_snap(1) マニュアル・ページを参照してください。

4. y を押して、ボリュームの復帰を確認します。 Data ONTAP は、Snapshot コピーのリストを表示します。

5. ボリュームを復帰するための Snapshot コピーの名前を入力してから、ステップ8 に進みます。 Data ONTAP は、復帰するボリュームの名前および復帰に使用する Snapshot コピーの名前を表示します。

6. 次のコマンドを入力します。snap restore -t vol -s snapshot_name

volume_name

-t vol は、復帰するボリューム名を指定します。

-s snapshot_name は、データを復帰する元の Snapshot コピーの名前を指定します。Snapshot コピー名は 1 つしか入力できません。

volume_name は、復帰するボリュームの名前です。完全なパスではなく、名前のみを入力してください。ボリューム名は 1 つしか入力できません。

7. y を押して、ボリュームの復帰を確認します。

Data ONTAP は、ボリュームの名前および復帰に使用する Snapshot コピーの名前を表示して、-f オプションが使用されていない場合は復帰を続行するかどうかの決定を求めるプロンプトを表示します。

注: ボリュームの復帰を取り消すには、ステップ 8 で y を入力する前にいつでも Ctrl-C を押してください。

8.

状況処置

復帰を続行する y を押します。

結果: システムは、選択された Snapshot コピーからボリュームを復帰します。ルート・ボリュームに復帰する場合、システムはリブートします。


状況処置

復帰を続行しない n または Ctrl-C を押します。

結果: ボリュームは復帰せず、プロンプトに戻されます。

例system> snap restore -t vol -s nightly.0 /vol/vol1system> WARNING! This will restore a volume from a snapshot into the active file system.If the volume already exists in the active file system, it will be overwritten withthe contents from the snapshot.Are you sure you want to do this? yYou have selected file /vol/vol1, snapshot nightly.0Proceed with restore? y

結果: Data ONTAP は、/vol/vol1 にある vol1 というボリュームを復元します。

SnapRestore によってボリュームが復帰した後、ユーザーが表示できるアクティブ・ファイル・システム内のそのボリュームに関するすべての情報 (データおよび属性)

は、Snapshot コピーに含まれている情報と等しくなります。

選択された Snapshot コピーへのファイルの復帰snap restore を使用して単一ファイルを選択した Snapshot コピーに復帰することは、ファイルが非常に大容量で、以前のファイル・バージョンを Snapshot コピーからアクティブ・ファイル・システムにコピーできない場合に実用的な方法です。


snap restore によるファイル復帰について、いくつかの注意事項があります。

v NT ストリームを使用するファイルまたはディレクトリー上の単一ファイルの復帰には SnapRestoreを使用できません。

v snap restore コマンドを使用して単一ファイルを復帰した後で snap list コマンドを発行する場合、snap list コマンドが完了するまでに数分かかる可能性があります。 snap list -n コマンドを使用することによって、完了に必要な時間を最小限に抑えることができます。詳しくは、マニュアル・ページ (man ページ) を参照してください。

(ボリュームではなく) 単一ファイルを復帰するには、次のステップを実行します。

注: ファイルの復帰を取り消すには、ステップ 8 で y を押す前にいつでも Ctrl-C

を押してください。

1. ネットワーク・ユーザーに、ファイルを復帰するため、ファイル内の現在のデータが選択された Snapshot コピー内のデータに置き換えられることを通知します。

注: NFS ユーザーが復帰されたファイルを最初に再オープンせずにファイルにアクセスしようとすると、ボリュームの復帰後に「stale file handle (失効ファイル・ハンドル)」エラー・メッセージを受け取る可能性があります。


2.

状況処置

復帰するファイルを復帰するためのSnapshot コピーの名前が分っている




3. 次のコマンドを入力します。snap restore -t file -r restore_as_new_path

path_and_file_name

-t file は、復帰するファイルの名前を入力することを指定します。

-r restore_as_new_path は、ファイルを Snapshot コピーの場所とは異なる場所(ただし、同じボリューム内) に復元します。例えば、-r への引数として/vol/vol0/vol3/myfile を指定する場合、SnapRestore は、path_and_file_name で示される vol3 のパスではなく、/vol/vol0/vol3 の場所に myfile というファイルを復帰します。

path_and_file_name は、復帰するファイルの名前への完全パスです。1 つのパス名のみを入力できます。

ファイルは、最初に置かれていたボリュームにのみ復元できます。ファイルが復元されるディレクトリー構造は、パスで指定されたのと同じでなければなりません。このディレクトリー構造が存在しなくなっている場合は、ファイルを復元する前に再作成する必要があります。

注: -f オプションは、ボリュームの復帰に関するユーザーの決定を確認する警告メッセージおよびプロンプトを回避するために使用します。詳しくは、na_snap(1) マニュアル・ページを参照してください。結果: Data ONTAP は、警告メッセージを表示して、ファイルの復帰に関するユーザーの決定を確認するプロンプトを表示します。

注: NFS ユーザーが復帰されたファイルを最初に再オープンせずにファイルにアクセスしようとすると、ボリュームの復帰後に「stale file handle (失効ファイル・ハンドル)」エラー・メッセージを受け取る可能性があります。

4. y を押して、ファイルの復帰を確認します。結果: Data ONTAP は、Snapshot

コピーのリストを表示します。

5. ファイルを復帰するための Snapshot コピーの名前を入力してから、ステップ 8

に進みます。

結果: Data ONTAP は、復帰するファイルの名前および復帰に使用する Snapshot

コピーの名前を表示します。

6. 次のコマンドを入力します。snap restore -t file -s snapshot_name -r

restore_as_path path_and_file_name

-t file は、復帰するファイルの名前を入力することを指定します。

-s snapshot_name は、データを復帰する元の Snapshot コピーの名前を指定します。


-r restore_as_path は、ファイルを Snapshot コピーの場所とは異なる場所に復元します。例えば、-r への引数として /vol/vol0/vol3/myfile を指定する場合、SnapRestore は、path_and_file_name のパスで示されるファイル構造ではなく、/vol/vol0/vol3 の場所に myfile というファイルを復帰します。

path_and_file_name は、復帰するファイルの名前への完全パスです。1 つのパス名のみを入力できます。

ファイルは、最初に置かれていたボリュームにのみ復元できます。ファイルが復元されるディレクトリー構造は、パスで指定されたのと同じでなければなりません。このディレクトリー構造が存在しなくなっている場合は、ファイルを復元する前に再作成する必要があります。

-r およびパス名を入力しない場合、path_and_file_name の最後にあるファイルのみが復帰されます。1 つのパス名のみを入力できます。

結果: -f オプションを使用しない場合、Data ONTAP は、警告メッセージを表示して、ファイルの復帰に関するユーザーの決定を確認するプロンプトを表示します。

7. y を押して、ファイルの復帰を確認します。結果: Data ONTAP は、ファイルの名前および復帰に使用する Snapshot コピーの名前を表示して、-f オプションを使用していない場合は復帰を続行するかどうかの決定を求めるプロンプトを表示します。

8.

状況処置

復帰を続行する y を押します。

結果: ストレージ・システムは、選択されたSnapshot コピーからファイルを復帰します。


n または Ctrl-C を押します。

結果: ファイルは復帰せず、プロンプトに戻されます。

例system> snap restore -t file /vol/vol1/users/jim/myfile -s nightly.0system> WARNING! This will restore a file from a snapshot into the active file system.If the file already exists in the active file system, it will be overwritten with thecontents from the snapshot. Are you sure you want to do this? yYou have selected file /vol/vol1/users/jim/myfile, snapshot nightly.0Proceed with restore? y

結果: Data ONTAP は、myfile というファイルを既存のボリュームおよびディレクトリー構造の /vol/vol1/users/jim に復元します。

例


system>snap restore -t file -s nightly.0 -r /vol/vol2/archive/eng/myfile /vol/vol2/users/jim/myfile

system>WARNING! This will restore a file from a snapshot into the active file system.If the file already exists in the active file system, it will be overwritten with thecontents from the snapshot.Are you sure you want to do this? yYou have selected file /vol/vol1/users/jim/myfile, snapshot nightly.0Proceed with restore? y

結果: Data ONTAP は、myfile というファイルを新しい場所の/vol/vol2/archive/eng に復元します。

SnapRestore によってファイルが復帰した後、ユーザーが表示できるアクティブ・ファイル・システム内のそのファイルに関するすべての情報 (データおよびファイル属性) は、Snapshot コピーに含まれている情報と等しくなります。

SnapRestore によってファイルが復帰した後、ユーザーが表示できるアクティブ・ファイル・システム内のそのファイルに関するすべての情報 (データおよびファイル属性) が Snapshot コピーに含まれている情報と等しいかどうか確認してください。

復帰後の正確な増分バックアップの取得復帰したボリューム内のすべてのファイルには、Snapshot コピーの作成時と同じタイム・スタンプが付いています。復帰操作の後、ファイルまたはボリュームでの増分バックアップおよびリストア操作では、タイム・スタンプを使用してバックアップまたはリストアが必要なデータを判別することはできません。

1. ボリュームを復元した後、基本レベルのバックアップを実行します。

2. テープからデータを復元する場合、ボリュームの復元後に作成されたバックアップのみを使用してください。


SnapMirror を使用するデータ保護

SnapMirror の概要SnapMirror は、Data ONTAP のフィーチャーの 1 つで、データの複製を可能にします。 SnapMirror を使用すれば、指定したソース・ボリュームまたは qtree から、指定した宛先ボリュームまたは qtree に、それぞれデータをコピーできます。SnapMirror を使用するには、別途ライセンスが必要です。

データが宛先ストレージ・システムに複製された後、宛先のデータにアクセスして次のアクションを実行できます。

v ソースが停止した場合に、ミラーリングされたデータへの即時アクセスをユーザーに提供する。

v データをソースにリストアして、災害、データ破壊 (qtree のみ)、またはユーザー・エラーからリカバリーする。

v データをテープに保存する。

v リソースの負荷のバランスを取る。

v データをリモート・サイトにバックアップまたは配布する。

次のいずれかのモードで動作するように SnapMirror を構成できます。

v 非同期モード: SnapMirror は、指定された定期的な間隔で Snapshot コピーを宛先に複製します。

v 同期モード: SnapMirror は、データがソース・ボリュームに書き込まれると同時に宛先にデータを複製します。

v 半同期モード: 宛先ボリュームでの SnapMirror 複製は、ソース・ボリュームより10 秒遅れて行われます。このモードは、同期ミラーリングの必要性と、非同期ミラーリングのパフォーマンス上の利点をバランスよく生かすために便利です。

SnapMirror は、従来型のボリュームと FlexVol ボリュームに対して使用できます。

関連概念

71ページの『同期 SnapMirror とは』同期モードでは、SnapMirror はソース・ボリュームへの書き込みと同時に宛先にデータを複製できます。

72ページの『SnapMirror over Fibre Channel とは』SnapMirror over Fibre Channel を使用すると、SAN 環境でファイバー・チャネルを経由して SnapMirror フィーチャーを使用できるようになります。

SnapMirror の動作SnapMirror は、Snapshot コピーを使用して、ソース・ボリュームまたは qtree から、パートナーの宛先ボリュームまたは qtree にそれぞれデータを複製します。SnapMirror を使用してデータをコピーする前に、ソースと宛先の間で関係を確立する必要があります。


次のいずれかのオプションを使用して、ボリュームまたは qtree 間で SnapMirror ソースと宛先の関係を指定できます。

v /etc/snapmirror.conf ファイル

v snapmirror.access オプション

v /etc/snapmirror.allow ファイル

SnapMirror フィーチャーは、次の処理を行います。

1. ソース・ボリューム上でデータの Snapshot コピーを作成します。

2. それを宛先 (読み取り専用のボリュームまたは qtree) にコピーします。

3. 指定したスケジュールに従って宛先を更新して、ソースに対する変更の増分を反映させます。

この処理の結果、オンラインの読み取り専用ボリュームまたは qtree に、最新の更新の時点でソースと同じデータが格納されます。

ボリューム SnapMirror 複製、qtree SnapMirror 複製、または SnapVault 複製はそれぞれ、1 対の操作によって行われます。次のそれぞれの場所で、操作が 1 つずつ実行されます。

v ソース・ストレージ・システム

v 宛先ストレージ・システム

したがって、ストレージ・システムが 1 つの複製のソースであり、別の複製の宛先である場合、2 つの複製操作が使用されます。同様に、ストレージ・システムが同じ複製のソースおよび宛先である場合にも、2 つの複製操作が使用されます。

SnapMirror を使用する目的SnapMirror は、いくつかのシナリオで便利に使用できます。

SnapMirror 宛先に保管されたデータをコピーまたは使用するとよいでしょう。また、次の表で説明するように、SnapMirror にはそのほかにもさまざまな状況でデータの取り出しに役立つ利点があります。

状況 SnapMirror の使用法

災害復旧: 災害によって qtree、ボリューム、またはシステムが使用不能になった後、データに即時にアクセスできるようにする。

宛先を書き込み可能にすることにより、データが最後にコピーされたときにソース・ボリュームにあったものと同じデータをクライアントが使用できるようになります。

災害復旧テスト: 災害が発生した場合に備えて、データのリカバリーとサービスの修復をテストする。

SnapMirror 宛先で FlexClone テクノロジーを使用して、災害復旧をテストでき、他の複製操作を停止または休止する必要はありません。

データのリストア: qtree またはボリューム・ソース上で失われたデータを、ミラーリングされた qtree またはボリューム SnapMirror

パートナーからリストアする。

ソースおよび宛先の qtree またはボリュームの役割を一時的に反転して、ミラーリングされた情報をソースに再びコピーできます。


状況 SnapMirror の使用法

アプリケーション・テスト: データベース上でアプリケーションを使用するが、そのアプリケーションがデータを損傷した場合に備えて、データベースのコピー上でアプリケーションをテストする。

アプリケーション・テストに使用するデータベースのコピーを作成して、ソースのデータが確実に失われないようにすることができます。

ロード・バランシング: 多数のユーザーが、qtree またはボリュームへの読み取り専用アクセスを必要としている。

qtree またはボリューム内のデータを複数のボリュームまたはストレージ・システムにコピーして、負荷を分散できます。

テープ・バックアップのオフロード: NFS および CIFS の要求に対応するために、ストレージ・システム上にある処理リソースとネットワーキング・リソースをすべて確保したい。

ソース・システム上のデータをコピーした後、宛先でそのデータをテープにバックアップできます。このため、ソース・システム上でバックアップを実行するためにリソースを割り振る必要はありません。

リモート・データへのアクセス: ボリュームへの読み取りアクセスを必要とするユーザーが、大きな地理的領域に分散している。

地理的にユーザーに近い他のストレージ・システムに、ソース・ボリュームをコピーできます。ローカル・システムにアクセスするユーザーがデータを読み取るために使用するリソース時間は、遠く離れたシステムに接続されている場合よりも短くなります。

Data ONTAP 7.3 以降では、SnapMirror と SnapVault は NFS バージョン 4 ACL

(アクセス制御リスト) の複製をサポートします。複製の際に、宛先は NFS バージョン 4 ACL を認識しない場合があります。

v 宛先が NFS バージョン 4 ACL を認識できる場合は、ソースから宛先に ACL

が現状のまま複製されます。宛先のデータに適用されるアクセス規則は、ソースのアクセス規則と同じです。

v 宛先が NFS バージョン 4 ACL を認識できない場合は、宛先が認識できる新規の ACL が作成されます。この新規 ACL のアクセス規則は、オリジナルの ACL

と同等かそれより厳しいものになります。この目的は、セキュリティー問題を防止することです。

注: この代替 ACL を使用すると、ユーザーはソース上ではデータにアクセスできても、宛先では同じデータのセットにアクセスできなくなる可能性があります。

同期 SnapMirror とは同期モードでは、SnapMirror はソース・ボリュームへの書き込みと同時に宛先にデータを複製できます。

同期 SnapMirror は、SnapMirror のフィーチャーです。同期 SnapMirror を使用して、単独のストレージ・システム間、またはリモート・サイトにあるアクティブ/アクティブ構成のストレージ・システム間で (IP 接続またはファイバー・チャネル接続を使用)、データを複製できます。

標準の SnapMirror ライセンスのほかに、同期 SnapMirror フィーチャーには別のライセンス・キーが必要です。同期 SnapMirror フィーチャーを使用可能に設定する前

SnapMirror を使用するデータ保護 71

に、このキーを入力して、重要な製品情報を受け取る必要があります。同期SnapMirror フィーチャーを使用可能に設定するには、license add コマンドを使用します。

注: 同期 SnapMirror はボリュームに対してのみ使用でき、qtree に対しては使用できません。

SnapMirror がデータを同期的に複製する方法Data ONTAP は、データをディスクに保存する前に、書き込まれるデータをNVRAM に取り込みます。その後、整合性ポイントと呼ばれる時点で、データをディスクに送ります。

データが追加または変更される際に、SnapMirror はデータをディスクに直接書き込みません。代わりに、SnapMirrorは NVRAM を使用してデータを一時的に保管します。その後、整合性ポイントで、SnapMirror は宛先システム上のディスクにデータを書き込みます。同期 SnapMirror フィーチャーが使用可能に設定されている場合、ソース・システムはデータが NVRAM に書き込まれたときに宛先システムにデータを転送します。その後、整合性ポイントで、ソース・システムはデータをディスクに送り、宛先システムにもそのデータをディスクに送るように指示します。最終的に、ソース・システムは、宛先システムがディスクにデータを送ったと応答するまで待ってから、次の書き込みに進みます。

同期 SnapMirror がネットワークの問題を処理する方法同期複製の操作の制約になるネットワーク問題を SnapMirror が検出した場合、SnapMirror は非同期モードになります。

通常、ソース・システムと宛先システムは定期的に相互に通信します。ネットワーク障害によって通信が中断されると、SnapMirror は次の処理を開始します。

1. SnapMirror は複製を非同期モードに設定します。

2. 非同期モードでは、ソース・システムは宛先システムとの通信を 1 分に 1 回試みます。

3. ソース・システムが宛先システムとの通信を再確立すると、ソース・システムはデータを非同期で宛先に複製します。

4. SnapMirror は、複製関係を段階的に同期モードに移行します。

アグリゲートを増大させる際のガイドライン同期 SnapMirror 宛先ボリュームが含まれるアグリゲートのサイズを増やす場合、以下のガイドラインに従う必要があります。

v 最小 4 つのディスクを追加します。

v 新しいディスクの追加によって作成された新しい RAID グループに最小 4 つのデータ・ディスクがあることを確認します。

v RAID グループ・サイズが 16 以下のディスクであることを確認します。

SnapMirror over Fibre Channel とはSnapMirror over Fibre Channel を使用すると、SAN 環境でファイバー・チャネルを経由して SnapMirror フィーチャーを使用できるようになります。


SnapMirror over Fibre Channel は、SnapMirror over Ethernet に備わっている機能をすべて含んでいます。操作上の概念とコマンド・インターフェースは両方とも同じです。ただし、これらの間には違いもいくつかあります。

ハードウェア要件ファイバー・チャネル上の IP 機能のために、X1024 または X1124 ファイバー・チャネル NIC アダプターをストレージ・システムに取り付ける必要があります。

X1024 アダプターには 2 つの 2 GB ファイバー・チャネル・ポートがあり、X1124 アダプターには 2 つの 4 GB ファイバー・チャネル・ポートがあります。

SnapMirror over Fibre Channel アプリケーションでは、これらは、ファイバー・チャネル・スイッチに F ポートとしてログインするスイッチ・ファブリック・トポロジーで実行されます。各ポートは、スイッチ・ネーム・サーバーに照会して他のFCVI 対応ポートをディスカバーし、必要に応じてそれらのポートにログインします。各ポートは、固有のワールドワイド名 (WWN) で識別されます。

アダプターは標準ネットワーク・インターフェースとして機能します。各ポートは、イーサネット・アダプターが構成されるように固有の IP アドレスとネットワーク・マスクで構成される必要があります。アクティブ/アクティブ構成システムの場合、管理者はそのパートナー IP アドレスも構成する必要があります。

注: X1024 および X1124 のみが Fibre Channel Virtual Interface (FCVI)

Architectural Mapping をサポートします。FCVI 機能は、ストレージ・システムのその他のファイバー・チャネル NIC アダプターまたはファイバー・チャネル・ポートによってサポートされません。

関連タスク

77ページの『SnapMirror over Fibre Channel の構成』SnapMirror over Fibre Channel を使用するには、ファイバー・チャネル NIC アダプターを取り付けて、SnapMirror 関係をセットアップする必要があります。また、サポートされるスイッチで複数の SnapMirror トラフィック・ゾーンをセットアップすることができます。

サポートされるファイバー・チャネル・スイッチSnapMirror over Fibre Channel は、次のベンダーが提供するファイバー・チャネル・スイッチで機能します。

v Brocade

v Cisco

v McDATA

同種のファイバー・チャネル SAN 環境が必要です。 SnapMirror over Fibre

Channel の認定に準拠するには、SnapMirror データ・パスで 1 つのベンダーのスイッチのみを使用します。

SnapMirror over Fibre Channel トポロジーSnapMirror over Fibre Channel は、ネットワーク・トランスポート・プロトコルとしてファイバー・チャネルを使用する SAN ベースのデータ・センターに通常はインストールされます。


ソースと宛先のストレージ・システム間の SnapMirror トラフィックは、ファイバー・チャネル・ネットワークを経由して伝送されます。ストレージ・システムに取り付けられたアダプターが、SnapMirror IP パケットとファイバー・チャネル・フレームを相互に変換します。

トポロジーの選択:

SnapMirror over Fibre Channel は、データ・パス内に少なくとも 1 つのファイバー・チャネル・スイッチを必要とします。

より複雑なトポロジーには、次の図に示すように、ソースと宛先のストレージ・システム間にマルチパスとスイッチが含まれることがあります。それぞれの建物内にあるストレージ・システムが、アクティブ/アクティブ構成で配置されています。アクティブ/アクティブ構成では、Single Point of Failure が排除され、より実用的な耐障害性のあるセットアップが可能になります。

マルチパス・サポート:

SnapMirror over Fibre Channel は、SnapMirror over Ethernet とまったく同様に、マルチパス構成をサポートします。これらの構成は同じです。

プライベート・サブネットに関する考慮事項:

ストレージ・システムは、Fibre Channel Virtual Interface (FCVI) トラフィックをファイバー・チャネル NIC アダプターに送信する必要があります。したがって、グローバルにルーティング可能でないプライベート・サブネットの範囲内で、ファイバー・チャネル NIC ポートの IP アドレスを構成する必要があります。プライベート・サブネットには次のものがあります。

v 10/8

v 172.16/12

v 192.168/16

複数の SAN アイランドのサポート:

図 5. マルチパスとスイッチを使用した SnapMirror デプロイメント


SAN を複数の SAN アイランドに分割できます。SnapMirror over Fibre Channel は現在、Cisco VSAN フィーチャーをサポートしています。

注: Brocade Multiprotocol Router フィーチャーは、SnapMirror over Fibre Channel

データ・パスではサポートされていません。

拡張ファブリックに関する考慮事項:

標準的な SnapMirror over Fibre Channel セットアップでは、拡張ファブリック構成によって、1 次ストレージ・システムからリモート・サイトにデータをミラーリングします。

リモート・サイトは 1 次サイトから非常に遠い場合があります。SnapMirror データ転送の正しい動作と期待どおりのスループットを実現するには、次に示す指針を守る必要があります。

v データ・パス内で、次のように正しい装置が使用されていることを確認します。

– 長距離 SFP (small form factor pluggable 光モジュール)

– 長距離光ファイバー・ケーブルおよびリピーター

v ファイバー・チャネル・スイッチが拡張ファブリック対応であり、その機能を使用するための適切なライセンスを受けていることを確認します。

v 拡張ファブリック・ポートになるようにスイッチ間リンク (ISL) を構成します。

拡張ライセンスの確認方法、および拡張ファブリック・モードでのスイッチ・ポートの構成方法については、ご使用のスイッチの資料を参照してください。

SnapMirror トラフィックのゾーンSnapMirror over Fibre Channel を使用するには、トラフィックを専用のゾーン内に区分化する必要があります。

標準的な SAN では、SnapMirror トラフィックは他のファイバー・チャネル・トラフィックと同じ物理ネットワークを共有します。ゾーニングにより、サーバーとストレージを別々のグループに区分化し、これらのグループにアクセス権を適用できます。

マルチパス・セットアップを使用している場合は、次の図に示すように、それぞれのデータ・パスに別々のゾーンを使用します。SnapMirror over Fibre Channel は、WWN ゾーニングと物理ポート番号ゾーニングの両方をサポートします。


注: ゾーニング構成手順について詳しくは、ご使用のスイッチの資料を参照してください。

関連タスク


SnapMirror over Fibre Channel をデプロイするための要件SnapMirror over Fibre Channel の有効なデプロイメントのための最小必要要件を満たしていることを確認する必要があります。

v サポートされるスイッチおよび互換ファームウェアを使用する必要があります。

注: サポートされるスイッチおよびそれらのファームウェア・バージョンは、IBM NAS サポート・サイトの「Requirements for SnapMirror over FibreChannel transport (asnychronous, synchronous, and semi-synchronous modes)(SnapMirror over Fibre Channel トランスポートの要件 (非同期、同期、および半同期モード))」に記載されています。

v ソースと宛先の間に最小 1 つのスイッチが必要です。

v SAN 構成は、スイッチ・ベンダーが同種であることが必要です。

v SnapMirror over Fibre Channel には、ファブリック再構成プロセスの間でもフレームのイン・オーダー・デリバリー (IOD) が必要です。そのため、ユーザーはファイバー・チャネル・スイッチの IOD 関連オプションをオンにする必要があります。例えば、Cisco スイッチでは、「in-order guarantee」オプションによってVSAN を構成します。

v ソースと宛先の間のパスが専用スイッチを使用するか、SnapMirror トラフィックが専用ゾーンで実行されるようにストレージ・エリア・ネットワーク (SAN) が構成されている必要があります。Cisco スイッチの場合、専用 VSAN 機能を使用できます。

図 6. SnapMirror トラフィックのゾーン


v ネイティブ・ファイバー・チャネル・ファブリック・デプロイメントを使用する必要があります。つまり、SnapMirror データ・パスで Fibre Channel over IP プロトコル変換は行われません。

v SnapMirror データ・パスでは、Brocade ファイバー・チャネル・ルーターはサポートされません。

v ストレージ・システムが FC NIC (X1024 または X1124) で構成されている必要があります。

関連情報


SnapMirror over Fibre Channel によってサポートされる機能

以下の機能がサポートされます。

v ポート ID に基づくロード・バランシング・アルゴリズム (SID/DID など)

v ダーク・ファイバーまたは DWDM 装置を使用するファイバー・チャネル距離延長

以下の機能はサポートされていません。

v 交換 ID に基づくロード・バランシング・アルゴリズム

v Fibre Channel over IP などのプロトコルを使用する距離延長

関連タスク

『SnapMirror over Fibre Channel の構成』SnapMirror over Fibre Channel を使用するには、ファイバー・チャネル NIC アダプターを取り付けて、SnapMirror 関係をセットアップする必要があります。また、サポートされるスイッチで複数の SnapMirror トラフィック・ゾーンをセットアップすることができます。

関連資料

190ページの『SnapMirror over Fibre Channel に関連する問題のトラブルシューティング』SnapMirror over Fibre Channel 接続をセットアップする際に問題が発生する場合があります。次の表に、発生する可能性があるいくつかの問題と、これらの問題を解決するために推奨される方法をリストします。

SnapMirror over Fibre Channel の構成SnapMirror over Fibre Channel を使用するには、ファイバー・チャネル NIC アダプターを取り付けて、SnapMirror 関係をセットアップする必要があります。また、サポートされるスイッチで複数の SnapMirror トラフィック・ゾーンをセットアップすることができます。

始める前に

ファイバー・チャネル接続の要件およびサポートされるスイッチを確認するには、IBM NAS サポート・サイトの「Product Documentation (製品資料)」セクションの「Requirements for SnapMirror Over Fibre Channel Transport (asynchronous,

synchronous, and semi-synchronous modes) (SnapMirror over Fibre Channel トランスポートの要件 (非同期、同期、および半同期モード))」を参照してください。




さまざまなストレージ・システム・モデルでサポートされるハードウェアに関する更新済みの情報については、IBM NAS サポート・サイトの適切なハードウェアとサービスのガイド、ならびにインターオペラビリティー・マトリックスを参照してください。

ファイバー・チャネルを使用するためにシステムを構成するには、次のステップを実行します。

1. ソース・システムと宛先システムでファイバー・チャネル NIC アダプターを取り付けます。ご使用のストレージ・システム用のハードウェアとサービスのガイドで取り付け手順を参照して、アダプターを正しいスロットに取り付けていることを確認してください。

2. システムをファイバー・チャネル・スイッチに接続します。詳しくは、ご使用のストレージ・システム用のハードウェアとサービスのガイドを参照してください。

3. sysconfig コマンドを使用して、それぞれのストレージ・システムのファイバー・チャネル NIC アダプターを識別します。次の例は、このコマンドの出力を示しています。ここで、ストレージ・システムでは、スロット 4 にファイバー・チャネル NIC アダプターが取り付けられています。

filer_1*> sysconfigRelease 7.3: Wed Mar 31 02:47:49 PST 2008System ID: 0033587346 (filer_1); partner ID 0033586737(filer_2)System Serial Number: 1022105 (filer_1)System Rev: B0Backplane Part Number: 0Backplane Rev: B0Backplane Serial Number: 1022105slot 0: System BoardProcessors:1Memory Size:3072 MBCIOB Revision ID:5slot 0:FastEnet-10/100 Ethernet Controllere0 MAC Address: 00:a0:98:00:f5:39 (auto-100x-fd-up)slot 4: FCVI Host Adapter 4aslot 4: FCVI Host Adapter 4bslot 6: Gigabit Ethernet Controller IVe6 MAC Address 00:02:b3:aa:19:d6: (auto-100x-fd-up)slot 7: FC Host Adapter 728 Disks 1904.0GBslot 8: FC Host Adapter 828 Disks: 1904.0GBslot 10: VI Cluster Adapterslot 11: NVRAMMemory Size: 128 MB

4. sysconfig -v コマンドを入力して、ポート接続の詳細を表示します。これには、スイッチへのログインによって取得したホスト・ポート ID のほか、接続先のスイッチ・ポートの ID も含まれます。次のコマンドにより、スロット 4 のアダプターのポート接続が表示されます。


filer_1*> sysconfig -v 4slot 4: FCVI Host Adapter 4a (Dual Channel, QLogic 2312(2352) rev. 2, 64-bit,F-port, <UP>Firmware rev: 3.1.18Host Loop Id:0xffHost Port Id: 0xa01200Cacheline size:8FC Packet Size: 2048SRAM parity:yesExternal GBIC: NoLink Data Rate:2 GbitSwitch Port brcd_sw_1: 2slot 4: FCVI Host Adapter 4a (Dual Channel, QLogic 2312(2352) rev. 2, 64-bit,F-port, <UP>Firmware rev: 3.1.18Host Loop Id:0xffHost Port Id: 0xa01200Cacheline size:8FC Packet Size: 2048SRAM parity:yesExternal GBIC: NoLink Data Rate:2 GbitSwitch Port brcd_sw_2: 2

5. ゾーニング構成を判別します。スイッチ構成情報については、資料を参照してください。ファイバー・チャネル・スイッチがファブリック・モードであり、シンボル名をサポートする Simple Name Service (SNS) プロトコルをサポートしていることを確認してください。ステップ 6 から 9 は、Brocade スイッチを使用してソース・ストレージ・システムと宛先ストレージ・システムの間で新しいゾーンおよびマルチパス・セットアップを作成する方法を示しています。それぞれのストレージ・システムには、1 つの X1024 ファイバー・チャネル NIC カードが取り付けられています。ポート WWN は次の表にリストされています。

ソース・ストレージ・システム宛先ストレージ・システム

port a: 20:00:00:e0:8b:0a:aa:6d port a: 20:00:00:e0:8b:14:70:af

port b: 20:01:00:e0:8b:2a:aa:6d port b: 20:01:00:e0:8b:34:70:af

1 次パスはソースおよび宛先の「port a」によって形成され、2 次パスはソースおよび宛先の「port b」によって形成されます。SnapMirror トラフィックには専用ゾーンが必要です。ユーザーが 2 つのパスに別々のゾーンを準備することを強くお勧めします。

ステップ 10 から 13 は、Cisco スイッチを使用して新しいゾーンおよびマルチパス・セットアップを作成する方法を示しています。ゾーニングの考え方は、Cisco または Brocade のどちらを使用する場合でも同じです。ただし、コマンドの意味構造が異なります。config コマンドを使用してスイッチ構成モードを入力し、ステップ 14 から 17 で示すようにゾーニング構成をセットアップします。

ステップ 14 から 17 は、McDATA スイッチを使用して新しいゾーンおよびマルチパス・セットアップを作成する方法を示しています。 config コマンドを使用してスイッチ構成モードを入力します。

6. (Brocade スイッチの場合) zonecreate コマンドを使用して新しいゾーンを作成します。

brcd_sw_1:root> zonecreate "sm_zone_1", "20:00:00:e0:8b:0a:aa:6d; 20:00:00:e0:8b:14:70:af"brcd_sw_1:root> zonecreate "sm_zone_2", "20:01:00:e0:8b:2a:aa:6d; 20:01:00:e0:8b:34:70:af"


7. cfgcreate コマンドを使用して新しいゾーニング構成を作成します。

brcd_sw_1:root> cfgcreate "sm_zone_cfg", "sm_zone_1; sm_zone_2"

8. cfgenable コマンドを使用してゾーニング構成を使用可能にします。

brcd_sw_1:root> cfgenable "sm_zone_cfg"zone config "sm_zone_cfg" is in effectUpdating flash ...

9. cfgshow コマンドを使用してゾーニング構成を検査します。

brcd_sw_1:root> cfgshowDefined configuration:cfg: sm_zone_cfgsm_zone_1; sm_zone_2zone: sm_zone_120:00:00:e0:8b:0a:aa:6d; 20:00:00:e0:8b:14:70:afzone: sm_zone_220:01:00:e0:8b:2a:aa:6d; 20:01:00:e0:8b:34:70:afEffective configuration:cfg: sm_zone_cfgzone: sm_zone_120:00:00:e0:8b:0a:aa:6d20:00:00:e0:8b:14:70:afzone: sm_zone_220:01:00:e0:8b:2a:aa:6d20:01:00:e0:8b:34:70:af

10. (Cisco スイッチの場合) 次のコマンドを使用して 2 つのゾーンを定義します。

cisco_sw_1(config)# zone name sm_zone_1cisco_sw_1(config-zone)# member pwwn 20:00:00:e0:8b:0a:aa:6dcisco_sw_1(config-zone)# member pwwn 20:00:00:e0:8b:14:70:afcisco_sw_1(config-zone)# zone name sm_zone_2cisco_sw_1(config-zone)# member pwwn 20:01:00:e0:8b:2a:aa:6dcisco_sw_1(config-zone)# member pwwn 20:01:00:e0:8b:34:70:af

11. 次のコマンドを使用してゾーニング構成を定義します。

cisco_sw_1(config)# zoneset name sm_zone_cfgcisco_sw_1(config-zoneset)# member sm_zone_1

12. 次のコマンドを使用してゾーニング構成を活動化します。

cisco_sw_1(config-zoneset)# zoneset activate name sm_zone_cfgZoneset activation initiated. check zone statuscisco_sw_1(config-zoneset)# member sm_zone_2

13. 次のコマンドを使用してゾーニング構成状況を検査します。

cisco_sw_1# show zoneset activezoneset name sm_zone_cfgzone name sm_zone_1pwwn 20:00:00:e0:8b:0a:aa:6dpwwn 20:00:00:e0:8b:14:70:afzone name sm_zone_2pwwn 20:01:00:e0:8b:2a:aa:6dpwwn 20:01:00:e0:8b:34:70:af

14. (McDATA スイッチの場合) 次のコマンドを使用して 2 つのゾーンを定義します。


mcdata_sw_1> configConfig> zoning addzone sm_zone_1Config> zoning addzone sm_zone_2Config> zoning addwwnmem sm_zone_1 20:00:00:e0:8b:0a:aa:6dConfig> zoning addwwnmem sm_zone_1 20:00:00:e0:8b:14:70:afConfig> zoning addwwnmem sm_zone_2 20:01:00:e0:8b:2a:aa:6dConfig> zoning addwwnmem sm_zone_2 20:01:00:e0:8b:34:70:af

15. 設定されたゾーンを「sm_zone_cfg」に名前変更します。

Config> zoning renamezoneset sm_zone_cfg

16. ゾーニング構成を活動化します。

Config> zoning activatezoneset

17. ゾーニング構成状況を検査します。

mcdata_sw_1> show zoningDefault Zone Enabled: FalseZone Set: sm_zone_cfgZone: sm_zone_2Zone Member: 20:01:00:E0:8B:34:70:AFZone Member: 20:01:00:E0:8B:2A:AA:6DZone: sm_zone_1Zone Member: 20:00:00:E0:8B:14:70:AFZone Member: 20:00:00:E0:8B:0A:AA:6D

18. 各ポートの IP アドレスおよびネットマスクを判別します。アクティブ/アクティブ構成の場合、パートナー・ポートの IP アドレスも決定する必要があります。これらの IP アドレスは、プライベート・ネットワークの IP アドレス範囲内でなければなりません。

注: ストレージ・システムのファイバー・チャネル・ポートごとに異なるプライベート・サブネットを構成する必要があります。

19. setup コマンドを使用して IP アドレスを構成します。これにより、変更内容が確実に不揮発性ストレージにコミットされてストレージ・システムのリブート後も持続します。次の例は、ファイバー・チャネル NIC アダプターを構成する場合に表示される省略形の setup コマンド出力を示しています。


filer_1*> setupThe setup command will rewrite the /etc/rc, /etc/exports, /etc/hosts, /etc/hosts.equiv,/etc/dgateways, /etc/nsswitch.conf, and /etc/resolv.conf files, saving the original contentsof these files in .bak files (e.g. /etc/exports.bak).Are you sure you want to continue? [yes] yes

Release 7.3: Wed Mar 31 02:47:49 PST 2006System ID: 0033587346 (filer_1); partner ID: 0033586737 (filer_2)System Serial Number: 1022105 (filer_1)System Rev: B0Backplane Part Number: 0Backplane Rev: B0Backplane Serial Number: 1022105slot 0: System BoardProcessors: 1Memory Size: 3072 MBCIOB Revision ID: 5

slot 0: FastEnet-10/100 Ethernet Controllere0 MAC Address: 00:a0:98:00:f5:39 (auto-100tx-fd-up)

slot 4: FCVI Host Adapter 4bslot 4: FCVI Host Adapter 4bslot 6: Gigabit Ethernet Controller IVe6 MAC Address: 00:02:b3:aa:19:d6 (auto-1000sx-fd-up)

slot 7: FC Host Adapter 728 Disks: 1904.0GB2 shelves with LRC

slot 8: FC Host Adapter 828 Disks: 1904.0GB2 shelves with LRC

slot 10: VI Cluster Adapterslot 11: NVRAMMemory Size: 128 MB

Please enter the new hostname [filer_1]:Do you want to configure virtual network interfaces? [n]: . . . .Please enter the IP address for FC Network Interface ql4a [10.1.1.15]: 10.1.1.15Please enter the netmask for FC Network Interface ql4a [255.255.255.0]: 255.255.255.0Should interface ql4a take over a partner IP address during failover? [y]: yPlease enter the IP address or interface name to be taken over by ql4a [10.1.1.16]: 10.1.1.16Please enter the IP address for FC Network Interface ql4b [10.1.2.15]: 10.1.2.15Please enter the netmask for FC Network Interface ql4b [255.255.255.0]: 255.255.255.0Should interface ql4b take over a partner IP address during failover? [y]: yPlease enter the IP address or interface name to be taken over by ql4b [10.1.2.16]: 10.1.2.16 . . . .

変更を有効にするために、ストレージ・システムをリブートする必要があります。reboot コマンドを使用します。

20. ストレージ・システムおよびファイバー・チャネル・スイッチをリブートします。

21. ifconfig コマンドを使用して IP アドレスを構成を確認します。

注: 同じファブリック上のポートの IP アドレスに同じネット番号が付けられていることを確認してください。

FC NIC アダプターのポートには qlxa または qlxb の名前が付けられます。ここで、文字の意味は次のとおりです。

v ql ― カードのベンダーを示します。(現時点では、QLogic を表す ql のみです)

v x ― ストレージ・システムでカードが取り付けられるスロット番号です

v a/b ― カード上の FC ポート番号です

次の例は、ifconfig コマンドの出力を示しています。

filer_1*> ifconfig ql4aql4a: flags=840041<UP,RUNNING,LINK_UP> mtu 8160inet 10.1.1.15 netmask 0xffffff00 broadcast 0.0.0.0partner inet 10.1.1.16 (not in use)ether 00:00:00:00:00:00 (VIA Provider)filer_1*> ifconfig ql4bql4b: flags=840041<UP,RUNNING,LINK_UP> mtu 8160inet 10.1.2.15 netmask 0xffffff00 broadcast 0.0.0.0partner inet 10.1.2.16 (not in use)ether 00:00:00:00:00:00 (VIA Provider)


注: 通常の操作では、コマンド出力に UP および LINK_UP が表示されます。UP

は、このインターフェースが使用可能にされ、機能していることを意味します。LINK_UP は、インターフェースの物理接続がオンラインであることを意味します。

22. route コマンドを使用して、IP ルーティング・テーブルのセットアップを確認します。これはプライベート・ネットワーク上であるため、ルーティング・テーブルには特殊な項目があります。

filer_1*> route -sRouting tables

Internet:Destination Gateway Flags Refs Use Interfacedefault harley-29-19.lab.n UGS 4 319989 e0 10.1.1/24 filer_1-ql4a U 0 0 ql4a10.1.2/24 filer_1-ql4b U 0 0 ql4b127 localhost UGS 0 0 lolocalhost localhost UH 1 0 lo

上記の項目は、サブネット 10.1.1.x 内の IP に対して ql4a インターフェースを使用して、サブネット 10.1.2.x 内の IP に対しては ql4b インターフェースを使用することを指定します。

23. ping コマンドを使用して、2 つのネットワーク・インターフェース間の接続を検査します。

filer_1*> ping -s 10.1.1.26

64 bytes from 10.1.1.26 (10.1.1.26): icmp_seq=0 ttl=255 time=0.903 ms64 bytes from 10.1.1.26 (10.1.1.26): icmp_seq=1 ttl=255 time=0.462 ms64 bytes from 10.1.1.26 (10.1.1.26): icmp_seq=2 ttl=255 time=0.439 ms64 bytes from 10.1.1.26 (10.1.1.26): icmp_seq=3 ttl=255 time=0.442 ms--- 10.1.1.26 ping statistics ---4 packets transmitted, 4 packets received, 0% packet lossround-trip min/avg/max = 0.439/0.561/0.903 ms

注: ゾーニング構成が変更された後、再び接続を検査する必要があります。

関連情報


SnapMirror のデプロイメントSnapMirror の基本デプロイメントは、ソース・ボリュームと qtree、および宛先ボリュームと qtree からなります。

ソース・ボリュームまたは qtree: SnapMirror 構成では、ソース・ボリュームとqtree は複製する必要があるデータ・オブジェクトです。通常、ストレージのユーザーはソース・ボリュームと qtree にアクセスし、データを書き込むことができます。

宛先ボリュームまたは qtree: SnapMirror 構成では、宛先ボリュームと qtree は、ソース・ボリュームと qtree が複製される先のデータ・オブジェクトです。宛先ボリュームと qtree は読み取り専用で、通常はソースとは別のシステムに配置されます。ソースが使用不可になった場合には、ユーザーは宛先ボリュームと qtree にアクセスできるようになります。管理者は、SnapMirror コマンドを使用して、宛先で複製されたデータへのアクセスと書き込みを可能にすることができます。



注: qtree SnapMirror を複製に使用する場合には、宛先ボリュームが書き込み可能であることが必要です。

関連概念

85ページの『SnapMirror デプロイメントのバリエーション』SnapMirror をデプロイする際には、いくつかのバリエーションが利用できます。これらのバリエーションにより、要件に応じてソリューションをカスタマイズできます。

サポートされる SnapMirror 構成SnapMirror を使用して、従来型のボリュームおよび FlexVol ボリュームの両方を複製できます。ただし、複製を行うためにサポートされていない構成がいくつかあります。

表 1. ボリューム SnapMirror の場合にサポートされる構成：この表では、ボリュームSnapMirror 複製の場合にサポートされるソースと宛先のボリューム・ペアのタイプを示します。

ソース宛先

従来型のボリューム従来型のボリューム

FlexVol ボリューム FlexVol ボリューム

注: ボリューム SnapMirror は、異なるボリューム・タイプ間の複製をサポートしません。

例外的なケースでは、2 つのボリューム間の同期または半同期 SnapMirror 複製はサポートされません。アクティブ/アクティブ構成では、構成の一方のノードから構成の他方のノードに対して同期または半同期 SnapMirror 関係を確立できません。

表 2. qtree SnapMirror の場合にサポートされる構成：この表では、qtree SnapMirror 複製の場合にサポートされるソースと宛先のボリューム・ペアのタイプを示します。

ソース宛先

従来型のボリューム従来型のボリュームまたは FlexVol ボリューム

FlexVol ボリューム従来型のボリュームまたは FlexVol ボリューム

図 7. 基本 SnapMirror デプロイメント


SnapMirror デプロイメントのバリエーションSnapMirror をデプロイする際には、いくつかのバリエーションが利用できます。これらのバリエーションにより、要件に応じてソリューションをカスタマイズできます。

ソース、宛先、テープの順のバリエーション: 基本 SnapMirror バックアップ・デプロイメントのバリエーションとして、宛先ボリュームのテープ・バックアップを追加することがよくあります。SnapMirror 宛先ボリュームのテープ・バックアップを実行すれば、ユーザーから頻繁にアクセスされるソース・ボリュームに性能低下が生じることがなく、システムが使用不可になっても影響を受けず、直接テープ・バックアップに伴う複雑さもありません。

ソース、テープ、宛先の順のバリエーション: 低帯域幅接続を経由した SnapMirror

複製をサポートする SnapMirror デプロイメントでは、ソースと宛先ボリュームの間での初期ミラーリングは、テープを物理的に移し替えることによって行うことができます。サイズの大きな基本 Snapshot コピーを複製した後、サイズの小さいインクリメンタル Snapshot コピー更新を低帯域幅の接続によって実行できます。

図 8. SnapMirror デプロイメント: ソース、宛先、テープの順


カスケード宛先のバリエーション: 基本的な SnapMirror デプロイメントと機能に対するバリエーションの 1 つとして、書き込み可能なソース・ボリュームを複数の読み取り専用の宛先に複製できます。このデプロイメントの目的は、ネットワーク全体のさまざまな場所から一様なデータのセットをユーザーに読み取り専用で提供し、そのデータを定期的な間隔で均一に更新できるようにすることです。

注: カスケード・デプロイメントは、SnapMirror ボリューム複製に対してのみサポートされます。 SnapMirror qtree 複製に対してはサポートされません。

図 9. SnapMirror デプロイメント: ソース、テープ、宛先の順

図 10. SnapMirror デプロイメント:カスケード


関連概念

114ページの『宛先相互間での連続したデータ複製 (カスケード)』SnapMirror を使用して、SnapMirror 宛先から別のストレージ・システムにデータを複製できます。したがって、ある SnapMirror 関係の宛先であるストレージ・システムを、別の SnapMirror 関係のソースにすることができます。これは、データを 1

つのサイトから多数のサイトにコピーする必要がある場合に便利です。

並行複製操作の最大数ボリューム SnapMirror 複製、qtree SnapMirror 複製、または SnapVault 複製は、2

つの操作で構成されます。1 つの操作は転送のソース・サイドで、もう 1 つの操作は宛先サイドで行われます。そのため、ストレージ・システムが 1 つの複製のソースかつ別の複製の宛先である場合、2 つの複製操作を使用します。同様に、ストレージ・システムが同じ複製のソースと宛先である場合も、2 つの複製操作を使用します。

表 3. ニアライン機能ライセンスがない場合の並行複製操作の最大数

ストレージ・システム・モデル

ボリュームSnapMirror 同期 SnapMirror

qtree

SnapMirror SnapVault

Open

Systems

SnapVault

SRC DSTN SRC DSTN SRC DSTN SRC DSTN DSTN

N3700 8 8 8 8 8 8 8 8 8

N3300 8 8 8 8 16 16 16 16 8

N3600 8 8 8 8 32 32 32 32 8

N5200 50 50 16 16 64 64 64 64 16

N5300 50 50 16 16 64 64 64 64 16

N5500 50 50 16 16 64 64 64 64 16

N5600 50 50 16 16 64 64 64 64 16

N6040 50 50 16 16 64 64 64 64 16

N6060 50 50 16 16 64 64 64 64 16

N6070 50 50 16 16 64 64 64 64 16

N7600 100 100 24 24 96 96 96 96 24

N7700 100 100 24 24 96 96 96 96 24

N7800 150 150 32 32 128 128 128 128 32

N7900 150 150 32 32 128 128 128 128 32

SRC ― ソース、DSTN ― 宛先

表 4. ニアライン機能ライセンスがある場合の並行複製操作の最大数



qtree


Open

Systems

SnapVault

SRC DSTN SRC DSTN SRC DSTN SRC DSTN DSTN


表 4. ニアライン機能ライセンスがある場合の並行複製操作の最大数 (続き)



qtree


Open

Systems

SnapVault

N3300 8 8 8 8 40 40 40 40 16

N3600 8 16 8 8 80 80 80 80 32

N5200 50 100 16 16 80 80 80 80 32

N5300 50 100 16 16 160 160 160 160 64

N5500 50 100 16 16 120 120 120 120 64

N5600 50 100 16 16 320 320 320 320 128

N6040 50 100 16 16 256 256 256 256 64

N6060 50 100 16 16 320 320 320 320 128

N6070 50 100 16 16 384 384 384 384 128

N7600 100 200 24 24 384 384 384 384 96

N7700 100 200 24 24 384 384 384 384 96

N7800 150 300 32 32 512 512 512 512 128

N7900 150 300 32 32 512 512 512 512 128

SRC ― ソース、DSTN ― 宛先

注:

v 上の表にリストされているそれぞれの値は、1 つのタイプの複製を使用する場合に特定のストレージ・システムで許可される並行複製操作の最大数を示しています。値は、排他的であり、累積ではありません。例えば、ストレージ・システムをソースとして最大数の同期 SnapMirror複製を使用している場合、ストレージ・システムでどのタイプの複製操作もそれ以上使用できません。

v ニアライン機能ライセンスは、N3700 ストレージ・システムではサポートされません。

ニアライン・システムとして使用されるストレージ・システム - ニアライン機能ストレージ・システムをバックアップの目的でのみ使用する場合、システムをバックアップ用に最適化することをお勧めします。そうすると、使用される転送リソースが少なくなります。

ニアライン機能: ニアライン機能は使用可能になると以下を行います。

v 許可される同時 SnapMirror および SnapVault 複製操作の数が多くなります。

v SnapVault for NetBackup を N5000 シリーズおよび N7000 シリーズのストレージ・システムで使用可能にすることができます。

ニアライン機能を使用可能にするニアライン機能を使用可能にして、ストレージ・システムをニアライン・システムに変換することができます。


始める前に

以下は、ニアライン機能を使用する前に対応する必要がある要件です。

v ストレージ・システムは、N3300 および N3600、N5000 シリーズ、またはN7000 シリーズシステムでなければなりません。

v Data ONTAP ソフトウェアのバージョンは次のとおりです。

ストレージ・システム Data ONTAP バージョン

N3300 および N3600 7.2.4L1 以降

N5000 シリーズ 7.1 以降

N7000 シリーズ 7.2 以降

v SnapVault 機能を使用する予定の場合、ストレージ・システムで SnapVault 2 次ライセンスが使用可能になっている必要があります。

ストレージ・システムで、ニアライン・システムに変換するには、次のコマンドを入力します。license add xxxxxxx xxxxxxx は、購入したライセンス・コードです。

並行操作の最大数に影響を与える要素ストレージ・システムは、次の理由によって並行複製操作の最大数に達しないことがあります。

v ストレージ・システム・リソース (CPU 使用率、メモリー、ディスク帯域幅、またはネットワーク帯域幅) が SnapMirror または SnapVault 操作で使用されている。

v ニアライン・システムが、SnapMirror および SnapVault 複製操作の宛先として最適化されている。

関連概念

207ページの『並行 SnapVault ターゲットの数の限度』Data ONTAP 7.3 以降では、ストレージ・システム上で可能な個々の qtree の並行SnapVault 転送の最大数は、Data ONTAP 7.2 での最大数よりも大きくなっています。ただし、並行 SnapVault ターゲットの最大数は、リリース・ファミリー間で変更されていません。

アクティブ/アクティブ構成での転送リソースの最大数フェイルオーバーが発生した場合、正常に作動するストレージ・システムは、そのストレージ・システムに対して指定されている最大数を超える並行複製操作を処理できません。これらの操作は、正常に作動するストレージ・システム、またはフェイルオーバーされたストレージ・システム、あるいはその両方に対して実行される予定であったものです。

データ・バックアップ中にフェイルオーバーが発生した場合、障害の起きたノードで障害発生時に行われていた同時転送はすべて打ち切られ、パートナー・ノードによって転送のスケジュールが変更されます。逆に、データ・バックアップ中にギブバックが発生した場合、パートナー・ノードのためにギブバックの時点で行われていた同時転送はすべて打ち切られ、パートナー・ノードによって転送のスケジュール変更が行われます。


最大数を超える SnapMirror ボリュームまたは qtree 複製の同時実行がスケジュールに入れられている場合は、さらに転送が行われるたびに、リソースの限度に達したことを示すエラー・メッセージが生成されます。最大数を超える転送はそれぞれ、その転送が正常に行われるか、SnapMirror がオフになるか、または更新が終了するまで、1 分に 1 回ずつ再試行されます。

従来型のボリュームから FlexVol ボリュームへのマイグレーション

従来型のボリュームから FlexVol ボリュームへのデータのマイグレーションにSnapMirror を使用する場合、このタイプのマイグレーションには qtree SnapMirror

のみを使用できます。ボリューム SnapMirror は別のタイプのボリュームへの複製を実行できないので、この目的には使用できません。

関連概念

179ページの『ボリューム SnapMirror と qtree SnapMirror の比較』SnapMirror 複製は、ボリューム全体、またはボリューム上の個々の qtree を対象に構成できます。これら 2 つのオプションの相違点を考慮する必要があります。

対称ディスク・ジオメトリーFlexVol ボリュームを使用してデータを複製する際には、従来型のボリュームの場合とは異なり、ディスク・ジオメトリーは問題になりません。

FlexVol ボリュームを使用する場合、ソース・ボリュームと宛先ボリュームの間でディスク・ジオメトリーが対称であることはあまり重要ではありません。ソース・ボリュームと宛先ボリュームのディスク数が同じであること、またはディスクのサイズが同一であることは必要ではありません。

関連資料

96ページの『SnapMirror 使用時の推奨アクション』SnapMirror の使用中に、以下の 1 つ以上の推奨アクションを使用することによってデータ・コピーの効率を高めることができます。

SnapMirror セットアップ・コマンドおよび構成ファイルSnapMirror 複製をセットアップするためのコマンドおよび構成ファイルがいくつかあります。

コマンドまたはファイル機能

license add ソースと宛先のストレージ・システムでSnapMirror ライセンスを使用可能にします。

options snapmirror.access

または /etc/snapmirror.allow ファイル

データをソース・システムから直接コピーすることが許可されるストレージ・システムのホスト名を指定します。注: options snapmirror.access および/etc/snapmirror.allow ファイルの両方が使用される場合、options snapmirror.access が優先されます。その場合、SnapMirror の初期化が禁止される可能性もあります。



/etc/snapmirror.conf ファイル複製先となる宛先ボリュームおよび qtree、ならびに宛先が更新されるスケジュールを指定します。

snapmirror on

または options snapmirror.enable

ソースと宛先のストレージ・システムでSnapMirror を使用可能にします。

vol create

およびvol restrict

組み合わせて使用され、SnapMirror ボリューム複製の宛先として必要な制限付き読み取り専用ボリュームを作成します。

snapmirror initialize ソース・ボリュームまたは qtree から宛先ボリュームまたは qtree への初回の完全な (ベースライン) SnapMirror Snapshot 複製を開始します。


関連概念

132ページの『snapmirror.conf ファイルの定義する内容』snapmirror.conf ファイルは、SnapMirror を使用して、ソースから宛先にデータをコピーする処理に関連した詳細を指定するために使用されます。このファイルは、宛先ストレージ・システムにあります。

107ページの『SnapMirror 宛先の初期化』SnapMirror のソース宛先関係を初めて開始する際には、snapmirror initialize コマンドを使用して、情報の完全 (ベースライン) 転送を実行する必要があります。このプロセスは宛先の初期化と呼ばれます。

107ページの『テープからの SnapMirror 宛先の初期化』ソース・ボリュームに対して snapmirror store コマンドを使用し、宛先ボリュームに対して snapmirror retrieve コマンドを使用して、テープから宛先ボリュームを初期化することもできます。

関連タスク

106ページの『ライセンス・コードの入力による SnapMirror の使用可能化』SnapMirror複製プロセスを開始するには、まずストレージ・システム上でSnapMirror フィーチャーのライセンスを有効にし、フィーチャーを使用可能に設定する必要があります。

106ページの『SnapMirror をオンにする』SnapMirror を使用する前に、ソースおよび宛先の両方のストレージ・システムでライセンス交付を受ける必要があります。

110ページの『非 qtree データの宛先の初期化』非 qtree データは、システム上にあって qtree に含まれていないすべてのデータです。非 qtree データには、通常はシステム・クライアントに対して表示されない、システム上の構成およびロギング用のディレクトリー (例えば、/etc または /logs)

が含まれます。また、qtree が構成されていないストレージ・システム・ボリューム上のディレクトリーおよびファイルも含まれます。

108ページの『SnapMirror 宛先の初期化』SnapMirror 宛先を初期化するには、以下のステップを実行します。

関連資料

130ページの『ソースで宛先ストレージ・システムを指定する方法』ソース・ストレージ・システムで宛先ストレージ・システムを指定するには 2 つの方法があります。

SnapMirror の使用に関する考慮事項SnapMirror を複製のために使用する計画を立てる場合、以下の点を覚えておいてください。

SnapMirror の前提条件SnapMirror を使用するには、その前に一連の前提条件を満たす必要があります。

v SnapMirror ライセンスを購入して使用可能にする必要があります。 SnapMirror

ソースと宛先が別のシステムにある場合、ライセンスを購入して、それぞれのストレージ・システムで SnapMirror ライセンス・コードを入力する必要があります。


v SnapMirror ボリューム複製の場合、宛先ボリュームとして使用される制限付きボリュームを作成する必要があります。SnapMirror は、ボリュームを自動的に作成しません。ボリュームの作成方法については、「Data ONTAP ストレージ管理ガイド」のボリュームおよび qtree を使用するデータの編成に関するセクションを参照してください。

v SnapMirror ボリューム複製の場合、宛先ストレージ・システムは、SnapMirror ソース・ストレージ・システムと同じまたはそれ以降の Data ONTAP のバージョンを使用する必要があります。災害復旧の目的で複製をサポートするようにボリューム SnapMirror を構成する場合、ソースと宛先の両方のストレージ・システムが同じバージョンの Data ONTAP を使用する必要があります。

注: ストレージ・システムを新しいバージョンの Data ONTAP にアップグレードする場合、SnapMirror ソース・ボリュームのストレージ・システムをアップグレードする前に、SnapMirror 宛先ボリュームのストレージ・システムをアップグレードしてください。

v SnapMirror qtree 複製の場合、宛先 qtree として使用される qtree を作成してはなりません。snapmirror initialize コマンドが自動的に宛先 qtree を作成します。

v SnapMirror qtree 複製の場合、宛先 qtree は Data ONTAP 6.2 以降で実行される必要があります。

v ソース・ストレージ・システムの名前および IP アドレスは、宛先ストレージ・システムの /etc/hosts ファイルにあるか、DNS または yp コマンドを使用して解決可能であることが必要です。

関連タスク


SnapMirror 使用時の制約事項SnapMirror の構成を計画する際、関連する制約事項について考慮する必要があります。

v ソース・ボリュームがオンラインでなければなりません。ボリュームをオンラインにする方法については、「Data ONTAP ストレージ管理ガイド」を参照してください。

v SnapMirror ボリューム複製の場合、宛先ボリュームの容量がソース・ボリュームの容量より大か等しい必要があります。ディスクをボリュームに追加する方法については、「Data ONTAP ストレージ管理ガイド」を参照してください。

v SnapMirror qtree 複製をサポートするには、宛先ボリュームにソース qtree が消費するよりも 5% 多い空きスペースがなければなりません。

v SnapMirror 宛先ボリュームがストレージ・システムのルート・ボリュームであってはなりません。ただし、SnapMirror ソース・ボリュームはルート・ボリュームでも構いません。

v 宛先 qtree がルート・ボリューム上にあっても構いませんが、/etc qtree が宛先qtree にあってはなりません。

v 宛先 qtree 名では以下が禁止されます。

– 「*」、「-」、「.」、または「/etc」が含まれる


– 「->」の文字の組み合わせが含まれる

この制約事項は、ソース qtree にも適用されます。

– タブ文字が含まれる

– 64 文字より長い

– 「/vol/volname/」(qtree 名がない) として指定される

– 「volname/qtree_name」(/vol/ がない) として指定される

注: qtree を作成または指定する場合、qtree 名にスペース文字を使用できます。ただし、その場合は qtree 名を二重引用符で囲む必要があります。また、qtree 名の中で二重引用符を使用できます。次の例は、スペース文字と二重引用符の両方を使用する qtree 名 vol/vol1/x y″z を指定する方法を示しています。″systemA:/vol/vol1/x y″″z″

v 2 つの異なるストレージ・システムの間でデータを転送するために、機能しているネットワークが必要です。

v 各ストレージ・システム・モデルは、一度に指定された数の snapmirror update コマンドまたは vol copy コマンドをサポートします。


関連概念



関連タスク

306ページの『各ボリュームのサイズの検査』あるボリュームのデータを別のボリュームにコピーまたは複製できるかどうかを調べるために、2 つのボリュームのファイル・システム・サイズを比較する必要があります。

110ページの『非 qtree データの宛先の初期化』非 qtree データは、システム上にあって qtree に含まれていないすべてのデータです。非 qtree データには、通常はシステム・クライアントに対して表示されない、システム上の構成およびロギング用のディレクトリー (例えば、/etc または /logs)


108ページの『SnapMirror 宛先の初期化』SnapMirror 宛先を初期化するには、以下のステップを実行します。

関連資料

87ページの『並行複製操作の最大数』ボリューム SnapMirror 複製、qtree SnapMirror 複製、または SnapVault 複製は、2


SnapMirror 使用時の注意点SnapMirror を使用する場合、以下の点について十分に注意する必要があります。

v SnapMirror がソース・ボリュームで作成する Snapshot コピーを宛先にコピーする前に削除しないでください。最新の SnapMirror Snapshot コピーは、最新の共通 Snapshot コピー (NCS) と呼ばれます。宛先に対する増分の変更は NCS に依存します。SnapMirror が必要な Snapshot コピーをソースで検出できない場合、宛先に対する増分の変更を実行できません。

v ソースからの増分の変更をコピーする必要がなくなるまで、宛先ボリュームまたは qtree で snapmirror release または snapmirror break コマンドを使用しないでください。宛先は、インクリメンタル更新を受信するために宛先としてアクティブに機能している必要があります。

v SnapMirror が転送するように構成されている間、宛先ボリュームを制限したり、オフラインにしないでください。宛先をオフラインにすると、SnapMirror は宛先への更新を実行できなくなります。


SnapMirror 使用時の推奨アクションSnapMirror の使用中に、以下の 1 つ以上の推奨アクションを使用することによってデータ・コピーの効率を高めることができます。

v パフォーマンスを最適化するために、Snapshot コピー更新スケジュールをずらして、snap sched コマンド操作が Snapshot コピーを作成しようとする時刻にSnapMirror アクティビティーが開始または終了しないようにします。

SnapMirror 機能が Snapshot 管理を snap sched アクティビティーと同じ時刻に実行するようにスケジュールされている場合、snap sched コマンドを使用してスケジュールされた Snapshot 管理操作は失敗して、「Skipping creation of hourly

snapshot」および「Snapshot already exists」のような syslog メッセージを出す可能性があります。

v 最適な SnapMirror ボリューム複製のパフォーマンスを得るために、SnapMirror

ソース・ボリュームと宛先ボリュームで、同じサイズのディスクが同じ RAID 構成で編成されていることを確認してください。

– SnapMirror ソースおよび宛先が FlexVol ボリュームである場合、RAID 構成は影響を及ぼしません。

– SnapMirror ソースおよび宛先が qtree である場合、ボリュームのサイズと構成は影響を及ぼしません。

関連資料

98ページの『SnapMirror でのファイアウォールの使用』SnapMirror は、TCP ソケットで通常のソケット/バインド/listen/受信シーケンスを使用します。

ボリューム SnapMirror による非重複化Data ONTAP 7.3 以降、ボリュームの非重複化メタデータはアグリゲート・レベルでボリュームの外に置かれます。これにより、非重複化を使用して達成できるスペース節約が向上します。

ボリューム SnapMirrorを使用してデータを複製する場合、ボリュームの非重複化メタデータはボリュームと一緒に複製されません。ボリューム内のデータは、ソースと宛先の両方で使用可能です。

宛先ボリュームでのスペース節約を最大限に高めるには、ファイル・システム全体をスキャンして、宛先ボリュームの非重複化メタデータを再作成します。そのためには、sis start -s コマンドを使用します。

注: 非重複化スキャンの進行中、宛先ボリュームは読み取り/書き込み操作のためにアクセス可能です。

sis start コマンドを使用して -s オプションを指定しない場合、ボリュームに書き込まれた新しいデータのみが非重複化のためにスキャンされるため、宛先ボリュームでのスペース節約の可用性は低くなります。


関連資料

98ページの『同期 SnapMirrorを使用する前の考慮事項』SnapMirror を同期複製のために使用する計画の場合、以下の点を覚えておいてください。

SnapMirror 操作と Snapshot コピー・スケジュールの間で起こりうる競合SnapMirror のいくつかの操作が Snapshot コピー管理スケジュールのアクションと競合する可能性があります。これらの競合を回避できるようにするステップがいくつかあります。

SnapMirror 機能が Snapshot コピー管理を snap sched アクティビティーと同じ時刻に実行するようにスケジュールされている場合、snap sched コマンドを使用してスケジュールされた Snapshot コピー管理操作は失敗して、「Skipping creation of

hourly snapshot」および「Snapshot already exists.」のようなメッセージを生成する可能性があります。

この状態を回避するには、Snapshot コピー更新スケジュールをずらして、snap sched

コマンド操作が Snapshot コピーを作成する時刻に SnapMirror アクティビティーが開始または終了しないようにします。

SnapMirror で CIFS を使用する場合に宛先へのアクセスを可能にするCIFS クライアントをサポートする SnapMirror ボリューム上のディレクトリーをコピーする前に、ディレクトリーが Unicode フォーマットであることを確認してください。これにより、宛先にコピーされる読み取り専用ディレクトリーが Unicode フォーマットになります。この結果、CIFS 経由での要求が宛先のディレクトリーとそのファイルにアクセスできるようになり、「アクセス拒否」エラーを防止できます。

ソース・ボリュームと宛先ボリュームの両方のディレクトリーを確実に Unicode フォーマットにするには、次の方法を使用できます。

v ソース・ボリュームに対するストレージ・システム・コンソール上で、次の 2 つのコマンドを入力します。

– vol options volname convert_ucode on により、ソース・ボリューム上の既存ディレクトリーすべてが Unicode フォーマットに変換されます。

– vol options volname create_ucode on により、ソース・ボリューム上の新規ディレクトリーが Unicode フォーマットで自動的に作成されます。

v もう 1 つのオプションは、CIFS クライアントによるアクセス対象になるソース・ボリューム上のディレクトリーすべてが、宛先への最初の複製が行われる前に CIFS クライアントからアクセスを受けるようにすることです。書き込み可能ソース・ボリュームに対してこのようなアクセスが行われると、そのディレクトリーが Unicode フォーマットに自動的に変換されます。

SnapMirror の TCP ウィンドウ・サイズの調整SnapMirror の TCP ウィンドウ・サイズは、SnapMirror のパフォーマンスに影響を与える可能性があります。ネットワーク構成を調整するために、TCP ウィンドウ・サイズのデフォルト値を変更する必要が生じる場合があります。


始める前に

SnapMirror 操作のソースと宛先の間の往復遅延を確認する必要があります。また、操作のために必要なビット・レートを判別する必要もあります。


TCP ウィンドウ・サイズは、ソースが宛先からの受信データの確認応答を要求する前に接続を介して送信できるデータの量を指定します。SnapMirror のデフォルト・ウィンドウ・サイズは 1,994,752 バイトです。SnapMirror 操作の最大ウィンドウ・サイズは 8,388,608 バイトです。TCP ウィンドウ・サイズを変更して、使用するネットワーク用に SnapMirror 転送を最適化することができます。

注: 例えば、SnapMirror 転送に 10 GbE ネットワークを使用する場合、TCP ウィンドウ・サイズを最大値の 8,388,608 バイトに変更することができます。

1. 次の数式を使用して、ネットワークで十分に機能する TCP ウィンドウ・サイズを計算します。ウィンドウ・サイズ = (往復遅延) × (目的の速度) 平均往復遅延が 100 ミリ秒で、10 Mbps の速度が必要な場合、式は次のようになります。

ウィンドウ・サイズ = (((0.1 秒) × (10,000,000 bps)) / 8) バイト = 125,000 バイト

したがって、TCP ウィンドウ・サイズを 125,000 バイトに設定します。

2. 次のコマンドを入力して、TCP ウィンドウ・サイズを調整します。options

snapmirror.window_size rate rate は、望ましい TCP ウィンドウ・サイズです。望ましい TCP ウィンドウ・サイズが 125,000 バイトである場合、次のように入力します。

options snapmirror.window_size 125000

SnapMirror でのファイアウォールの使用SnapMirror は、TCP ソケットで通常のソケット/バインド/listen/受信シーケンスを使用します。

SnapMirror ソースはポート 10566 でバインドします。宛先ストレージ・システムは、システムによって割り当てられた使用可能なポートのいずれかを使用して、SnapMirror ソース・ストレージ・システムにポート 10566 で通信します。ファイアウォールは、SnapMirror ソース・ストレージ・システムのこのポートへの要求を許可する必要があります。

同期 SnapMirror では、追加の TCP ポートをオープンにする必要があります。ソース・ストレージ・システムは、TCP ポート 10566 および 10569 で listen します。宛先ストレージ・システムは、TCP ポート 10565、10567、および 10568 で listen

します。そのため、ファイアウォールが TCP ポート 10565 から 10569 の範囲を許可することをお勧めします。

同期 SnapMirrorを使用する前の考慮事項SnapMirror を同期複製のために使用する計画の場合、以下の点を覚えておいてください。


以下の SnapMirror 構成はサポートされません。

v 1 つのソース・ストレージ・システムは、複数の宛先への同期 SnapMirror 関係を持つことができません。

v 同じストレージ・システム内または同じアクティブ/アクティブ構成内の FlexVol

ボリューム間で同期 SnapMirror 関係を作成することはできません。

v 非重複化を使用するボリュームを複製するために同期 SnapMirror を使用することはできません。

v 同期 SnapMirror 関係のボリュームを、非重複化を使用するボリュームと同じアグリゲートの中に配置できません。

同期 SnapMirrorでは、ソースと宛先の両方のストレージ・システムにあるディスクは同じタイプでなければなりません。両側とも ATA であるか、両側ともファイバー・チャネルでなければなりません。いかなる構成でも 2 つのタイプのディスクを組み合わせることは、同期 SnapMirrorの使用ではサポートされません。

次の表に、2 つの異なるタイプのボリュームとの双方向の同期および半同期SnapMirror 複製に対するサポートを示します。

ボリュームのタイプ Data ONTAP バージョン

従来型ボリューム 7.2 以降

FlexVol ボリューム 7.2.2 以降

同期的に複製するデータを選択できます。例えば、データベース・データを同期的に複製して、ホーム・ディレクトリーを非同期的に複製することができます。ホーム・ディレクトリーに重要なログ・データが含まれている場合、同期 SnapMirror オプションを使用して複製することができます。詳しくは、na_snapmirror.conf(5) マニュアル・ページを参照してください。

ソースと宛先のストレージ・システムが複製トラフィック用に適切に構成されている必要があります。同期 SnapMirror は、ソースと宛先のストレージ・システムが同じタイプで、同じディスク・ジオメトリーになっている構成でのみサポートされます。

注: FlexVol ボリュームにはディスク・ジオメトリーの制限はありません。

宛先ストレージ・システムのシステムのタイプおよびディスク構成は、ソース・ストレージ・システムのパフォーマンスに影響を与えます。そのため、宛先ストレージ・システムには、トラフィックの増大とメッセージ・ロギングに必要な帯域幅がなければなりません。 NVLOG ファイルは、複製されているボリュームの親アグリゲートに保管されます。

ネットワーク・トランスポートが SnapMirror 複製のために最適化されている必要があります。ソースと宛先のストレージ・システム間で、高帯域幅/低遅延の専用ネットワークを使用する必要があります。同期 SnapMirror は、ファイバー・チャネルおよび IP トランスポート経由のトラフィックをサポートします。SnapMirror では、マルチパスも使用できるため、2 つのパス間で負荷のバランスを取るか、2 番目のパスをフェイルオーバー用に予約することができます。パフォーマンスを最適化す


るために、ソースと宛先のストレージ・システム間で使用できる最適な経路を使用して、経路を 2 つのシステム間のトラフィックに限定することができます。

Snapshot コピーの最大数をはるかに下回るように維持してください。同期SnapMirror は、同期のために 3 つの Snapshot コピーを必要とします。そのため、1 つのボリュームで保持する Snapshot コピーの合計数を 252 以下に制限してください。

必要となる特別なライセンス・キー: 標準の SnapMirror ライセンスのほか、同期SnapMirror フィーチャーにはライセンス・キーが必要です。同期 SnapMirror フィーチャーを使用可能にする前に、このキーを入力して重要な製品情報を受け取る必要があります。同期 SnapMirror フィーチャーを使用可能にするには、license add

コマンドを使用して以下のいずれかのライセンス・キーを入力します。

プラットフォームライセンス・キー

Data ONTAP を実行しているストレージ・システム

KZZTWOJ

IBM N シリーズ・ゲートウェイ PLFQNUJ

関連概念


103ページの『マルチパス上での SnapMirror』1 つの SnapMirror 関係に対する物理パスを複数にすることができます。SnapMirror

は、1 つの SnapMirror 関係に対して 2 つまでのパスをサポートします。

関連資料

134ページの『snapmirror.conf ファイル項目の構文』snapmirror.conf ファイルの項目の構文は次のとおりです。

同期 SnapMirror 宛先ボリュームのアグリゲート・サイズの見積もりSnapMirror を使用するボリュームの同期複製の場合、宛先ボリュームを含むアグリゲートには、NVLOG データを保管するのに十分な空きスペースが必要です。そうすると、指定されたとおりに定期的な複製が行われます。

始める前に

複製のソースとなっているストレージ・システムのモデル名を確認する必要があります。

1. ソース・ストレージ・システムの NVRAM のサイズを判別します。詳しくは、IBM NAS サポート・サイトの適切なハードウェアとサービスのガイド、およびインターオペラビリティー・マトリックスを参照してください。 N7800 のNVRAM は 2 GB です。

2. NVRAM のサイズに 20 を乗算して、空きスペースの推定サイズを判別します。2 GB の 20 倍は 40 GB であるため、宛先ボリュームを含むアグリゲートには40 GB の空きスペースが必要です。


基本的な SnapMirror 操作のセットアップ適切なライセンスがインストールされ、ソース・ストレージ・システムがデータを複製する前にデータを複製する場所を認識している必要があります。

始める前に

ソース・ボリュームに CIFS クライアントがアクセスするディレクトリーが含まれている場合、SnapMirror を使用してボリュームを複製する前に、それらのディレクトリーが Unicode フォーマットであることを確認します。

また、ソースと宛先の両方のストレージ・システムに適切な SnapMirror ライセンスがあることを確認してください。

1. ソースと宛先の両方のシステム・コンソールに対して license add コマンドを使用して、ソースと宛先のストレージ・システムで SnapMirror ライセンスを使用可能にします。license add snapmirror_license_code

2. ソース・システム・コンソールで options snapmirror.access コマンドを使用して、ソース・システムから直接データをコピーすることを許可されているシステムのホスト名を指定します。 options snapmirror.access host=d_systemA

3. Data ONTAP AdminHost を使用して、宛先システム上の /etc/snapmirror.conf

ファイルを作成または編集し、コピーされるボリュームと qtree、および宛先が更新されるスケジュール (minute hour day_of_month day_of_week または sync)

を指定します。次の入力では、月曜日から金曜日の毎時 15 分過ぎに最大 2,000

キロバイト/秒で s_systemA のボリューム 0 から d_systemA のボリューム 1 への Snapshot ミラーリングが行われることを指定します。s_systemA:vol0

d_systemA:vol1 kbs=2000,restart=always 15 * * 1,2,3,4,5

ボリューム 0 からボリューム 1 に同期的にミラーリングするには、次のように入力します。s_systemA:vol0 d_systemA:vol1 - sync

宛先ストレージ・システムの /etc/snapmirror.conf ファイルのスケジュール項目について詳しくは、na_snapmirror.conf(5) マニュアル・ページを参照してください。

4. ソースと宛先の両方のストレージ・システム・コンソールで snapmirror on コマンドを使用して、ソース・システムと宛先システムで SnapMirror を使用可能にします。

5. SnapMirror ボリュームまたは qtree のどちらの複製をセットアップしているかに応じて、宛先システムを適切に準備してください。

v SnapMirror ボリュームの複製 - 宛先システム・コンソールで、vol create コマンドを使用してソース上のボリュームの宛先となるボリュームを作成してから、vol restrict コマンドを使用してそのボリュームに制限付きのマークを付けます。

v SnapMirror qtree の複製をセットアップしている場合、SnapMirror を使用してqtree を複製する宛先システム上のボリュームがオンラインであり、制限付きでないことを確認してください。宛先 qtree を手動で作成しないでください。

6. 宛先システム・コンソールで、snapmirror initialize コマンドを使用して、宛先でソースの初回の完全な (ベースライン) コピーを作成し、ミラーリング・プロセスを開始します。 SnapMirror ボリュームの複製の場合: 次のコマンドを呼び出


すと、ソース・ボリューム (システム A の vol0) の完全なコピーが宛先ボリューム (システム B の vol2) に転送されます。宛先ボリュームは制限付きおよび読み取り専用として構成されている必要があります。snapmirror initialize -S

systemA:vol0 systemB:vol2 SnapMirror qtree の複製の場合: 次のコマンドを呼び出すと、宛先 qtree (システム B の vol1 の qtree4) が作成され、ソース qtree

(システム A の vol1 の qtree4) の完全なコピーが宛先 qtree に転送されます。宛先 qtree が作成されるボリュームは、オンラインかつ書き込み可能でなければなりません。snapmirror initialize -S systemA:/vol/vol1/qtree4

systemB:/vol/vol1/qtree4 snapmirror initialize コマンドを呼び出した後、指定された時刻に、ステップ 3 で指定したスケジュール済みの Snapshot ミラーリングが自動的に宛先のボリュームまたは qtree を更新します。

7. SnapMirror のソースのボリュームまたは qtree が使用不可になっている場合は、snapmirror break コマンドを使用して宛先のボリュームまたは qtree を書き込み可能にすることができます。これにより、使用不可のソース・システムにアクセスできなくなったクライアントに対してデータへの持続的なアクセスを提供することができます。


関連概念



162ページの『宛先から書き込み可能なボリュームまたは qtree への変換』snapmirror break コマンドを使用して、読み取り専用状況の SnapMirror 宛先を、書き込み可能なボリュームまたは qtree に変換できます。

関連タスク


106ページの『SnapMirror をオンにする』SnapMirror を使用する前に、ソースおよび宛先の両方のストレージ・システムでライセンス交付を受ける必要があります。

関連資料

97ページの『SnapMirror で CIFS を使用する場合に宛先へのアクセスを可能にする』CIFS クライアントをサポートする SnapMirror ボリューム上のディレクトリーをコピーする前に、ディレクトリーが Unicode フォーマットであることを確認してください。これにより、宛先にコピーされる読み取り専用ディレクトリーが Unicode フォーマットになります。この結果、CIFS 経由での要求が宛先のディレクトリーとそのファイルにアクセスできるようになり、「アクセス拒否」エラーを防止できます。


マルチパス上での SnapMirror1 つの SnapMirror 関係に対する物理パスを複数にすることができます。SnapMirror

は、1 つの SnapMirror 関係に対して 2 つまでのパスをサポートします。

マルチパスを使用する際には、次のいずれかの方法で構成をセットアップする必要があります。

v それぞれの IP 接続に対して別々の経路が使用されるように、静的ルートをセットアップします。

v 2 つの接続には別々のサブネットを使用します。

パスは、イーサネットまたはファイバー・チャネル、あるいはイーサネットとファイバー・チャネルの組み合わせを使用できます。次に示す 2 つのモードのどちらかで、2 つのパスを使用できます。


v 多重化モード―SnapMirror は両方のパスを同時に使用し、基本的には転送のロード・バランシングを行います。一方のパスに障害が起こると、残りのパス上で転送が行われます。障害の起こったパスが修復された後、転送は両方のパスを使用して再開します。

v フェイルオーバー・モード―SnapMirror は、最初に指定されたパスを優先パスとして使用し、2 番目に指定されたパスは最初のパスに障害が起こった後にのみ使用します。

マルチパスを使用するベースラインの初期化のための SnapMirror のセットアップベースラインの初期化のためにソースと宛先のストレージ・システム間でマルチパスを実装するには、以下のステップを行います。


最初にマルチパスを使用するために SnapMirror をセットアップすることができます。また、単一パスの SnapMirror 関係を変換してマルチパスを使用することもできます。

1. ソース・システムから宛先システム上の各 IP アドレスに ping コマンドを使用して、2 つの有効なパスがあることを確認します。

宛先システム上の IP アドレスは、10.10.10.24 および 10.10.11.24 です。

source> ping 10.10.10.24

10.10.10.24 is alive

source> ping 10.10.11.24

10.10.11.24 is alive

2. ソース・システム・コンソールで、options snapmirror.access コマンドを使用して、ソース・システムから直接データをコピーすることを許可されているシステムのホスト名を指定します。 options snapmirror.access host=d_systemA

3. 管理ホストで、宛先システム上の snapmirror.conf ファイルを編集して、接続のモードおよび 2 つの接続の名前を定義する項目を追加します。項目の形式を次に示します。name = mode (src_system1,dest_system1)

(src_system2,dest_system2) ここで、mode は「multi」または「failover」です。詳細については、na_snapmirror.conf(5) マニュアル・ページを参照してください。

4. 管理ホストで、宛先システム上の /etc/snapmirror.conf ファイルを編集して、コピーされるボリュームと qtree、および宛先が更新されるスケジュール (minute

hour day_of_month day_of_week または sync) を指定します。ステップ 3 で指定した接続名をソース・システムとして使用します。


関連資料


マルチパスを使用するための単一パス SnapMirror 関係の変換最初にマルチパスを使用するために SnapMirror をセットアップすることができます。また、単一パスの SnapMirror 関係を変換してマルチパスを使用することもできます。

1. ソース・システムから宛先システム上の各 IP アドレスに ping コマンドを使用して、2 つの有効なパスがあることを確認します。宛先システム上の IP アドレスは、10.10.10.24 および 10.10.11.24 です。

source> ping 10.10.10.2410.10.10.24 is alive

source> ping 10.10.11.2410.10.11.24 is alive

2. 管理ホストで、宛先システム上の snapmirror.conf ファイルを編集して、接続のモードおよび 2 つの接続の名前を定義する接続行を追加します。行の形式は次のとおりです。name = mode (src_system1,dest_system1)

(src_system2,dest_system2) mode は、multi または failover です。詳細については、na_snapmirror.conf(5) マニュアル・ページを参照してください。

3. 同じ snapmirror.conf ファイルで、スケジュール項目を編集して新しい接続名をソース・システムとして反映させます。

注: マルチパスは、非同期的または同期的に実行されている SnapMirror によってサポートされます。以下は、同期 SnapMirror を使用してマルチパスを実装する例です。NYC というストレージ・システム上のボリューム vol1 を Newark というストレージ・システム上のボリューム vol1 に同期的にミラーリングするとします。同期的にミラーリングされた各ボリュームの間に 2 つのパスがあるというビジネス要件を満たすには、各システムに 2 つずつ、4 つのネットワーク・インターフェース・カードが必要です。NYC システム上の 2 つのインターフェースにNYC-pri および NYC-sec という名前を付け、Newark システム上の 2 つのインターフェースに Newark-pri および Newark-sec という名前を付けます。マルチパスをフェイルオーバー・モードで実装するには、Newark の snapmirror.conf

ファイルを編集して次の 2 行を組み込みます。NYC-Newark = failover

(NYC-pri,Newark-pri) (NYC-sec,Newark-sec) NYC-Newark:vol1 Newark:vol1 -

sync NYC-pri および Newark-pri がファイバー・チャネル NIC アダプターで、両方の接続を使用してデータを複製する場合、以下の手順に従ってファイバー・チャネル NIC アダプターを SnapMirror 用に構成します。次に、Newark のsnapmirror.conf ファイルを編集して以下の 2 行を組み込み、マルチパスを多重方式で実装します。NYC-Newark = multi (NYC-pri,Newark-pri)

(NYC-sec,Newark-sec)NYC-Newark:vol1 Newark:vol1 - sync


関連タスク


ライセンス・コードの入力による SnapMirror の使用可能化SnapMirror複製プロセスを開始するには、まずストレージ・システム上でSnapMirror フィーチャーのライセンスを有効にし、フィーチャーを使用可能に設定する必要があります。


SnapMirror ライセンスのほかに、同期 SnapMirror を使用可能にするには、特別なライセンス・キーが必要です。ソースと宛先にする予定のストレージ・システム上で、ライセンス・コードを入力します。

SnapMirror ライセンス・コードを入力するには、コマンド license add xxxxxxx を入力します。 xxxxxxx は、購入したライセンス・コードです。

注: この設定は、再起動しても持続します。

関連概念

71ページの『同期 SnapMirror とは』同期モードでは、SnapMirror はソース・ボリュームへの書き込みと同時に宛先にデータを複製できます。

SnapMirror をオンにするSnapMirror を使用する前に、ソースおよび宛先の両方のストレージ・システムでライセンス交付を受ける必要があります。

1. SnapMirror をオンにするには、ソース・システムと宛先システムの両方で次のコマンドを入力します。options snapmirror.enable on あるいは、以前のコマンドを使用して SnapMirror をオンにすることもできます。snapmirror on

注: この設定は、再起動しても持続します。

2. 許可される宛先を指定するために snapmirror.access オプションまたは/etc/snapmirror.allow ファイルのどちらを使用するかに応じて、以下のいずれかのアクションを選択します。

選択内容処置

snapmirror.access オプションソースで、次のコマンドを単一行として入力します。options snapmirror.access

host=[dest_system1,dest_ system2...]

snapmirror.access オプションのデフォルト値は legacy です。これを指定すると、/etc/snapmirror.allow ファイルはアクセス許可を定義できます。このオプションは、再起動しても持続します。


選択内容処置

/etc/snapmirror.allow ファイル /etc/snapmirror.allow ファイルで、宛先システムの名前をそれぞれ別々の行で追加します。

SnapMirror 宛先の初期化SnapMirror のソース宛先関係を初めて開始する際には、snapmirror initialize コマンドを使用して、情報の完全 (ベースライン) 転送を実行する必要があります。このプロセスは宛先の初期化と呼ばれます。

SnapMirror 宛先 qtree に対する割り当て量qtree 割り当て量は、SnapMirror 関係内の qtree に適用されます。

宛先 qtree が 100 GB に制限されている場合、100 GB を超えるソース qtree からの転送は、次の場合を除いては失敗します。

v ソース qtree が 100 GB 未満に縮小した

v 宛先の qtree 割り当て量が増加した

注: ユーザー割り当て量は、SnapMirror 宛先 qtree にも適用されます。ただし、ユーザーが割り当て量を超過した場合に、SnapMirror qtree 更新は失敗しません。

qtree SnapMirror 関係を作成する際のガイドラインqtree SnapMirror 関係を作成する場合、以下のガイドラインに従ってください。

v vol lang 設定が同じボリューム間で qtree SnapMirror 関係を確立します。

v qtree SnapMirror 関係を確立した後、宛先ボリュームに割り当てられた言語を変更しないでください。

v ソースおよび宛先 qtree の名前で空白文字 (スペースまたはタブ文字) を使用しないでください。

v qtree SnapMirror 関係を確立した後でボリュームまたは qtree を名前変更しないでください。

テープからの SnapMirror 宛先の初期化ソース・ボリュームに対して snapmirror store コマンドを使用し、宛先ボリュームに対して snapmirror retrieve コマンドを使用して、テープから宛先ボリュームを初期化することもできます。

snapmirror store 機能および snapmirror retrieve 機能は、ボリュームに対してのみ有効で、SnapMirror 関係内の qtree に対しては無効です。


関連概念

176ページの『SnapMirror を使用したテープへのボリュームのコピー』さまざまな理由で、SnapMirror を使用して、ソース・ストレージ・システムからローカル・テープにボリュームをコピーする場合があります。

関連タスク

122ページの『ローカル・テープを使用する SnapMirror 宛先の初期化』SnapMirror 関係の初期ベースライン転送では、テープを使用して転送する場合があります。基本データをテープにコピーした後、データをテープから目的の宛先にコピーして宛先を初期化する必要があります。

SnapMirror 宛先の初期化SnapMirror 宛先を初期化するには、以下のステップを実行します。

始める前に

ソース・ボリュームに CIFS クライアントがアクセスするディレクトリーが含まれている場合、そのボリュームの SnapMirror 複製を実行する前に、それらのディレクトリーが Unicode フォーマットであることを確認します。

1. 宛先がオンラインのボリュームで、かつ以前に初期化されていない場合、宛先システムから次のコマンドを入力します。vol restrict dest_volume

dest_volume は、宛先ボリュームです。

注: qtree に対して vol restrict コマンドを使用しないでください。qtree を初期化している場合は、ステップ 2 に進みます。

2. 宛先システムから、次のコマンドを入力します。snapmirror initialize

[options] [dest_system:] {dest_volume | qtree_path} options は、以下の 1

つ以上が可能です。

v -k n は、最大転送速度を毎秒 n キロバイトに設定します。このオプションは、 /etc/snapmirror.conf ファイルの kbs 引数と同じ効果があります。

v -S [source_system:]{source_volume | source_qtree_path} は、コピー対象のソース・システムとボリュームまたは qtree を指定します。

source_volume は、コピーするボリュームです。

注: 指定されたソースは、/etc/snapmirror.conf ファイル内の source_volume

の項目と一致する必要があります (存在する場合)。項目が存在しても一致しない場合、この操作により、エラー・メッセージが表示されて終了します。指定されたソースの項目がない場合、コマンドは実行されます。

source_qtree_path は、コピーする qtree のパスです。-S オプションが設定されていない場合、ソースが /etc/snapmirror.conf ファイルで指定されている必要があります。指定されない場合、この操作により、エラー・メッセージが表示されて終了します。

注: source_qtree_path は、SnapMirror 宛先ボリューム内の qtree にすることができます。


v -c snapshot_name は、次回の更新後に宛先の qtree の Snapshot コピーを(snapshot_name の名前で) 作成します (進行中の更新と競合しないようにするため)。SnapMirror は、この Snapshot コピーをロックまたは削除しません。

注: snapshot_name を minutely.x、hourly.x、nightly.x、または weekly.x

にすることはできません。これらの名前は、スケジュールに基づく Snapshot

コピー用に予約されているためです。

注: このオプションは、qtree の場合にのみ有効です。

v -s snapshot_name は、転送される既存のソース qtree Snapshot コピーを指定します。これにより、ソースが転送する Snapshot コピーを作成する通常のアクションを防止できます。SnapMirror は、この Snapshot コピーをロックまたは削除しません。このオプションは、qtree SnapMirror 複製の場合にのみ有効です。

dest_system は、宛先システムの名前です。宛先は、ソースと同じシステムに置かれていても、別のシステムに置かれていても構いません。

dest_volume または qtree_path は、宛先のボリュームまたは qtree を指定します。/etc/snapmirror.conf ファイルで指定されているローカル・ソースに関連付けられている場合、SnapMirror はそのソースを使用します。指定された宛先のボリュームまたは qtree がスケジュールされた関係ではない場合、-S オプションを使用してソースを指定する必要があります。

snapmirror initialize コマンドは、宛先 qtree を作成しますが、宛先 qtree 名を既に存在しているかのようにパスの末尾で指定する必要があります。

注: コマンドを実行する前に宛先 qtree が存在する場合、コマンドは失敗します。次のコマンドを使用して、SnapMirror は、ソース・ボリューム (systemA のvol0) の完全なコピーを宛先ボリューム (systemB の vol2) に転送します。

systemB> snapmirror initialize -S systemA:vol0 systemB:vol2

次のコマンドを使用して、SnapMirror は、qtree ソース (systemA の vol1 のqtree4) の完全なコピーを宛先 qtree (systemB の vol1 の qtree4bak) に転送します。

systemB> snapmirror initialize -S systemA:/vol/vol1/qtree4 systemB:/vol/vol1/qtree4bak


関連資料

97ページの『SnapMirror で CIFS を使用する場合に宛先へのアクセスを可能にする』CIFS クライアントをサポートする SnapMirror ボリューム上のディレクトリーをコピーする前に、ディレクトリーが Unicode フォーマットであることを確認してください。これにより、宛先にコピーされる読み取り専用ディレクトリーが Unicode フォーマットになります。この結果、CIFS 経由での要求が宛先のディレクトリーとそのファイルにアクセスできるようになり、「アクセス拒否」エラーを防止できます。

ボリューム SnapMirror 宛先のスペース・ギャランティーアグリゲートの中のボリュームのためにスペースを予約できます。この機能を使用して、ボリューム SnapMirror 宛先のスペース・ギャランティーを確保することができます。

vol options コマンドを使用して特定のボリュームの設定を表示できます。

ボリュームのデフォルト設定は、guarantee=volume です。これは、ボリューム用のスペースがアグリゲートの中で予約されていることを示します。この設定は、次のコマンドを使用して変更できます。vol options vol_name guarantee {none | file

| volume}

ボリュームのスペース・ギャランティーについて詳しくは、「Data ONTAP ストレージ管理ガイド」を参照してください。

注: ボリューム SnapMirror 関係では、ソース・ボリュームと宛先ボリュームの両方に対して guarantee=volume を設定できます。

非 qtree データの宛先の初期化非 qtree データは、システム上にあって qtree に含まれていないすべてのデータです。非 qtree データには、通常はシステム・クライアントに対して表示されない、システム上の構成およびロギング用のディレクトリー (例えば、/etc または /logs)



SnapMirror を使用してソースから宛先に非 qtree データを複製するには、宛先システムで次のコマンドを入力します。snapmirror initialize -S

source_system:/vol/source_volume/- dest_system:/vol/dest_volume/qtree_name

ダッシュ (-) 文字は、指定されたボリューム内のすべての非 qtree データを示します。

注: snapmirror initialize コマンドは、指定されたボリューム内の非 qtree データを転送しますが、宛先 qtree 名を既に存在しているかのようにパスの末尾で指定する必要があります。コマンドを実行する前に宛先 qtree が存在する場合、コマンドは失敗します。次のコマンドを使用して、SnapMirror は、systemA のボリューム 3 にあって qtree

の一部になっていないすべてのデータの完全コピーを宛先 qtree (systemB の vol4

の non_qtree_data_in_vol3) に転送します。


systemB> snapmirror initialize -S systemA:/vol/vol3/- systemB:/vol/vol4/non_qtree_data_in_vol3

注: 転送の後、非 qtree データを SnapMirror ソースのみにすることができ、宛先にすることはできません。非 qtree データを別の qtree にコピーすることはできますが、別の qtree から非 qtree データにデータをコピーすることはできません。

例

宛先ボリューム (/vol/vol4/non_qtree_data_in_vol3) で snapmirror quiesce またはsnapmirror break コマンドを実行した場合、宛先ボリュームをソース・ボリュームに再同期することができます。

systemB> snapmirror resync -S /vol/vol3/- /vol/vol4/non_qtree_data_in_vol3

注: 2 つの qtree を逆の方向で再同期することはできません。

要約すると、/vol/volname/- を SnapMirror 宛先にすることはできません。この非qtree データは、SnapMirror ソースにしかできません。

snapmirror initialize コマンドがボリュームをコピーする方法snapmirror initalize コマンドがボリュームをコピーする際には、ソース上にあるすべてのデータの Snapshot コピーを作成して、宛先に転送します。宛先は、ユーザーが既に作成済みで制限付きのマークを付けてあるボリュームです。 SnapMirror がデータの転送を完了した後、宛先はオンラインになりますが、読み取り専用の状態です。このバージョンの宛先は、最初のインクリメンタル更新のベースラインになります。

初期データ転送が行われている間、vol status コマンドの出力内で、宛先には「invalid」のマークが付けられます。初期転送の完了後にボリュームは有効になり、オンラインになります。

注: このボリュームを手動でオンラインにしようとした場合は、初期転送の完了後にのみ正常にオンラインになります。

snapmirror initialize コマンドが qtree をコピーする方法SnapMirror を使用して qtree をコピーする場合は、snapmirror initialize コマンドが宛先 qtree を作成するので、ユーザーが宛先 qtree を作成することはありません。宛先 qtree を配置するボリュームは、オンラインになっている必要があります。宛先 qtree は、初期化された後で書き込み不可になります。ただし、qtree があるボリュームの残りの部分は引き続き書き込み可能です。

qtree の初期化によって作成された宛先 Snapshot コピーは、次回の転送が完了するまで、snap list コマンドの出力内で busy のマークが付けられます。

SnapMirror が宛先への初期コピーを行った後の処理SnapMirror ボリューム複製を初期化した後、ソース・ボリューム内のファイルとSnapshot コピーが宛先で使用可能になります。


SnapMirror qtree 複製を初期化した後、ソース qtree 上のファイルが宛先 qtree 上で使用可能になります。

NFS マウントのために宛先をエクスポートしたり、CIFS 共有の宛先に対応する共有を追加したりすることができます。

ボリュームの初期化を検査する方法宛先ボリュームが初期化されたことを検査するには、snapmirror status コマンドを使用します。

オプションまたは引数を指定しない場合は、次の例に示すように、snapmirror status

コマンドはシステム内のボリュームの状況を表示します。また、vol status コマンドまたは qtree コマンドを使用して、ボリュームまたは qtree が SnapMirror 宛先であるかどうかを検査することもできます。

systemA> snapmirror statusSnapmirror is on.Source Destination State Lag StatussystemA:vol0 systemA:vol0bak Snapmirrored 00:56:58 IdlesystemA:vol1 systemB:vol6 Source 23:69:26 Transferring (126 MB done)

関連タスク

145ページの『SnapMirror データ転送状況の検査』snapmirror status コマンドを使用してデータ転送状況を確認し、ストレージ・システムにあるすべての既存の SnapMirror 関係の状況を判別する必要があります。

qtree の初期化の確認以下のステップを実行することにより、宛先 qtree の作成と初期化を確認することができます。

次のコマンドを入力します。qtree

注: オプションまたは引数を指定しない場合、qtree コマンドは、ストレージ・システム内のすべての qtree の状況を表示します。

systemA> qtreeVolume Tree Style Oplocks Status-------- ----- ----- ------- ------vol0 unix enabled normalqtree24 unix enabled normalsystemB_vol0 unix disabled normalsystemB_vol0 qt1 mixed enabled snapmirroredsystemB_vol0 qt2 unix disabled normalsystemB_vol0 qt3 ntfs enabled snapmirrored

snapmirror initialize コマンドがソースと宛先のボリューム・サイズを一致させる方法snapmirror initialize コマンドを使用してボリューム複製を初期化する際に、SnapMirror は vol options fs_size_fixed オプションをオンに設定します。このオプションにより、宛先ボリューム上のファイル・システムは、ソース・ボリューム上のファイル・システムと同じサイズを保つように強制されます。


初期化の失敗または中断が起こった場合の処置初期 SnapMirror 転送が失敗した場合、下記のすべての条件が満たされていると、snapmirror initialize コマンドを再入力することによって転送を再開できます。

v /etc/snapmirror.conf ファイル内の再開モードの値が always またはデフォルトに設定されていて、次回のスケジュール更新がまだ開始されていない。

v snapmirror status コマンドの出力で、プロセスに再開チェックポイントがあることが表示される。

v 初期 SnapMirror転送で使用された Snapshot コピーがまだ存在している。

v ディスク・ジオメトリーが変更されていない。

注: これらの条件が満たされていない場合は、転送を再開するのではなく、初期SnapMirror 転送を再び開始できます。

SnapMirror は、宛先の初期化を自動的に再試行しません。

すべての転送の最大転送速度の設定すべての転送の最大転送速度を設定すると、いつでもすべての転送によって使用される合計帯域幅を制限することができます。すべての転送の最大転送速度を設定するために、Data ONTAP では、ストレージ・システムに到着する転送の最大速度とストレージ・システムから発信される転送の最大速度を設定できます。


注: これは、すべての SnapMirror および SnapVault の転送に適用されます。

ストレージ・システムの最大転送速度を構成して、/etc/snapmirror.conf ファイルを使用して転送ごとの最大転送速度を設定できます。システム・レベルの転送速度と転送レベルの転送速度が構成される場合、着信および発信のすべての転送の合計帯域幅がシステム・レベルの最大速度を超える場合にのみ、システム・レベルの最大速度が適用されます。

1. 次のコマンドを使用して、システム・レベルの最大転送速度を設定できるようにします。options replication.throttle.enable on

2. ストレージ・システムに到着する転送で使用される最大転送速度 (宛先システムで適用されます) を指定する場合、次のコマンドを入力します。options

replication.throttle.incoming.max_kbs value value は、最大転送速度 (キロバイト/秒) です。転送速度の有効値は 1 から 125000 です。デフォルト値はunlimited です。

3. ストレージ・システムから発信される転送で使用される最大転送速度 (ソース・システムで適用されます) を指定する場合、次のコマンドを入力します。options replication.throttle.outgoing.max_kbs value value は、最大転送速度 (キロバイト/秒) です。転送速度の有効値は 1 から 125000 です。デフォルト値は unlimited です。

次のタスク

replication.throttle.enable オプション、replication.throttle.incoming.max_kbs オプション、および replication.throttle.outgoing.max_kbs オプションについて詳しくは、options(1) マニュアル・ページを参照してください。


宛先相互間での連続したデータ複製 (カスケード)SnapMirror を使用して、SnapMirror 宛先から別のストレージ・システムにデータを複製できます。したがって、ある SnapMirror 関係の宛先であるストレージ・システムを、別の SnapMirror 関係のソースにすることができます。これは、データを 1


データを単一のソースからそれぞれの宛先に複製する代わりに、データを宛先相互間で連続して複製できます。これはカスケードと呼ばれます。

注: 宛先ボリュームからのデータの複製は、書き込み可能なソース・ボリュームからの複製と同じ方法で行うことができます。

関連概念


関連タスク

101ページの『基本的な SnapMirror 操作のセットアップ』適切なライセンスがインストールされ、ソース・ストレージ・システムがデータを複製する前にデータを複製する場所を認識している必要があります。


関連資料




サポートされる SnapMirror カスケード構成使用可能な SnapMirror には、さまざまなタイプがあります。ただし、異なるタイプの SnapMirror をカスケードの別のステージで使用することはできません。

次の表に、サポートされるカスケード構成をリストします。例えば、表に示すカスケードの数を超えてカスケードを拡張するなど、その他の構成はいずれもサポートされません。

注: この制限は、3 つより多いストレージ・システムに伝搬できる非同期SnapMirror カスケード構成には厳密に適用されません。


表 5. サポートされる 2 ホップ・カスケード構成：次の表に、SnapMirror 複製でサポートされる 2 ホップ・カスケード構成をリストします。

ストレージ・システム A からストレージ・システム B

ストレージ・システム B からストレージ・システム C

同期 SnapMirror (ボリューム) 非同期 SnapMirror (ボリューム)

非同期 SnapMirror (ボリューム) 非同期 SnapMirror (ボリューム)

非同期 SnapMirror (ボリューム) 非同期 SnapMirror (qtree)

非同期 SnapMirror (qtree) 非同期 SnapMirror (ボリューム)

この表は、左から右に向かって読んでください。

例

第 1 行には、ストレージ・システム A にはストレージ・システム B との同期SnapMirror 関係があり、ストレージ・システム B にはストレージ・システム C との非同期 SnapMirror 関係があることが示されています。

同期 SnapMirror 宛先からボリューム宛先をカスケードすることはできますが、カスケード・シリーズは非同期 SnapMirror の場合と若干異なります。同期 SnapMirror

の場合、最初の複製はカスケード内の同期 SnapMirror 複製のみで、同期複製は 1

つの宛先ストレージ・システムに対してのみ行うことができます。その宛先システムからカスケードする後続の SnapMirror 複製は非同期でなければならず、複数の宛先システムに対して行うことができます。

サポートされる SnapMirror 3 ホップ・カスケード構成3 ホップ・カスケード構成では、SnapMirror 複製タイプの特定の組み合わせのみがサポートされます。

最初の関係が同期 SnapMirror 関係となっている 3 つの SnapMirror 関係のカスケードは、Data ONTAP 7.1.2 および 7.2.1 以降のリリースでサポートされます。

表 6. サポートされる 3 ホップ・カスケード構成：次の表に、SnapMirror 複製でサポートされる 3 ホップ・カスケード構成をリストします。



ストレージ・システム C からストレージ・システム D


非同期 SnapMirror (ボリューム)


非同期 SnapMirror (qtree)






非同期 SnapMirror (qtree)






注: カスケード内の最初の SnapMirror 関係が同期ボリューム SnapMirror 関係である場合、ソース・ストレージ・システムの Data ONTAP のバージョンは宛先ストレージ・システムのバージョンと同じリリースまたはそれ以降のリリースでなければなりません。例えば、次の表で説明するカスケード構成の場合、同期 SnapMirror 関係のソースと宛先の両方のストレージ・システムが Data ONTAP 7.2.1 を実行する必要があります。



ストレージ・システム C からストレージ・システム D



カスケード・セットアップの例

上図に示す一連のカスケード・ボリューム宛先をサポートするために、カスケード内の各システムの /etc/snapmirror.conf ファイルの項目は次のような項目となっている必要があります。systemA:vol1 systemB:vol1 - 15 * * 1,2,3,4,5

systemA:vol1 systemL:vol1 - 15 * * 1,2,3,4,5 systemB:vol1 systemC:vol1 - 25

* * 1,2,3,4,5 systemC:vol1 systemD:vol1 - 35 * * 1,2,3,4,5 systemL:vol1

systemM:vol1 - 25 * * 1,2,3,4,5 systemM:vol1 systemX:vol1 - 35 * *

1,2,3,4,5 systemM:vol1:systemN:vol1 - 35 * * 1,2,3,4,5 systemX:vol1

systemY:vol1 - 45 * * 1,2,3,4,5 systemX:vol1 systemZ:vol1 - 45 * *

1,2,3,4,5

注: snapmirror.conf ファイルで宛先の更新スケジュールを指定する場合、同時に複数の宛先の更新を開始するのではなく、更新の時間をずらしてください。SnapMirror にスケジュールされたすべての宛先の更新を実行するために十分なリソースがない場合、いくつかの更新が延期されます。その結果、SnapMirror は、snapmirror.conf ファイルで指定されたのとは異なる時間に後続の更新を実行しなければならない可能性があります。

図 11. カスケード構成のストレージ・システム間でのデータのコピー


カスケード宛先を使用する場合に SnapMirror が Snapshot コピーを処理する方法SnapMirrorは、後続の一連の宛先に転送するために必要な Snapshot コピーを、オリジナルのソース・ボリューム上で保持します。宛先がまだ必要としている Snapshot

コピーは、snap list コマンドの出力内では「snapmirror」というラベルによって示されます。SnapMirror は、不要になった Snapshot コピーを削除します。

カスケードから宛先を除去した場合は、snapmirror release コマンドを直近のソースから使用して、その宛先に関連した Snapshot コピーを削除するように SnapMirror

に指示します。

カスケード・シリーズ内のボリュームの SnapMirror 宛先のリストsnapmirror destinations コマンドを使用して、カスケード・シリーズ内のボリュームの宛先を表示することができます。


ソース・ボリュームの SnapMirror 宛先を表示するには、次のステップを実行します。

ソースの役割を果たすボリュームが置かれているシステムから、次のコマンドを入力します。snapmirror destinations [-s] [volume_name] -s オプションは、宛先ごとに保持されている Snapshot コピーの名前のリストを生成します。volume_name は、宛先を表示するソース・ボリュームの名前です。次の図に示すカスケード構成に対して snapmirror destinations コマンドを使用したとします。

このようなカスケード構成に対する snapmirror destinations コマンドの出力は、次の出力のようになります。

systemA> snapmirror destinations vol1Path Destination/vol/vol1 systemB:vol1->systemC:vol1->systemD:vol8/vol/vol1 systemL:vol1->systemM:vol1->systemX:vol1->systemY:vol1/vol/vol1 systemL:vol1->systemM:vol1->systemX:vol1->systemZ:vol1/vol/vol1 systemL:vol1->systemM:vol1->systemN:vol1

図 12. カスケード構成のストレージ・システム間でのデータのコピー


注: コマンドでボリューム名を指定しない場合、出力に、ストレージ・システム上のそれぞれの宛先ボリュームに関する情報が表示されます。

カスケードの再構築システムの負荷のバランスを取るため、ストレージ・システムまたはボリュームを別の目的で使用するため、あるいはアップグレード、保守、または修復を行うためにカスケードを再構築することがあります。


例えば、次のカスケード構造で systemD:vol1 を systemC:vol1 の宛先ではなくsystemM:vol1 の宛先にする場合があります。

1. 宛先システムで、宛先に対する新しいソースを指定するために/etc/snapmirror.conf ファイルを変更します。 systemM:vol1 systemD:vol1 -

35 * * 1,2,3,4,5

2.

状況処置

宛先の最新の Snapshot コピーがソースに存在する。

次のコマンドを使用して、新しいソースから宛先を更新します。snapmirror update -S

source_volume dest_system:dest_volume

例: snapmirror update -S systemM:vol1

systemD:vol1

宛先の最新の Snapshot コピーがソースに存在しない。

以下のいずれかのタスクを実行します。

v snapmirror update コマンドを使用して、元のソースから新しいソースを更新します。宛先が更新されるまで待ちます。

v snapmirror break コマンドを使用して、宛先を書き込み可能にします。次に、snapmirror resync コマンドを使用して、宛先と新しいソースと再同期します。

図 13. カスケード内の宛先の関係の再構築


3. 次のコマンドを使用して、以前のソースを解放します。snapmirror release

source_volume [[dest_system:]dest_volume]

systemC> snapmirror release systemC:vol1 systemD:vol1

カスケード・シリーズからの宛先の切断

上図で示した構成で、systemB から次のコマンドを入力するとします。snapmirror

release vol1 systemC:vol1

以下の結果になります。

v systemA:vol1 は、引き続き宛先の systemB:vol1 のソースになります。

v systemC:vol1 は、systemB:vol1 からコピーしなくなります。SnapMirror は、systemC 以下の Snapshot コピーを保持します。

v systemC が systemB からの更新を要求すると、宛先がまだ書き込み可能でなく、基本 Snapshot コピーがまだソースに存在する場合は、宛先が再設定されます。

v systemD:vol1 は、引き続き systemC:vol1 からコピーします。

v systemL:vol1 に依存するすべての宛先は、以前と同じように機能します。

次のように、systemA で snapmirror destinations コマンドを実行することによって、宛先が解放されたかどうか確認することができます。

systemA> snapmirror destinations -s systemA:vol1

Volume Snapshot Destinationvol1 systemB(0015269532)_vol1.37 systemB:vol1vol1 systemL(0015269532)_vol1.42 systemL:vol1->systemM:vol1->systemXvol1->systemY:vol1vol1 systemL(0015269532)_vol1.42 systemL:vol1->systemM:vol1->systemXvol1->systemZ:vol1vol1 systemL(0015269532)_vol1.42 systemL:vol1->systemM:vol1->systemN:vol1

注: 宛先を永続的に解放する場合、/etc/snapmirror.conf ファイルの項目を削除するか、項目の前にポンド記号 (#) を付けて項目をコメント化する必要があります。そうでないと、SnapMirror は引き続き宛先を更新しようとします。

図 14. カスケード内の宛先の切断


SnapMirror ソースからテープ、テープから宛先へのシナリオこのシナリオでは、低帯域幅接続を介したソース・システムと宛先システムの間のSnapMirror 関係を確立します。低帯域幅接続を介したソースから宛先へのインクリメンタル Snapshot ミラーリングは実現可能ですが、初回の基本 Snapshot ミラーリングは不可能です。

そのような場合、最初にテープを使用して初回の基本 Snapshot イメージをソースから宛先に転送してから、低帯域幅接続を介して宛先システムへのインクリメンタルSnapMirror 更新をセットアップした方が高速であることがあります。

このシナリオでは、次の構成を使用します。

v ソース・システムと宛先システムの間の低帯域幅接続

v ソース・システムに接続されたローカル磁気テープ・ドライブ

v 宛先システムに接続されたローカル磁気テープ・ドライブ

注: テープからストレージ・システムへの転送時間の延長を防止するために、宛先システムのディスクのサイズおよび RAID 構成がソース・システムのディスクと同じであることを確認してください。

この配置をセットアップするには、次の一連のアクティビティーに従う必要があります。

1. ソース・システムで、snapmirror store コマンドを使用して基本 Snapshot コピーを含むすべてのボリューム Snapshot コピーをテープにコピーし、複数のバックアップ・テープが必要な場合は snapmirror use コマンドを使用してコピーを続行します。

2. バックアップ・テープを物理的にソース・システムから宛先システムに移送します。

3. 宛先システムで、vol create および vol restrict コマンドを使用して SnapMirror

ターゲット・ボリュームをセットアップします。

4. snapmirror retrieve コマンドを使用して最初の SnapMirror テープを宛先システムにコピーし、複数のバックアップ・テープに保管するために必要な場合はsnapmirror use コマンドを使用してコピーを続行します。

次に、snapmirror update コマンドを使用して手動で低帯域幅接続を介してソース・システムから宛先システムにインクリメンタル更新をミラーリングするか、snapmirror.conf ファイルを編集してソース・システムから宛先システムへのインクリメンタル更新スケジュールをセットアップします。

5. 接続を介した手動またはスケジュールに基づくインクリメンタル更新を完了した後、snapmirror release コマンドを使用してソースからテープへの関係および関連する Snapshot コピーを除去することができます。


関連タスク


123ページの『SnapMirror ソースからテープの関係の解放』接続を介して宛先システムを正常に更新した後、snapmirror store コマンドによって確立したソースからテープの SnapMirror 関係および関連する Snapshot コピーは不要になります。

ソースの中間テープへのコピーSnapMirror 関係の初期ベースライン転送では、テープを使用して転送する場合があります。そのためには、最初に基本データをテープにコピーする必要があります。

1. ソース・ボリュームと最終的な宛先ボリュームのディスク・ジオメトリー (つまり、ディスクのサイズと数) が一致するかどうか不明な場合、snapmirror retrieve

-g コマンドを使用して判別します。ソースと宛先の両方のストレージ・システム・コンソールで、次のコマンドを入力します。snapmirror retrieve -g

vol_name

ソース・ボリュームと宛先ボリュームの両方について、システムは、含まれているディスクの数とブロック・サイズを表示します。戻り値 7200000x10 7000x10

は、指定されたボリュームが 720,000 ブロックのディスク 10 個と 7,000 ブロックのディスク 10 個で構成されていることを意味します。

v 最も望ましい結果は、ソースと宛先のボリュームでディスク・ジオメトリーが一致することです。

v 形状が一致しない場合、宛先ボリュームのディスク・ジオメトリーを後で使用するために記録します。

2. ソース・システムで、テープをローカル接続された磁気テープ装置にロードします。

3. ソース・システムで、次のコマンドを入力してデータ転送を開始します。snapmirror store [-g dest_disk_geom] source_volume dest_tapedevices -g

dest_disk_geom は、ステップ 1 で判別した宛先ボリュームのディスク・ジオメトリーがソース・ボリュームのディスク・ジオメトリーと異なる場合に適用されます。異なる場合は、-g パラメーターを使用して宛先ボリュームのディスク・ジオメトリーを指定します。 -g 140000x10,7000x10 source_volume は、コピーするボリュームです。

dest_tapedevices は、ボリュームのコピー先とする磁気テープ装置のコンマ区切りリストです。 snapmirror store -g 14000x10,7000X10 vol2 nrst0a,rst1a

SnapMirror は、テープへのデータ転送を開始します。このコマンドにより、ベースライン転送が作成されます。複数のテープを使用する必要がある場合、SnapMirror は、別のテープを求めるプロンプトを表示します。

4. SnapMirror が別のテープを求めるプロンプトを表示する場合、別のテープをドライブに追加してから、次のコマンドを入力してテープへのデータ転送を続行します。snapmirror use dest_tapedevices tape_drive dest_tapedevices は、ボリュームのコピー先とする磁気テープ装置または磁気テープ装置のコンマ区切りリストです。


tape_drive は、準備した新しいテープを保持しているドライブです。

注: snapmirror use コマンドは、テープからの qtree のコピーをサポートしません。qtree パスをソースまたは宛先として指定すると、SnapMirrorはエラー・メッセージを返します。

5. SnapMirror がボリュームのテープへのコピーを終了するまで、上記のステップを繰り返します。

関連概念



関連タスク

『ローカル・テープを使用する SnapMirror 宛先の初期化』SnapMirror 関係の初期ベースライン転送では、テープを使用して転送する場合があります。基本データをテープにコピーした後、データをテープから目的の宛先にコピーして宛先を初期化する必要があります。

ローカル・テープを使用する SnapMirror 宛先の初期化SnapMirror 関係の初期ベースライン転送では、テープを使用して転送する場合があります。基本データをテープにコピーした後、データをテープから目的の宛先にコピーして宛先を初期化する必要があります。

1. SnapMirror 宛先システムでボリュームを作成します。ボリュームの作成方法については、「System Administration Storage Management Guide」を参照してください。

2. ボリュームを制限状態にします。ボリュームを制限する方法については、「System Administration Storage Management Guide」を参照してください。

3. (snapmirror store によって作成された) テープを宛先システムのローカル磁気テープ装置にロードします。

4. 宛先システムで次のコマンドを入力して、初期化を開始します。snapmirror

retrieve dest_volume tape_drive dest_volume は、初期化するボリュームです。

tape_drive は、ボリュームの復元元のテープ装置または装置のコンマ区切りリストです。 SnapMirror は、テープからのデータ転送を開始します。データが複数のテープに保管されている場合、SnapMirror は、次のテープを求めるプロンプトを表示します。

5. Data ONTAP が別のテープを求めるプロンプトを表示したら、次のテープをドライブに追加してから、次のコマンドを入力して初期化を再開します。snapmirror

use volume tape_list volume は、復元先のボリュームです。

tape_list は、ボリュームの復元元のテープ装置です。


6. SnapMirror がテープからのボリュームの初期化を終了するまで、上記のステップを繰り返します。

7. 必要な場合、次のコマンドを使用して手動でデータをオンラインで更新することができます。snapmirror update [-k n] -S source_system:source_volume

[dest_system:]dest_volume -k n は、最大転送速度を毎秒 n キロバイトに設定します。このオプションは、 /etc/snapmirror.conf ファイルの kbs 引数と同じ効果があります。

-S source_system:source_volume は、マイグレーションするソース・システムおよびボリュームを指定します。source_volume は、コピーするボリュームです。

dest_system は、宛先システムの名前です。

dest_volume は、宛先ボリュームです。

注: あるいは、/etc/snapmirror.conf ファイルで設定したスケジュールによって、ベースライン転送を自動的に更新することができます。

関連概念

140ページの『SnapMirror 宛先の手動更新』通常、SnapMirror は /etc/snapmirror.conf ファイルに指定した更新スケジュールに従って宛先を自動的に更新します。ただし、snapmirror update コマンドを使用して更新を手動で開始することもできます。




関連タスク

133ページの『snapmirror.conf ファイルの編集』SnapMirror が使用可能になっている場合、/etc/snapmirror.conf ファイルに対する変更は 2 分以内で有効になります。SnapMirror が使用可能になっていない場合、/etc/snapmirror.conf ファイルに対する変更は、snapmirror on コマンドを使用して SnapMirror を使用可能にした直後に有効になります。

SnapMirror ソースからテープの関係の解放接続を介して宛先システムを正常に更新した後、snapmirror store コマンドによって確立したソースからテープの SnapMirror 関係および関連する Snapshot コピーは不要になります。

1. ソース・システム・コンソールで、次のコマンドを入力します。snapmirror

status システムは、少なくとも 2 つの SnapMirror 関係を表示します。


v snapmirror store コマンドを使用したときに確立されたソースからテープの関係

v snapmirror update コマンドを使用したときに確立されたソースから宛先の関係

>snapmirror status....source destination state ....s_system:vol1 snapmirror_tape_01_15_03_20:05:32 ...s_system:vol1 d_system:vol1 snapmirrored ...

2. ソースからテープの SnapMirror 関係を解放します。 snapmirror release 構文は、この特定の操作に固有のものとなっています。snapmirror release

source_vol tape_snapshot_name

snapmirror release vol1 snapmirror_tape_01_15_03_20:05:32

注: その他の SnapMirror 関係を解放しないでください。それらの関係は、低帯域幅接続を介したインクリメンタル更新を続行するために必要です。

SnapMirror の管理

FlexVol ボリュームの再同期ソースに複製する必要がある宛先ストレージ・システムに何らかの変更がある場合は、qtree SnapMirror を使用してデータを再同期させることができます。

snapmirror resync コマンドを使用して、ソースのデータを宛先で行われた変更と再同期させることができます。データの再同期の際に、ボリューム SnapMirror の場合は、Data ONTAP のバージョンに関する制約事項が適用されます。

関連概念

179ページの『ボリューム SnapMirror と qtree SnapMirror の比較』SnapMirror 複製は、ボリューム全体、またはボリューム上の個々の qtree を対象に構成できます。これら 2 つのオプションの相違点を考慮する必要があります。

SnapMirror 管理コマンドおよび構成ファイルSnapMirror 複製を管理するためのコマンドおよび構成ファイルがいくつかあります。


snapmirror update 宛先の手動 (スケジュール外) の更新を実行します。

snapmirror status SnapMirror データ転送の状況を表示します。

/etc/log/snapmirror SnapMirror データ転送履歴を表示します。

snapmirror abort 進行中の転送を停止します。

/etc/snapmirror.conf 1 つ以上のボリュームまたは qtree のスケジュール更新を指定または変更できるようにします。


関連概念


153ページの『SnapMirror データ転送ログ』options snapmirror.log.enable コマンドを使用して、SnapMirror データ転送ログを検査できます。転送が計画どおりに行われているかどうか、転送にどれだけ時間がかかっているか、およびシステム・セットアップがどれだけ適切に機能しているかを調べることができます。この情報は、SnapMirror ログ・ファイル内にあります。

157ページの『ボリュームまたは qtree のスケジュールに基づく更新』宛先を更新する必要がないと判断した場合は、宛先の etc/snapmirror.conf ファイルを編集して、特定のボリュームまたは qtree のスケジュールに基づく更新を変更するかオフにすることができます。

関連タスク

140ページの『手動による SnapMirror 更新の実行』/etc/snapmirror.conf ファイルのスケジュールとは関係なく、スケジュール外のSnapMirror インクリメンタル更新を実行するには、次のステップを実行します。

145ページの『SnapMirror データ転送状況の検査』snapmirror status コマンドを使用してデータ転送状況を確認し、ストレージ・システムにあるすべての既存の SnapMirror 関係の状況を判別する必要があります。

153ページの『SnapMirror データ転送状況の検査』SnapMirror ロギングは、デフォルトでオンに設定されています。ただし、SnapMirror ロギングがオンまたはオフのどちらになっているか調べる必要がある場合は、次の手順で行います。

153ページの『SnapMirror ロギングをオンにする』SnapMirror は、既存システムのルート・ボリューム上の現在のログを/etc/log/snapmirror.0 として保持します。毎週、新しいログ・ファイルが/etc/log/snapmirror.0 として生成されます。古いログ・ファイルは/etc/log/snapmirror.[1-5] に名前変更され、最も古いログ・ファイルは削除されます。テキスト・エディターを使用してログ・ファイルを読み取ることができます。

155ページの『SnapMirror 転送の中止』snapmirror abort コマンドを使用して、ソースが宛先へのデータ転送を終了する前にボリュームまたは qtree コピー操作を中止することができます。転送は、スケジュール更新、手動更新、または初期化の結果として行われます。

158ページの『1 つのボリュームまたは qtree に対するスケジュール更新の変更』1 つのボリュームまたは qtree に対するスケジュール更新を変更するには、次のステップを実行します。

158ページの『1 つのボリュームまたは qtree のスケジュール更新をオフにする』1 つのボリュームまたは qtree のスケジュール更新をオフにするには、以下のステップを実行します。

159ページの『SnapMirror 更新をオフにする』snapmirror off コマンドを使用すると、コピーが進行中でも随時、ストレージ・システム全体のスケジュール更新と手動更新の両方をオフにすることができます。スト


レージ・システムで SnapMirror をオフにすると、すべてのアクティブな転送が中止されます。更新をオフにした後、宛先は未変更のまま残されます。

関連資料

145ページの『SnapMirror 状況検査の表示内容』状況を確認して SnapMirrorを使用可能にすると、次の形式のメッセージが表示されます。

148ページの『SnapMirror 状況検査の情報メッセージ』snapmiror status コマンドが表示する可能性がある情報メッセージは次のとおりです。

154ページの『SnapMirror ログ・ファイルのフォーマット』ログ・ファイルは次のフォーマットになっています。

SnapMirror シャットダウン・コマンド以下のコマンドを使用して、ストレージ・システム、ボリューム、または qtree のSnapMirror プロセスを一時的または永続的にシャットダウンすることができます。

コマンド機能

snapmirror off

または options snapmirror.enable off

指定されたシステムの SnapMirror 機能をオフにします。

snapmirror break 宛先を書き込み可能なボリュームまたはqtree に変換して、ソースと宛先の間のSnapMirror 関係を分断します。

snapmirror release 以前のソース・ボリュームまたは qtree のSnapMirror Snapshot コピーを削除するために解放します。


関連概念

157ページの『ボリュームまたは qtree のスケジュールに基づく更新』宛先を更新する必要がないと判断した場合は、宛先の etc/snapmirror.conf ファイルを編集して、特定のボリュームまたは qtree のスケジュールに基づく更新を変更するかオフにすることができます。


関連タスク

158ページの『1 つのボリュームまたは qtree に対するスケジュール更新の変更』1 つのボリュームまたは qtree に対するスケジュール更新を変更するには、次のステップを実行します。

158ページの『1 つのボリュームまたは qtree のスケジュール更新をオフにする』1 つのボリュームまたは qtree のスケジュール更新をオフにするには、以下のステップを実行します。

159ページの『SnapMirror 更新をオフにする』snapmirror off コマンドを使用すると、コピーが進行中でも随時、ストレージ・システム全体のスケジュール更新と手動更新の両方をオフにすることができます。ストレージ・システムで SnapMirror をオフにすると、すべてのアクティブな転送が中止されます。更新をオフにした後、宛先は未変更のまま残されます。

163ページの『SnapMirror 宛先の書き込み可能なボリュームまたは qtree への変換』SnapMirror 宛先を書き込み可能なボリュームまたは qtree に変換するには、以下のステップを実行します。


関連資料

163ページの『割り当て量の制限』割り当て量は、ソース・ボリュームで割り当て量が使用可能になっているかどうかに関係なく、SnapMirror ボリューム宛先で常に使用不可になっています。ボリューム宛先で割り当て量を使用可能にしようとすると、SnapMirror はエラー・メッセージを表示します。割り当て量は、SnapMirror 宛先 qtree では使用不可になりません。

164ページの『snapmirror break コマンドの使用後』snapmirror break コマンドを使用してソースと宛先の間の SnapMirror 関係を一時的に分断した後、他の SnapMirror コマンドを使用して、SnapMirror 関係を永続的に分断したり、復元または再定義することができます。

SnapMirror の拡張機能コマンドおよび構成ファイル下記のコマンドを使用して、SnapMirror で拡張機能を実行できます。



snapmirror quiesce 進行中のデータ転送を終了して、一時的に新しい転送の開始を防止することにより、宛先の内容を Snapshot コピーの直前の状態に固定します。このアクションにより、安定したデータベースの手動 Snapshot コピーが確保されます。

snapmirror resume 宛先への通常のデータ転送を静止後に再開します。

snapmirror resync snapmirror break コマンドの後にソースと以前の宛先ボリュームまたは qtree の間のSnapMirror 関係を SnapMirror 関係に再確立して、初期転送を繰り返すことなく、その内容をソースと再同期します。

/etc/snapmirror.conf ファイル snapmirror

initialize snapmirror destinations

これらのコマンドは、SnapMirror 宛先のカスケード・シリーズをセットアップします。ネットワーク全体のさまざまな場所から一様なデータのセットをユーザーに読み取り専用で提供し、そのデータを定期的な間隔で均一に更新します。

snapmirror store

およびsnapmirror use

これらのコマンドは、ボリュームをローカル・テープにコピーして、必要に応じて後続のテープでバックアップを続行します。

snapmirror retrieve

およびsnapmirror use

これらのコマンドは、ローカル・テープからボリュームを初期化または復元します。


関連概念

157ページの『quiesce コマンドが行う処理』snapmirror quiesce コマンドは、すべてのボリュームと qtree の SnapMirror 転送が完了するまで待ち、以降の更新をブロックします。qtree が安定状態にない (遷移中)

場合、snapmirror quiesce コマンドは qtree を強制的に安定状態にします。

167ページの『snapmirror resync コマンドが行う処理』snapmirror break コマンドの後、snapmirror resync コマンドをオリジナルのSnapMirror 宛先またはオリジナル・ソースに適用します。

169ページの『snapmirror resync コマンドがデータ損失を最小限にする方法』snapmirror resync コマンドを使用すれば、長時間かかるベースライン転送を行わずに、分断した SnapMirror 関係を再確立できます。



176ページの『SnapMirror を使用したテープへのボリュームのコピー』さまざまな理由で、SnapMirror を使用して、ソース・ストレージ・システムからローカル・テープにボリュームをコピーする場合があります。

関連タスク

156ページの『Snapshot コピー前の宛先の安定化』一時的に宛先への転送を停止することが必要な場合があります。例えば、データベースを含む SnapMirror 宛先ボリュームまたは qtree の Snapshot コピーを作成する場合、その内容が Snapshot コピー中に安定していることを確認する必要があります。

157ページの『宛先を静止した後の転送の再開』snapmirror resume コマンドを使用して、静止したボリュームまたは qtree へのデータ転送機能を復元することができます。

167ページの『SnapMirror 関係の再同期』snapmirror resync コマンドを使用して、snapmirror break コマンドによって分断された SnapMirror のソースまたは宛先の関係を復元または再定義することができます。

117ページの『カスケード・シリーズ内のボリュームの SnapMirror 宛先のリスト』snapmirror destinations コマンドを使用して、カスケード・シリーズ内のボリュームの宛先を表示することができます。

118ページの『カスケードの再構築』システムの負荷のバランスを取るため、ストレージ・システムまたはボリュームを別の目的で使用するため、あるいはアップグレード、保守、または修復を行うためにカスケードを再構築することがあります。


関連資料

116ページの『カスケード・セットアップの例』

177ページの『バックアップ方式としてテープへの SnapMirror コピーを使用する前


の考慮事項』データをローカル・テープにコピーするための SnapMirror 複製は、SnapMirror 関係の初期化プロセス用であり、バックアップ方式として使用する場合は制約事項があります。バックアップ方式としてテープへの SnapMirror を使用する前に、以下の制約事項について考慮してください。

非同期 SnapMirror 複製の同期への変換SnapMirror 関係について、以前に非同期複製を指定している場合があります。ただし、必要な場合は、関係を変更してデータを同期的に複製することができます。


ボリューム SnapMirror関係のみを同期 SnapMirror 関係に変換することができます。

非同期 SnapMirror 関係を同期 SnapMirror 関係に変換するには、管理ホストで、宛先システム上の snapmirror.conf ファイルを編集してスケジュールを sync に変更します。

ソースで宛先ストレージ・システムを指定する方法ソース・ストレージ・システムで宛先ストレージ・システムを指定するには 2 つの方法があります。

snapmirror.access オプションを使用する宛先の指定snapmirror.access オプションを使用して、ソース・ストレージ・システムへのアクセスを許可される宛先ストレージ・システムを指定できます。このオプションは、転送を開始できる SnapMirror 宛先ストレージ・システムおよびそれらが使用できるネットワーク・インターフェースを指定します。これは、SnapMirror ソース・ストレージ・システムへの SnapMirror のアクセスを制御するための推奨される方法です。

snapmirror.access オプションを使用して SnapMirror ソースへのアクセスを許可される SnapMirror 宛先を指定するには、ソース・ストレージ・システムで次のコマンドを入力します。options snapmirror.access access_specification サーバーへのアクセスを許可されるストレージ・システムを指定するための構文は、SNMP、Telnet、および rsh で同じで、na_protocolaccess(8) マニュアル・ページに記載されています。options コマンドについて詳しくは、na_options(1) マニュアル・ページを参照してください。

注: このオプションは、再起動しても持続します。

例

SnapMirror 関係の宛先 (systemB) にソース (systemA) へのアクセス権を付与して、systemA から systemB にデータをコピーするには、systemA でプロンプトが表示されたら次のように入力します。

systemA> options snapmirror.access host=systemA,systemB


snapmirror.allow ファイルを使用する宛先の指定snapmirror.allow ファイルをソース・システムの /etc/ ディレクトリーに作成できます。 /etc/snapmirror.allow ファイル内に項目を作成して、ソース・システムから直接データをコピーすることが許可される宛先ストレージ・システムを指定できます。snapmirror.access オプションが legacy (デフォルト設定) に設定されている場合、snapmirror.allow ファイルはアクセス許可を定義します。

1. /etc/snapmirror.allow ファイルを使用して SnapMirror ソースへのアクセスを許可された SnapMirror 宛先を指定するには、テキスト・エディターを使用して、ソース・システムのルート・ボリュームの /etc/ ディレクトリーにsnapmirror.allow ファイルを作成します。

注: ファイルが以前に作成されている場合があります。その場合は、ファイル内の項目の変更に進むことができます。

2. /etc/snapmirror.allow ファイルに、アクセスを許可される各ストレージ・システムの名前をそれぞれ別々の行で追加します。

注: ローカル・システムの名前を追加する必要はありません。

3. ファイルの編集内容を保存します。

例

SnapMirror がローカルの systemA と、systemB および systemC という名前の他のシステムでデータをコピーするようにするには、systemA の /etc/

snapmirror.allow ファイルに次の項目を追加します。

systemB

systemC

注: /etc/snapmirror.allow ファイル内の項目は、大/小文字が区別されます。宛先システムで hostname コマンドを使用して、/etc/snapmirror.allow ファイルの正確な項目を検索することができます。

ホスト名の IP アドレスへの解決デフォルトで、SnapMirror フィーチャーは、/etc/snapmirror.allow ファイル内のホスト名を宛先ストレージ・システムから送信されたホスト名と対照して検査します。あるいは、SnapMirror が /etc/snapmirror.allow ファイル内のホスト名を IP

アドレスに解決して、それらを宛先ストレージ・システムの IP アドレスと比較するように設定できます。

始める前に

/etc/snapmirror.allow ファイル項目は、宛先システム上の発信ネットワーク・インターフェースの IP アドレスにマップされる必要があります。例えば、要求がsystemA-e10 というギガビット・イーサネット・インターフェース e10 の IP アドレスから到着する場合、名前が正しい IP アドレスに解決されるように、/etc/snapmirror.allow ファイルに「systemA-e10」または「systemA-e10.

acme.com」が含まれている必要があります。



snapmirror.checkip.enable オプションは、ホスト名が検査される方法を制御します。このオプションがデフォルトのオフである場合、/etc/snapmirror.allow ファイル内の項目は hostname コマンドによって報告される宛先システムのホスト名と一致する必要があります。オプションがオンである場合、ソース・システムはsnapmirror.allow ファイル内の名前を IP アドレスに解決してから、要求元の宛先システムの IP アドレスと一致するかどうか検査します。このモードでは、リテラル IP アドレス (例えば、123.45.67.89) および完全修飾名 (例えば、systemA.acme.com) が /etc/snapmirror.allow ファイル内の有効な項目になります。

同じストレージ・システム上の 2 つのボリューム間のローカル SnapMirror 関係には、/etc/snapmirror.allow ファイル内の項目は必要ありません。SnapMirror がホスト名を IP アドレスに解決するように構成するには、次のステップを実行します。

ソース・ストレージ・システムで次のコマンドを入力します。options

snapmirror.checkip.enable on

snapmirror.conf ファイルの定義する内容snapmirror.conf ファイルは、SnapMirror を使用して、ソースから宛先にデータをコピーする処理に関連した詳細を指定するために使用されます。このファイルは、宛先ストレージ・システムにあります。

/etc/snapmirror.conf ファイルは、次の内容を定義します。

v ソースと宛先の関係

v データをコピーするために宛先によって使用されるスケジュール

v データをコピーする際に SnapMirror を制御する引数

snapmirror.conf ファイルの配布サイト用に単一の snapmirror.conf ファイルを作成し、SnapMirror を使用するすべてのストレージ・システムにコピーできます。snapmirror.conf ファイルには、他のストレージ・システムに関係する項目を含めることができます。

例えば、システム B の /etc/snapmirror.conf ファイルには、システム C からシステム D にボリュームをコピーするための項目を含めることができます。システムB が /etc/snapmirror.conf ファイルを読み取る際に、他のストレージ・システムに関する項目は無視されます。

注: ファイルが読み取られるたびに、無視された行ごとに警告メッセージがストレージ・システム・コンソールに表示されます。

各ストレージ・システムの snapmirror.conf ファイルの項目に対する制約事項/etc/snapmirror.conf ファイル内の各ストレージ・システム用の項目の数に対する制限は 1,024 です。この制限を超える項目は無視され、ストレージ・システム・コンソールに警告メッセージが表示されます。


アクティブ/アクティブ構成の場合、項目の数に対する制限はストレージ・システム・ペアの組み合わせに適用されます。項目に対する制限は、アクティブ/アクティブ構成の 2 つのストレージ・システムで共有されます。例えば、アクティブ/アクティブ構成で、1 つのストレージ・システムが 480 の項目を使用している場合、もう1 つのストレージ・システムは 544 の項目を使用できます。

注: この制限は、ストレージ・システムで実行できる同時複製の最大数とは異なります。

関連資料



snapmirror.conf ファイルの編集SnapMirror が使用可能になっている場合、/etc/snapmirror.conf ファイルに対する変更は 2 分以内で有効になります。SnapMirror が使用可能になっていない場合、/etc/snapmirror.conf ファイルに対する変更は、snapmirror on コマンドを使用して SnapMirror を使用可能にした直後に有効になります。


snapmirror.conf ファイルを編集するのは、変更するソースと宛先の関係でアクティブな SnapMirror 転送が行われていないときにしてください。

注: 特定のソースと宛先の関係で 1 つより多くのアクティブな SnapMirror 転送が行われているときに snapmirror.conf ファイル項目のホスト名を変更すると、1 つ以上の転送が中断される可能性があります。

1. /etc/snapmirror.conf ファイルにコメントを追加するには、コメントの前にポンド記号 (#) を付けます。

注: まだ存在しない場合は、テキスト・エディターを使用して、snapmirror.conf というファイルを、宛先ストレージ・システム上のルート・ボリュームの /etc ディレクトリーに作成します。# Replicating from systemA

2. このストレージ・システムに配置する宛先ボリュームまたは qtree ごとに、次の構文を使用してデータ転送のソース、宛先、特性、およびスケジュールを指定する項目を 1 行で入力します。source_system:{source_volume |

/vol/volume_name/qtree_name} dest_system:{dest_volume |

/vol/volume_name/qtree_name} arguments schedule

注: qtree をソースとして使用する場合、宛先として機能する別の qtree を作成しません。SnapMirror が、ユーザーの代わりにユーザーが指定した名前を使用して作成します。ただし、/etc/snapmirror.conf ファイルまたは snapmirror

initialize コマンドのいずれかで、配置するボリュームの qtree 宛先の名前を指定する必要があります。


注: /etc/snapmirror.conf ファイル項目で 1 つのボリュームに対して 254 を超える宛先 qtree を指定しないでください。

ボリューム内のすべての非 qtree データを 1 つの qtree に結合して SnapMirror

ソースとして使用する場合は、次の構文を使用します。source_system:/vol/

source_volume/- dest_system:/vol/dest_volume/qtree_name

ハイフン (-) 文字は、指定されたボリューム内のすべての非 qtree データを示します。

注: /vol/source_volume/- qtree のデータは、SnapMirror ソースのみにすることができ、宛先にすることはできません。つまり、/- qtree を作成した後、命名する別の qtree にデータをコピーすることはできますが、別の qtree からデータをコピーすることはできません。

3. ファイルの編集内容を保存します。

関連資料

『snapmirror.conf ファイル項目の構文』snapmirror.conf ファイルの項目の構文は次のとおりです。

snapmirror.conf ファイル項目の構文snapmirror.conf ファイルの項目の構文は次のとおりです。

src_system:/vol/src_vol[/src_qtree] dest_system:/vol/dest_vol[/dest_qtree]

[arguments] [sched]

次の表に、項目のパラメーターを示します。

パラメーター説明

src_system データのコピー元のストレージ・システムの名前。SnapMirror は、DNS および NIS によって使用される /etc/hosts ファイルまたはデータベースをネーム解決のために使用します。SnapMirror がソース・ストレージ・システム名を検索する場合、転送で使用するネットワーク上のソース・ストレージ・システムの IP アドレスが見つかる必要があります。

例: ソース・ストレージ・システムと宛先ストレージ・システムを接続するプライベート・ネットワークを作成して、ソース・ストレージ・システムのインターフェースにsystemA-e0 という名前を付けたとします。インターフェース名 systemA-e0 は、src_system

フィールドに入力します。



src_vol/src_qtree コピーしているボリュームまたは qtree の名前。ボリュームの場合、ボリューム名のみを使用します。qtree の場合は絶対パス名を使用します。

例: ボリュームの名前が vol1 である場合、vol1 を src_vol/src_qtree フィールドに入力します。 qtree の名前が qtree3 で、ボリューム vol3 に含まれている場合、絶対パス/vol/vol3/qtree3 を src_vol/src_qtree フィールドに入力します。

dest_system データのコピー先となるシステムのホスト名。使用する名前は、宛先システムの正確なホスト名でなければなりません。 dest_system

フィールドは、大/小文字が区別されます。

宛先システムで hostname コマンドを使用して、このフィールドに入力する名前を判別できます。

例: 宛先システムの名前が systemA である場合、systemA を dest_system フィールドに入力します。

dest_vol [/dest_qtree] データのコピー先となる宛先ボリュームまたは qtree の名前。ボリュームの場合、ボリューム名のみを使用します。qtree の場合は絶対パス名を使用します。

例: ボリュームの名前が vol1 である場合、vol1 を dest_vol[/dest_qtree] フィールドに入力します。qtree の名前が qtree4 で、vol2 にある場合、絶対パス /vol/vol2/qtree4 をdest_vol[/dest_qtree] フィールドに入力します。

kbs=kbs Data ONTAP がデータ転送で使用できる最大転送速度 (キロバイト/秒)。

kbs および restart 引数は、name=value ペアのスペースのないコンマ区切りリストとして表現します。例: kbs=2000,restart=always



restart={ never | always | default } SnapMirror がインクリメンタル転送を中断された場合にチェックポイントから続行するために使用する再開モード。3 つのオプションがあります。

v never ― 転送は、常に転送の最初から再開され、中断される前の時点から再開されません。このモードは、宛先で最新データが必要な場合に役立ちます。

v always ― 転送は、可能な場合は常に中断される前の時点から再開されます。このモードは、大容量ボリュームのコピーに役立ちます。

v default ― 転送は、スケジュール転送と競合しない場合に再開されます。これは推奨されるオプションです。

SnapMirror は、常に中断前の転送の時点から再開します。ただし、スケジュール転送の後で再開する場合は再開しません。スケジュール転送の方が、再開される転送よりも最新のデータを転送するためです。

cksum= { none | crc32c } SnapMirror の送信データを保護するために使用されるチェックサム・アルゴリズムを選択します。

visibility_interval={xs | xm | xh} 同期または半同期 SnapMirrorを使用して複製されているソース・ボリュームで自動Snapshot コピーが作成されるまでの時間を判別します。SnapMirror を使用して同期的または半同期的に複製する場合、ソース・ボリュームに対する変更は、変更が複製されても宛先ボリュームで即時に表示されません。ソース・システムがソース・ボリュームの自動Snapshot コピーを作成して初めて、変更は表示されます。これは、デフォルトで 3 分ごとに行われます。自動 Snapshot コピーの間隔を変更することはできますが、間隔を短く設定すると、Snapshot コピーが頻繁に作成されるため、パフォーマンスが低下する可能性があります。設定できる最小の間隔は 30 秒です。注: s、m、および h の接尾部は、それぞれ秒、分、および時間を指定します。

wsize=size 接続によって使用される TCP ウィンドウ・サイズを判別します。すべての SnapMirror

複製の TCP ウィンドウ・サイズを判別するsnapmirror.window_size オプションとは異なります。注: TCP ウィンドウ・サイズはバイト単位で指定されます。



schedule 宛先がデータの更新に使用するスケジュールを決定します。スケジュールは必須です。

スケジュールは、次の順序でスペースで区切られた 4 つのフィールドで構成されます。minute hour dayofmonth dayofweek

v minute は 0 から 59 の値です。

v hour は 0 から 23 の値です。

v dayofmonth は 1 から 31 の値です。

v dayofweek は 0 (日曜日) から 6 (土曜日)

の値です。

どのフィールドにも、コンマで区切られた複数の値を入力できます。

アスタリスク (*) を使用して、フィールドのすべての設定可能な値を適用できます。スケジュールの各フィールドにアスタリスクを指定すると、SnapMirror は宛先を 1 分ごとに更新します。

いずれかのフィールドに 1 つのダッシュ (-)

を指定することは、「never」の意味になり、このスケジュール項目は実行されません。(これは、サーバーが /etc/snapmirror.conf ファイルに表示されて snapmirror update によって検出されるようにして、SnapMirror スケジューラーが自動的に実行されないようにする場合に有用です。)

いずれかのフィールドで値の範囲を指定するには、低い値と高い値をダッシュで区切ります。例えば、hour フィールドに次の値を入力することによって、8:00 a.m. から 5:00 p.m

までの 1 時間ごとに更新することを指定できます。8-17

値の範囲の後にスラッシュと数値を入力すると、更新の頻度を指定できます。例えば、minutes フィールドに次の値を入力することによって、5 分ごとに更新することを指定できます。0-59/5

スペースで区切られた 4 つのフィールドの代わりに sync と入力すると、同期複製を指定できます。詳しくは、na_snapmirror.conf(5)

マニュアル・ページを参照してください。


snapmirror.conf ファイルのスケジュール項目の例

systemA と systemB の間にプライベート・ネットワークを作成するとします。systemA の /etc/hosts ファイルで、インターフェースのホスト名を systemA-e0 として指定し、systemA-e0 が宛先システムの systemB の /etc/hosts ファイルにもあることを確認します。毎週月曜日、水曜日、および金曜日の午後 11 時に systemA

の vol0 をプライベート・ネットワークを介して systemB の vol1 にコピーします。また、引数フィールドのデフォルトを使用するとします。

毎週月曜日、水曜日、および金曜日の午後 11 時にプライベート・ネットワークを介してデータをコピーするには、/etc/snapmirror.conf ファイルに次のように入力します。systemA-e0:vol0 systemB:vol1 - 0 23 * 1,3,5

次の図で、この例の各フィールドの項目の意味を説明します。

qtree 名でスペース文字と二重引用符を使用する snapmirror.conf ファイル項目の例

次の snapmirror.conf ファイル項目は、スペース文字と二重引用符を使用するqtree 名を指定する方法を示しています。この項目は、データが systemA の qtree

vol/vol1/x y″z から systemB の qtree vol/vol2/x y″z に複製されることを示しています。

″systemA:/vol/vol1/x y″″z″ ″systemB:/vol/vol2/x y″″z″ - * * * *

注: スペース文字と二重引用符を使用する qtree 名は、以前のバージョンの Data

ONTAP では機能しない可能性があります。そのため、以前のバージョンの Data

ONTAP に戻す場合は、互換性を確認する必要があります。

最大更新速度を設定する例

/etc/snapmirror.conf ファイルの次の行は、速度を 1 秒当たり 2000 キロバイトに設定します。systemA:vol0 systemA:vol1 kbs=2000 15 * * 1,2,3,4,5

図 15. snapmirror.conf スケジュール項目


注: 転送速度はネットワーク帯域幅などの要素によって制限されるため、指定された転送速度は達成できない可能性があります。

always restart を指定する例

/etc/snapmirror.conf ファイルの次の行は、restart 値を always に設定します。systemA:vol0 systemA:vol1 kbs=2000,restart=always 15 * * 1,2,3,4,5

最大速度および再開にデフォルト値を指定する例

1 つの引数 (kbs または restart) のみの値を設定する場合、もう 1 つの引数はデフォルト値を使用します。両方の値に対してデフォルトの引数を使用する場合、ダッシュ (-) を入力します。

/etc/snapmirror.conf ファイルの次の行は、両方の引数をデフォルト値に設定します。systemA:vol0 systemA:vol1 - 15 * * 1,2,3,4,5

特定の時間における 15 分間隔の更新を指定する例

毎日午後 1:00、1:15、1:30、1:45、5:00、5:15、5:30、5:45、7:00、7:15、7:30、および 7:45 に更新をスケジュールするには、スケジュール・フィールドに次のように入力します。systemA:vol0 systemA:vol1 - 0,15,30,45 13,17,19 * *

注: 現在事項が 4 つのすべてのフィールドの値と一致すると、更新が開始されます。日付フィールドの値によって曜日フィールドの値が除外されないように注意してください。例えば、次のスケジュールでは、月の最初の日が月曜日になる場合にのみ、毎日午後 1:00、1:30、3:00、3:30、5:00、および 5:30 に宛先が更新されます。systemA:vol0 systemA:vol1 - 0,30 13,15,17 1 1

注: スケジュールは、SnapMirror 機能の目標を表します。SnapMirror が 1 分ごとに更新できなくなる要素には、リソース制約またはネットワークの安定性があります。更新の進行中に別の更新が行われるようにスケジュールされている場合、SnapMirror は、最初の転送が完了するとすぐに次の転送を開始します。ただし、現在の転送が進行中の間に 3 つの更新が経過すると、SnapMirror はもう 1 回のみ更新を実行して、後でスケジュール更新が行われたために古くなった更新に戻って実行することはありません。

関連タスク

97ページの『SnapMirror の TCP ウィンドウ・サイズの調整』SnapMirror の TCP ウィンドウ・サイズは、SnapMirror のパフォーマンスに影響を与える可能性があります。ネットワーク構成を調整するために、TCP ウィンドウ・サイズのデフォルト値を変更する必要が生じる場合があります。

再開および再試行とはSnapMirror では、再試行とは、何らかのデータが正常に転送されたかどうかに関係なく、中断の後に転送処理の開始を自動的に試行することです。再開とは、前の転送処理を再開チェックポイントから再び始めることです。

SnapMirror は、転送中に 5 分ごとに再開チェックポイントを設定します。SnapMirror は、次に示す条件が満たされた場合に、中断した箇所から直前の転送を再開します。


v 再開チェックポイントが存在する。

v 転送中の Snapshot コピーがすべてまだ存在している。

v /etc/snapmirror.conf ファイル内で、再開モードの値が always に設定されているか値が設定されておらず、スケジュールに基づく次回更新の時期に達していない。

これらの条件が満たされていない場合、SnapMirror は新規 Snapshot コピーを作成し、新規転送を開始します。

スケジュール転送が失敗した場合 (例えば、ネットワーク障害が原因で)、SnapMirror は転送を 1 分後に自動的に再試行します。エラーによって転送が再試行に適さない状態になったために転送が失敗した場合 (例えば、ユーザーによる打ち切り)、またはソースが何らかの理由で転送を拒否した場合は、転送は 1 分後に再試行されません。このような場合は、snapmirror.conf ファイルに指定されたスケジュールに常に従って更新が試行されます。

注: ユーザーが開始した手動更新が失敗した場合、更新は自動的に試行されず、ユーザーには通知が出されます。更新が必要な場合、ユーザーはコマンドを再発行する必要があります。

リブート後、SnapMirror は中断された転送を自動的に再試行しませんが、次回のスケジュール転送または手動転送によって、該当する再開チェックポイントから転送が再開されます (チェックポイントがまだ有効な場合)。

初期転送は再開できますが、自動的に再試行されません。初期転送を再開するには、snapmirror initialize コマンドを再度入力します。スケジュールに基づくインクリメンタル更新は、転送を自動的に再試行します。

SnapMirror 宛先の手動更新通常、SnapMirror は /etc/snapmirror.conf ファイルに指定した更新スケジュールに従って宛先を自動的に更新します。ただし、snapmirror update コマンドを使用して更新を手動で開始することもできます。

近い将来の電源異常、定期保守、またはデータ・マイグレーションによるデータ損失を防ぐために、スケジュール外の更新を実行する必要が生じることがあります。また、外部スクリプトを使用して更新を実行する場合は、そのスクリプトにsnapmirror update コマンドを組み込むこともできます。

手動による SnapMirror 更新の実行/etc/snapmirror.conf ファイルのスケジュールとは関係なく、スケジュール外のSnapMirror インクリメンタル更新を実行するには、次のステップを実行します。

宛先システムから、次のコマンドを入力します。snapmirror update [options]

[dest_system:] {dest_volume | /vol/dest_volume/qtree_path} options は、以下の 1 つ以上が可能です。

v -k n は、最大転送速度を毎秒 n キロバイトに設定します。このオプションは、/etc/snapmirror.conf ファイルの kbs 引数と同じ効果があります。


v -s snapshot_name は、ソースによって取られた Snapshot コピーではなく、転送される既存の (qtree のみ) ソース Snapshot コピーを指定します。SnapMirror は、この Snapshot コピーをロックまたは削除しません。

注: snapshot_name を minutely.x、hourly.x、nightly.x、weekly.x、snapshot_for_backup.x、または snapshot_for_volcopy.x にすることはできません。そのような Snapshot コピーをソースで名前変更してからコピーする必要があります。

v -c snapshot_name は、次回の更新後に宛先の qtree の Snapshot コピーをsnapshot_name の名前で作成します (進行中の更新と競合しないようにするため)。SnapMirror は、この Snapshot コピーをロックまたは削除しません。

注: snapshot_name を minutely.x、hourly.x、nightly.x、または weekly.x にすることはできません。これらの名前は、スケジュールに基づく Snapshot コピー用に予約されているためです。

v -S [source_system:]source_volume | qtree_path は、更新用のソース・システムおよびボリュームを指定します。source_volume は、コピーするボリュームです。

-S オプションによって指定されたソースは、/etc/snapmirror.conf ファイル内の source_volume の項目と一致する必要があります。項目が存在しても一致しない場合、この操作により、エラー・メッセージが表示されて終了します。指定されたソース・ボリュームの項目がない場合、コマンドは実行されます。

注: -S オプションが設定されていない場合、ソースが /etc/snapmirror.conf ファイルで指定されている必要があります。指定されない場合、この操作により、エラー・メッセージが表示されて終了します。

dest_system は、宛先システムの名前を指定します。dest_volume は、宛先ボリュームを指定します。/etc/snapmirror.conf ファイルで指定されているローカル・ソース・ボリュームのスケジュール済みの宛先である場合、そのソース・ボリュームがソースと見なされます。指定された宛先ボリュームがスケジュールされた関係ではない場合、-S オプションを使用してソースを指定する必要があります。次のコマンドを使用して、SnapMirror は、/etc/snapmirror.conf ファイルで指定されたソースから宛先 (systemB の vol2) を更新します。

systemB> snapmirror update systemB:vol2

次のコマンドを使用して、SnapMirror は、systemA:/vol/vol1/users のソース qtree

から systemB:/vol/vol2/usersbak の qtree 宛先を更新します。

systemB> snapmirror update -S systemA:/vol/vol1/users systemB:/vol/vol2/usersbak

SnapMirror qtree の追加のバックアップ Snapshot コピーの作成SnapMirror qtree 関係のソースと宛先で、追加のバックアップ Snapshot コピーを作成する必要が生じる場合があります。これらの Snapshot コピーは、基本 Snapshot

コピーが誤って削除された場合に最新の共通 Snapshot コピーとして機能します。また、SnapMirror qtree 関係を以前の再同期点に再同期するために使用することもできます。



snap create コマンドを使用して手動 Snapshot コピーを作成できます。次に、snapmirror update コマンドの -c および -s オプションを一緒に使用して、SnapMirror qtree 関係の両側で追加のバックアップ Snapshot コピーを設定します。

1. 次のコマンドを入力します。snap create vol_name snapshot-name vol_name

は、Snapshot コピーを作成するボリュームの名前です。

snapshot-name は、Snapshot コピーの名前です。

systemB> snap create vol2 my_snap

これにより、ボリューム vol2 の Snapshot コピーの my_snap が作成されます。

2. 次のコマンドを入力します。snapmirror update -S source -s src_snap -c

dest_snap destination source は、ソースの名前です。

src_snap は、ソースの Snapshot コピーの名前です。

dest_snap は、宛先の Snapshot コピーの名前です。

destination は、宛先の名前です。

systemA> snapmirror update -S systemB:/vol/vol2/qtree1 -s my_snap -c my_dest_snap vol/vol4/qtreeSafe

SnapMirror が宛先へのインクリメンタル更新を行った後の処理SnapMirror による転送を完了した後、宛先はソースに変更を反映します。SnapMirror 転送が不完全な場合、または中断された場合は、転送が完了するまで宛先での変更内容は表示されません。SnapMirror が宛先の更新を完了した後、ファイルを開くと変更内容が表示されます。

注: SnapMirror は、データの更新に必要でなくなった古い Snapshot コピーを自動的に削除します。

SnapMirror Snapshot コピーのリストsnap list コマンドを使用して、ストレージ・システムに保管されている SnapMirror

固有の Snapshot コピーも含む、すべての Snapshot コピーをリストできます。

ソース・システムまたは宛先システムのいずれかのコンソールで、次のコマンドを入力します。snap list vol_name

タスクの結果

システムに保管されているすべての Snapshot コピーのリストが表示されます。SnapMirror Snapshot コピーは、より詳細な命名規則と括弧付きの「snapmirror」というラベルによってシステムの Snapshot コピーと区別されます。

SnapMirror によって使用される Snapshot コピーの命名規則snap list コマンドを使用する際、命名規則によって SnapMirror Snapshot コピーを通常のシステム Snapshot コピーと区別することができます。


ボリューム複製の場合、SnapMirror は、宛先ボリュームにコピーされるソース・ボリューム全体の Snapshot コピーを作成します。

SnapMirror ボリューム Snapshot コピー名は次の形式になっています。

dest_system(sysid)_name.number

v dest_system は、宛先システムのホスト名です。

v sysid は、宛先システム ID 番号です。

v name は、宛先ボリュームの名前です。

v number は、Snapshot コピーの正常な転送の番号で、1 から始まります。Data

ONTAP は、転送ごとにこの番号を増分します。

注: snap list コマンドの出力で、SnapMirror Snapshot コピーの後に括弧付きのSnapMirror の名前が続きます。

ボリュームの例

systemA(0016791363)_vol0.9 (snapmirror)

qtree 複製の場合、SnapMirror は、宛先ボリュームの qtree にコピーされるソース・ボリュームの 1 つ以上のソース qtree の Snapshot コピーを作成します。

SnapMirror qtree Snapshot コピー名は次の形式になっています。

dest_system(sysid)_name-src|dst.number

v dest_system は、宛先システムのホスト名です。

v sysid は、宛先システム ID 番号です。

v name は、宛先ボリュームの名前または qtree パスです。

v src|dst は、ソースまたは宛先の名前です。

v number は、Snapshot コピーの任意の開始点番号です。Data ONTAP は、転送ごとにこの番号を増分します。

qtree の例

systemA(0016789302)_vol1_qtree3-dst.15 (snapmirror)

注: 手動で作成されて snap list コマンドの出力で「snapmirror」とマークされたSnapshot コピーを削除しないでください。

宛先ボリューム上の SnapMirror 更新を表示するための snap listコマンドの使用snap list コマンドは、ストレージ・システム上のそれぞれの Snapshot コピーに関する情報を表示します。Snapshot コピーの名前のほか、Snapshot コピーの作成日とSnapshot コピーのサイズを表示します。


例

次の例は、ソース・ボリュームで作成されて宛先ボリュームにコピーされたSnapMirror Snapshot コピーを示しています。この例では、データは systemA のvol1 (ソース) から systemB の vol2 (宛先) にコピーされます。

宛先ボリュームのベースライン・バージョンを作成するために、systemA は、systemB(0016782130)_vol2.1 という名前の Snapshot コピーを systemA で作成します。systemB(0016782130)_vol2.1 を含めて、systemA の vol1 にあるすべてのSnapshot コピーは systemB の vol2 に転送されます。qtree を複製する場合、SnapMirror は、その qtree の Snapshot コピーにある qtree のデータのみを転送します。

systemB(0016782130)_vol2.1 Snapshot コピーが systemA から systemB に転送された後で管理者が snap list コマンドを宛先の systemB で実行した場合、次の例のようなリストが生成されます。

systemB> snap list vol2

working.....

%/used %/total date name-------- -------- ------------ --------0% ( 0%) 0% ( 0%) Nov 17 10:50 systemB(0016782130)_vol2.1 (snapmirror)1% ( 0%) 0% ( 0%) Nov 17 10:00 hourly.01% ( 0%) 0% ( 0%) Nov 17 00:00 nightly.01% ( 0%) 0% ( 0%) Nov 15 16:00 hourly.11% ( 0%) 1% ( 0%) Nov 15 15:00 hourly.22% ( 0%) 1% ( 0%) Nov 15 14:00 hourly.32% ( 0%) 1% ( 0%) Nov 15 13:00 hourly.42% ( 0%) 1% ( 0%) Nov 15 12:00 hourly.5

宛先を更新する時間になると、systemA に別の Snapshot コピーが作成されます。

systemA で snap list コマンドを実行すると、systemA で systemB(0016782130)

_vol2.2 Snapshot コピーが作成された後で次の画面が生成されます。

systemA> snap list vol1

working....

%/used %/total date name-------- -------- ------------ --------0% ( 0%) 0% ( 0%) Nov 17 10:52 systemB(0016782130)_vol2.2 (snapmirror)0% ( 0%) 0% ( 0%) Nov 17 10:51 systemB(0016782130)_vol2.1 (snapmirror)1% ( 0%) 0% ( 0%) Nov 17 10:00 hourly.01% ( 0%) 0% ( 0%) Nov 17 00:00 nightly.01% ( 0%) 0% ( 0%) Nov 15 16:00 hourly.11% ( 0%) 1% ( 0%) Nov 15 15:00 hourly.2

systemB(0016782130)_vol2.2 Snapshot コピーが systemA から systemB に転送された後、両方の Snapshot コピーが systemB に存在します。ただし、systemA では、systemB(0016782130)_vol2.1 は不要になり、削除されます。systemB(0016782130)

_vol2.2 のみが次回の転送で使用するために保存されます。

snap list -q コマンドを使用して、サーバー上のそれぞれの SnapMirror Snapshot コピー、その中にある qtree、それらの qtree のクライアント・ソース、およびそれらのタイム・スタンプのリストを表示できます。


snap list -o コマンドを使用して、指定するボリュームまたはパス名の qtree の名前、タイム・スタンプ、およびソース (コピーである場合) を表示できます。

SnapMirror データ転送状況の検査snapmirror status コマンドを使用してデータ転送状況を確認し、ストレージ・システムにあるすべての既存の SnapMirror 関係の状況を判別する必要があります。

次のコマンドを入力します。snapmirror status [options] [[system:] [path]

...] options は、以下のいずれかです。

v -l は、さらに詳細な情報を含む長形式の出力を表示します。

v -q は、静止したか、静止中のボリュームまたは qtree を表示します。

v -t は、アクティブなボリュームまたは qtree を表示します。

system は、ソース・ストレージ・システムの名前です。path は、ソース・ボリュームの名前またはソース qtree のパスと名前です。

注: -t オプションが使用される場合、出力にはアクティブな関係が表示されます。関係がアクティブと見なされるのは、ソースまたは宛先が以下のいずれかに関与している場合です。

v ネットワークとの間でのデータ転送

v 磁気テープ装置の読み取りまたは書き込み

v テープ変更の待機

v ローカルのディスク上の処理またはクリーンアップの実行

タスクの結果

引数またはオプションが指定されない場合、SnapMirror は、転送が進行中であるかどうか、完了したデータ転送の量、宛先の状態、および Snapshot コピーが最後に正常に作成および転送されてからの経過時間を示すメッセージを表示します。

関連タスク

156ページの『Snapshot コピー前の宛先の安定化』一時的に宛先への転送を停止することが必要な場合があります。例えば、データベースを含む SnapMirror 宛先ボリュームまたは qtree の Snapshot コピーを作成する場合、その内容が Snapshot コピー中に安定していることを確認する必要があります。

SnapMirror 状況検査の表示内容状況を確認して SnapMirrorを使用可能にすると、次の形式のメッセージが表示されます。

systemA> snapmirror status

Snapmirror is on.Source Destination State Lag StatussystemA:vol0 systemA:vol1 Snapmirrored 02:25:11 Transferring (60 MB done)systemB:/vol/vol1/qtree systemB:/vol/vol3/qtree Quiesced 00:01:15 Idle

基本 Snapshot コピーが含まれるすべての SnapMirror ソース、および現在のSnapMirror 関係のすべての宛先または /etc/snapmirror.conf ファイルでリストさ


れているすべての宛先に関する状況レポートが表示されます。snapmirror break コマンドによって中断されても基本 Snapshot コピーにまだ含まれている宛先はリストされます。

データ転送の状況を確認して、SnapMirrorを使用可能にしなかった場合、次のメッセージが表示されます。

systemA> snapmirror status

Snapmirror is off.

注: SnapMirror 関係の状況があれば、前の例で示したように引き続き表示されます。

例

オプションを指定しない場合、snapmirror status コマンドによって表示される情報は次のようになります。

systemB> snapmirror status

Snapmirror is on.Source Destination State Lag StatussystemA:vol0 systemB:vol2 Broken-off 29:09:58 IdlesystemC:vol0 systemB:vol3 Snapmirrored 00:09:53 Idle with restart checkpoint (23 MB done)systemC:vol4 systemB:vol5 Snapmirrored 00:04:58 Transferring (36 MB done)systemA:/vol/vol1/qt5 systemB:/vol/vol4/qt5 Quiesced 00:05:12 IdlesystemC:/vol/vol2/qt1 systemB:/vol/vol1/qt2 Snapmirrored 00:02:33 Quiescing

例

-l オプションを指定すると、前の例で示した構成は次のようになります。


systemB> snapmirror status -l

Snapmirror is on.Source: systemA:vol0Destination: systemB:vol2Status: SyncingProgress: 60 KBState: SourceLag: 00:01:17Mirror Timestamp: Sat Jul 15 00:50:02 GMT 2000Base Snapshot: tpubs-f720(0016791363)_vol2.1249Current Transfer Type: -Current Transfer Error: -Contents: -Last Transfer Type: UpdateLast Transfer Size: 1052 KBLast Transfer Duration: 00:00:02Last Transfer From: systemA:vol0

Source: systemC:vol0Destination: systemB:vol3Status: Idle with restart checkpointProgress 23552 KB doneState: SnapmirroredLag: 00:09:53Mirror Timestamp: Sun Jul 16 05:50:07 GMT 2000Base Snapshot: system2(0016778780)_vol3.985Current Transfer Type: -Current Transfer Error: Abort by userContents: ReplicaLast Transfer Type: UpdateLast Transfer Size: 432000 KBLast Transfer Duration: 00:01:23Last Transfer From: systemC:vol0

Source: systemC:vol4Destination: systemB:vol5Status: TransferringProgress 36864 KB doneState: SnapmirroredLag: 00:04:58Mirror Timestamp: Sun Jul 16 05:55:02 GMT 2000Base Snapshot: systemB(0016778780)_vol5.57843Current Transfer Type: ScheduledCurrent Transfer Error: -Contents: ReplicaLast Transfer Type: ScheduledLast Transfer Size: 345000 KBLast Transfer Duration: 00:03:23Last Transfer From: systemB:vol4

Source: systemC:/vol/vol1/qt5Destination: systemB:/vol/vol4/qt5Status: IdleProgress -State: QuiescedLag: 0:05:12Mirror Timestamp: Sun Jul 16 05:56:12 GMT 2000Base Snapshot: systemB(0016778780)_vol_vol4_qt5.54Current Transfer Type: -Current Transfer Error: -Contents: ReplicaLast Transfer Type: ScheduledLast Transfer Size: 45000 KBLast Transfer Duration: 0:00:12Last Transfer From: systemC:/vol/vol1/qt5

Source: systemC:/vol/vol2/qt1Destination: systemB:/vol/vol4/qt2Status: QuiescingProgress -State: SnapmirroredLag: 0:02:33Mirror Timestamp: Sun Jul 16 05:58:20 GMT 2000Base Snapshot: systemB(0016778780)_vol_vol4_qt2.122Current Transfer Type: -Current Transfer Error: -Contents: TransitioningLast Transfer Type: ScheduledLast Transfer Size: 80 KBLast Transfer Duration: 0:00:08Last Transfer From: systemC:/vol/vol2/qt1


例

-q オプションを指定すると、出力は次のようになります。

systemC> snapmirror status -q

Snapmirror is on.vol3 is quiescedvol2 has quiesced/quiescing qtrees:

/vol/vol2/qt1 is Quiescing/vol/vol2/qt2 is Quiesced

関連資料

『SnapMirror 状況検査の情報メッセージ』snapmiror status コマンドが表示する可能性がある情報メッセージは次のとおりです。

SnapMirror 状況検査の情報メッセージsnapmiror status コマンドが表示する可能性がある情報メッセージは次のとおりです。

ソース・カテゴリーの SnapMirror 状況項目は次のとおりです。

ソース項目説明

system:vol ソース・システムおよびソース・ボリューム

system:qtree_path ソース・システムおよび qtree パス

- SnapMirror 宛先がインポートされたボリュームで /etc/snapmirror.conf ファイルに項目がないか、Data ONTAP アップグレードが進行中です。

system:tape_device ソース磁気テープ装置。この磁気テープ装置からの転送がまだ進行中です。

base snapshot ソースが磁気テープ装置で、/etc/snapmirror.conf ファイルに宛先の項目がない場合に、完了済み転送が行われた基本 Snapshot コピーの名前。

宛先カテゴリーの SnapMirror 状況項目は次のとおりです。

宛先項目説明

system:vol 宛先システムおよびボリューム

system:qtree_path 宛先システムおよび qtree パス

system:tape_device 宛先磁気テープ装置。この磁気テープ装置への転送が進行中です。

tape_destination テープへの転送が終了した後で表示されます。snapmirror destinations コマンドによってもこの情報は表示されます。


状況項目説明

Uninitialized 宛先は /etc/snapmirror.conf ファイルにリストされていますが、ボリュームまたはqtree が初期化されていないか、宛先が初期化中です。

Snapmirrored ボリュームまたは qtree は SnapMirror 関係に関与しています。

Broken-off 宛先は SnapMirror 関係に関与していましたが、snapmirror break コマンドによってボリュームまたは qtree は書き込み可能になりました。基本 Snapshot コピーがまだボリューム内に存在する間、この状態は報告されます。Snapshot コピーが削除されると、宛先が/etc/snapmirror.conf ファイル内にある場合は状態が「uninitialized」としてリストされ、ない場合はリストされなくなります。snapmirror resync コマンドが成功すると、「snapmirrored」状況が復元されます。

Quiesced SnapMirror は整合した内部状態で、SnapMirror アクティビティーは行われていません。この状態では、すべての宛先が整合していることを信頼して Snapshot コピーを作成できます。 snapmirror quiesce コマンドにより、宛先はこの状態になります。snapmirror

resume コマンドは、すべての SnapMirror アクティビティーを再開します。

Unknown 宛先ボリュームまたは宛先 qtree を含むボリュームは不明な状態です。オフラインまたは制限付きの可能性があります。

Source snapmirror status コマンドがソース・システムで実行され、宛先が別のシステムである場合、宛先の状態は不明であるため、ソースの状況が報告されます。

遅延項目説明

hh:mm:ss 現在時刻と、宛先に正常に転送された前回のSnapshot コピーのタイム・スタンプの差を示します。

- 宛先が初期化されていません。

ソース・カテゴリーの SnapMirror 状況項目は次のとおりです。

状況項目説明

Idle 転送中のデータはありません。


状況項目説明

Idle with restart checkpoint (n XB done) 転送中のデータはありません。前回の転送の試行は中止されましたが、転送は再開チェックポイントを保存したため、次回の試行で再開できます。転送サイズが次の単位で報告されます。

v KB (10,240 KB まで)

v MB (10,240 MB まで)

v GB (10,240 GB まで)

v TB

Transferring 転送が始まりましたが、まだ開始されていないか、終了するところです。

Transferring (n XB done) データ転送が進行中です。転送サイズが次の単位で報告されます。

v KB (10,240 KB まで)

v MB (10,240 MB まで)

v GB (10,240 GB まで)

v TB

Pending 宛先が転送失敗のために更新されませんでした。転送は自動的に再試行されます。

Pending with restart checkpoint (n XB done) 宛先が転送失敗のために更新されませんでした。転送は、再開チェックポイントから自動的に再試行されます。転送サイズが次の単位で報告されます。

v KB (10,240 KB まで)

v MB (10,240 MB まで)

v GB (10,240 GB まで)

v TB

Aborting 転送は中止およびクリーンアップされています。

Quiescing 指定されたボリュームまたは qtree は、すべての既存の転送が完了するまで待っています。宛先は、安定状態になっています。

Resyncing 指定されたボリュームまたは qtree は、共通Snapshot コピー内のデータと突き合わせられています。

Waiting SnapMirror は、新しいテープが磁気テープ装置に入れられるのを待っています。

その他の snapmirror 状況項目は次のとおりです。

その他の -l オプション項目説明

Progress 現在の転送で転送されているデータの量 (KB

単位) を表示します。状況が「Idle」または「Pending」の場合は再開チェックポイントを表示します。



Mirror Timestamp ソースから宛先に正常に転送された前回のSnapshot コピーのタイム・スタンプ。注: 再同期によって、基本 Snapshot コピーが、古いタイム・スタンプの Snapshot コピーに変更される可能性があります。

Base Snapshot copy 宛先の基本 Snapshot コピーの名前。

SnapMirror 関係のボリュームの場合、このフィールドはソース・サイドと宛先サイドで同じです。 SnapMirror 関係の qtree の場合、宛先サイドは、宛先のその qtree のエクスポートされた Snapshot コピーの名前をリストします。注: 再同期によって、基本 Snapshot コピーの名前が変更される可能性があります。

Current Transfer Type 現在進行中の転送の種類 (スケジュール、再試行、再同期、更新、初期化、保管、またはアーカイブ) を示します。このフィールドは、宛先サイドにのみ適用されます。

Current Transfer Error 最新の転送の試行が失敗した場合にエラー・メッセージを表示します。

Contents アクティブ・ファイル・システム内の宛先ボリュームまたは qtree の内容が最新のレプリカであるか、または移行中であるかを示します。このフィールドは、宛先サイドにのみ適用されます。

v SnapMirror ボリューム複製では、内容は常にレプリカです。

v SnapMirror qtree 複製では、通常は内容はレプリカですが、場合によっては移行中になります。

Last Transfer Type 以前に実行された転送の種類 (スケジュール、再試行、再同期、更新、初期化、保管、または検索) を示します。このフィールドは、宛先サイドにのみ適用されます。

Last Transfer Size 前回の正常な転送で転送されたデータの量(KB 単位) を表示します。

Last Transfer Duration 前回の正常な転送が完了するのに掛かった経過時間を表示します。転送が失敗して再開された場合、この時間には転送を再開するまで待機した時間も含まれます。転送が中止されて最初から再試行された場合、この時間には、最終的に成功した試行に要した時間のみが含まれます。



Last Transfer From このフィールドは、宛先サイドにのみ適用され、ソース・システムおよびボリュームまたは qtree の名前を示します。このフィールドは、/etc/snapmirror.conf ファイルでソースを変更して、データが実際には古いソースのものである場合に有用です。snapmirror

retrieve (テープからの) 操作では、このフィールドは、検索操作で使用された磁気テープ装置をリストします。

関連概念



関連タスク

117ページの『カスケード・シリーズ内のボリュームの SnapMirror 宛先のリスト』snapmirror destinations コマンドを使用して、カスケード・シリーズ内のボリュームの宛先を表示することができます。

関連資料

145ページの『SnapMirror 状況検査の表示内容』状況を確認して SnapMirrorを使用可能にすると、次の形式のメッセージが表示されます。

転送の最大転送速度の変更スケジュール SnapMirror 転送の最大転送速度は、/etc/snapmirror.conf ファイルの kbs オプションを使用して設定します。最大転送速度を変更することはできますが、変更された転送速度が適用されるのは現在の転送のみです。次回のスケジュール転送では、/etc/snapmirror.conf ファイルで指定された最大転送速度が使用されます。


現在の転送が行われているときに最大転送速度を変更すると、新しい最大転送速度は 2 分以内で有効になります。

最大転送速度を変更して現在の転送に適用するには、ソースまたは宛先のいずれかのストレージ・システムで次のコマンドを入力します。snapmirror throttle n

[system:] path n は、新しい最大転送速度 (キロバイト/秒) です。値がゼロ (0) の場合、スロットルは使用不可になります。system は、宛先ストレージ・システムです。この変数は、コマンドをソース・ストレージ・システムで実行する場合に使用します。path は、宛先パスです。パスは、/volume_name または /vol/volume_name/

qtree_name です。


SnapMirror データ転送ログoptions snapmirror.log.enable コマンドを使用して、SnapMirror データ転送ログを検査できます。転送が計画どおりに行われているかどうか、転送にどれだけ時間がかかっているか、およびシステム・セットアップがどれだけ適切に機能しているかを調べることができます。この情報は、SnapMirror ログ・ファイル内にあります。

SnapMirror ログ・ファイルは、次の内容をリストします。

v SnapMirror ロギング処理の開始時刻と終了時刻。

v それぞれの転送の開始時刻、終了時刻、およびサイズ。

v 転送の異常終了と再開。

v その他の SnapMirror 関連のアクティビティー。

提供される未加工の情報を使用して、次のことが可能です。

v 平均転送サイズを計算する。

v 平均転送時間を計算する。

v 正常に行われた転送の数と失敗率を調べる。

v スケジュールを調整する。

v 異常終了した転送に関する通知機能を作成する。

v ボリュームごとのレベルでパフォーマンスをモニターする。

v 計画どおりに処理が行われていることを確認する。

SnapMirror データ転送状況の検査SnapMirror ロギングは、デフォルトでオンに設定されています。ただし、SnapMirror ロギングがオンまたはオフのどちらになっているか調べる必要がある場合は、次の手順で行います。

情報が必要なシステム上で、コマンド options snapmirror.log.enable を入力します。 SnapMirror は、ロギングが使用可能かどうかを報告します。

例

systemA> options snapmirror.log.enable

snapmirror.log.enable on

SnapMirror ロギングをオンにするSnapMirror は、既存システムのルート・ボリューム上の現在のログを/etc/log/snapmirror.0 として保持します。毎週、新しいログ・ファイルが/etc/log/snapmirror.0 として生成されます。古いログ・ファイルは/etc/log/snapmirror.[1-5] に名前変更され、最も古いログ・ファイルは削除されます。テキスト・エディターを使用してログ・ファイルを読み取ることができます。

ログが必要なシステムで次のコマンドを入力します。options

snapmirror.log.enable on

注: この設定は、リブートしても持続します。


タスクの結果

SnapMirror は、このシステムでの転送のロギングを使用可能にします。

SnapMirror ログ・ファイルのフォーマットログ・ファイルは次のフォーマットになっています。

type timestamp source_system:source_path dest_system:dest_path event_info

type は、src、dst、log、cmd のいずれかです。type は、レコードが転送のソース・サイド (src) または宛先サイド (dst) のどちらであるかを示します。特定のイベントは 1 つのサイドにのみ適用されます。タイプ log は、ロギング・システム自体に関するレコード (例えば、Start_Logging および End_Logging) を示します。タイプcmd は、ユーザー・コマンドのレコード (例えば、Release_command およびResync_command) を示します。

timestamp は、ctime フォーマットで表現されます (例えば、Fri Jul 27 20:41:09

GMT)。

event_info には、次のイベント名が含まれます。Request ( IP address | transfer

type ) Start Restart (@ num KB) End (num KB done) Abort (error_msg) Defer

(reason) Rollback_start Rollback_end Rollback_failed Start_Logging

End_Logging Wait_tape New_tape Snapmirror_on Snapmirror_off Quiesce_start

Quiesce_end Quiesce_failed Resume_command Break_command Release_command

Abort_command Resync_command Migrate_command

ソース・サイドの Request イベントには、転送要求を行ったストレージ・システムの IP アドレスが含まれます。宛先サイドの Request イベントには、転送のタイプが含まれます。正常な転送が行われるたびに、転送の最後に、End イベントは転送の合計サイズ (KB 単位) も報告します。エラー・メッセージは Abort および Defer

イベントに含まれます。

例

下記は、ソース・サイドのログ・ファイルの例です。

log Fri Jul 27 20:00:01 GMT - - Start_Loggingcmd Fri Jul 27 20:00:20 GMT - - Snapmirror_onsrc Fri Jul 27 20:41:09 GMT system1:vol1 system2:vol1 Request (10.56.17.133)src Fri Jul 27 20:41:32 GMT system1:vol1 system2:vol1 Abort (Destination not allowed)src Fri Jul 27 20:45:31 GMT system1:vol0 system1:vol1 Request (10.56.17.132)src Fri Jul 27 20:45:35 GMT system1:vol0 system1:vol1 Startsrc Fri Jul 27 20:51:40 GMT system1:vol0 system1:vol1 End (26200 KB)src Fri Jul 27 22:41:09 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Request (10.56.17.133)src Fri Jul 27 22:41:12 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Startsrc Fri Jul 27 22:41:13 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Abort (Non-unicode directory found in source qtree.)src Fri Jul 27 22:45:53 GMT system1:/vol/vol1/qtb system2:/vol/vol1/qsmb Request (10.56.17.133)src Fri Jul 27 22:45:56 GMT system1:/vol/vol1/qtb system2:/vol/vol1/qsmb Startsrc Fri Jul 27 22:45:59 GMT system1:/vol/vol1/qtb system2:/vol/vol1/qsmb End (3800 KB)cmd Fri Jul 27 22:50:29 GMT system1:/vol/vol1/qtb system2:/vol/vol1/qsmb Release_command


例

下記は、宛先サイドのログ・ファイルの例です。

dst Fri Jul 27 22:50:18 GMT system1:vol0 system1:vol1 Request (Initialization)dst Fri Jul 27 22:50:20 GMT system1:vol0 system1:vol1 Abort (Destination is not restricted)dst Fri Jul 27 22:57:17 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Request (Initialize)dst Fri Jul 27 22:57:24 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Startdst Fri Jul 27 22:57:36 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB End (55670 KB)dst Fri Jul 27 23:10:03 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Request (Scheduled)dst Fri Jul 27 23:10:07 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Startdst Fri Jul 27 23:10:18 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB End (12900 KB)cmd Sat Jul 28 00:05:29 GMT - system2:/vol/vol1/qtB Quiesce_startcmd Sat Jul 28 00:05:29 GMT - system2:/vol/vol1/qtB Quiesce_endcmd Sat Jul 28 00:05:40 GMT - system2:/vol/vol1/qtB Break_commandcmd Sat Jul 28 00:41:05 GMT system1:/vol/vol1/qtA system2:/vol/vol1/qtB Resync_commandlog Sat Jul 28 00:41:10 GMT - - End_Logging

例

下記は、(テープからの) 検索要求のログ・ファイルの例です。

dst Fri Jun 22 03:07:34 GMT filer_1:rst0l filer_1:bigtwo Request (retrieve)dst Fri Jun 22 03:07:34 GMT filer_1:rst0l filer_1:bigtwo Startdst Fri Jun 22 05:03:45 GMT filer_1:rst0l filer_1:bigtwo Wait_tapedst Fri Jun 22 15:16:44 GMT filer_1:rst0l filer_1:bigtwo New_tapedst Fri Jun 22 17:13:24 GMT filer_1:rst0l filer_1:bigtwo Wait_tapedst Fri Jun 22 17:56:43 GMT filer_1:rst0l filer_1:bigtwo New_tapedst Fri Jun 22 18:10:37 GMT filer_1:rst0l filer_1:bigtwo End (98602256 KB)

SnapMirror ロギングをオフにするSnapMirror ログ・プロセスをオフにするには、次のステップを実行します。

ログを使用不可にするシステムで次のコマンドを入力します。options

snapmirror.log.enable off

タスクの結果

SnapMirror はロギング・プロセスを使用不可にします。

SnapMirror 転送の中止snapmirror abort コマンドを使用して、ソースが宛先へのデータ転送を終了する前にボリュームまたは qtree コピー操作を中止することができます。転送は、スケジュール更新、手動更新、または初期化の結果として行われます。

このタスクについてv コピー操作を中止すると、データ転送は停止され、SnapMirror は再開可能モードになります。

v 以前に中止された転送を中止すると、その転送を再び再開することはできません。

v snapmirror abort コマンドで -h オプション (ハード中止) を使用する場合、転送を再開できません。

ソース・システムまたは宛先システムのいずれかで、次のコマンドを入力します。snapmirror abort [-h] {[dest_system:]dest_volume | [dest_system:]/vol/

volume_name/qtree_name ...} -h は、ハード中止を指定します。転送を再開できません。SnapMirror は、転送を停止して、再開可能な転送ログを消去します。このオプションは、SnapMirror 宛先にのみ適用されます。


dest_system は、宛先システムの名前です。dest_volume は、宛先ボリュームです。/vol/ volume_name/qtree_name は、宛先 qtree のパス名です。

注: 宛先システムが指定されない場合、ローカル・ホストの名前がシステム名として使用されます。複数の宛先ボリュームを入力できます。宛先システムおよびボリュームは、snapmirror status 出力で分かります。

注: 宛先ボリュームまたは qtree が指定されない場合、コマンドはエラー・メッセージを返し、すべての転送を中止しません。すべての転送を中止するには、snapmirror off コマンドを使用してください。無効な SnapMirror 宛先 (snapmirror status コマンドの出力に表示されていないもの)

を入力した場合、コマンドは失敗し、エラー・メッセージを表示します。

タスクの結果

SnapMirror は、コマンドが入力された systemA の vol1 への転送を中止して、systemB の vol2 への転送および system C の vol3 の qtree 3 への転送を中止します。

例systemA> snapmirror abort vol1 systemB:vol2 systemC:/vol3/qtree3snapmirror abort: Aborting transfer to vol1 systemB:vol2 systemC:/vol3/qtree3

Snapshot コピー前の宛先の安定化一時的に宛先への転送を停止することが必要な場合があります。例えば、データベースを含む SnapMirror 宛先ボリュームまたは qtree の Snapshot コピーを作成する場合、その内容が Snapshot コピー中に安定していることを確認する必要があります。


snapmirror quiesce コマンドを使用して、宛先が安定状態になった後で宛先への転送をブロックすることができます。

転送をブロックするシステムで次のコマンドを入力します。snapmirror quiesce

{dest_volume | /vol/volume_name/qtree_name} dest_volume は、宛先ボリュームの名前です。qtree_name は、volume_name の中の qtree の名前です。

systemA> snapmirror quiesce vol1snapmirror quiesce: in progress.snapmirror quiesce: vol1: successfully quiesced

SnapMirror は、それ以降の vol1 へのデータ転送を停止します。

systemA> snapmirror quiesce vol2snapmirror quiesce: in progress.This can be a long-running operation. Use Control-C to interrupt.......................................snapmirror quiesce: vol2: successfully quiesced


SnapMirror は、転送が終了するまで待ってから、それ以降の vol2 へのデータ転送を停止します。

systemA> snapmirror quiesce /vol/vol1/qtree1

SnapMirror は、vol1 の qtree1 へのデータ転送を停止します。静止した宛先でsnapmirror break コマンドを使用する場合、宛先が書き込み可能になると、静止状態は自動的にクリアされます。

注: SnapMirror 静止操作を中止するには、いつでも Ctrl-C を押すか、snapmirror

resume コマンドを入力します。

quiesce コマンドが行う処理snapmirror quiesce コマンドは、すべてのボリュームと qtree の SnapMirror 転送が完了するまで待ち、以降の更新をブロックします。qtree が安定状態にない (遷移中)

場合、snapmirror quiesce コマンドは qtree を強制的に安定状態にします。

静止できるボリュームと qtree は、オンラインであり、SnapMirror 宛先であるもののみです。制限付きまたはオフラインのボリューム、あるいは制限付きまたはオフラインのボリューム内にある qtree は、静止できません。

snapmirror quiesce コマンドは、ボリュームまたは qtree が SnapMirror 宛先として動作しないようにしますが、SnapMirror ソースとして動作することは禁止しません。

注: 静止状態はリブート後も持続します。

宛先を静止した後の転送の再開snapmirror resume コマンドを使用して、静止したボリュームまたは qtree へのデータ転送機能を復元することができます。

転送を再開するシステムに対して次のコマンドを入力します。snapmirror resume

{dest_volume | /vol/volume_name/qtree_name} dest_volume は、宛先ボリュームの名前です。qtree_name は、volume_name の中の qtree の名前です。

systemA> snapmirror resume vol2snapmirror resume: vol2: Successfully resumed

SnapMirror は、vol2 の正常なデータ転送機能を再開します。

ボリュームまたは qtree のスケジュールに基づく更新宛先を更新する必要がないと判断した場合は、宛先の etc/snapmirror.conf ファイルを編集して、特定のボリュームまたは qtree のスケジュールに基づく更新を変更するかオフにすることができます。

ストレージ・システムの使用パターンまたは構成が変更された場合は、スケジュールに基づく更新の時刻または頻度を変更するとよいでしょう。また、ボリュームを別の目的に使用する場合は、宛先を書き込み可能ボリュームに変更できます。


注: 宛先の etc/snapmirror.conf ファイルの項目を編集してスケジュールに基づく更新をオフにしても、宛先は書き込み可能ボリュームに変更されません。宛先を書き込み可能なボリュームまたは qtree に変更する場合は、snapmirror break コマンドを使用して宛先を書き込み可能なボリュームまたは qtree にするか、snapmirror

release コマンドを使用して、ソース上で不要になった Snapshot コピーをSnapMirrorが削除できるようにします。

宛先の etc/snapmirror.conf ファイルを編集して、スケジュールに基づく更新をいつでも (データ転送が実行中であっても) オフにしたり変更したりできます。宛先は転送前と同じ状態のままになります。ソース内でデータ転送のために作成されたSnapshot コピーは残りますが、宛先が次回に更新されるときに削除して新規Snapshot コピーに置き換えることができます。

関連概念


関連タスク



1 つのボリュームまたは qtree に対するスケジュール更新の変更1 つのボリュームまたは qtree に対するスケジュール更新を変更するには、次のステップを実行します。

宛先の /etc/snapmirror.conf ファイルで、宛先ボリュームまたはスケジュール情報を編集して目的の構成を指定します。

例

元の更新スケジュール:

systemA:vol0 systemA:vol1 - 0 23 * 1,3,5systemA:vol1 systemB:vol6 - 0 23 * 1,3,5

変更された更新スケジュール

systemA:vol0 systemA:vol2 - 0 23 * 1,3,5systemA:vol1 systemB:vol6 - 0 23 * 2,4,6

1 つのボリュームまたは qtree のスケジュール更新をオフにする1 つのボリュームまたは qtree のスケジュール更新をオフにするには、以下のステップを実行します。


次の方法によって、/etc/snapmirror.conf ファイル内の項目を削除するか、項目を変更します。

v 項目の前にポンド記号 (#) を付けて項目をコメント化します。

systemA:vol0 systemA:vol1 - 0 23 * 1,3,5systemA:vol1 systemB:vol6 - 0 23 * 1,3,5#systemB:vol1 systemC:vol2 - 0 23 * 1,3,5

v いずれかのスケジュール・フィールド (minute/hour/dayofmonth/dayofweek) にダッシュ (-) を付けます。

注: /etc/snapmirror.conf ファイルで宛先を削除またはコメント化したり、宛先のいずれかのスケジュール・フィールドにダッシュを付けても、その宛先に対する手動更新が妨げられることはありません。

systemA:vol0 systemA:vol1 - 0 23 * 1,3,5systemA:vol1 systemB:vol6 - 0 23 * 1,3,5systemB:vol1 systemC:vol2 - - 23 * 1,3,5

SnapMirror 更新をオフにするsnapmirror off コマンドを使用すると、コピーが進行中でも随時、ストレージ・システム全体のスケジュール更新と手動更新の両方をオフにすることができます。ストレージ・システムで SnapMirror をオフにすると、すべてのアクティブな転送が中止されます。更新をオフにした後、宛先は未変更のまま残されます。


このプロセスは、システムが SnapMirror 関係のソースまたは宛先のどちらでも、システムのすべての SnapMirror 転送に影響を与えます。

1. ソース・システムと宛先システムの両方で次のコマンドを入力して、SnapMirror

を使用不可にします。options snapmirror.enable off あるいは、以前のコマンドを使用して SnapMirror をオフにすることもできます。snapmirror off

SnapMirror が現在データをボリューム間または qtree 間で転送している場合、その転送は即時に中止されます。宛先は転送前と同じ状態のままです。データ転送のためにソース・ボリュームで作成された Snapshot コピーはそのまま残されます。

SnapMirror は、変更を見つけるための /etc/snapmirror.conf ファイルのモニタリングを停止します。

宛先システムのみで snapmirror off コマンドを入力すると、ソース・システム上の SnapMirrorは影響を受けません。その他のシステムは、ソース・システムからのデータのコピーを続行できます。

注: snapmirror off コマンドおよび snapmirror.enable off オプションは両方とも、リブートしても持続します。

2. snapmirror on コマンドが /etc/rc ファイル内にある場合、コマンドを除去します (リブート後に現在の設定を保持するため)。そうでないと、/etc/rc ファイルの設定によって、入力したコマンドが指定変更されます。


SnapMirror ソース・ボリュームと宛先ボリューム・ペアのサイズ変更

ボリューム SnapMirror ソースのサイズを増やすことができます。増大したファイル・システム・サイズを収容するのに宛先ボリューム・サイズが十分である場合、次回の更新でボリューム SnapMirror は宛先のファイル・システム・サイズを同じ分だけ増やします。


ソース・ボリュームのサイズを増やす前に、特定のボリューム SnapMirror 関係のソース・ボリュームと宛先ボリュームのサイズを比較する必要があります。宛先ボリュームが大容量のソース・ボリュームを収容するのに十分なサイズではない場合、宛先ボリュームを手動でサイズ変更する必要があります。

注: アクティブなボリューム SnapMirror 関係では、ソース・ボリュームと宛先ボリュームのファイル・システム・サイズは同じです。ただし、宛先のボリューム・サイズをソースのボリューム・サイズ以上にすることができます。宛先からソースを復元する必要がある場合は、ファイル・システム・サイズが同じであることが必要です。

1. ソース・ストレージ・システムで、次のコマンドを入力して fs_size_fixed オプションがオフであるかどうか検査します。vol status volname -v volname は、SnapMirror のソース・ボリュームの名前です。

SRC_A> vol status sm_src -vVolume State Status Optionssm_src online raid_dp, flex nosnap=off, nosnapdir=off,

minra=off, no_atime_update=off,nvfail=off,ignore_inconsistent=off,snapmirrored=off,create_ucode=off,convert_ucode=off,maxdirsize=31457,schedsnapname=ordinal,fs_size_fixed=off,compression=off,guarantee=volume, svo_enable=off,svo_checksum=off,svo_allow_rman=off,svo_reject_errors=off,no_i2p=off,fractional_reserve=100,extent=off,try_first=volume_grow,read_realloc=off,snapshot_clone_dependency=off

Containing aggregate: 'aggr1'

Plex /aggr1/plex0: online, normal, activeRAID group /aggr1/plex0/rg0: normal

注: fs_size_fixed オプションが off に設定されている場合、宛先ボリュームのファイル・システム・サイズはソース・ボリュームと異なっている可能性があります。ソース・ボリュームを SnapMirror 宛先から復元するためには、ソース・ボリュームと宛先ボリュームのファイル・システム・サイズが同じであることが必要です。ボリューム SnapMirror 関係が Idle 状況である場合、宛先ボリューム・サイズを増やした後で、このオプションをソース・ストレージ・システムで変更することができます。


2. fs_size_fixed オプションの値に応じて、以下のアクションのいずれかを選択します。

状況処置

fs_size_fixed オプションが off に設定されている。

次のステップに進みます。

fs_size_fixed オプションが on に設定されている。

ソース・ストレージ・システムで次のコマンドを入力します。vol options volname

fs_size_fixed off

volname は、SnapMirror のソース・ボリュームの名前です。

SRC_A> vol options sm_src fs_size_fixed off

3. ソース・ストレージ・システムで次のコマンドを入力して、ソース・ボリュームのボリュームおよびファイル・システムのサイズを調べます。vol status

volname -b volname は、SnapMirror ソース・ボリュームの名前です。

SRC_A> vol status sm_src -bVolume Block Size (bytes) Vol Size (blocks) FS Size (blocks)------ ------------------ ------------------ ----------------sm_src 4096 256000 256000

4. 宛先ストレージ・システムで次のコマンドを入力して、宛先ボリュームのボリュームおよびファイル・システムのサイズを調べます。vol status volname -b

volname は、SnapMirror 宛先ボリュームの名前です。

DST_B> vol status sm_dst -bVolume Block Size (bytes) Vol Size (blocks) FS Size (blocks)------ ------------------ ------------------ ----------------sm_dst 4096 512000 256000

5. SnapMirror 関係のソースと宛先ペアのボリュームおよびファイル・システムのサイズを比較します。

注: 宛先ボリュームに、宛先のボリューム・サイズまでのソース・ボリュームを収容することができます。ソース・ボリュームを宛先ボリュームより大きくする場合は、宛先ボリュームのサイズを手動で増やす必要があります。上記のステップで示した例では、宛先ボリューム・サイズの方がソース・ボリューム・サイズより大きくなっています。

6. SnapMirror 宛先ボリュームの現在のサイズに応じて、以下のアクションのいずれかを選択します。

宛先ボリュームのサイズ処置

希望どおりに増やしたソース・ボリュームのサイズを収容するのに十分である。


希望どおりに増やしたソース・ボリュームのサイズを収容するためには、増やす必要がある。

次のステップに進みます。


7. ボリュームのタイプに応じて以下のアクションのいずれかを選択して、SnapMirror 宛先ボリュームのサイズを増やします。

ボリューム・タイプボリュームのサイズを増やすためのコマンド

FlexVol ボリューム vol size volname size

volname は、SnapMirror ソース・ボリュームの名前です。

size は、SnapMirror ソース・ボリュームの必要なサイズです。注: このコマンドを SnapMirror 宛先 FlexVol

ボリュームに対して使用する場合、システムは次のメッセージを表示します。

Warning: Volume 'sm_dst' is a replica.This will not change the file system sizein the replica, which is set from thereplica source. The new volume size willbe used to set the upper limit on replicatransfers into this volume.

vol size: Flexible volume 'sm_dst' sizelimit set to new_size.

従来型ボリューム vol add volname disks

volname は、SnapMirror ソース・ボリュームの名前です。

disks は、従来型ボリュームに追加するディスクの数です。

vol status コマンドを使用して、ソース・ボリューム・サイズの増大を確認できます。

注: 宛先ボリューム・サイズを、希望どおりに増やしたソース・ボリュームのサイズ以上になるように増やすことができます。

8. ソース・ボリュームについてステップ 7 を実行し、SnapMirror ソース・ボリュームのサイズを増やします。

9. ソース・ストレージ・システムで次のコマンドを入力します。vol options

volname fs_size_fixed on

volname は、SnapMirror のソース・ボリュームの名前です。このオプションにより、SnapMirror ソース・ボリュームと宛先ボリュームのファイル・システム・サイズが確実に同じになります。

注: SnapMirror は、ボリューム・ペアの次回の SnapMirror 転送で宛先ボリュームのファイル・システム・サイズを更新してソースと一致するようにします。

宛先から書き込み可能なボリュームまたは qtree への変換snapmirror break コマンドを使用して、読み取り専用状況の SnapMirror 宛先を、書き込み可能なボリュームまたは qtree に変換できます。


次のいずれかの作業を行うために、宛先を書き込み可能なボリュームまたは qtree

に変換することができます。

v データ・マイグレーション ― データを一方のボリュームまたは qtree (オリジナル・ソース) から他方のボリュームまたは qtree (現在の宛先) に移動して、宛先のデータをアクセス可能、書き込み可能にします。

v 災害復旧 ― ソースが使用不可になり、現在の宛先をユーザーの検索および入力のソースとして代用する場合。

v アプリケーション・テスト ― 現在の宛先ボリュームまたは qtree を書き込み可能にして、現在のデータのミラーリングされた複製に基づいて新規アプリケーションをテストする場合。ソース・ボリュームまたは qtree 上のオリジナル・データを破壊するリスクがなくなります。

宛先を書き込み可能なボリュームまたは qtree に変換することにより、宛先のデータを使用できるようになります。特に、オリジナル・ソースが使用不可になった場合に便利です。

割り当て量の制限割り当て量は、ソース・ボリュームで割り当て量が使用可能になっているかどうかに関係なく、SnapMirror ボリューム宛先で常に使用不可になっています。ボリューム宛先で割り当て量を使用可能にしようとすると、SnapMirror はエラー・メッセージを表示します。割り当て量は、SnapMirror 宛先 qtree では使用不可になりません。

ソース・ボリュームまたは qtree と宛先が別のストレージ・システムに置かれていて、宛先を書き込み可能にした後でいくつかの割り当て量の制限を適用する場合、宛先システムに、ソース・システムによって使用されている /etc/quotas ファイルのすべての項目を含む /etc/quotas ファイルがなければなりません。

v データ・マイグレーションのために SnapMirror 複製を使用する場合、snapmirror

break コマンドを使用して宛先を書き込み可能にする前に、ソース・システムから /etc/quotas 項目を宛先システムの /etc/quotas ファイルにコピーすることができます。

v バックアップおよび潜在的な災害復旧のために SnapMirror 複製を使用する場合、ソース・システムによって使用されるすべての /etc/quotas 項目のコピーを常に宛先システム上で保持する必要があります。このようにすると、ソース・システムが使用不可になった場合に、宛先ボリュームまたは qtree の割り当て量項目を適用することができます。

SnapMirror 宛先の書き込み可能なボリュームまたは qtree への変換SnapMirror 宛先を書き込み可能なボリュームまたは qtree に変換するには、以下のステップを実行します。

1. 宛先システムで、snapmirror break コマンドを使用して宛先ボリュームまたはqtree を書き込み可能にします。

v 宛先ボリュームを書き込み可能にするには、宛先システムで次のコマンドを入力します。snapmirror break volume_name

v 宛先 qtree を書き込み可能にするには、宛先システムで次のコマンドを入力します。snapmirror quiesce /vol/volume_name/qtree_namesnapmirror break

/vol/volume_name/qtree_name


2. 以前の宛先ボリュームで割り当て量を使用可能にするには、以下のステップを実行します。

a. 以前の宛先システム上の /etc/quotas ファイルを編集して、変換後に以前の宛先にソース・ボリュームと同じ割り当て量の制限が適用されるようにします。元のソース・ボリュームがボリュームごとの割り当て量を使用する場合、割り当て量項目の元のソース・ボリューム名を以前の宛先名に置き換えます。

b. 次のコマンドを入力して以前の宛先で割り当て量を使用可能にします。quota

on volume_name

3. 以下のオプションの手段を検討します。

v SnapMirror ソースによる分断された宛先の更新を停止する場合、/etc/snapmirror. conf ファイルの項目を削除またはコメント化することができます。そうしないと、SnapMirror は引き続き宛先を更新しようとします。

v また、options fs_size_fixed off コマンドを使用して、宛先ボリューム上のファイル・システムのサイズを制限するオプションをオフにすることもできます。

注: options fs_size_fixed off を設定すると、宛先ボリュームとソース・ボリュームを再同期できることは保証されません。

snapmirror break コマンドの使用後snapmirror break コマンドを使用してソースと宛先の間の SnapMirror 関係を一時的に分断した後、他の SnapMirror コマンドを使用して、SnapMirror 関係を永続的に分断したり、復元または再定義することができます。

v 永続的に分断するには、snapmirror release コマンドを使用します。

v SnapMirror 関係を復元または再定義するには、snapmirror resync コマンドを使用します。


関連概念

167ページの『snapmirror resync コマンドが行う処理』snapmirror break コマンドの後、snapmirror resync コマンドをオリジナルのSnapMirror 宛先またはオリジナル・ソースに適用します。


関連タスク

『SnapMirror 関係からのパートナーの解放』ボリュームまたは qtree のソースと宛先ペアの間の SnapMirror 関係を永続的に終了するには、ソースと宛先のストレージ・システムで異なるコマンドを使用する必要があります。


SnapMirror 関係からのパートナーの解放ボリュームまたは qtree のソースと宛先ペアの間の SnapMirror 関係を永続的に終了するには、ソースと宛先のストレージ・システムで異なるコマンドを使用する必要があります。

このタスクについてv ソース・システム - snapmirror release コマンドを使用します。宛先ボリュームまたは qtree からソースを解放すると、ソースは、SnapMirror 関係の基本 Snapshot

コピーを削除できます。

v 宛先システム - snapmirror break コマンドを使用します。関係を分断した後、追加のステップを実行して宛先を修正する必要があります。これらの追加のステップが実行されないと、分断された関係に関連付けられている Snapshot コピーは宛先システムに保管されたままになり、snapmirror status コマンドは引き続き以前の宛先オブジェクトを現在の宛先オブジェクトとしてリストします。

1. ソース・システムで、次のコマンドを入力します。snapmirror release

{source_volume | qtree_path}[dest_system:]{dest_volume | qtree_path}

source_volume または qtree_path は、宛先から解放するソース・ボリュームの名前または qtree へのパスです。

dest_system は、宛先が置かれているシステムの名前です。

dest_volume または qtree_path は、宛先にあるボリュームの名前または qtree へのパスです。

宛先システムの名前を入力しない場合、SnapMirror は、コマンドを入力したシステムの名前を使用します。 SnapMirror ボリューム関係の場合

systemA> snapmirror release vol0 systemB:vol2

SnapMirror qtree 関係の場合


systemA> snapmirror release vol/vol1/qtree2 systemB:/vol/vol2/qtree5

SnapMirror は、SnapMirror 関係に専用であったソース・システムのすべてのリソースを解放します。

2. 宛先システムで、次のコマンドを入力してソース・オブジェクトと宛先オブジェクトの間の SnapMirror 関係を分断します。snapmirror break {vol_name |

qtree_path} vol_name は、関係から解放するボリュームの名前です。

qtree_path は、関係から解放する qtree のパスです。

3. 宛先システムで snapmirror status -l コマンドを使用して、分断した SnapMirror

関係に関連付けられている Snapshot コピーのベース名を判別します。

v SnapMirror ボリューム関係の場合 snapmirror status -l dest_vol

v SnapMirror qtree 関係の場合 snapmirror status -l /vol/dest_vol/

dest_qtree

表示される詳細な出力で、SnapMirror 関係に関連付けられている Snapshot コピーのベース名を書き留めます。

4. 宛先システムで次のコマンドを使用して、前のステップで表示した Snapshot コピー・セットを削除します。snap delete dest_vol snapshot_basename

5. Adminhost クライアントを介して、宛先システム上の /etc/snapmirror.conf ファイルを編集します。終了する SnapMirror 関係を指定する項目を見つけて削除します。


関連概念



関連タスク

133ページの『snapmirror.conf ファイルの編集』SnapMirror が使用可能になっている場合、/etc/snapmirror.conf ファイルに対する変更は 2 分以内で有効になります。SnapMirror が使用可能になっていない場合、/etc/snapmirror.conf ファイルに対する変更は、snapmirror on コマンドを使用して SnapMirror を使用可能にした直後に有効になります。


関連資料

134ページの『snapmirror.conf ファイル項目の構文』snapmirror.conf ファイルの項目の構文は次のとおりです。

snapmirror resync コマンドが行う処理snapmirror break コマンドの後、snapmirror resync コマンドをオリジナルのSnapMirror 宛先またはオリジナル・ソースに適用します。

v オリジナルの宛先に適用―snapmirror resync コマンドは、ボリュームまたは qtree

を SnapMirror 関係に戻し、初期転送を繰り返さずにその内容をソースと再同期させます。

v ソース・ボリュームに適用―snapmirror resync コマンドを使用して、ソース・ボリュームをオリジナルの宛先ボリュームのコピーにすることができます。このようにして、ソースと宛先の役割を反転できます。

注: SnapMirror がソースと宛先で再同期の基礎として使用する共通の Snapshot コピーを検出できない場合、再同期は不可能です。 SnapMirror は、問題を説明するエラー・メッセージを生成し、コマンドを終了します。 SnapMirror 関係を確立するには、宛先を再初期化する必要があります。

SnapMirror 関係の再同期snapmirror resync コマンドを使用して、snapmirror break コマンドによって分断された SnapMirror のソースまたは宛先の関係を復元または再定義することができます。


次のような場合にソースおよび宛先のボリュームまたは qtree を再同期することが必要になります。

v 現在のソースを別のボリュームまたは qtree に変更する。


v 宛先ボリュームをアプリケーション・テストのために書き込み可能にした後で、再び SnapMirror の宛先にする。

v ソースが使用不可になった災害から復旧する必要がある。

v ソースと宛先の機能を反転させる。

注: 宛先ストレージ・システムの再同期を実行する場合、宛先の内容はソースの内容によって上書きされます。

1. 宛先システムから、次のコマンドを入力します。snapmirror resync [options]

[dest_system:]{dest_volume | /vol/qtree_path} options は、以下のいずれかです。

v -n は、再同期を実行しませんが、snapmirror resync コマンドが実行された場合の結果を表示します。このオプションを使用して、特定の SnapMirror 関係を再同期するために、最新の共通 Snapshot コピー (基本 Snapshot コピー) として使用できる Snapshot コピーがソースおよび宛先にあるかどうかを調べることができます。

v -f は、ユーザーの確認を求めるプロンプトを出さずに操作を強制的に続行します。


v -S [source_system:]{source_volume | qtree_path} は、再同期のソースとして使用するシステムおよびボリュームまたは qtree を指定します。

-S オプションによって指定されたソースは、/etc/snapmirror.conf ファイルのソース項目と一致する必要があります。項目が存在してもソースが一致しない場合、この操作により、エラー・メッセージが表示されて終了します。指定されたソースの項目がない場合、コマンドは実行されます。

注: -S オプションが設定されていない場合、ソースが /etc/snapmirror.conf

ファイルで指定されている必要があります。指定されない場合、この操作により、エラー・メッセージが表示されて終了します。

dest_system は、宛先システムの名前です。

dest_volume または vol/qtree_path は、宛先のボリュームまたは qtree です。/etc/snapmirror.conf ファイルで指定されるスケジュール済みの宛先である場合、そのソースのボリュームまたは qtree がソースと見なされます。指定された宛先のボリュームまたは qtree がスケジュールされた関係ではない場合、-S

オプションを使用してソースを指定する必要があります。 SnapMirror は、再同期の基本として使用される最新の共通 Snapshot コピーを識別して、以下に該当する宛先の Snapshot コピーのリストを生成します。

v 基本 Snapshot コピーより新しく、削除される。

v 基本 Snapshot コピーより古く、既にソースから削除されている。

注: qtree の再同期の場合、共通 Snapshot コピーのみが表示されます。

次に、SnapMirror は、続行するかどうかを選択するためのプロンプトを表示します。


2. 必要に応じて、以下のいずれかのアクションを実行します。

状況処置

以下のことを実行する。

v SnapMirror ペアを再設定する。

v リストされた宛先ボリューム上の Snapshot

コピーを削除する (ボリュームを再同期している場合)。

プロンプトで y と入力します。

結果: SnapMirror は以下を行います。

v リストされた宛先ボリューム上の Snapshot

コピーを削除します (ボリュームを再同期している場合)。

v 宛先を読み取り専用にします。

v 宛先の更新を開始します。

宛先にある共通 Snapshot コピーより後に作成された Snapshot コピーのデータを失わずに、データを保存した後で 2 つのボリュームまたは qtree を再同期する。

v プロンプトで n と入力します。

v 保存するデータをソースまたは他のボリュームの手動でコピーします。

v ステップ 1 に戻り、snapmirror resync コマンドを再実行します。

SnapMirror 関係を再確立しない。プロンプトで n と入力します。

結果: SnapMirror はコマンドを終了します。

ボリュームの例

systemB> snapmirror resync systemB:vol2

The resync base snapshot will be vol2(0001234567)_d.4These newer snapshots will be deleted from the destination:hourly.0hourly.1These older snapshots have already been deleted from the source and will bedeleted from the destination:vol2(0001234567)_d.3Are you sure you want to resync the volume?

qtree の例

systemB> snapmirror resync -S systemA:/vol/vol2/qtreeBob systemB:/vol/vol3/qtreeBak

The resync base snapshot will be vol2(0001234567)_d.4Data could be lost as a result of this operation.Are you sure you want to resync the volume?

snapmirror resync コマンドがデータ損失を最小限にする方法snapmirror resync コマンドを使用すれば、長時間かかるベースライン転送を行わずに、分断した SnapMirror 関係を再確立できます。

このコマンドを実行する際には、ソースまたは宛先のどちらが再開した SnapMirror

関係のソースになるかを選択できます。2 つのボリュームまたは qtree が共有する最新の共通 Snapshot コピー (NCS) を検出し、コマンドを実行する対象のストレージ・システムに関するそれより新しい情報をすべて削除します。

注: snapmirror resync コマンドを使用するには、2 つのボリュームまたは qtree

に、少なくとも 1 つの共通した Snapshot コピーが必要です。両方に少なくとも 1

つの共通した Snapshot コピーが存在する限り、ボリュームまたは qtree を他の任意のボリュームまたは qtree と再同期させることができます。


再同期により、基本 Snapshot コピーの作成後に宛先に書き込まれたデータがすべて失われます。snapmirror resync コマンドは、再同期中に失われる可能性のあるデータをユーザーに通知し、処理を進めるための許可を要求します。宛先のデータを保存する必要がある場合は、再同期を停止して、必要なデータを他の場所に手動でコピーし、宛先に対して snapmirror resync コマンドを再発行できます。

データベース・アプリケーションのテスト: snapmirror resync の特殊な使用法データベースで実行されるソフトウェア・アプリケーションをテストすると、場合によってはデータベースが変更されたり、破壊されることがあります。そのようなソフトウェア・アプリケーションをテストする際に確実にデータを損失しないようにするために、テストの目的でデータを別のボリュームにコピーして、宛先ボリュームを分断して書き込み可能な状態に戻し、そこでテスト・アプリケーションを実行することができます。テストの完了時に、ソース・ボリュームと宛先ボリュームを再同期して、データを復元し、必要に応じた頻度でテストを繰り返すことができます。

始める前に

ソース・システムと宛先システムで SnapMirror が使用可能になっていることを確認します。


次の手順で、以下を行うために snapmirror break コマンドおよび snapmirror resync

コマンドの組み合わせを使用できます。

v 宛先ボリュームをテストのために書き込み可能にします。

v さらにテストが必要な場合、新しく書き込み可能になったボリュームを元の状態に復元します。

1. データベースを含むボリュームまたは qtree に対する宛先として使用するボリュームまたは qtree を作成または選択します。(この例では、Test_vol というボリュームを使用します。)

2. 宛先システムで、次のコマンドを入力して宛先を書き込み可能にします。snapmirror break Test_vol qtree の場合、次の例に示すようにパスを指定する必要があります。関係を分断する前に、qtree が静止していることを確認する必要があります。

dst> snapmirror quiesce /vol/dst_vol/Testqtreedst> snapmirror break /vol/dst_vol/Testqtree

3. 以前の宛先 (Test_vol) のデータに対してアプリケーションを実行します。

4. 以前の宛先 (Test_vol) でデータを確認します。


5. 次の表から適切なアクションを選択します。

状況処置

データが有用でない方法で変更されたため、さらにテストするためにデータの新しいコピーをインポートする

宛先システムから、次のコマンドを入力します。snapmirror resync Test_vol

注: qtree の場合、次の例に示すようにパスを指定する必要があります。

src> snapmirror resyncdst_system:/vol/dst_vol/Testqtree/vol/src_vol/Testqtree

SnapMirror は、以前の宛先ボリュームを再びSnapMirror 宛先にして、最新データで宛先を更新します。

有害な方法で変更されていない、あるいはテストを停止する

終了です。

6. 十分にテストするまで、ステップ 3、4、および 5 を繰り返します。

災害復旧のためのデータの取得: snapmirror resync の特殊な使用法災害によって SnapMirror 関係のソースが使用できなくなった場合、修復されたソースを更新してストレージ・システムの元の構成を再設定するための戦略としてsnapmirror resync コマンドを使用できます。


次の例で、元の (災害によって使用できなくなった) ソースは systemA:vol/volA

で、元の宛先は systemB:/vol/volB です。snapmirror break コマンドと snapmirror

resync コマンドまたは snapmirror initialize コマンドの組み合わせを使用して、以下のタスクを実行します。

v 一時的に systemB:volB をソースにして、systemA:volA を宛先にして、ミラーリングされたデータを systemA:volA に復元し、systemA:volA を更新します。

v systemA:/vol/volA および systemB:volB を、SnapMirror ソース・ボリュームおよび SnapMirror 宛先ボリュームとしての元の役割に復元します。

この例で、ソースが使用できなくなる前に最後にスケジュールされた SnapMirror

Snapshot コピーからのすべてのデータ、および書き込み可能になった後でsystemB:vol/volB に書き込まれたすべてのデータは保持されます。最後のSnapMirror Snapshot コピーから systemA:vol/volA が使用できなくなった時刻までの間に systemA:vol/volA に書き込まれたすべてのデータは保持されません。

1. ソース・ボリューム (この例では systemA:volA) が使用できなくなった後、管理者は次のように snapmirror break コマンドを使用して宛先ボリュームsystemB:volB を書き込み可能にします。snapmirror break systemB:volB

2. 管理者は、ソース systemA のクライアントをソース systemB にリダイレクトします。 systemA の以前のクライアントは、この時点で systemB にアクセスして書き込むようになっています。

3. 管理者は、元のソース・ボリュームを一時的に読み取り専用の宛先ボリュームにします。


v systemA:volA がリカバリー可能で、そのデータが損なわれない場合、systemA

の管理者は snapmirror resync コマンドを使用して systemA を systemB と再同期します。snapmirror resync -S systemB:VolB systemA:volA

v systemA:volA がリカバリー不能である場合、管理者は systemA に新しいvolA を作成して、systemA から systemB の systemA:volA を初期設定します。snapmirror initialize -S systemB:volB systemA:volA

また、このコマンドにより、systemA:volA は読み取り専用の宛先になります。

注: これらのコマンドは、元のソース・ストレージ・システムで実行する必要があります。

4. 管理者は、クライアントを systemB から systemA にリダイレクトします。クライアントは systemA:volA にアクセスしたり、書き込むことはできませんが、それ以降、新しいデータを systemB:volB に書き込むことはありません。

5. 管理者は systemB から systemA:volA を更新して、systemB から最新データを転送します。 systemB から次のステップを実行します。snapmirror update -S

systemB:volB systemA:volA

6. この時点で、管理者は snapmirror break コマンドを使用して systemA:volA を書き込み可能にします。systemA で、管理者は次のコマンドを入力します。snapmirror break volA

7. systemB から、管理者は snapmirror resync コマンドを使用して元の宛先であるsystemB を再び宛先にします。snapmirror resync volB

SnapMirror を使用するボリューム間でのデータの移動SnapMirror は、ストレージ・システムをリブートしたり、NFS クライアント上のボリュームに再マウントすることなく、ボリューム間でデータをマイグレーションして、NFS クライアントを新しいボリュームにリダイレクトすることができます。


マイグレーションは、現時点で SnapMirror 関係のソース・ボリュームと宛先ボリュームである 2 つのボリューム上で実行する必要があります。マイグレーション・プロセスを開始すると、SnapMirror は以下を行います。

v 宛先ボリュームへの SnapMirror インクリメンタル転送を実行します。

v ソース・ボリュームを使用してストレージ・システム全体への NFS および CIFS

サービスを停止します。

v NFS ファイル・ハンドルを宛先ボリュームにマイグレーションします。

v ソース・ボリュームを制限付きにします。

v 宛先ボリュームを読み取り/書き込みにします。

次のコマンドを入力します。snapmirror migrate [srcsystem:]srcvolume

[dstsystem:]dstvolume srcsystem は、ソース・システムです。srcvolume は、ソース・ボリュームです。dstsystem は、宛先システムです。dstvolume は、宛先ボリュームです。


データのマイグレーション時に SnapMirror が行わない処理SnapMirror は、次の処理を行いません。

v IP アドレス、ライセンス・キー、または割り当て量情報の転送。次のいずれかが当てはまらない限り、NFS クライアント上で再マウントを行う必要があります。

– マイグレーション後に、ソース・システムの IP アドレスを宛先システムに別途転送する。

– ソース・ボリュームと宛先ボリュームが同じシステム上にある。この場合、どちらのボリュームにも同じ IP アドレスによってアクセスできます。

v CIFS クライアントをマイグレーションする。宛先ボリュームにデータをマイグレーションした後、CIFS クライアント・セッションを再確立する必要があります。

SnapMirror ソースの移動についてボリューム SnapMirror ソースまたは qtree SnapMirror ソースのどちらを新規ストレージ・システムまたは新規ドライブに移動する場合にも、ソースと宛先に共通のSnapshot コピーが存在していれば、移動は円滑に進みます。

ボリューム SnapMirror は、すべての Snapshot コピーを SnapMirror 処理の一環として転送します。 Qtree SnapMirror には共通の Snapshot コピーがただ 1 つ存在し、それぞれの宛先には共通の Snapshot コピーは存在しません。それぞれの宛先には、複製しない限り共通の Snapshot コピーは存在しません。

実稼働環境では、SnapMirror 関係をボリューム間またはストレージ・システム間で移動する処理は、保守またはサービス休止の時間枠にのみ行う必要があります。移動中に新規データがオリジナル・ソースに追加されないようにしてください。

SnapMirror ソースの移動中に使用される用語以下の用語は、ボリューム SnapMirror ソースを移動するためのタスクの説明で使用されます。

v oldsource ― ソースが置かれている元のストレージ・システム。

v newsource ― ソースの移動先となるストレージ・システム。

v destination ― ソースの複製先となるストレージ・システム。

v oldsourcevol ― 元のソース・ボリューム。

v newsourcevol ― 移動先の新しいソース・ボリューム。

v destinationvol ― ソースの複製先となるボリューム。

ボリューム SnapMirror ソースの移動ボリューム SnapMirror ソース・ボリュームを別のソース・ボリュームに移動するには、以下のステップを実行します。

始める前に

宛先ストレージ・システムの Data ONTAP のメジャー・バージョンが、新しいソース・ストレージ・システムで実行されているメジャー・バージョン以上であることを確認します。


1. 次のコマンドを使用して、元のソースを新しいソースにコピーします。newsource> snapmirror initialize -S oldsource:oldsourcevol

newsource:newsourcevol

注: これが終了するまでにしばらく時間がかかることがあります。

2. 続行する前に古いソースを読み取り専用にしておくことをお勧めします。

3. 次のコマンドを使用して、古いソース・ストレージ・システムで手動 Snapshot

コピーを作成します。oldsource> snap create oldsourcevol common_Snapshot

4. 次のコマンドを使用して、古いソースに基づいて新しいソースと宛先を更新します。newsource> snapmirror update -S oldsource:oldsourcevol

newsource:newsourcevol destination> snapmirror update -S

oldsource:oldsourcevol destination:destinationvol

注: すべての Snapshot コピーはボリューム SnapMirrorを使用してミラーリングされるため、common_Snapshot コピーはすべてのボリュームに置かれます。

5. 次のコマンドを使用して、古いソースと宛先、および古いソースと新しいソースの間の SnapMirror 関係を静止および分断します。destination> snapmirror

quiesce destinationvol destination> snapmirror break destinationvol

newsource> snapmirror quiesce newsourcevol newsource> snapmirror break

newsourcevol

6. エディターを使用して、古いソース情報を新しいソース情報に置き換えることにより、新しい関係の宛先にある /etc/snapmirror.conf ファイルを更新します。現在の内容 oldsource:oldsourcevol destination:destinationvol

restart=always 0 * * * *

編集後の内容 newsource:newsourcevol destination:destinationvol

restart=always 0 * * * *

7. 次のコマンドを使用して、新しい SnapMirror 関係を確立します。destination>

snapmirror resync -S newsource:newsourcevol destination:destinationvol

注: SnapMirror 関係は、common_Snapshot より古いすべての Snapshot コピーを破棄します。つまり、前回の SnapMirror 更新で使用されたものです。これは予期されることであり、移動中に元のソース・ボリュームに新しいデータが追加されないようにした場合、データが失われることはありません。新しい SnapMirror 関係は、ミラーリングする共通の最も新しい Snapshot コピーを自動的に選択します。これは common_Snapshot になります。

8. 次のコマンドを使用して、SnapMirror 関係が再同期中であることを確認します。destination> snapmirror status


関連資料

92ページの『SnapMirror の使用に関する考慮事項』SnapMirror を複製のために使用する計画を立てる場合、以下の点を覚えておいてください。

92ページの『SnapMirror の前提条件』SnapMirror を使用するには、その前に一連の前提条件を満たす必要があります。

qtree SnapMirror ソースの移動ソースからすべての Snapshot コピーが宛先にミラーリングされるボリュームSnapMirror とは異なり、qtree SnapMirror では、ソース上に Snapshot コピーを作成して、それを宛先および新しいソースに強制的に伝搬する必要があります。

始める前に

宛先ストレージ・システムの Data ONTAP のメジャー・バージョンが、新しいソース・ストレージ・システムで実行されているメジャー・バージョン以上であることを確認します。


qtree SnapMirror ソースを移動するプロセスでは、元のソースに Snapshot コピーを作成してから、Snapshot コピーを新しいソースと既存の宛先の両方に複製します。これを行った後、Snapshot コピーはすべてのボリュームで共通になり、SnapMirror

関係が元のソースから分断され、新しいソースと既存の宛先の間で確立されます。

1. 次のコマンドを使用して、元のソースを新しいソースにコピーします。newsource> snapmirror initialize -S oldsource:/vol/oldsourcevol/qtree

newsource:/vol/newsourcevol/qtree

注: これが終了するまでにしばらく時間がかかることがあります。

2. 続行する前に古いソースを読み取り専用にしておくことをお勧めします。

3. 次のコマンドを使用して、古いソース・ストレージ・システムで手動 Snapshot

コピーを作成します。oldsource> snap create oldsourcevol common_Snapshot

4. 次のコマンドを使用して、ミラーを更新します。newsource> snapmirror update

-c common_Snapshot -s common_Snapshot -S oldsource:/vol/oldsourcevol/

qtree newsource:/vol/newsourcevol/qtree destination> snapmirror update

-c common_Snapshot -s common_Snapshot -S oldsource:/vol/oldsourcevol/

qtree destination:/vol/destinationvol/qtree snapmirror update コマンドの -s

オプションは、common_Snapshot に基づいて新しいソースを古いソースと同期し、宛先を古いソースと同期します。 snapmirror update コマンドの -c オプションは、common_Snapshot Snapshot コピーを宛先ストレージ・システムに作成します。

5. 次のコマンドを使用して、古いソースと宛先、および古いソースと新しいソースの間の SnapMirror 関係を静止および分断します。destination> snapmirror

quiesce /vol/destinationvol/qtree destination> snapmirror break

/vol/destinationvol/qtree newsource> snapmirror quiesce

/vol/volnewsourcevol/qtree newsource> snapmirror break

/vol/volnewsourcevol/qtree


6. エディターを使用して、古いソース情報を新しいソース情報に置き換えることにより、新しい関係の宛先にある /etc/snapmirror.conf ファイルを更新します。現在の内容 oldsource:/vol/oldsourcevol/qtree destination:/vol/

destinationvol/qtree restart=always 0 * * * *

編集後の内容 newsource:/vol/newsourcevol/qtree destination:/vol/

destinationvol/qtree restart=always 0 * * * *

7. 次のコマンドを使用して、新しい SnapMirror 関係を確立します。destination>

snapmirror resync -S newsource:/vol/newsourcevol/qtree

destination:/vol/destinationvol/qtree

注: SnapMirror 関係は、common_Snapshot より古いすべての Snapshot コピーを破棄します。つまり、前回の SnapMirror 更新で使用されたものです。これは予期されることであり、移動中に元のソース・ボリュームに新しいデータが追加されないようにした場合、データが失われることはありません。新しい SnapMirror 関係は、ミラーリングする共通の最も新しい Snapshot コピーを自動的に選択します。これは common_Snapshot になります。

8. 次のコマンドを使用して、SnapMirror 関係が再同期中であることを確認します。destination> snapmirror status

関連資料

92ページの『SnapMirror の使用に関する考慮事項』SnapMirror を複製のために使用する計画を立てる場合、以下の点を覚えておいてください。


SnapMirror を使用したテープへのボリュームのコピーさまざまな理由で、SnapMirror を使用して、ソース・ストレージ・システムからローカル・テープにボリュームをコピーする場合があります。

v SnapMirror ソースと SnapMirror 宛先の間で行われる、ベースライン転送のネットワーク転送時間が非常に長い。

v オフライン・ストレージのため、または SnapVault 2 次ストレージが失われた場合に備えた保護のために、SnapVault 2 次ストレージ・データをテープにバックアップする。

snapmirror store コマンドは、テープへの SnapMirror qtree 複製をサポートしません。ソースまたは宛先として qtree パスを指定すると、SnapMirror はエラー・メッセージを返します。


関連資料

120ページの『SnapMirror ソースからテープ、テープから宛先へのシナリオ』このシナリオでは、低帯域幅接続を介したソース・システムと宛先システムの間のSnapMirror 関係を確立します。低帯域幅接続を介したソースから宛先へのインクリメンタル Snapshot ミラーリングは実現可能ですが、初回の基本 Snapshot ミラーリングは不可能です。

183ページの『SnapVault 宛先からテープへのバックアップ』このシナリオでは、SnapMirror を使用して、バックアップの目的で Snapshot コピーを SnapVault 2 次ストレージ・システムから接続されたローカル磁気テープ・ドライブに複製します。SnapVault 2 次システムでデータ損失が発生した場合、指定された Snapshot コピーを元の SnapVault 2 次システムに復元することができます。

バックアップ方式としてテープへの SnapMirror コピーを使用する前の考慮事項データをローカル・テープにコピーするための SnapMirror 複製は、SnapMirror 関係の初期化プロセス用であり、バックアップ方式として使用する場合は制約事項があります。バックアップ方式としてテープへの SnapMirror を使用する前に、以下の制約事項について考慮してください。

ディスク・ジオメトリー SnapMirror がテープにデータを複製する場合、ソースまたは宛先のいずれかのファイル・システムのディスク・ジオメトリーに基づいてファイル・システムの書き込みを最適化します。デフォルトでソース・ファイル・システムのディスク・ジオメトリーが使用されますが、snapmirror store -g コマンドを使用して宛先ファイル・システムのディスク・ジオメトリーを指定することができます。詳しくは、na_snapmirror(1) マニュアル・ページを参照してください。

データをテープに書き込むときに使用されたストレージ・システムのディスク・ジオメトリーと一致しないファイル・システムにバックアップ・テープを取り出すと、取り出しが非常に低速になる可能性があります。注: FlexVol ボリュームを使用する場合、ボリュームの復元時のディスク・ジオメトリーの不一致は問題になりません。

ファイル・システム・バージョンテープに書き込まれるデータは、特定バージョンの Data ONTAP に関連付けられているファイル・システムのブロック単位のコピーです。そのため、テープからデータを取り出す場合、取り出しの宛先は、データをテープに保管するときに使用されたのと同じまたはそれ以降のバージョンの Data ONTAP を使用する必要があります。古いバージョンのData ONTAP を使用する宛先にデータを取り出そうとすると、取り出しは失敗します。


Snapshot コピーの問題テープへの SnapMirror の本来の目的は、SnapMirror 関係のミラーの初期化であるため、SnapMirror 関係がそれ以降に更新を実行するために使用する Snapshot コピーを維持します。バックアップ方式として使用される場合、Snapshot コピーは作成されますが、使用されることはありません。そのため、Snapshot コピーおよびデータ・リソースが無駄になります。注: snapmirror release および snapmirror

destinations コマンドを使用して、Snapshot

コピーを管理および削除することができます。詳しくは、na_snapmirror(1) マニュアル・ページを参照してください。

ボリューム・タイプ従来型ボリューム・ファイル・システムのフォーマットは、FlexVol ボリューム・ファイル・システムのフォーマットと異なります。この違いがあるため、バックアップされたFlexVol ボリュームを従来型ボリュームに取り出すことはできません。同様に、バックアップされた従来型ボリュームを FlexVol ボリュームに取り出すことはできません。

アーカイブ・サポートの欠如いくつかのバックアップは、長期にわたって保管されるために作成されます。そのため、古いバージョンのデータが長期保管されます。テープへの SnapMirror 複製を使用するバックアップは、Data ONTAP およびWAFL ファイル・システムのみが読み取ることが可能なフォーマットで、長期保管用ではありません。テープ一式を長期にわたって維持すると、それらを将来復元できる可能性がリスクにさらされます。

不良テープの影響テープからファイル・システムを取り出す場合、テープへの SnapMirror 複製のフォーマットでは、ファイル・システムが使用可能になる前にファイル・システム全体が取り出される必要があります。ファイル・システムを取り出す場合にテープが不良であると、ファイル・システムの全部を取り出すことができなくなります。そのため、ファイル・システムは構築不可能で、データの全部は使用可能になりません。

バックアップ機能の欠如データをテープにコピーするためのSnapMirror 複製を使用しても、バックアップ・ソフトウェアと同じ機能は提供されません。例えば、個別ファイルの復元、バックアップのインデックス付け、および増分バックアップなどの機能はサポートされません。


Protection Manager による SnapMirror 操作の管理Protection Managerグラフィカル・ユーザー・インターフェースを使用して、SnapMirror 環境での管理作業の一部を実行できます。

v 非同期および同期 SnapMirror 関係の作成および管理。

v 複製およびフェイルオーバーのポリシーの作成および管理。

v 関係および遅延時間に関するレポート。

v 複製の状態変更に関するアラート。

v レプリカ更新のスケジュール。

v 関係の表示。

v 障害が発生した後のデータ・サービスの容易なリカバリー。

詳しくは、「Protection Manager Administration Guide」を参照してください。

他のフィーチャーおよび製品と組み合わせた SnapMirror の操作

SnapMirror と vol copy コマンドの比較SnapMirror と vol copy コマンドは、ソースから宛先にボリュームをコピーするために使用できます。これらの間には類似点もいくつかありますが、大きな違いもあります。

次に、SnapMirror と vol copy コマンドの類似点のリストを示します。

v どちらを使用しても、ソース・ボリュームから宛先ボリュームに Snapshot コピーをコピーできます。

v ソース・ボリュームと宛先ボリュームは両方とも、従来型のボリュームまたはFlexVol ボリュームのどちらかであることが必要です。

注: qtree SnapMirror を使用して、従来型のボリュームと FlexVol ボリュームの間でデータを複製できます。

v ボリュームは同じタイプであることが必要です。

次の表に示すように、これらのコマンドはいくつかの重要な点で異なっています。

SnapMirror vol copy コマンド

ソース・ボリュームから宛先ボリュームに複製される、Snapshot コピーのスケジュール・インクリメンタル更新をサポートします。

インクリメンタル更新はサポートしません。

ソース・システムと宛先システムの間でqtree レベルの複製をサポートします。

ボリュームの複製のみをサポートし、qtree

レベルの複製はサポートしません。

適切なライセンスが必要です。別途ライセンスは必要としません。

ボリューム SnapMirror と qtree SnapMirror の比較SnapMirror 複製は、ボリューム全体、またはボリューム上の個々の qtree を対象に構成できます。これら 2 つのオプションの相違点を考慮する必要があります。


次の表では、SnapMirror 複製の特性について説明します。

SnapMirror ボリューム複製 SnapMirror qtree 複製

同期複製または非同期複製非同期複製のみ

宛先ボリュームは読み取り専用。宛先 qtree は読み取り専用。ただし、qtree

が置かれるボリュームはオンラインで書き込み可能になっていることが必要です。

ソース・ボリュームと宛先ボリュームは両方とも、従来型のボリュームまたは FlexVol ボリュームのどちらかであることが必要です。

ソースおよび宛先の qtree は、従来型のボリュームまたは FlexVol ボリュームのどちらのボリューム・タイプであっても構いません。

ソース・ボリュームの Snapshot コピー、およびすべての qtree を宛先ボリュームに複製します。

個々の qtree の内容のみを宛先に複製します。

宛先ボリュームのセットを複製対象としてセットアップする前に、制限付きの読み取り専用状況に設定する必要があります。

qtree 複製の宛先ボリュームは書き込み可能にし、読み取り専用であってはなりません。

宛先でボリュームの複製を行うと、データの保管に使用されたボリュームの量に関係なく、ソース・ボリュームに割り振られたスペースが占有されます。

個々の qtree に保管されたデータのみをミラーリングする必要がある場合は、その個々のqtree の SnapMirror複製を行うと、ソースqtree と同じ量のディスク・スペースのみが宛先ボリューム上で使用されます。

宛先ボリュームへの複製元としてセットアップできるソース・ボリュームはただ 1 つです。つまり、1 つの宛先ボリュームを複数のソース・ボリュームの複製に使用することはできません。

1 つのボリューム上で最大 255 の qtree に対して複製をセットアップできます。

ブロック単位での複製

ファイル・システムを完全に現状のままの状態で転送します。したがって、Data ONTAP

の旧リリースでは、新しいリリースの Data

ONTAP から転送されたファイル・システムを認識できません。

論理複製

ソース・ファイル・システム内のファイルとディレクトリーはすべて、宛先ファイル・システム内で作成されます。したがって、Data

ONTAP の旧バージョンを実行するストレージ・システムと新バージョンを実行するストレージ・システムの間で、データを複製できます。注: ソース・ファイル・システムに宛先ファイル・システム上では表現できないファイル・タイプが含まれている場合、複製は失敗します。

関連資料


qtree SnapMirror と SnapVault の比較次の表は、qtree SnapMirror と SnapVault を比較したものです。


Qtree SnapMirror SnapVault

即時フェイルオーバー機能を提供する場合に適しています。

データ可用性の重要性が低く、即時フェイルオーバーが必要でない場合には、さらに適しています。

ソースと宛先のストレージ・システムで、同じソフトウェアとライセンスを使用します。

異なる機能を備えた SnapVault ソース・システムおよび SnapVault 宛先システムを使用します。

毎分 1 回の最大頻度で転送のスケジュールを設定できます。

毎時 1 回の最大頻度で転送のスケジュールを設定できます。

ソース・ボリューム内のすべての qtree が、ソース・システム上でそれぞれ 1 つのSnapshot コピーを使用します。

ただ 1 つの Snapshot コピーが使用されます。

複製に必要ない場合は、Snapshot コピーがqtree SnapMirror によって削除されます。

Snapshot コピーは保存され、指定のスケジュールに従って削除されます。

関係は反転できます。これにより、ソースを宛先で行われた変更内容に再同期させることができます。

関係は反転できません。このため、データをリストアする目的でのみ宛先からソースにデータを転送できます。複製の方向は反転できません。

Data ONTAP を実行するストレージ・システム間でのデータ複製のみに使用できます。

IBM システム、およびオープン・システムの両方のバックアップに使用できます。ただし、宛先ストレージ・システムは IBM ストレージ・システムであることが必要です。

qtree SnapMirror を使用する LUN クローンの転送Data ONTAP 7.3 より前は、SnapMirror はそれぞれの LUN クローンを新しい LUN

として認識します。そのため、LUN クローンの初回転送時に、LUN クローンおよび元の LUN からのすべてのデータは 2 次ストレージ・システムに転送されます。

LUN を含むボリューム上のデータのバックアップおよび復元の説明については、「Data ONTAP ブロック・アクセス管理ガイド (iSCSI および FC 用)」を参照してください。

SnapMirror を使用する LUN クローンの転送は、非最適化モードの SnapVault を使用する LUN クローンの転送と同じ方法で機能します。

注: qtree SnapMirror は、非最適化モードでのみ LUN クローンを転送します。qtree

SnapMirror には、最適化された転送のオプションはありません。


関連概念

226ページの『LUN クローンと SnapVault』LUN クローンは、別の LUN を高いスペース効率でコピーしたものです。最初は、LUN クローンとその親は同じストレージ・スペースを共有します。一方または他方の LUN が変更された場合に限って、追加のストレージ・スペースが消費されます。

SnapDrive ソフトウェアでの SnapMirror の使用SnapDrive ソフトウェアを使用している場合は、SnapMirror を使用してデータを複製します。

詳しくは、ご使用の SnapDrive のバージョンに対応する「SnapDrive Installation and

Administration Guide」を参照してください。

SnapDrive は、非同期モードでのボリューム SnapMirror の使用をサポートしています。同期モードまたは半同期モードのボリューム SnapMirror の場合は、SnapDrive

5.0 を使用する必要があります。

SnapDrive は、qtree SnapMirror 複製をサポートしません。

MultiStoreソフトウェアでの SnapMirror の使用MultiStore ソフトウェアを使用している場合は、SnapMirror を使用して、災害復旧用 vFiler ユニットをマイグレーションまたは作成します。詳しくは、「Data

ONTAP MultiStore Management Guide」を参照してください。

FlexClone が SnapMirror に与える影響FlexClone ボリュームは、SnapMirror のソース・ボリュームまたは宛先ボリュームから作成できます。ただし、ボリュームを作成する前に、作成される FlexClone ボリュームの性質を理解しておく必要があります。

FlexClone ボリュームは、ボリュームのほぼ瞬間的なレプリカを同じアグリゲート内に作成します。FlexClone ボリュームについては、「Data ONTAP ストレージ管理ガイド」を参照してください。

SnapMirror ボリュームのクローン作成: SnapMirror ボリュームのクローンを作成できます。 SnapMirror 宛先のクローンは、クローンが作成される元になったSnapshot コピーをロックします。また、ソース・ボリューム内にあるその Snapshot

コピー、およびカスケード内のすべてのボリューム (ボリュームが SnapMirrorカスケードに含まれている場合) もロックします。

qtree SnapMirror を使用するボリュームのクローン作成と、ボリューム SnapMirror

を使用するボリュームのクローン作成には異なる点があります。Snapshot コピー名を指定せずに、qtree SnapMirror 複製の宛先であるボリュームのクローンを作成すると、クローン・ボリュームの SnapMirror関係が分断されるまで、クローンは書き込み不可になります。クローンの作成時に Snapshot コピー名を指定すると、クローン・ボリュームの SnapMirror 関係が分断され、ボリュームは書き込み可能になります。ボリューム SnapMirror の宛先ボリュームのクローンには、このような性質はありません。


注: FlexClone ボリュームは SnapMirror 宛先内の Snapshot コピーから作成できますが、FlexClone ボリュームを SnapMirror 関係の宛先にすることはできません。

最新の Snapshot コピーでない Snapshot コピーからのクローン作成: FlexClone ボリュームが最新の Snapshot コピーではない Snapshot コピーから作成され、そのSnapshot コピーが現在はソース・ボリュームに存在しない場合、更新のたびに宛先にある Snapshot コピーを削除する必要があります。この場合、クローンが破棄または分割されるまで、宛先ボリュームに対する SnapMirror 更新はすべて失敗します。

注: クローンが SnapMirror 宛先にある最新の Snapshot コピーから作成された場合、この問題は発生しません。これは、その Snapshot コピーがソース・ボリュームに存在することが保証されているからです。

ソース Snapshot コピーの削除による影響: SnapMirror 関係のソース Snapshot コピーが削除されると、後続の更新要求では SnapMirror が失敗します。この失敗が起こる理由は、FlexClone ボリュームがソースまたは宛先のどちらのボリュームで作成されたかに関係なく、FlexClone ボリュームはソース Snapshot コピーにバインドされるからです。FlexClone ボリュームがリモート側の宛先システム上で作成された場合であっても、ソース・システム上でソース Snapshot コピーが削除されると、その削除を宛先に伝搬する際に SnapMirror 更新が失敗します。SnapMirror 更新を続行するために、FlexClone ボリュームを削除または分割できます。

SnapVault 宛先からテープへのバックアップこのシナリオでは、SnapMirror を使用して、バックアップの目的で Snapshot コピーを SnapVault 2 次ストレージ・システムから接続されたローカル磁気テープ・ドライブに複製します。SnapVault 2 次システムでデータ損失が発生した場合、指定された Snapshot コピーを元の SnapVault 2 次システムに復元することができます。

注: このシナリオは、SnapVault 2 次ストレージのバックアップにのみ適用されます。この構成をその他の目的で適用しないでください。

ローカル磁気テープ・ドライブが接続された SnapVault 2 次システムが必要です。また、2 次ストレージ qtree が置かれているボリュームが SnapMirror ソース・ボリュームとして構成されている必要があります。

この配置をセットアップするには、次の一連のアクティビティーに従う必要があります。

1. SnapVault 2 次システム/SnapMirror ソース・システムで、snapmirror store コマンドを使用してボリュームの Snapshot コピーをテープにコピーし、複数のバックアップ・テープが必要な場合は snapmirror use コマンドを使用してコピーを続行します。

2. snapmirror update コマンドを使用して、手動でテープへのインクリメンタル更新をミラーリングします。

3. SnapVault 2 次ストレージ・システムでデータ損失が発生した場合、SnapVaultデータを保持するボリュームを SnapMirror ソース・ボリュームとしての役割から宛先ボリュームに変換して、テープの内容をミラーリングして戻し、復元した宛先ボリュームを元の通常のボリュームに変換します。


関連タスク

『SnapVault ボリュームからローカル・テープへのコピー』SnapMirror を使用して SnapVault ボリュームをテープにバックアップすることができます。テープ上のバックアップは、後でデータを SnapVault ボリュームに復元するために使用できます。

185ページの『ローカル・テープからの SnapVault の復元』SnapMirror のソースとして構成されている SnapVault 2 次ストレージ・ボリュームでデータ損失が起こった場合、snapmirror retrieve コマンドによって、SnapMirror を使用してテープに複製されたデータを SnapVault 2 次ストレージ・ボリュームに復元することができます。

SnapVault ボリュームからローカル・テープへのコピーSnapMirror を使用して SnapVault ボリュームをテープにバックアップすることができます。テープ上のバックアップは、後でデータを SnapVault ボリュームに復元するために使用できます。

1. SnapVault 2 次ストレージ・システムで、テープをローカル接続された磁気テープ装置にロードします。

2. SnapVault 2 次ストレージ・システムで、次のコマンドを入力してテープへのデータ転送を開始します。snapmirror store sv_volume dest_tapedevices

sv_volume は、コピーするボリュームです。

dest_tapedevices は、ボリュームのコピー先とする磁気テープ装置のコンマ区切りリストです。 SnapMirror は、テープへのデータ転送を開始します。このコマンドにより、ベースライン転送が作成されます。複数のテープを使用する必要がある場合、SnapMirror は、別のテープを求めるプロンプトを表示します。

3. SnapMirror が別のテープを求めるプロンプトを表示する場合、別のテープをドライブに追加してから、次のコマンドを入力してテープへのデータ転送を続行します。snapmirror use dest_tapedevices tape_drive dest_tapedevices は、ボリュームのコピー先とする磁気テープ装置のコンマ区切りリストです。

tape_drive は、準備した新しいテープを保持しているドライブです。

注: snapmirror use コマンドは、テープからの qtree のコピーをサポートしません。qtree パスをソースまたは宛先として指定すると、SnapMirrorはエラー・メッセージを返します。

4. SnapMirror がボリュームのテープへのコピーを終了するまで、上記のステップを繰り返します。

5. バックアップした SnapVault 2 次システム上のボリュームを復元する必要が生じた場合は、テープ上のバックアップを使用してボリュームを復元します。


関連タスク

『ローカル・テープからの SnapVault の復元』SnapMirror のソースとして構成されている SnapVault 2 次ストレージ・ボリュームでデータ損失が起こった場合、snapmirror retrieve コマンドによって、SnapMirror を使用してテープに複製されたデータを SnapVault 2 次ストレージ・ボリュームに復元することができます。

ローカル・テープからの SnapVault の復元SnapMirror のソースとして構成されている SnapVault 2 次ストレージ・ボリュームでデータ損失が起こった場合、snapmirror retrieve コマンドによって、SnapMirror を使用してテープに複製されたデータを SnapVault 2 次ストレージ・ボリュームに復元することができます。


snapmirror retrieve コマンドは、完全ボリュームのみを復元します。qtree パスをソースまたは宛先として指定すると、SnapMirrorはエラー・メッセージを返します。

1. SnapVault 2 次ストレージ・システムで、vol restrict コマンドを使用して、テープから復元するボリュームを制限状態にします。ボリュームを制限する方法について詳しくは、「System Administration Storage Management Guide」を参照してください。

2. (snapmirror store コマンドによって作成された) テープをローカル磁気テープ装置にロードします。

3. SnapVault 2 次ストレージ・システムで次のコマンドを入力することによって初期化を開始します。snapmirror retrieve [-h] rest_volume tape_drive -h オプションは、ソース・テープのヘッダーを表示しますが、データを転送しません。

rest_volume は、復元するボリュームです。

tape_drive は、ボリュームの復元元のテープ装置または装置のコンマ区切りリストです。 SnapMirror は、テープからのデータ転送を開始します。データが複数のテープに保管されている場合、SnapMirror は、次のテープを求めるプロンプトを表示します。

4. Data ONTAP が別のテープを求めるプロンプトを表示したら、次のテープをドライブに追加してから、次のコマンドを入力して初期化を再開します。snapmirror

use rest_volume tape_list rest_volume は、復元先のボリュームです。

tape_list は、ボリュームの復元元のテープ装置です。

5. SnapMirror がテープからのボリュームの初期化を終了するまで、上記のステップを繰り返します。

6. 先ほど復元したベースライン Snapshot データへのインクリメンタル更新がテープに存在する場合、そのテープを SnapVault 2 次ストレージ・システムのローカル・テープ・ドライブに挿入して、次のコマンドを入力します。snapmirror

update [options] [sv_secondary:]sv_volume options は、以下の 1 つ以上が可能です。



v -S [source_system:]source_volume は、マイグレーションするソース・システムおよびボリュームを指定します。source_volume は、コピーするボリュームです。

sv_secondary は、復元先とする SnapVault 2 次システムの名前です。

sv_volume は、復元するボリュームです。

7. テープから SnapVault へのすべての取得および更新の操作が完了した後で、snapmirror break コマンドを使用して、復元されたシステム・ボリュームを書き込み可能な状態に戻します。snapmirror break /vol/volume_name/

関連概念


dump コマンドを使用する場合の SnapMirror の動作dump コマンドを使用して、SnapMirror 宛先ボリュームからデータをバックアップできます。dump コマンドは、最新の Snapshot コピーを選出して、テープにコピーします。

宛先で snap list コマンドを実行すると表示される、任意の Snapshot コピーをバックアップできます。また、ソース・ボリューム上で Snapshot コピーを作成し、Snapshot コピーを宛先にコピーしてから、dump コマンドを使用してこの Snapshot

コピーを宛先からテープにバックアップすることもできます。

SnapMirror 宛先の更新スケジュールに対する dump コマンドの効果dump コマンドを SnapMirror 宛先に対して実行すると、その宛先での SnapMirror

操作がいくつかの点で影響を受けます。

v 宛先ボリュームのスケジュールに基づくインクリメンタル SnapMirror 更新は、テープに対する dump コマンド操作と同時に行われる可能性があります。宛先ボリュームへのスケジュール SnapMirror 更新で、dump コマンド操作が現在テープに書き込んでいる Snapshot コピーの削除が行われる場合、dump コマンド操作が完了するまで SnapMirror 更新は延期されます。

注: 宛先 qtree の SnapMirror 更新は、どの状況でも dump コマンド操作の影響を受けません。

v snapmirror break、snapmirror resync、および snapmirror migrate コマンドの操作は、dump コマンドの操作と同時に行われません。

ボリューム SnapMirror を使用した SnapVault 2 次システムの保護

ボリューム SnapMirror は、SnapVault 2 次ストレージ・システム上のボリュームから、Data ONTAP を実行するリモート (3 次) ストレージ・システム上のボリュームにデータをマイグレーションする SnapMirror 関係を作成して、SnapVault 2 次シ


ステムを保護します。 SnapMirror は、SnapVault 2 次データの正確なレプリカを 3

次ストレージ・システム上で提供します。

ボリューム SnapMirror を使用して SnapVault 2 次システムを保護する利点は、ソフト・ロック・サポートによって、オリジナルの SnapVault 1 次ストレージ・システムと 3 次ストレージ・システムの間の SnapVault 関係を継続でき、初期ベースライン転送は必要ないことです。

注:

このソリューションをデプロイするには、SnapMirror および SnapVault を使用するための適切なライセンスを使用していることを確認してください。この 3 次システム上で sv_ontap_sec のライセンスを有効にしていない場合、新しい 2 次システム(SnapMirror 宛先でもある) 上で SnapVault コマンドを実行することはできません。

例えば、SnapVault 2 次ストレージ・システムが災害のために使用不能になった場合は、以降の SnapVault 転送を、使用不能な 2 次ストレージ・システムの代わりに、3 次ストレージ・システムに手動でリダイレクトできます。 3 次ストレージ・システムは新しい SnapVault 2 次ストレージ・システムになり、1 次と 3 次のストレージ・システムに共通の最新 Snapshot コピーを使用して、SnapVault 転送は続行します。

ボリューム SnapMirrorを使用した SnapVault データのマイグレーションベースライン転送を実行せずに、SnapVault 宛先 qtree を含むボリュームを 1 つの2 次ストレージ・システムから 3 次ストレージ・システムにマイグレーションするには、以下のステップを実行します。

始める前に

Open Systems SnapVault ベースラインがあることを確認します。例えば、次の手順では、bno:C:¥500MB ディレクトリーのベースラインが r200-old:

/vol/old_vol/bno_C_500MB にバックアップされたとします。

1. SnapMirror を使用して、ボリュームを現在の 2 次ストレージ・システムから新しい 2 次ストレージ・システム上のボリュームに複製します。 old_vol ボリュームを r200-old 2 次ストレージ・システムから r200-new 2 次ストレージ・システム上の new_vol ボリュームに複製するには、新しい 2 次ストレージ・システム(r200-new) で以下のステップを実行します。

a. new_vol ボリュームを作成します。r200-new> vol create new_vol 3

b. new_vol ボリュームに制限付きのマークを付けます。r200-new> vol

restrict new_vol

c. old_vol ボリュームを new_vol ボリュームに転送します。r200-new>

snapmirror initialize -S r200-old:old_vol new_vol

2. 古い 2 次ストレージ・システムと新しい 2 次ストレージ・システムの間のSnapMirror 関係を静止および分断します。 r200-old と r200-new の間のSnapMirror 関係を静止および分断するには、r200-new で以下のステップを実行します。

a. snapmirror quiesce new_vol


b. snapmirror break new_vol

3. 新しい 2 次ストレージ・システムで SnapMirror 状況および SnapVault 状況を確認します。SnapMirror 状況は「Broken-off」のはずです。SnapVault 状況は、新しい 2 次ストレージ・システムの新しいボリュームへの「Snapvaulted」になっているはずです。 r200-new から次のステップを実行します。

a. snapmirror status

Source Destination Stater200-old:old_vol r200-new:new_vol Broken-off

b. snapvault status

Source Destination Statebno:C:¥500MB r200-new:/vol/new_vol/bno_C_500MB Snapvaulted

4. snapvault status -c コマンドを使用して、SnapVault 構成情報が新しい 2 次ストレージ・システムに存在しないことを確認します。 r200-new から次のステップを実行します。snapvault status -c

Snapvault secondary is ON.

5. options snapvault.access コマンドを使用して、SnapVault 1 次ストレージ・システムから新しい SnapVault 2 次ストレージ・システムへのアクセスを使用可能にします。 r200-new から次のステップを実行します。options snapvault.access

host=r200-old

注: SnapVault を使用する際、アクセス権を 1 次と 2 次の両方のストレージ・システムで指定する必要があります。

6. snapvault start コマンドを使用して、SnapVault 構成情報を新しい 2 次ストレージ・システム上のレジストリーに追加します。

注: これにより新しいベースラインが開始されるのではなく、レジストリーが更新されます。r200-new から次のステップを実行します。snapvault start -S bno:C:¥500MB

r200-new:/vol/new_vol/bno_C_500MB

SnapVault configuration for the qtree has been set.Qtree /vol/new_vol/bno_C_500MB is already a replica.

7. snapvault status -c コマンドを使用して、SnapVault 構成情報が新しい 2 次ストレージ・システムに存在することを確認します。 r200-new から次のステップを実行します。snapvault status -c

SnapVault secondary is ON./vol/new_vol/bno_C_500MB source=bno:C:¥500MB

8. r200-new を手動で更新することによって、新しい SnapVault 関係をテストします。コマンド行を使用して環境を管理している場合、次のステップに進みます。そうでない場合は、これで終了です。 r200-new から次のステップを実行します。snapvault update r200-new:/vol/new_vol/bno_C_500MB


Transfer started.Monitor progress with 'snapvault status' or the snapmirror log.

9. 古い 2 次ストレージ・システムで使用されていたスケジュールを新しい 2 次ストレージ・システムで再作成して、アクセス許可が設定されていることを確認します。

SnapMirror の問題のトラブルシューティング

宛先ボリューム名を変更した場合SnapMirror 宛先ボリュームの名前を変更する場合、変更の影響を受ける SnapMirror

関係を手動で修正する必要があります。SnapMirror は、構成情報が不完全な新しい名前の宛先ボリュームにソース・ボリューム・データを複製できません。

次のケースでは、宛先の volJobak が volStatbak に名前変更されました。名前変更の後、snapmirror status コマンドはソースを表示しません。その代わり、この項目はソース列でダッシュ (-) と共に示されます。

systemB> vol rename volJobak volStatbak

volJobak renamed to volStatbakyou may need to update /etc/exports

systemB> snapmirror status volJobakSnapmirror is on.

systemB>snapmirror status volStatbakSnapmirror is on.Source Destination State Lag Status- systemB:volStatbak Snapmirrored -00:03:22 Idle

SnapMirror ソースまたは宛先のボリューム名を変更する場合、以下の変更を行う必要があります。

v snapmirror.conf ファイルを更新します (古い項目がある場合)。

v snapmirror release コマンドを使用して古い宛先名を更新し、SnapMirror がソフト・ロックおよび古い Snapshot コピーを解放するようにします。

v 新しいボリューム名に対して snapmirror update コマンドを使用し、状況レジストリーが新しいボリューム名で更新されるようにします。

v /etc/exports ファイルを更新します。

注: ストレージ・システムが同時転送の限界で稼働しているときに、手動でsnapmirror update コマンドを使用してさらに転送を開始しようとすると、試行された転送は失敗します。

SnapMirror Snapshot コピーの予定外の削除SnapMirror ソースまたは宛先のいずれかの場所に保管されている SnapMirror

Snapshot コピーを削除してはなりません。


基本 Snapshot コピー (最新の共通 Snapshot コピー) がソースまたは宛先のいずれかのロケーションから誤って削除された場合、次のようにしてリカバリーを試行してください。

SnapMirror 関係を分断してから、ソースと宛先を再同期することにより、宛先を再初期化することなくリカバリーできる可能性があります。

ソースと宛先で共通の Snapshot コピーが少なくとも 1 つある場合、再同期は成功します。

ソースと宛先で共通の Snapshot コピーがない場合、snapmirror initialize コマンドをネットワーク経由で使用する必要があります。あるいは、ソースと宛先がボリュームである場合、snapmirror store コマンドを使用してソース・ボリュームをテープに保管し、次に snapmirror retrieve コマンドを使用してボリュームをテープから宛先に復元します。

関連概念


関連タスク


SnapMirror over Fibre Channel に関連する問題のトラブルシューティング

SnapMirror over Fibre Channel 接続をセットアップする際に問題が発生する場合があります。次の表に、発生する可能性があるいくつかの問題と、これらの問題を解決するために推奨される方法をリストします。


問題解決法

接続障害 1. ストレージ・システムとスイッチの間のケーブル接続を調べて、接続が緩くなっていないことを確認してください。

2. ポートを ping します。接続が良好である場合は、次のような出力が表示されます。

filer_1*> ping -s 10.1.1.26

64 bytes from 10.1.1.26 (10.1.1.26):icmp_seq=0 ttl=255 time=0.903 ms




--- 10.1.1.26 ping statistics ---

4 packets transmitted, 4 packetsreceived,

0% packet loss

round-trip min/avg/max =0.439/0.561/0.903 ms

接続障害がある場合は、次のように表示されます。

filer_1*> ping 10.1.1.26

no answer from 10.1.1.26


問題解決法

ローカル・ファイバー・チャネル NIC ポートがオフラインになっている可能性がある

1. ifconfig コマンドを入力して、ファイバー・チャネル NIC ポートの状態を検査します。

2. 下記のように、ifconfig 出力に UP 状態が表示されない場合、インターフェースは停止されています。

filer_1*> ifconfig ql4a

ql4a: flags=800040<RUNNING,LINK_UP>mtu 8160

inet 1.1.1.15 netmask 0xffffff00broadcast 0.0.0.0

partner inet 1.1.1.16 (not in use)ether 00:00:00:00:00:00 (VIA Provider)

3. 次のコマンドを入力して、この問題を修正します。ifconfig interface_name up

4. 出力に LINK_UP 状態が表示されない場合、物理接続はオフラインになっています。

filer_1*> ifconfig ql4a

ql4a: flags=40041<UP,RUNNING> mtu 8160inet 1.1.1.15 netmask 0xffffff00broadcast 0.0.0.0

partner inet 1.1.1.16 (not in use)ether 00:00:00:00:00:00 (VIA Provider)

5. この場合、光ファイバー・ケーブルを含む物理接続と FC スイッチ側の構成を検査してください。


問題解決法

リモート・ファイバー・チャネル NIC ポート情報が正しくない可能性があり、ローカル・ポートがリモート・ポートを「認識」していない可能性がある

1. fcnic コマンドを使用して、ローカル FC

NIC ポートが一緒にゾーニングされているリモート・ポートを「認識」できることを確認します。このコマンドを実行するには、診断権限が必要です (priv set

diag コマンド)。出力例を下に示します。

filer_1*> fcnic show fabric ql4a

pid = 0xa01000 wwn =20:00:00:e0:8b:14:67:afIP addr(s) = 10.1.1.13

* pid = 0xa01200 wwn =20:00:00:e0:8b:0a:a8:6dIP addr(s) = 10.1.1.15

pid = 0xa01300 wwn =20:01:00:e0:8b:2a:aa:6dIP addr(s) = 10.1.1.16

pid = 0xa01800 wwn =20:00:00:e0:8b:14:70:afIP addr(s) = 10.1.1.26

Port Login database:

pid = 0xfffffe, lid = 0x7epid = 0xfffffc, lid = 0x80pid = 0xa01800, lid = 0xeepid = 0xfffffa, lid = 0xef

2. 先頭にアスタリスク (*) が付いた項目は、コマンド行で指定されたローカル項目です。この出力には、一緒にゾーニングされているすべての FC NIC ポート(リモートおよびローカル) が表示されます。項目が欠落しているか、項目の中の情報が欠落している場合は、接続の問題を示しています。


問題解決法

ファイバー・チャネル・スイッチが正しく構成されていない可能性がある

1. ファイバー・チャネル接続の問題を突き止めるには、ファイバー・チャネル・スイッチおよびストレージ・システムが接続されているファブリックを調べます。

2. 正常な作動状態では、FC NIC ポートがF ポートとして FC スイッチと通信します。次の例は、Brocade スイッチに関するswitchshow コマンドの出力を示しています。

brcd_sw_1:root> switchshow

switchName: brcd_sw_1switchType: 9.2switchState: OnlineswitchMode: NativeswitchRole: PrincipalswitchDomain: 160switchId: fffca0switchWwn: 10:00:00:60:69:51:58:d9switchBeacon: OFFZoning: ON (sm_zone_cfg)

port 0: id N2 OnlineF-Port 20:00:00:e0:8b:14:67:af

port 1: id N1 OnlineF-Port 20:00:00:e0:8b:0a:16:6e

port 2: id N2 OnlineF-Port 20:00:00:e0:8b:0a:a8:6d

port 3: id N2 OnlineF-Port 20:00:00:e0:8b:0a:aa:6d

port 4: id N2 No_Lightport 5: id N2 OnlineF-Port 21:00:00:e0:8b:0a:15:6e

port 6: id N1 OnlineF-Port 20:00:00:e0:8b:14:7c:af

port 7: id N2 OnlineF-Port 21:00:00:e0:8b:14:9c:af

port 8: id N2 OnlineF-Port 20:00:00:e0:8b:14:70:af

port 9: id N2 No_Lightport 10: id N2 No_Lightport 11: id N2 No_Lightport 12: id N2 No_Light L2port 13: id N2 No_Lightport 14: id N2 No_Lightport 15: id N2 No_Light

3. 対応するポートが F ポートとして表示されない場合、ストレージ・システム上のファイバー・チャネル NIC ポートとスイッチ・ポートの間で折衝の問題が起こっています。スイッチ・ポート構成 (特にポート・トポロジーおよび速度の構成) を確認してください。


問題解決法

スイッチ・ネーム・サーバーにすべてのファイバー・チャネル NIC ポート項目がない可能性がある

1. スイッチ・ネーム・サーバー・データベースにすべての FC NIC ポート項目があることを確認してください。Brocade スイッチで、nsallshow コマンドを使用します。下に出力を示します。

brcd_sw_1:root> nsallshow

{a01000 a01100 a01200 a01300a01500 a01600 a01700 a01800

8 Nx_Ports in the Fabric }

2. このコマンドにより、ファブリック内のすべての装置の 24 ビット・ファイバー・チャネル・アドレス (PID) が表示されます。このリストにすべての FC NIC

ポートが含まれていることを確認してください。

注: 使用可能な物理ネットワーク帯域幅と比較してスループットが非常に遅い場合、技術サポートに連絡してください。


SnapVault を使用するデータ保護

SnapVault とはSnapVault は、ディスクに基づいた Data ONTAP のストレージ・バックアップ・フィーチャーです。SnapVault を使用すれば、複数のストレージ・システムに保管されたデータを、読み取り専用の Snapshot コピーとして、中央の 2 次ストレージ・システムに素早く効率的にバックアップできます。

ストレージ・システム上でデータ損失またはデータ破壊が起こった場合に、バックアップ済みデータを SnapVault 2 次ストレージ・システムからリストアでき、従来のテープによるバックアップおよびリストアの操作に比べてダウン時間や不確実性は少なくなります。

次に示す SnapVault フィーチャーを説明する用語を理解しておく必要があります。

v 1 次ストレージ・システム―バックアップ元のデータがあるシステム

v 2 次ストレージ・システム―データのバックアップ先であるストレージ・システムまたはニアライン・システム

v 1 次システム qtree―2 次ストレージ・システム上の 2 次 qtree にバックアップされるデータがある、1 次ストレージ・システム上の qtree

v 2 次システム qtree―1 次ストレージ・システム上の 1 次 qtree からデータがバックアップされる先である、2 次ストレージ・システム上の qtree

v オープン・システム・プラットフォーム―AIX、Solaris、HP-UX、Red Hat

Linux、SUSE Linux、または Windows を実行するサーバーであり、そのデータはSnapVault 2 次ストレージ・システムにバックアップ可能

v Open Systems SnapVault エージェント―システムのデータを SnapVault 2 次ストレージ・システムにバックアップすることを可能にするソフトウェア・エージェント

v SnapVault 関係―1 次ストレージ・システム上の qtree、またはオープン・システム 1 次プラットフォーム上のディレクトリーと、それに対応する 2 次システムqtree の間のバックアップ関係

v SnapVaultSnapshot コピー―SnapVault が一定の間隔で 1 次および 2 次のストレージ・システム上に作成するバックアップ・イメージ

SnapVault Snapshot コピーは、各 1 次システム上の 1 次 qtree データの状態を取り込みます。このデータは、SnapVault 2 次システム上の 2 次 qtree に転送されます。2 次ストレージ・システムは、長期保管および必要な場合のリストア操作のために、結合されたデータの Snapshot コピーを作成し、コピーのバージョンを保守します。

v SnapVault Snapshot ベース名―snapvault snap sched コマンドを使用して、SnapVault Snapshot コピーのセットに割り当てる名前。セットに対してインクリメンタル Snapshot コピーが作成され、1 次および 2 次の両ストレージ・システムに保管されると、システムはベース名に番号 (0、1、2、3 など) を付加して、最新およびそれ以前の Snapshot 更新を追跡します。


v SnapVault ベースライン転送―1 次ストレージ qtree またはオープン・システム・プラットフォーム・ディレクトリーの初期の完全バックアップを、2 次ストレージ・システム上の対応する qtree に転送する処理

v SnapVault インクリメンタル転送―現在の転送アクションから最後の転送アクションまでの間に 1 次ストレージ・データに加えられた変更のみを含む、2 次ストレージ・システムに対する後続のバックアップ

SnapVault を使用する利点ディスク・ベースのバックアップおよびリストア・システムである SnapVault を使用すれば、データ・リストア操作を迅速、容易に実行できます。

また、次の操作を実行することもできます。

v バックアップ済みファイルをオンラインで表示する。

v 大量のデータを頻繁に効率よくバックアップするためのスケジュールを設定する。

v 増分バックアップによってメディアの消費量とシステム・オーバーヘッドを最小限にする。

v テープ・バックアップが必要な場合は、1 次ストレージ・システムからSnapVault2 次ストレージ・システムにテープ・バックアップ・タスクを移動して負荷を軽減する。操作が集中化され、リソースが節約されます。

v 複数のプラットフォーム (Data ONTAP、AIX、Solaris、HP-UX、Linux、またはWindows サーバー・システム) に保管されているデータをバックアップするために、単一のストレージ・システムを構成して保守する。

SnapVault によってバックアップおよびリストアされるデータSnapVault によってバックアップおよびリストアされるデータ構造は、1 次ストレージ・システムによって異なります。

v Data ONTAP を実行するストレージ・システム上では、qtree が SnapVault によるバックアップおよびリストアの基本単位です。

SnapVault は、1 次ストレージ・システム上の指定された qtree を、SnapVault 2

次ストレージ・システム上の関連した qtree にバックアップします。必要な場合、データは 2 次 qtree から関連した 1 次 qtree に再びリストアされます。

v オープン・システム・ストレージ・プラットフォーム上では、ディレクトリーがSnapVault バックアップの基本単位です。SnapVault は、指定されたディレクトリーを、ネイティブ・システムから SnapVault 2 次ストレージ・システム内にある指定された qtree にバックアップします。

必要に応じて、SnapVault はオープン・システム・ストレージ・プラットフォームにディレクトリー全体をリストアすることも、指定したファイルをリストアすることもできます。

注: 複数の 1 次ストレージ・システムからの qtree、または複数のオープン・システム・ストレージ・プラットフォームからのディレクトリーを、単一の SnapVault 2

次ボリューム上の関連した qtree にバックアップできます。


SnapVault デプロイメントのタイプビジネス要件に応じて、3 とおりの方法で SnapVault をデプロイできます。

v 基本 SnapVault デプロイメント

v 1 次、2 次、テープ・バックアップの順のバリエーション

v 1 次、2 次、SnapMirror の順のバリエーション

基本 SnapVault デプロイメントとはSnapVault バックアップ・システムの基本デプロイメントは、1 次ストレージ・システムと 2 次ストレージ・システムで構成されます。

1 次ストレージ・システム: 1 次ストレージ・システムは、バックアップ対象のData ONTAP を実行するプラットフォーム、およびオープン・システム・ストレージ・プラットフォームです。

v 1 次ストレージ・システム上で、SnapVault は 1 次 qtree データ、非 qtree データ、およびボリューム全体を、SnapVault 2 次ストレージ・システム上の qtree

の場所にバックアップします。

v サポートされるオープン・システム・ストレージ・プラットフォームは、Windows サーバー、Solaris サーバー、AIX サーバー、Red Hat Linux サーバー、SUSE Linux サーバー、HP-UX サーバーなどです。オープン・システム・ストレージ・プラットフォーム上では、SnapVault は 2 次ストレージ・システム上

図 16. 1 次および 2 次ストレージ・システム

SnapVault を使用するデータ保護 199

の qtree の場所にディレクトリーをバックアップできます。SnapVault は、ディレクトリーと個々のファイルをリストアできます。詳しくは、Open Systems

SnapVault の資料を参照してください。

2 次ストレージ・システム: SnapVault 2 次ストレージ・システムは、ストレージ・システムからのバックアップ・データを受け取り、Snapshot コピーとして保管する、ディスク・ベースの中央ユニットです。任意のストレージ・システムをSnapVault 2 次ストレージ・システムとして構成できますが、推奨されるハードウェア・プラットフォームは、ニアライン・システムです。

次の図に、基本 SnapVault デプロイメントを示します。

1 次、2 次、テープ・バックアップの順のバリエーション一般的な SnapVault バックアップ・デプロイメントのバリエーションとして、SnapVault 2 次ストレージ・システムのテープ・バックアップを配置することがよくあります。

このデプロイメントは、次の 2 つの目的に役立ちます。

v 最新のバックアップを 2 次ストレージにオンラインで使用可能な状態に維持しながら、ネットワーク・バックアップをいくつでも制限なくオフラインで保管できます。これは、データの迅速なリストアに役立ちます。 SnapVault 2 次ストレージ・システムから単一のテープ・バックアップを実行すれば、ストレージ・プラットフォームに性能低下が生じることがなく、システムが使用不可になっても影響を受けず、複数システムの直接テープ・バックアップに伴う複雑さもありません。

v SnapVault 2 次ストレージ・システム上でデータ損失やデータ破壊が生じた場合に、そのシステムにデータをリストアするためにテープ・バックアップを使用できます。

注: 一部の UNIX 属性、特に UNIX アクセス制御リスト (ACL) は、この方式を使用すると保存されません。

図 17. 基本 SnapVault デプロイメント


次の図に、基本 SnapVault デプロイメントとテープ・バックアップを示します。

1 次、2 次、SnapMirror の順のバリエーション基本的な SnapVault デプロイメントに対するバリエーションとして、2 次ストレージ・システム自体に問題が発生したときに、SnapVault 2 次ストレージに保管されている Snapshot コピーを保護します。

SnapVault 2 次ストレージにバックアップされたデータが、SnapMirror パートナー、または宛先として構成されたユニットにミラーリングされます。 2 次ストレージ・システムに障害が起こった場合は、SnapMirror 宛先にミラーリングされたデータを 2 次ストレージ・システムに変換し、それを使用することによって、中断を最小限にして SnapVault バックアップ操作を続行できます。

図 18. 基本 SnapVault デプロイメントとテープ・バックアップ

図 19. SnapMirror バックアップを使用した SnapVault デプロイメント


ストレージ・システムの SnapVault バックアップの動作SnapVault を使用したストレージ・システム qtree のバックアップでは、ベースライン転送の開始、スケジュールに基づくインクリメンタル転送の実行、および要求に応じたデータのリストアが行われます。

ベースライン転送を開始する方法:

v コマンド行の入力に応じて、SnapVault 2 次ストレージ・システムは、バックアップ対象として指定された qtree の初期基本転送を要求します。1 次ストレージ・ボリュームから 2 次ストレージ・ボリュームへの転送が行われます。これらの転送によって、1 次 qtree と 2 次 qtree の間に SnapVault 関係が確立されます。

v それぞれの 1 次ストレージ・システムは、2 次ストレージ・システムによる要求に応じて、指定された 1 次 qtree の初期基本イメージを 2 次ストレージ・システム上の qtree の位置に転送します。

スケジュールに基づくインクリメンタル転送の実行方法:

v それぞれの 1 次ストレージ・システムは、コマンド行の入力に応じて、バックアップする qtree を含むボリュームのスケジュール SnapVault Snapshot コピーのセットを作成します。追跡のために、例えば「sv_hourly」、「sv_nightly」など、頻度に応じた名前を付けることができます。

Snapshot セットごとに、SnapVault は指定した数の 1 次ストレージ Snapshot コピーを保存し、それぞれの Snapshot にバージョン番号を割り当てます (0 が最新、1 がその次に新しい、以下同様)。

v SnapVault 2 次ストレージ・システムは、コマンド行の入力に応じて、指定されたスケジュール・データ転送のセットと、Snapshot アクションを実行します。ボリューム上の 2 次 qtree ごとに、SnapVault は対応するそれぞれの 1 次 qtree

の Snapshot データから、前回のデータ転送より後に 1 次 qtree に対して行われた増分の変更内容を取り出します。

その後、SnapVault は 2 次 qtree 内での変更内容を保管するボリューム Snapshot

コピーを作成します。

転送および Snapshot セットごとに、SnapVault は指定した数の 2 次ストレージSnapshot コピーを保存し、それぞれの Snapshot コピーにバージョン番号を割り当てます (0 が最新、1 がその次に新しい、以下同様)。

要求に応じたリストア:

v データを 1 次ストレージ・システムにリストアする必要がある場合、SnapVault

は指定されたバージョンの qtree を要求側の 1 次ストレージ・システムに返送します。

次の図に、SnapVault の機能を示します。


オープン・システム・プラットフォームの SnapVault バックアップの動作

オープン・システム・プラットフォームのディレクトリーの SnapVault バックアップ・プロセスでは、ベースライン転送の開始、インクリメンタル転送のスケジュール、および要求に応じたデータのリストアが行われます。

ベースライン転送の開始:

v コマンド行の入力に応じて、SnapVault 2 次ストレージ・システムは、バックアップ対象として指定されたディレクトリーの初期ベースライン・イメージ転送をオープン・システム・プラットフォームに要求します。これらの転送によって、オープン・システム・プラットフォームのディレクトリーと SnapVault 2 次qtree の間で、SnapVault関係が確立されます。

v それぞれのオープン・システム・プラットフォームは、2 次ストレージ・システムによる要求に応じて、指定されたディレクトリーの初期基本イメージを 2 次ストレージ・システム上の qtree の位置に転送します。

注: Open Systems SnapVault には、1 次側 Snapshot コピーは存在しません。

インクリメンタル転送のスケジュール:

v SnapVault 2 次ストレージ・システムは、コマンド行の入力に応じて、スケジュールに基づく一連のデータ転送を実行します (データ転送には、追跡のために「sv_hourly」、「sv_nightly」などの名前を割り当てることができます)。

ボリューム上のそれぞれの 2 次 qtree に対して、オープン・システム・ストレージ・プラットフォーム上の対応する 1 次ディレクトリーから、直前のデータ転送より後に追加または変更されたファイルが、SnapVault によって転送されます。

図 20. SnapVault の機能


スケジュールに基づくデータ転送のセットごとに、それぞれの転送後に 2 次qtree に対して行われた変更内容を取り込むインクリメンタル Snapshot コピーのセットが、SnapVault によって作成されます。Snapshot コピーのセットごとに、SnapVault 2 次ストレージ・システムは指定した数の 2 次ストレージ Snapshot

コピーを保存し、セット内のそれぞれの Snapshot コピーにバージョン番号を割り当てます (0 が最新、1 がその次に新しい、以下同様)。

v 要求に応じたリストア: ディレクトリーまたはファイル・データをオープン・システム・ストレージ・プラットフォームにリストアする必要がある場合、SnapVault は保存された Snapshot コピーの 1 つからデータを取り出し、要求側のオープン・システム・ストレージ・プラットフォームにデータを返送します。

詳しくは、「Open Systems SnapVault Installation and Administration Guide」を参照してください。

SnapVault バックアップの計画SnapVault バックアップを開始する前に、1 次システム qtree または Open Systems

ディレクトリーおよび対応する 2 次システム qtree を計画する必要があります。また、SnapVault バックアップ・スケジュールと Snapshot コピーの保持も計画して、初期バックアップ時間を見積もる必要があります。

1 次および 2 次 qtree のロケーションの計画1 次システム qtree または Open Systems ディレクトリーおよび対応する 2 次システム qtree のロケーションを計画すると、ストレージ管理の向上に役立ちます。複数のボリュームからの複数の 1 次システム qtree および複数の Open Systems ディレクトリーをすべて単一ボリューム内の対応する 2 次システム qtree にバックアップすることができます。

1 次システム qtree または Open Systems ディレクトリーおよび対応する 2 次システム qtree を表にリストします。次の表で例を参照してください。

1 次システム qtree またはディレクトリーのロケーション

対応する 2 次システム qtree のロケーション

systemA:/vol/vol1/qtreeAA sv_secondary:/vol/sv_vol/qtreeAA

systemA:/vol/vol1/qtreeAB sv_secondary:/vol/sv_vol/qtreeAB

systemB:/vol/vol1/qtreeBB sv_secondary:/vol/sv_vol/qtreeBB

winsrvrA:c:¥melzdir sv_secondary:/vol/sv_vol/melzdir

ux_srvrB:/usrs/moz_acct sv_secondary:/vol/sv_vol/moz_acct

注: ボリューム当たりの 2 次システム qtree の最大数は 255 です。ファイバー・チャネル・ネットワーク経由の qtree の SnapVault バックアップはサポートされません。


同じストレージ・システム上の SnapVault 1 次システムおよび 2次システム

Data ONTAP7.3 以降では、SnapVault の 1 次および 2 次フィーチャーが、同じストレージ・システム上にあっても構いません。ただし、SnapVault 1 次ライセンスとSnapVault 2 次ライセンスを両方とも同じストレージ・システム上で有効にする必要があります。

SnapVault 1 次システムおよび SnapVault 2 次システムの両方のライセンスを有効にしたストレージ・システムは、他のストレージ・システムとの間で SnapVault バックアップを送受信でき、またシステム自体の中でローカルに送受信することもできます (例えば、FC アグリゲートと ATA アグリゲートの間で)。

注: 1 次 qtree と 2 次 qtree は、ストレージ・システムの同じボリューム内にあってはなりません。

SnapVault バックアップ・スケジュールおよび Snapshot コピーの保持の計画

SnapVault バックアップ・スケジュールおよび保持する Snapshot コピーの数を計画することは重要です。

始める前に

SnapVault 構成を開始する前に、表を使用して、ボリュームごとに必要な Snapshot

コピーの数、希望の更新時期、および保持する数を計画します。

例えば、次のようにします。

v 時間ごと (1 日を通して定期的に実行します)

Snapshot コピーを 1 時間ごと、2 時間ごと、あるいは 4 時間ごとに作成する必要があるほど、1 日を通してデータ変更が頻繁に行われますか?

v 夜間

Snapshot コピーを毎晩作成するか、平日の夜にのみ作成しますか?

v 週ごと

いくつの週ごとの Snapshot コピーを保持すると有用ですか?

ストレージ・ベースの 1 次システムと SnapVault 2 次ストレージ・システムで、バックアップされるデータは Snapshot コピーに収集され、保持されます。

1. Data ONTAP 1 次ストレージ・システムで、1 次システム qtree の SnapVault

Snapshot コピーを作成する間隔を計画します。Snapshot コピーを作成する最大の頻度は 1 時間ごとです。

注: Data ONTAP を実行していない 1 次ストレージ・プラットフォームでは、Snapshot コピーの計画および作成は適用されません。詳しくは、Open Systems

SnapVault 資料を参照してください。


2. SnapVault 2 次ストレージ・システムで、1 次ストレージ・プラットフォームからデータを転送して 2 次システム qtree を更新する間隔を計画し、その情報を保持するための SnapVault Snapshot コピーを作成します。

3. SnapVault 2 次ストレージ・システムの 1 つのボリュームで保持する Snapshot

コピーの合計数を 251 以下に制限する方法を計画します。

重要: SnapVault 2 次ストレージ・システムの各ボリュームで保持されるSnapshot コピーの合計数が 251 を超えてはなりません。ボリュームごとのSnapshot コピーの数の制限に達して、古い Snapshot コピーが削除されない場合、SnapVault は、そのボリューム上に新しい Snapshot コピーを作成しません。

例

この例では、ユーザーは 2 次ストレージ・システム・ボリュームに 12 の qtree を持っているとします。

Snapshot 間隔 1 次ストレージ:

作成時1 次ストレージ:

保持するSnapshot コピー

2 次ストレージ:

作成時2 次ストレージ:

保持するSnapshot コピー

週ごと sat @19 4 sat @21 8

夜間 mon-fri @19 10 mon-fri @20 60

時間ごと @7-18 11 @8-19 120

Total n/a 21 n/a 188

2 次ストレージ・システムで、ユーザーは以下をスケジュールします。

v 毎週土曜日の 9:00 p.m. に週ごとの更新を行い、8 個を保持します

v 毎週月曜日から金曜日の 8:00 p.m に日ごとの更新を行い、60 個を保持します

v 8:00 a.m. から 7:00 p.m. までの 1 時間ごとに時間ごとの更新を行い、120 個を保持します

この例の結果として、188 個の Snapshot コピーが SnapVault 2 次ストレージ・システム・ボリュームに保持されることになります。

ボリューム当たりの Snapshot コピーの制限は 251 であるため、この例でスケジュールされた 188 個の Snapshot コピーはボリューム制限を超過しません。

251 個を超える Snapshot コピーを SnapVault 2 次ストレージ・システムで保持する必要がある場合、2 次ストレージ・システムで追加のボリュームを構成できます。追加の各ボリュームは、さらに 251 個の Snapshot コピーをサポートできます。

初期バックアップ時間の見積もり1 次ストレージ・システムから 2 次ストレージ・システムへのデータの初期転送に必要なバックアップ時間は、バックアップされる 1 次データの i ノード・カウント、データ・セットのサイズ、およびネットワークの能力によって異なります。

SnapVault は、概算で 1 時間当たり 700 万の i ノード (1 分当たり 110,000 の i

ノード) の速度で初期バックアップを実行できます。


並行 SnapVault ターゲットの数の限度Data ONTAP 7.3 以降では、ストレージ・システム上で可能な個々の qtree の並行SnapVault 転送の最大数は、Data ONTAP 7.2 での最大数よりも大きくなっています。ただし、並行 SnapVault ターゲットの最大数は、リリース・ファミリー間で変更されていません。

Data ONTAP 7.3 より前のリリースでは、ストレージ・システムによってサポートされる並行 SnapVault ターゲットの最大数は、システムに対して可能な並行SnapVault 転送の最大数と同じでした。 SnapVault ターゲットは、SnapVault 宛先ボリューム上でスケジュール SnapVault Snapshot コピーの作成を制御するプロセスです。更新される qtree を含む SnapVault 宛先ボリュームごとに、SnapVault ターゲットが存在します。

プラットフォームごとの並行 SnapVault ターゲットの最大数について、次の表で説明します。どの時点でも、並行して更新できる qtree を含むボリュームの数が、ここにリストされている数を超えることはありません。 SnapVault ターゲットの数が表に示されている限度を超える場合、超過分の SnapVault ターゲットはキューに入れられ、アクティブ SnapVault ターゲットがバックアップを完了した後で実行されます。

表 7. 並行 SnapVault ターゲットの最大数

モデル並行 SnapVault ターゲットの最大数

N3700 8

N3300 16

N3600 32

N5200 32

N5300 64

N5500 64

N5600 128

N6060 128

N7600 96

N7700 96

N7800 128

N7900 128

注: これらの最大数は SnapVault ターゲットのみに適用され、したがって SnapVault

qtree に適用されます。SnapMirror qtree の場合、並行して更新できるボリュームの数に制限はありません。

並行 SnapVault ターゲットの最大数は存在しますが、SnapVault 関係は必要なだけの数のボリューム内で構成できます。ただし、どの時点でも、限度内の数のボリュームに含まれる qtree のみを更新できます。

SnapVaultバックアップのスループットが、複数の 1 次ストレージ・システムと 2

次ストレージ・システムの間にある個々のリンクの帯域幅や待ち時間によって制約されている場合は、Data ONTAP 7.3 で利用可能な並行転送数限度の拡張によっ


て、全体のスループットを高めることができます。指定された数のボリュームにqtree を分散することによって、従来より高い限度を利用できます。

関連資料



SnapVault を使用可能にする1 次システムで SnapVault バックアップをセットアップすることは、1 次ストレージ・システムおよび SnapVault 2 次ストレージ・システムがバックアップ・タスクを実行するように準備することを意味します。Data ONTAP 7.3 以降では、SnapVault 1 次ライセンスおよび SnapVault 2 次ライセンスを同じストレージ・システムにインストールできます。SnapVault を使用してデータをバックアップするには、その前にストレージ・システムにライセンス交付して準備する必要があります。

ライセンス・コードの入力2 次ストレージ・システム, で SnapVault 2 次ストレージ・システム・ライセンス・コードを入力して、1 次ストレージ・システムアクティブ/アクティブ構成を使用している場合、1 つのアクティブ/アクティブ・ノードで SnapVault 1 次ライセンスを使用可能にして、もう 1 つのアクティブ/アクティブ・ノードで SnapVault 2

次ライセンスを使用可能にすることができます。

1. SnapVault 2 次ストレージ・システム・ライセンス・コードを入力するには、2

次ストレージ・システムで次のコマンドを入力します。license add xxxxxxx

xxxxxxx は、購入したライセンス・コードです。

この設定は、再起動しても持続します。

2. SnapVault 1 次ストレージ・システム・ライセンス・コードを入力するには、1

次ストレージ・システムで次のコマンドを入力します。license add xxxxxxx

xxxxxxx は、購入したライセンス・コードです。

この設定は、再起動しても持続します。ライセンス・コードの入力について詳しくは、「Data ONTAP ストレージ管理ガイド」のライセンス交付に関する情報を参照してください。

enable オプションの設定enable オプションを設定すると、SnapVault データ転送および Snapshot コピーの作成が可能になります。


始める前に

2 次ストレージ・システムで SnapVault 2 次ストレージ・システム・ライセンス・コードを入力して、1 次ストレージ・システムで別の SnapVault 1 次ストレージ・システム・ライセンス・コードを入力します。

1 次と 2 次の両方のストレージ・システムで、次のコマンドを入力します。options snapvault.enable on

このオプションは、再起動しても持続します。

ndmp オプションの設定ndmp オプションにより、それぞれの 1 次ストレージ・システム上の NDMP サービスをバックアップできます。

ndmpd オプションを設定するには、次のコマンドを入力します。ndmpd on このオプションは、再起動しても持続します。NDMP を使用可能にして構成するには、「Data ONTAP Data Protection Tape Backup and Recovery Guide」の NDMP 管理の章を参照してください。

access オプションの設定snapvault.access オプションは、どのストレージ・システムがデータ転送を要求できるかを制御します。このオプションは、再起動しても持続します。

1. 1 次ストレージ・システム: 1 次ストレージ・システムがアクセス権を 2 次ストレージ・システムにのみ付与するように設定するには、次のコマンドを入力します。 options snapvault.access host= snapvault_secondary

このオプションを SnapVault 1 次ストレージ・システムで設定すると、どの 2

次ストレージ・システムがその 1 次ストレージ・システムからのデータにアクセスできるかが決定されます。

2. 2 次ストレージ・システム: 1 次ストレージ・システムが 2 次ストレージ・システムからのデータを復元できるようにするには、次のコマンドを入力します。options snapvault.access host= snapvault_primary1, snapvault_primary2

...

このオプションを SnapVault 2 次ストレージ・システムで設定すると、どのSnapVault 1 次ストレージ・システムが 2 次ストレージ・システムにアクセスできるかが決定されます。

システムは、snapvault_primary として入力されたホスト名を /etc/hosts ファイル内の IP アドレスに解決できる必要があります。そうでない場合、システムはDNS または NIS を実行している必要があります。また、ホスト名の代わりにリテラル IP アドレスを使用することもできます。2 次ストレージ・システムへのアクセスを許可されるシステムを指定するための構文は、na_protocolaccess(8) マニュアル・ページに記載されています。options コマンドについて詳しくは、na_options(1) マニュアル・ページを参照してください。

システムは、snapvault_secondary として入力されたホスト名を /etc/hosts ファイル内の IP アドレスに解決できる必要があります。そうでない場合、システムは DNS または NIS を実行している必要があります。また、ホスト名の代わり


にリテラル IP アドレスを使用することもできます。詳しくは、na_protocolaccess(8) マニュアル・ページを参照してください。options コマンドについて詳しくは、na_options(1) マニュアル・ページを参照してください。

注: すべてのリクエスターにアクセス権を付与するには、options snapvault.access

all と入力します。セキュリティー上の理由から、この構成は推奨されません。systemB> options snapvault.access host=systemA systemA> options

snapvault.access host=systemB,systemC

SnapVault バックアップ関係を開始する方法1 次および 2 次のストレージ・システム上で SnapVault を使用可能に設定し、1 次および 2 次のストレージ・システムが互いにアクセスできるようにした後、どのqtree またはボリュームのデータを 1 次ストレージ・システムから SnapVault 2 次ストレージ・システムに転送するか指定する必要があります。その後、1 次ストレージ・システムから 2 次ストレージ・システムへの完全な (ベースライン) データ転送を実行する必要があります。

snapvault start コマンドは、次の項目を指定して、1 次 qtree またはボリュームと 2

次 qtree との間の SnapVault 関係を構成します。

v ストレージ・システム上でバックアップする 1 次ストレージ・システム qtree またはボリューム

v 1 次ストレージ・システムから 2 次ストレージ・システムへの更新に関するパラメーター

これらのパラメーターには、転送速度や試行回数などがあります。試行回数は、SnapVault が操作を停止するまでに転送の開始を試行する回数です。

v snapvault start コマンドはまた、1 次ストレージ・システム qtree データの 2 次ストレージ・システム qtree へのベースライン転送を開始します。

SnapVault 関係の作成に関する指針SnapVault 関係を作成する際には、ボリュームおよび qtree に関する次の指針を守ってください。

v 同じ vol lang 設定をもつボリューム間で、SnapVault 関係を確立します。

v SnapVault 関係を確立した後、宛先ボリュームに割り当てられている言語を変更しないでください。

v ソースと宛先の qtree の名前には空白文字 (スペースおよびタブ文字) を入れないでください。

v SnapVault 関係を確立した後、ボリュームまたは qtree の名前を変更しないでください。

v ベースライン転送の前に、2 次ストレージ・システム上に qtree が存在していてはなりません。

qtree データのバックアップバックアップ対象として指定された qtree の完全な SnapVault 転送を実行します。


2 次ストレージ・システムのコンソールから、次のコマンドを入力します。snapvault start -S prim_system:prim_qtree_path sec_host:sec_qtree_path

-S オプションは、1 次ストレージ・システムおよびパスを指定します。このオプションは、コピーする 1 次ストレージ・システムqtree ごとに初めてコマンドを実行するときに設定する必要があります。以前に構成された qtree の初期転送を再開する場合はオプションです。prim_system:prim_qtree_path は、バックアップする 1 次ストレージ・システムのqtree を指定します。sec_host は、1 次ストレージ・システムqtree のデータの転送先とする宛先 (2 次ストレージ・システム) の名前です。 2 次ストレージ・システムが指定されない場合、ローカル・ホストの名前が使用されます。sec_qtree_path は、2 次ストレージ・システムの qtree のパスであり、その名前が含まれます。

注: sec_qtree_name で指定される qtree は、snapvault start コマンドの実行前に 2

次ストレージ・システムに存在していてはなりません。snapvault start コマンド・オプションについて詳しくは、na_snapvault(1) マニュアル・ページを参照してください。

例

systemB> snapvault start -S systemA:/vol/vol2/qtree3 /vol/vol1/qtree3

SnapVault は、1 次ストレージ・システム (systemA) の vol2 の qtree3 の Snapshot

コピーを作成して、その中のデータを 2 次ストレージ・システム (systemB) のvol/vol1/qtree3 にコピーし、qtree を将来の更新のために構成します。

注: このベースライン転送に必要な時間は、バックアップされる 1 次ストレージ・システムのデータの合計量および i ノード・カウントによって制限されます。SnapVault は、概算で 1 時間当たり 700 万の i ノード (1 分当たり 110,000 の i

ノード) の速度で初期バックアップを実行できます。大容量の転送の第 1 段階では、SnapVault が i ノードを作成します。その間、アクティビティーがまったく実行されていないように見えることがあります。

非 qtree データとは非 qtree データは、ストレージ・システム上にあって qtree に含まれていないすべてのデータです。

非 qtree データには、次のような項目が含まれます。

v 通常はクライアントに対して表示されない、構成およびロギング用のディレクトリー (例えば、/etc または /logs)

v qtree が構成されていないボリューム上のディレクトリーおよびファイル

非 qtree データのバックアップSnapVault を使用してソース・ボリュームをバックアップする場合、ボリュームは 2

次ストレージ・システム上の qtree にバックアップされます。そのため、ソース・ボリュームのすべての qtree が宛先 qtree のディレクトリーになります。


1 次ストレージ・システムの非 qtree データを複製および保護するには、次のステップを実行します。 2 次ストレージ・システムから、次のコマンドを入力します。snapvault start -S prim_system:/vol/volume_name/- /vol/volume_name/

qtree_name

-S prim_system:/vol/volume_name/- は、非 qtree データをバックアップする 1 次ストレージ・システムのボリュームを指定します。ダッシュ (-) は、指定されたボリューム内のすべての非 qtree データを示します。/vol/volume_name/qtree_name は、このデータを保管する 2 次ストレージ・システムの qtree を指定します。

注: volume_name/qtree_name で指定される qtree は、snapvault start コマンドの実行前に 2 次ストレージ・システムに存在していてはなりません。

注: 1 次ストレージ・システム・ボリュームの非 qtree の部分は、SnapVault 2 次ストレージ・システムにのみ複製できます。データを 1 次ストレージ・システムのqtree に復元できますが、非 qtree データとして復元することはできません。systemB> snapvault start -S systemA:/vol/vol1/- /vol/vol4/

non_qtree_data_in_vol7

SnapVault は、1 次 systemA の非 qtree データを systemB (2 次ストレージ・システム) の vol4 の non_qtree_data_in_vol7 という qtree に転送します。また、qtree

を将来の更新のために構成します。

ボリューム・データ・バックアップの内容SnapVault を使用してソース・ボリュームをバックアップする場合、ボリュームは 2

次ストレージ・システム上の qtree にバックアップされます。そのため、ソース・ボリュームのすべての qtree が宛先 qtree のディレクトリーになります。

SnapVault を使用してボリュームをバックアップする理由

v 多くの qtree を含むボリュームをバックアップする。

v SnapVault が提供する Snapshot 管理が必要である。

v 複数のソース・ボリュームから単一の宛先ボリュームにデータを統合する。

ボリュームを qtree にバックアップする際の制約事項

ボリュームから qtree へのバックアップを実行する前に、以下の制約事項を考慮してください。

v 割り当て量管理の単位としての qtree が失われます。

ソース・ボリュームの qtree からの割り当て量情報は、宛先 qtree のディレクトリーとして複製された場合は保存されません。

v qtree セキュリティー情報が失われます。

ソース・ボリュームの qtree が異なる qtree セキュリティー・スタイルである場合、それらのセキュリティー・スタイルは宛先 qtree への複製時に失われ、ボリュームのセキュリティー・スタイルによって置き換えられます。

v データを復元するのは単純なプロセスではありません。


SnapVault は、データを元のボリュームに復元することはできません。データの復元時に、元のソース・ボリュームは qtree として復元されます。データを復元するためのプロセスについては、『qtree の元のボリューム構造への復元』を参照してください。

v ボリュームから qtree へのバックアップは、Data ONTAP LUN を含むボリュームではサポートされません。

関連概念

210ページの『SnapVault バックアップ関係を開始する方法』1 次および 2 次のストレージ・システム上で SnapVault を使用可能に設定し、1 次および 2 次のストレージ・システムが互いにアクセスできるようにした後、どのqtree またはボリュームのデータを 1 次ストレージ・システムから SnapVault 2 次ストレージ・システムに転送するか指定する必要があります。その後、1 次ストレージ・システムから 2 次ストレージ・システムへの完全な (ベースライン) データ転送を実行する必要があります。

関連タスク

218ページの『SnapVault Snapshot コピーのスケジュール解除』バックアップしている qtree のデータが別の場所にマイグレーションされたり、有用でなくなった場合、SnapVault Snapshot コピー・セットをスケジュール解除することができます。

ボリューム・データのバックアップSnapVault を使用して 1 次ストレージ・システムのボリューム・データを複製および保護することができます。

始める前に

2 次ストレージ・システムから、次のコマンドを入力します。snapvault start -S

prim_system:/vol/volume_name /vol/volume_name/qtree_name

-S prim_system:/vol/volume_name は、非 qtree データをバックアップする 1 次ストレージ・システムのボリュームを指定します。/vol/volume_name/qtree_name は、このデータを保管する 2 次ストレージ・システムの qtree を指定します。

注: /vol/volume_name/qtree_name で指定する qtree は、snapvault start コマンドの実行前に 2 次ストレージ・システムに存在していてはなりません。systemB> snapvault start -S systemA:/vol/vol1 /vol/vol4/vol1_copy

SnapVault は、1 次 systemA の vol1 にあるデータを systemB (2 次ストレージ・システム) の vol4 の vol1_copy という qtree に転送します。また、qtree を将来の更新のために構成します。

qtree の元のボリューム構造への復元snapvault restore コマンドを使用すると、qtree にバックアップしたソース・ボリュームは 1 次ストレージ・システム上の qtree として復元されます。

1. バックアップした qtree を 1 次ストレージ・システムの複数の qtree を持つ元のボリューム構造に復元するには、qtree create コマンドを使用して 1 次ストレージ・システムのボリュームにすべての qtree を再作成します。pri_system>

qtree create /vol/projs/project_x


2. ndmpcopy コマンドを使用して、それぞれの qtree のデータを復元します。次のコマンドにより、2 次ストレージ・システムのバックアップされた project_x ディレクトリーから 1 次ストレージ・システムの再作成された project_x qtree にデータが復元されます。pri_system> ndmpcopy -sa username:password

sec_system:/vol/vol1/projs/project_x /vol/projs/project_x ndmpcopy コマンドについて詳しくは、「Data ONTAP Data Protection Tape Backup and

Recovery Guide」を参照してください。

3. snapvault stop コマンドを使用して、qtree 更新を停止し、2 次ストレージ・システムの qtree を除去します。次のコマンドにより、2 次ストレージ・システムから projs qtree が除去されます。sec_system> snapvault stop /vol/vol1/projs

4. snapvault start コマンドを使用して、それぞれの qtree の 2 次ストレージ・システムへのベースライン・コピーを再初期化します。次のコマンドにより、SnapVault バックアップが再初期化されます。sec_system> snapvault start -S

pri_system:/vol/projs /vol/vol1/projs

SnapVault Snapshot コピー更新スケジュールとは1 次ストレージ・システム上の qtree から、SnapVault 2 次ストレージ・システム上の qtree への初期ベースライン・バックアップを完了した後、snapvault snap sched

コマンドを使用して、SnapVault 1 次ストレージ・システム上で一連の Snapshot コピーをスケジュールに入れる必要があります。また、Snapshot コピーを作成する対象のボリューム、Snapshot コピーのベース名、保存する Snapshot コピーのバージョンの数、およびこの Snapshot コピーのセットを作成する日と時間も指定できます。

次のタスクのスケジュールを設定するには、snapvault snap sched コマンドを使用する必要があります。

v SnapVault 関係が設定された qtree 内の新規データおよび変更されたデータを取り込むために、1 次ストレージ・システム上のボリュームの定期的な SnapVault

Snapshot コピーを実行する時刻 (関係は snapvault start コマンドによって構成される)

v 1 次 qtree から SnapVault 2 次ストレージ・システム上の関連した 2 次 qtree

への、新規データまたは変更されたデータの定期的なトランスポート

v SnapVault によるアーカイブ対象である、更新された 2 次 qtree を含むボリュームの定期的な Snapshot コピー

注: ここに示した説明と手順は、Data ONTAP を実行するストレージ・システムのSnapVault バックアップのみに関連しています。オープン・システムのドライブおよびディレクトリーの SnapVault バックアップに関連した説明および手順については、Open Systems SnapVault の資料を参照してください。

Snapshot スケジュールの競合を避ける方法SnapVault フィーチャーがデフォルト snap sched アクティビティーと同時にSnapshot 管理を実行するようにスケジュールが設定されていると、snap sched コマンドを使用してスケジュールに入れられた Snapshot 管理操作が、syslog メッセージ「Skipping creation of hourly snapshot」、および「Snapshot already exists」を出して失敗する場合があります。


この状態が起こらないようにするには、snap sched コマンドを使用して競合する時刻を使用不可に設定し、snapvault snap sched コマンドを使用して、Snapshot コピーを作成するための同等なスケジュールを構成します。

注: ベスト・プラクティスとしては、snap sched のスケジュールを使用不可に設定し、snapvault snap sched コマンドのみを使用して Snapshot コピーを作成するようにします。したがって、Snapshot コピーの作成スケジュールを追跡するには、snapvault snap sched の出力も調べ、snap sched の出力は参照しないでください。

SnapVault 1 次ストレージ・システムでの Snapshot コピーのスケジュール

SnapVault 1 次ストレージ・システムで Snapshot コピーのセットをスケジュールするには、snapvault snap sched コマンドを使用して、Snapshot コピーを作成する対象のボリューム、Snapshot コピーのベース名、保持する Snapshot コピー・バージョンの数、およびこの Snapshot コピーのセットを実行する曜日と時刻を指定します。

1 次ストレージ・システムのスケジュールを設定するには、1 次ストレージ・システムから次のコマンドを入力します。snapvault snap sched volume_name

snap_name schedule_spec

volume_name は、この Snapshot コピーのセットを作成する 1 次ストレージ・システム上のボリュームの名前です。snap_name は、Snapshot セットのベース名 (例えば、sv_nightly) です。このSnapshot コピーの名前は、1 次ストレージ・システムと 2 次ストレージ・システムで同じでなければなりません。snap sched Snapshot コピーとの競合を回避するために、snap_name を「hourly」、「nightly」、または「weekly」にしてはなりません。schedule_spec は、count[@day_list][@hour_list] で構成されます。count は、この Snapshot セットを保持する Snapshot コピーの数です。このフィールドのゼロ (0) は、この Snapshot コピーの新規インスタンスが作成されないことを意味します。

注: この Snapshot セットと他のセットのために保持される Snapshot コピーの合計数は、ボリューム当たり 251 の Snapshot コピーを超えてはなりません。この数を超える場合、SnapVault は新しい Snapshot コピーを作成しません。@day_list は、このセットの新しい Snapshot コピーが作成される曜日を指定するコンマ区切りリストです。有効な入力値は、mon tue wed thu fri sat sun です。大/

小文字の区別はありません。ダッシュ (-) を使用して範囲を指定できます (例えば、mon-fri)。ダッシュ (-) が単独で使用される場合、Snapshot コピーが自動的に作成されないことを意味します。 Snapshot コピーを手動で作成することができます。デフォルト値は mon-sun です。@hour_list は、このセットのために新しい Snapshot コピーが作成される時刻を指定します。有効な入力値は、0 から 23 の整数です。ダッシュ (-) またはコンマ区切りリストを使用して範囲を指定できます (例えば、7, 8-17, 19, 21, 23)。デフォルトは深夜 12 時 (0) です。

例

下記の 3 つの snapvault snap sched コマンド行は、1 次ストレージ・システムのボリューム vol1 で SnapVault Snapshot コピーの 3 つのセットをスケジュールしま


す。systemB> snapvault snap sched vol1 sv_weekly 1@sat@19systemB> snapvault

snap sched vol1 sv_nightly 2@mon-fri@19 systemB> snapvault snap sched vol1

sv_hourly 11@mon-fri@7-18

結果: SnapVault 1 次ストレージ・システムは、次のように、指定されたボリューム上に Snapshot コピーを作成します。

v SnapVault は、毎週土曜日の 7:00 p.m. に sv_weekly.0 を作成して 1 つのコピーを保持します。

v SnapVault は、毎週月曜日から金曜日の 7:00 p.m. に sv_nightly.0 を作成して 2

つのコピーを保持します。

v SnapVault は、毎週月曜日から金曜日の 7:00 a.m. から 6:00 p.m. までの 1 時間ごとに sv_hourly.0 を作成して 11 のコピーを保持します。

SnapVault 2 次ストレージ・システムへの Snapshot コピー・バックアップのスケジュール

1 次ストレージ・システムから 2 次ストレージ・システムへの SnapVault Snapshot

コピーのバックアップをスケジュールするには、snapvault snap sched -x コマンドを使用します。

2 次ストレージ・システムから次のコマンドを単一行で入力します。snapvault

snap sched -x sec_vol snap_name schedule_spec

コマンドの -x の部分は、2 次ストレージ・システムで必須です。このパラメーターは、指定されたボリュームの新しい Snapshot コピーが作成される直前に、指定されたボリューム上の SnapVault 2 次 qtree が関連する 1 次システム qtree から更新されることを指定します。sec_vol は、この Snapshot コピーがスケジュールされる 2 次ストレージ・システム上のボリュームの名前です。snap_name は、作成する Snapshot コピーのセットのベース名 (例えば、sv_nightly)

です。この Snapshot セットのベース名は、1 次ストレージ・システムのボリュームで構成された対応する Snapshot セットのベース名と一致している必要があります。このセット用に新しい Snapshot コピーが作成されるたびに、0 の番号が付けられ、このセット内の直前の Snapshot コピーの番号は 1 ずつ増分され、このセットで最も古い Snapshot コピーが削除されます。定期的な Data ONTAP snap sched

Snapshot コピーとの競合を回避するために、snap_name を「hourly」、「nightly」、または「weekly」にしてはなりません。schedule_spec は、count[@day_list][@hour_list] で構成されます。

v count は、このセットのために保持する Snapshot コピーの数です。このフィールドのゼロ (0) は、このセット用に新しい 2 次ストレージ・システム Snapshot コピーが作成されないことを意味します。ただし、2 次ストレージ・システム上のqtree は 1 次ストレージ・システムからの転送によって更新されます。

重要: この Snapshot セットと他のセットのために保持される Snapshot コピーの合計数は、ボリューム当たり 251 の Snapshot コピーを超えてはなりません。この数を超える場合、SnapVault は新しい Snapshot コピーを作成しません。

v @day_list は、このセットの新しい Snapshot コピーが作成される曜日を指定するコンマ区切りリストです。有効な入力値は、mon、tue、wed、thu、fri、sat、sun

です。大/小文字の区別はありません。ダッシュ (-) を使用して範囲を指定できま


す (例えば、mon-sun)。ダッシュ (-) が単独で使用される場合、Snapshot コピーが自動的に作成されないことを意味します。 Snapshot コピーを手動で作成することができます。

v @hour_list は、このセットのために新しい Snapshot コピーが作成される時刻を指定します。有効な入力値は、0 から 23 の整数です。ダッシュ (-) またはコンマ区切りリストを使用して範囲を指定できます (例えば、6, 8-17, 19, 21, 23)。デフォルトは深夜 12 時 (0) です。

注: snapvault snap unsched コマンドを使用して、いつでも 1 次ストレージ・システムまたは 2 次ストレージ・システムで SnapVault Snapshot スケジュールをオフにすることができます。また、options snapvault.enable off を使用してすべてのSnapVault 転送を停止することもできます。

例

下記の 3 つの snapvault snap sched コマンド行は、2 次ストレージ・システムのボリューム vol1 で SnapVault の転送更新および Snapshot コピーの 3 つのセットをスケジュールします。systemA> snapvault snap sched -x vol1 sv_weekly

5@sat@21 systemA> snapvault snap sched -x vol1 sv_nightly 5@mon-fri@20

systemA> snapvault snap sched -x vol1 sv_hourly 4@mon-fri@8-19

結果: SnapVault は、次のように、1 次ストレージ・システムの Snapshot コピーから qtree データを転送します。

v SnapVault は、毎週土曜日の 9:00 p.m. に sv_weekly.0 を 2 次ストレージ・システムに転送して、転送されたすべてのデータを含む同じ名前の新しい Snapshot コピーを作成し、5 つのコピーを保持します。

v SnapVault は、毎週月曜日から金曜日の 8:00 p.m. に sv_nightly.0 を 2 次ストレージ・システムに転送して、転送されたすべてのデータを含む同じ名前の新しいSnapshot コピーを作成し、5 つのコピーを保持します。

v SnapVault は、月曜日から金曜日の 8:00 a.m. から 7:00 p.m. までの 1 時間ごとに sv_hourly.0 を 2 次ストレージ・システムに転送して、転送されたすべてのデータを含む同じ名前の新しい Snapshot コピーを作成し、4 つのコピーを保持します。

注: snapvault snap sched -x コマンドによって 2 次ストレージ・システムでスケジュールされた Snapshot コピーは、2 次ストレージ・システムが更新する前に 1 次ストレージ・システム上の SnapVault が Snapshot コピーを作成するのに十分な時間を持てるように指定する時刻の 5 分後に作成されます。

アーカイブのための 2 次システム上の Snapshot コピーのスケジュール

1 次ストレージ・システムからの転送を必要としないいくつかの Snapshot コピーを2 次ストレージ・システムでスケジュールすることができます。例えば、時間ごと、および夜間の Snapshot コピーを 1 次ストレージ・システムで維持して、週ごとの Snapshot コピーのみを 2 次ストレージ・システムで保持することができます。


1 次ストレージ・システムで対応する Snapshot コピーを作成する必要なしに、2 次ストレージ・システムでの Snapshot コピーをスケジュールするには、次のコマンドを入力します。snapvault snap sched sec_vol snap_name schedule_spec

注: snapvault snap sched コマンドが使用される理由は、Snapshot コピーを作成する前にアクティブな SnapVault 転送が終了するのを待つためです。次のコマンドは、週ごとの Snapshot コピーを土曜日の午後 11 時にスケジュールして、最新の 5 つの Snapshot コピーを保持します。snapvault snap sched vol2

sv_weekly 5@sat@22

現在構成されている Snapshot スケジュールの表示スケジュールを指定せずに snapvault snap sched コマンドを入力すると、現在のスケジュール値が表示されます。

systemA> snapvault snap sched

注: snap_name が指定されない場合、このコマンドは、指定されたボリューム用にスケジュールされたすべての Snapshot コピー・セットのベース名を表示します。volume_name が指定されない場合、コマンドは、すべての SnapVault ボリュームのすべての Snapshot コピー・セットのベース名を表示します。

xfer vol1 sv_weekly 5@sat@21xfer vol1 sv_nightly 5@mon-fri@20xfer vol1 sv_hourly 4@mon-fri@8-19xfer vol2 sv_nightly 5@mon-fri@20xfer vol2 sv_hourly 4@mon-fri@8-19

SnapVault Snapshot コピーのスケジュール解除バックアップしている qtree のデータが別の場所にマイグレーションされたり、有用でなくなった場合、SnapVault Snapshot コピー・セットをスケジュール解除することができます。

Snapshot コピー・セットの SnapVault スケジュールをオフにして、SnapVault 1 次ストレージ・システムまたは 2 次ストレージ・システムの Snapshot プロセスを停止するには、1 次または 2 次ストレージ・システムのコンソールで次のコマンドを入力します。snapvault snap unsched [-f] [volume [snap_name]]

-f は、作成を停止する Snapshot コピーのリストを表示せず、確認を求めずにコマンドを強制的に実行します。volume は、Snapshot コピーの作成を停止するボリュームの名前です。snap_name は、作成を停止する Snapshot セットのベース名です。snap_name の値が指定されない場合、SnapVault は、ボリューム内のすべてのSnapshot セットの SnapVault Snapshot スケジュールをオフにして、それ以降、ボリュームの SnapVault Snapshot コピーを更新しません。ボリュームが指定されない場合、SnapVault は、すべての SnapVault Snapshot セットのスケジュールを削除して、それ以降、ストレージ・システムの SnapVault Snapshot コピーを更新しません。ボリュームで既に Snapshot コピーが作成中の場合、コマンドは失敗します。systemB> snapvault snap unsched vol1 sv_nightly SnapVault が確認を求めます。ユーザーがアクションを確認すると、SnapVault は、systemB の vol1 のベース名sv-nightly を持つすべての SnapVault Snapshot コピーをスケジュール解除します。


SnapVault 転送の検査SnapVault 転送が期待どおりに行われていることを確認するには、snapvault status

コマンドを使用して転送状況を検査します。

データ転送の状況を検査して、最新の qtree の更新状況を表示するには、次のコマンドを入力します。snapvault status [-l|-s|-c|-t]

[[[system_name:]qtree_path] ...]

v -l は、さらに詳細な情報を含む長形式の出力を表示します。

v -s は、各ボリュームの SnapVault Snapshot コピーのベース名、状況、およびスケジュールを表示します。

v -c は、システム上のすべての SnapVault qtree の構成パラメーターを表示します。このオプションは、2 次ストレージ・システムからのみ実行できます。

v -t は、アクティブな関係を表示します。

注: 関係がアクティブと見なされるのは、ソースまたは宛先がネットワークとの間でのデータ転送、磁気テープ装置の読み取りまたは書き込み、テープの変更の待機、またはローカルのディスク上の処理またはクリーンアップのいずれかのアクティビティーに関与している場合です。

system_name は、SnapVault 操作の状況を表示するシステムの名前です。qtree_path は、SnapVault 操作の状況を表示する qtree (複数可) のパスです。複数のqtree パスを指定できます。ストレージ・システムは、転送が進行中であるかどうか、転送されたデータの量、宛先の状態、および前回の正常な転送からの経過時間を示すメッセージを表示します。

v オプションまたは引数が指定されない場合、出力には、下記の例 1 に示す情報が表示されます。

[system_name:]qtree_path 引数が指定される場合、指定された qtree の状況のみが表示されます。

v -l オプションが指定される場合、出力には、例 2 に示す詳細情報が表示されます。

v -s オプションが指定される場合、出力には、例 3 に示すような Snapshot コピーの作成状況が表示されます。

v -c オプションが指定される場合、出力には、例 4 に示すような現在の 1 次ストレージ・システム構成パラメーターが表示されます。

v -t オプションが指定される場合、出力には、例 5 に示すように、アクティブな転送が行われている関係のリストが表示されます。

Data ONTAP により、ストレージ・システムへの転送およびストレージ・システムからの転送の最大速度を設定できます。


関連タスク

113ページの『すべての転送の最大転送速度の設定』すべての転送の最大転送速度を設定すると、いつでもすべての転送によって使用される合計帯域幅を制限することができます。すべての転送の最大転送速度を設定するために、Data ONTAP では、ストレージ・システムに到着する転送の最大速度とストレージ・システムから発信される転送の最大速度を設定できます。

状況を検査する例以下の例は、Data ONTAP のみを実行しているストレージ・システムの SnapVault

バックアップに関連するデータ転送状況を検査する上で役立ちます。

例 1

オプションを指定しないで snapvault status を入力すると、1 次 qtree から 2 次qtree への最新の転送に関与した SnapVault qtree 関係が表示されます。

systemA> snapvault status

Snapvault primary is ON.Source Destination State Lag StatussystemB:/vol/vol2/qtree3 systemA:/vol/sv_vol/qtree3 Snapvaulted 00:48:24 Idle

注: SnapVault 1 次ライセンスおよび 2 次ライセンスが同じストレージ・システムにインストールされた場合、次のメッセージが表示されます。

Snapvault is ON.

例 2

snapvault status -l コマンドは、最新の SnapVault 転送および Snapshot コピー・アクティビティーに関するさらに詳細な情報を表示します。

systemA> snapvault status -l

SnapVault primary is ON.Source: systemA:/vol/vol2/qtree3Destination systemB:/vol/sv_vol/qtree3Status IdleProgress: -State: SnapVaultedLag: 2:09:58SnapVault Timestamp: Thu Jan 31 12:30:01 PST 2002Base Snapshot: systemB(0016778780)_sv_vol.59Current Transfer TypeCurrent Transfer Error:Contents: ReplicaLast Transfer Type: ScheduledLast Transfer Size: 1680 KBLast Transfer Duration: 00:02:08-

例 3

snapvault status -s コマンドは、1 次または 2 次ストレージ・システムでスケジュールされているすべての Snapshot コピーをリストします。情報には、ボリューム、Snapshot コピーのベース名、現在の状況、および Snapshot スケジュールが含まれます。


systemA> snapvault status -s

Snapvault secondary is ON.Volume Snapshot Status Schedule------ -------- ------ --------sv_vol sv_hourly Idle 1@0-23vol2 sv_weekly Idle 8@fri

例 4

snapvault status -c コマンドは、すべての 2 次システム qtree、それらに対応する 1

次システム qtree、スケジュールされた転送の最大速度、および SnapVault がスケジュールされた転送をスキップするまでにその転送の開始を試行する最大回数をリストします。

systemA> snapvault status -c

/vol/sv_vol/db_qtree1 source=systemB:/vol/db1/s1 kbs=unlimited tries=20/vol/sv_vol/db_qtree2 source=systemC:/vol/db2/s2 kbs=unlimited tries=20/vol/sv_vol/qtree1 source=systemC:/vol/users/qtree1 kbs=10000 tries=10/vol/sv_vol/qtree2 source=systemC:/vol/users/qtree2 kbs=10000 tries=10/vol/sv_vol/qtree3 source=systemD:/vol/users/qtree1 kbs=10000 tries=10/vol/sv_vol/qtree4 source=systemD:/vol/db/db_1 kbs=7000 tries=10

systemA> snapvault status -c /vol/sv_vol/qtree3

/vol/sv_vol/qtree3 source=systemA:/vol/vol2/qtree3 kbs=10000 tries=10

例 5

snapvault status -t コマンドは、アクティブな転送があるすべての SnapVault 関係をリストします。

systemA> snapvault status -t

Snapvault secondary is ON.Source Destination State Lag StatussystemB:/vol/vol2/qtree3 systemA:/vol/sv_vol/qtree3 Snapvaulted 00:48:24 Transferring

アクティブな転送がない場合、次のメッセージが表示されます。

systemA> snapvault status -t

Snapvault secondary is ON.There are no active transfers.

状況フィールドの意味SnapVault が snapvault status および snapvault status -l コマンドに対して表示できる情報フィールドは次のとおりです。

フィールド表示される可能性がある値

Source system:qtree_path ― ソースは、リストされた 1 次ストレージ・システムおよび qtree パスです。

Destination system:qtree_path ― 宛先は、リストされた 2 次ストレージ・システムおよび qtree パスです。



State Uninitialized ― 宛先 SnapVault 2 次ストレージ qtree は、まだsnapvault start コマンドによって初期化されていません。

Snapvaulted ― qtree は SnapVault 2 次宛先です。

Unknown ― 2 次ストレージ・システム qtree の状態が不明です。2

次ストレージ・システム qtree を含むボリュームはオフラインまたは制限付きである可能性があります。

Source ― この状態は、snapvault status コマンドが 1 次ストレージ・システムで実行された場合に報告されます。また、snapvault

restore コマンドが関連する 1 次ストレージ・システムで実行された後に snapvault status が 2 次ストレージ・システムで実行された場合にも表示されます。

Lag hh:mm:ss は、現在 1 次ストレージ・システムにあるデータと 2 次ストレージ・システムストレージ・システムに保管されている最新データの間の時差を示します。つまり、現在時刻と、2 次ストレージ・システムに最後に正常に転送された Snapshot コピーのタイム・スタンプの差です。

このフィールドのダッシュ (-) は、2 次ストレージ・システムが初期化されていないことを意味します。

Status Aborting ― 転送は中止およびクリーンアップされています。

Idle ― 転送中のデータはありません。

Pending ― リソースに問題があるために 2 次ストレージ・システムを更新できません。転送は自動的に再試行されます。

Quiescing ― 指定された qtree は、すべての既存の転送が完了するのを待機しています。宛先は、安定状態になっています。

Resyncing ― 指定された qtree は再同期中です。

Transferring ― 転送が始まりましたが、まだ開始されていないか、終了するところです。

Progress 現在の転送によって転送された KB 数を示すか、状況が Idle または Pending の場合は再開チェックポイントを示します。

Mirror Timestamp hh:mm:ss は、1 次ストレージ・システムから 2 次ストレージ・システムに最後に正常に転送された Snapshot コピーのタイム・スタンプを示します。注: 再同期 (snapvault start -r) によって、基本 Snapshot コピーが元の基本よりも古いタイム・スタンプの Snapshot コピーに変更される可能性があります。

Base Snapshot copy 2 次ストレージ・システムの対応する qtree の基本 Snapshot コピーの名前です。

SnapVault 関係の qtree の場合、2 次ストレージ・サイドは、ストレージ・サイドのその qtree のエクスポートされた Snapshot コピーの名前をリストします。再同期 (snapvault start -r) によって、基本 Snapshot コピーの名前が変更される可能性があります。



Current Transfer Type 現在の転送のタイプ (スケジュール、再試行、再同期、更新、初期化、保管、または検索) を示します。このフィールドは、宛先サイドにのみ適用されます。

Current Transfer Error 最新の転送の試行が失敗した場合にエラー・メッセージを表示します。

Contents アクティブ・ファイル・システム内の宛先ボリュームまたは qtree

の内容が最新のレプリカであるか、または移行中であるかを示します。このフィールドは、宛先サイドにのみ適用されます。宛先は読み取り専用であるため、その内容は常にレプリカです。

Last Transfer Type 前回の転送のタイプ (スケジュール、再試行、再同期、更新、初期化、保管、または検索) を示します。このフィールドは、2 次ストレージ・サイドにのみ適用されます。

Last Transfer Size 前回の正常な転送で転送された KB 数を示します。

Last Transfer Duration 前回の正常な転送の経過時間を示します。転送が失敗して再開された場合、この時間には転送を再開するまで待機した時間も含まれます。転送が中止されて最初から再試行された場合、この時間には、最終的に成功した試行に要した時間のみが含まれます。

Last Transfer From このフィールドは、2 次ストレージ・サイドにのみ適用され、1 次システムおよびボリュームまたは qtree (内容の転送元) の名前を示します。

注: snapvault status が負の遅延時間を示す場合、宛先ストレージ・システムのクロックがソース・ストレージ・システムのクロックより進んでいることを意味します。この解決策として、両方のストレージ・システムのクロックを同期します。

SnapVault Snapshot コピーの表示snap list コマンドを使用して、Snapshot コピーのリストを表示することにより、1

次 qtree データのどのバージョンがバックアップ済みか確認したり、取り出す qtree

の特定バージョンを日付や時刻によって見つけたりすることができます。

snap list -q コマンドを使用して、次の内容を表示できます。

v 2 次ストレージ・システム上の Snapshot コピーすべてのリスト (SnapVault

Snapshot コピーのみでなく)

v Snapshot コピー内の qtree

v これらの qtree の 1 次ストレージ・システムのソース

v 2 次ストレージ・システムの Snapshot コピーにあるデータのソースであった 1

次ストレージ・システム Snapshot コピーのタイム・スタンプ

snap list -o コマンドを使用して、個々の qtree について保管されている Snapshot

コピーのタイム・スタンプ、1 次 qtree の起点 (該当する場合)、および Snapshot

コピー名をリストすることもできます。



ボリューム上の SnapVault Snapshot コピーの表示ボリューム上の Snapshot コピーおよび qtree のリストを表示できます。

Snapshot コピーの情報を表示するシステムで、次のコマンドを入力します。snap

list -q [volume_name] volume_name は、Snapshot コピーをリストするボリュームの名前です。ボリューム名が指定されない場合、このシステム上のすべてのボリューム上の Snapshot コピーが表示されます。

注: 非重複化機能が SnapVault 2 次ボリュームで使用可能になっている場合、SnapVault ターゲット Snapshot が作成された後で、ボリュームに対して非重複化操作が実行されます。この操作により、ボリュームから重複したデータ・ブロックが除去されます。非重複化操作が完了した後、前に作成された SnapVault ターゲットSnapshot コピーが削除され、同じ名前の新しい Snapshot コピーが作成されます。

ボリューム上の SnapVault Snapshot コピーを表示する例1 次ストレージの出力例:

snap list -q 出力の表示例を参照してください。1 次ボリューム名を指定する場合、このコマンドは、ボリューム内の Snapshot コピーごとの情報をリストします。この出力は、SnapVault 1 次ストレージ・システムとして使用されているボリュームからのものです。

systemA> snap list -q vol2Volume vol2working...

qtree contents timestamp source----- -------- --------- ------

sv_hourly.0 (Jan 22 20:00)qtree1 Original Jan 22 20:00 -qtree2 Original Jan 22 20:00 -qtreeZ Original Jan 22 20:00 -




sv_nightly.0 (Jan 22 00:00)qtree1 Original Jan 22 00:00 -qtree2 Original Jan 22 00:00 -qtreeZ Original Jan 22 00:00 -

sv_hourly.4 (Jan 21 20:00)qtree1 Original Jan 21 20:00 -qtree2 Original Jan 21 20:00 -

qtreeZ Original Jan 21 20:00 -sv_hourly.5 (Jan 21 16:00)

qtree1 Original Jan 21 16:00 -qtree2 Original Jan 21 16:00 -qtreeZ Original Jan 21 16:00 -

sv_nightly.1 (Jan 21 00:00)qtree1 Original Jan 21 00:00 -qtree2 Original Jan 21 00:00 -qtreeZ Original Jan 21 00:00 -


この出力には、書き込み可能であったために元の内容が入っている qtree が表示されます (これらのケースのタイム・スタンプは、Snapshot コピーとまったく同じです)。また、移行中であったために正確なレプリカでも元の内容でもない qtree があるかどうかも表示されます。移行中の qtree は、タイム・スタンプの代わりにダッシュ (-) で示されます。

2 次ストレージの出力例

ボリューム名 (この例では sv_vol) を指定して、SnapVault 2 次ストレージ・システムとして使用されているシステムからコマンドを実行する場合、ボリューム sv_vol

で保持されているすべての SnapVault Snapshot コピーとそれらの Snapshot コピーに含まれている qtree の詳細情報のリストが表示されます。

systemB> snap list -q sv_volVolume sv_volworking...

qtree contents date source-------- --------- -------- -------sv_hourly.0 (Jan 31 20:00)

qtree1 Replica Jan 22 20:40 systemA:/vol/vol2/qtree1qtree2 Replica Jan 22 20:40 systemA:/vol/vol2/qtree2qtreeZ Replica Jan 22 20:40 systemA:/vol/vol2/qtreeZ

sv_hourly.1 (Jan 22 16:00)qtree1 Replica Jan 22 16:00 systemA:/vol/vol2/qtree1qtree2 Replica Jan 22 16:00 systemA:/vol/vol2/qtree2qtreeZ Replica Jan 22 16:00 systemA:/vol/vol2/qtreeZ

sv_hourly.2 (Jan 22 12:00)qtree1 Replica Jan 22 12:00 systemA:/vol/vol2/qtree1qtree2 Replica Jan 22 12:00 systemA:/vol/vol2/qtree2qtreeZ Replica Jan 22 12:00 systemA:/vol/vol2/qtreeZ

.....

この出力には、どの qtree が別の qtree のレプリカであるか、およびソースSnapshot コピーのタイム・スタンプが表示されます。

注: 移行中の qtree は、タイム・スタンプの代わりにダッシュ (-) で示されます。一般的に、移行中の qtree の Snapshot コピー・バージョンの復元を試行しないでください。引数を指定しない場合、出力には、各ボリューム内の Snapshot コピーごとの情報が表示されます。

qtree の Snapshot コピーのリストsnap list コマンドを使用して、qtree に関連する Snapshot コピーおよび該当する場合は Snapshot コピーの 1 次 qtree の起点のリストを表示することができます。

情報を表示するシステムで、次のコマンドを入力します。 snap list -o

[qtree_path] qtree_path は 1 つの qtree を表示します。qtree 名が指定されない場合、ボリューム上のすべての qtree 名に関する情報が表示されます。

snap list -o の出力例

-o パラメーターで qtree パスを指定する場合、snap list の出力には、システムで保持されている関連する SnapVault Snapshot コピーの日付、ソース (ある場合)、および名前が表示されます。例えば、次のとおりです。


systemB> snap list -o /vol/sv_vol/qtree3working...Qtree /vol/sv_vol/qtree3date source name------------ -------- --------Jan 31 18:00 systemA:/vol/vol2/qtree3 hourly.0Jan 31 17:00 systemA:/vol/vol2/qtree3 hourly.1Jan 31 16:00 systemA:/vol/vol2/qtree3 hourly.2Jan 31 15:00 systemA:/vol/vol2/qtree3 hourly.3Jan 30 14:00 systemA:/vol/vol2/qtree3 hourly.4Jan 30 13:00 systemA:/vol/vol2/qtree3 hourly.5Jan 30 12:00 systemA:/vol/vol2/qtree3 hourly.6Jan 30 11:00 systemA:/vol/vol2/qtree3 hourly.7Jan 31 10:00 systemA:/vol/vol2/qtree3 hourly.8Jan 31 9:00 systemA:/vol/vol2/qtree3 hourly.9Jan 31 8:00 systemA:/vol/vol2/qtree3 hourly.10Jan 30 20:00 systemA:/vol/vol2/qtree3 nightly.0Jan 29 20:00 systemA:/vol/vol2/qtree3 nightly.1Jan 26 16:00 systemA:/vol/vol2/qtree3 weekly.0

LUN クローンと SnapVaultLUN クローンは、別の LUN を高いスペース効率でコピーしたものです。最初は、LUN クローンとその親は同じストレージ・スペースを共有します。一方または他方の LUN が変更された場合に限って、追加のストレージ・スペースが消費されます。

Data ONTAP 7.3 より前のリリースでは、SnapVault はそれぞれの LUN クローンを新規 LUN と見なします。このため、LUN クローンの初期転送時には、クローンおよびバッキング LUN からのデータはすべて 2 次ストレージ・システムに転送されます。

LUN を含むボリューム上でのデータ・バックアップおよびリストアについては、「Data ONTAP ブロック・アクセス管理ガイド (iSCSI および FC 用)」を参照してください。

Data ONTAP 7.3 以降では、SnapVault は SnapDrive for Windows を使用して、最適化された方法で LUN クローンを転送できます。この処理を管理するために、SnapDrive for Windows は次に示す 2 つの Snapshot コピーを作成します。

v バッキング Snapshot コピー。これは、クローンを作成する対象の LUN を格納します。

v バックアップ Snapshot コピー。これは、LUN とクローンの両方を格納します。

転送モード

Data ONTAP 7.3 以降では、LUN クローンを含む SnapVault 転送は次の 2 つのモードで実行できます。

v 非最適化モードでは、LUN クローンは LUN として複製されます。このため、LUN クローンとそのバッキング LUN は、宛先では 2 つの別個の LUN として複製されます。SnapVault は、LUN クローンから得られるスペース節約効果を保持しません。

v 最適化モードでは、LUN クローンは宛先で LUN クローンとして複製されます。最適化モードで LUN クローンを 2 次ストレージ・システムに転送できるようにするには、 SnapDrive for Windows を使用する必要があります。


これらのモードは、新規に作成された LUN クローンに適用されます。以降の更新転送時には、どちらのモードでも増分の変更のみが宛先に転送されます。

注: 個々の関係は、最適化または非最適化のどちらかであることが必要です。2 つのモードを切り替えることはできません。

非最適化モードでの LUN クローンの転送LUN クローンは通常、2 次ストレージ・システム上で完全な LUN として複製されます。これは、デフォルトでは非最適化転送が使用されるからです。

データを非最適化モードで転送する際には、事前に次の点を考慮してください。

v バッキング Snapshot コピーが 1 次ストレージ・システム上に存在している必要があります。2 次ストレージ・システム上には存在していなくても構いません。

v スペースの節約効果はありません。LUN クローン全体、およびバッキング LUN

からのデータすべてが、2 次ストレージ・システムに複製されます。

v 転送の宛先側に LUN クローンが存在してはなりません。この転送には、リストア転送も含まれます。宛先側に LUN クローンがあると、転送は失敗します。LUN クローンを破棄し、転送を再実行する必要があります。

注: リストア操作後に、すべての LUN クローンが LUN に変換されます。

LUN クローンは、SnapDrive for Windows を使用して、最適化モードでの転送を行います。

LUN クローンは、SnapVault関係の管理に SnapDrive for Windows を使用している場合に限って、最適化モードで複製できます。

LUN クローンを最適化モードにして SnapVault を使用するには、事前に次の要件を考慮してください。

v SnapDrive for Windows は、TxF リカバリー用の Microsoft Windows ボリューム・シャドー・コピー・サービスをサポートする最適化 LUN クローンのみを転送します。ボリューム・シャドー・コピー・サービスは、アプリケーション整合性のある Snapshot コピーの作成に役立ちます。バックアップ・アプリケーションが Snapshot 作成時に TxF リカバリー・データを要求している場合、SnapDrive

for Windows はこれらの Snapshot コピーを自動的に作成します。ボリューム・シャドー・コピー・サービスおよび TxF リカバリー・データについて詳しくは、Microsoft の資料を参照してください。

v 1 次と 2 次の両方のストレージ・システムが Data ONTAP 7.3 以降のリリース上で実行されている場合、SnapVault は 2 次ストレージ・システム上で LUN クローンを作成し、SnapDrive for Windows を使用して最適化された転送が行われます。

v 関係が SnapDrive for Windows に引き継がれた後、その関係を外部に移動してはなりません。

重要: CLI から手動更新を実行しないでください。データ破壊の原因になる可能性があります。

v SnapVault 関係を作成する際には、SnapVault 1 次ストレージ・システムに LUN

クローンが含まれていないことを確認してください。


v バッキング LUN およびクローン LUN が別々の qtree 内にあると、LUN クローンの初期転送が正しく動作しません。

v LUN クローン転送が正しく機能するためには、バッキング Snapshot コピーが 2

次ストレージ・システム上に存在している必要があります。これが 1 次ストレージ・システム上に存在していなくても、最適化された転送は可能です。

v バッキング Snapshot コピーが 2 次ストレージ・システム上で削除されると、バックアップ Snapshot コピーの転送は失敗します。

v バッキング Snapshot コピーが 1 次ストレージ・システム上では削除されていても、2 次ストレージ・システム上には存在する場合、転送は正常に行われます。

v 2 次ストレージ・システム上のバッキング Snapshot コピーは、バックアップSnapshot コピーの転送後にロックされます。バッキング Snapshot コピーを削除するには、まずそれに依存するバックアップ Snapshot コピーを削除してください。バックアップ Snapshot コピーを見つけるには、lun snap usage コマンドを実行します。

v リストア操作時に、バックアップ Snapshot コピーを転送するためには、バッキング Snapshot コピーが事前に 1 次ストレージ・システム上にあることが必要です。バッキング Snapshot コピーが既に 1 次ストレージ・システム上に存在する場合、再び転送する必要はありません。

v SnapVault 転送の後にボリューム SnapMirror カスケードが続く場合は、バッキング Snapshot コピーの転送中にボリューム SnapMirror 更新を実行しないでください。このようにすると、LUN クローンの作成時に、次善のバッキング Snapshot

コピーを SnapVault が検出する可能性があります。データ破壊が起こる可能性はありませんが、余分な Snapshot コピーがロックされる場合があります。

v バッキング Snapshot コピーの転送中に、Snapshot コピーを手動で作成しないでください。

注: ボリューム・シャドー・コピー・サービスに基づくバックアップのために、SnapDrive for Windows が Data ONTAP 7.3 上で実行される SnapVault 関係を使用している場合は、Data ONTAP を 7.3 より前のリリースに戻さないでください。SnapDrive for Windows を使用して、ボリューム・シャドー・コピー・サービスに基づく Snapshot コピーを転送する方法について詳しくは、「SnapDrive for Windows

Installation and Administration Guide」を参照してください。

SnapVault の設定を変更する方法snapvault modify を使用して、1 次ストレージ・システム (ソース) qtree (snapvault

start コマンドを使用して指定したもの) を変更できます。

snapvault modify コマンドを使用して、転送速度と終了までの試行回数に関するSnapVault の設定を変更できます。ストレージ・システムのハードウェアまたはソフトウェアに変更があった場合に、これらの設定を変更する必要が生じることがあります。

オプションの意味は、snapvault start コマンドの場合と同じです。オプションが設定されると、そのオプションの構成が変更されます。オプションが設定されない場合は、そのオプションの構成は変更されません。



snapvault modify コマンドは、2 次ストレージ・システムからのみ使用できます。このコマンドを使用して、関係がセットアップされた後に試行回数を変更することもできます。これは、ネットワークの計画停止を行うときに役立ちます。

1 次システム、ボリューム、または qtree の名前が変更された場合に、snapvault

modify コマンドを使用して、ソースを変更できます。これにより、1 次および 2

次のストレージ・システム間で既存の SnapVault 関係の継続性が保たれます。ただし、1 次 qtree を別のボリュームまたはストレージ・システムにコピーし、このコマンドを使用してその新しい場所からバックアップを作成することはできません。

SnapVault スケジュールを変更する必要がある場合は、snapvault snap sched コマンドを使用します。

関連概念

210ページの『SnapVault バックアップ関係を開始する方法』1 次および 2 次のストレージ・システム上で SnapVault を使用可能に設定し、1 次および 2 次のストレージ・システムが互いにアクセスできるようにした後、どのqtree またはボリュームのデータを 1 次ストレージ・システムから SnapVault 2 次ストレージ・システムに転送するか指定する必要があります。その後、1 次ストレージ・システムから 2 次ストレージ・システムへの完全な (ベースライン) データ転送を実行する必要があります。

SnapVault バックアップ関係の設定の変更snapvault start コマンドで入力した値を変更できます。

2 次ストレージ・システムから次のコマンドを単一行で入力します。snapvault

modify [-k kbs] [-t n] [-o options] [-S [prim_system:]prim_qtree_path]

[sec_system:]sec_qtree_path

-k kbs は、1 次ストレージ・システムのスロットル (転送速度) の値をキロバイト/

秒の単位で指定します。unlimited の値を指定すると、可能な限り高速で転送が実行されます。その他の有効値は、正の整数です。-t n は、転送をやめるまでに試行する回数を指定します。デフォルトは 2 です。0 に設定された場合、2 次ストレージ・システムは qtree を更新しません。これは、qtree への更新を一時的に停止する 1 つの方法です。options は opt_name=opt_value [[, opt_name=opt_value ]...] です。使用可能なオプションについて詳しくは、SnapVault マニュアル・ページを参照してください。

注: クライアントがファイルを読み取るときにアクセス時間が変化するためにSnapVault が i ノードを転送しないようにするには、-o ignore_atime=on を設定します。-S [prim_system:]prim_qtree_path は、qtree の 1 次ストレージ・システムを指定します。[sec_system:]sec_qtree_path は、更新用の 2 次ストレージ・システムを指定します。


例

次の例では、1 次ストレージ・システム上の名前 qtree3 が qtreeBob に変更された後で 1 次ストレージ・システムの systemB:/vol2/qtree3 上のデータのバックアップが継続されるように SnapVault を変更する方法を示します。


Snapvault server is ON.Source Destination State Lag StatussystemB:/vol/vol2/qtree3 systemA:/vol/sv_vol/qtree3 Snapvaulted 02:48:24 Idle

[The qtree3 on systemB is renamed qtreeBob.]

systemA> snapvault modify -S systemB:/vol/vol2/qtreeBob /vol/sv_vol/qtree3


Snapvault server is ON.Source Destination State Lag StatussystemB:/vol/vol2/qtreeBob systemA:/vol/sv_vol/qtree3 Snapvaulted 0:00:31 Idle

2 次ストレージ・システム上で qtree を手動で更新する理由snapvault update コマンドを使用して、1 次ストレージ・システム上の Snapshot コピーから、2 次ストレージ・システム上の SnapVault qtree を手動で更新できます。

次のいずれかの状態が生じた場合に、1 次ストレージ・システムのデータを保護するために、スケジュール外の時間に更新するとよいでしょう。

v 1 次ストレージ・システム上のディスクに障害が発生し、データの保護を強化する必要がある。

v ネットワーク上の問題が原因で夜間バックアップが失敗した。

v 1 次ストレージ・システムのハードウェアを再構成する予定である。

v 静止したデータベースの Snapshot コピーを転送する必要がある。

注: ここに示した説明と手順は、Data ONTAP を実行するストレージ・システムのSnapVault バックアップのみに関連しています。オープン・システムのドライブおよびディレクトリーの SnapVault バックアップについては、Open Systems SnapVault

の資料を参照してください。

手動による 2 次ストレージ・システム qtree の個別更新2 次ストレージ・システム上の SnapVault qtree を手動で更新することができます。

2 次ストレージ・システム上の SnapVault qtree を手動で更新するには、2 次ストレージ・システムで次のコマンドを入力します。snapvault update [options]

[sec_system:]sec_qtree_path options は、以下の 1 つ以上が可能です。

v -k kbs は、構成済みの速度を指定変更して、この Snapshot コピーの転送に対するスロットル (転送速度) の値をキロバイト/秒の単位で指定します。デフォルト値の unlimited では、可能な限り高速で転送が実行されます。

v -s snapname では、現在の基本 Snapshot コピーよりも最近の 1 次ストレージ・システムの Snapshot コピーを指定することができます。


[sec_system:]sec_qtree_path は、更新する 2 次ストレージ・システム qtree の名前です。

2 次ストレージ・システムで Snapshot コピーを更新する方法の例

以下の例は、2 次ストレージ・システムで Snapshot コピーを更新する方法を示しています。

例 1systemB> snapvault update /vol/vol2/qtree3

SnapVault は、2 次ストレージ・システム (systemB) の qtree を、1 次ストレージ・システム (systemA) で作成する qtree の新しい Snapshot コピーのデータで更新します。1 次ストレージ・システムのデータの場所を指定する必要がありません。snapvault start コマンドを使用して SnapVault 関係をセットアップしたときに既に指定したためです。

例 2

2 次ストレージ・システム (systemB) の qtree3 を、1 次ストレージ・システム(systemA) の qtree3 の特定の Snapshot コピーで更新するには、次の例のように -s

オプションを使用して、1 次ストレージ・システムの Snapshot コピーを指定します。

systemB> snapvault update -s my_snap systemB:/vol/vol0/qtree3

結果: SnapVault は、2 次ストレージ・システム (systemB) の qtree を、1 次ストレージ・システム (systemA) で以前に作成した qtree3 の Snapshot コピー (my_snap)

データで更新します。

注: snapvault update コマンドは、新しい Snapshot コピーを 2 次ストレージ・システムに作成しません。2 次ストレージ・システムに新しい Snapshot コピーを作成するには、snapvault snap create コマンドを使用します。

関連概念

『Snapshot コピーを手動で作成する理由』次の理由から、手動で (スケジュール外) Snapshot コピーを作成することがあります。

Snapshot コピーを手動で作成する理由次の理由から、手動で (スケジュール外) Snapshot コピーを作成することがあります。

v 計画ダウン時間を予定している、またはダウン時間から復旧する必要がある (ダウン時間中に Snapshot コピーが定時に作成されなかった)。

v 2 次 qtree の手動更新を行った直後で、 2 次ストレージ・システム上に保存されている Snapshot コピーにその更新内容を即時に取り込む必要がある。



関連タスク

230ページの『手動による 2 次ストレージ・システム qtree の個別更新』2 次ストレージ・システム上の SnapVault qtree を手動で更新することができます。

手動による Snapshot コピーの作成Snapshot コピーを作成するボリュームが入った SnapVault 1 次ストレージ・システムまたは SnapVault 2 次ストレージ・システムで、snapvault snap create コマンドを実行します。

手動でボリュームの Snapshot コピーを作成するには、1 次ストレージ・システムまたは 2 次ストレージ・システムから次のコマンドを入力します。snapvault snap

create volume_name snap_name

volume_name は、作成される Snapshot コピーが置かれるボリュームの名前です。snap_name は、作成する Snapshot コピーのベース名です。このコマンドの呼び出し時に既にボリュームで Snapshot コピーが作成されている場合、このコマンドは、他の Snapshot コピーが完了した後で実行されます。

例

systemB> snapvault snap create vol1 sv_nightly

SnapVault は、新しい Snapshot コピーを作成し、指定された Snapshot コピーのベース名に基づいて、この Snapshot コピーが SnapVault スケジュール・プロセスによって作成された場合と同じように番号を付けます。SnapVault は、新しいSnapshot コピーに sv_nightly.0 という名前を付けて、古い Snapshot コピーを名前変更し、最も古い sv_nightly Snapshot コピーを削除します。

注: snapvault snap sched -x コマンドとは異なり、snapvault snap create コマンドは、新しい Snapshot コピーを作成する前に 2 次ストレージ・システム qtree のデータを 1 次ストレージ・システム qtree のデータで更新しません。snapvault snap

create コマンドを実行する前に 2 次 qtree を更新する場合は、snapvault updateコマンドを使用してください。

関連タスク

230ページの『手動による 2 次ストレージ・システム qtree の個別更新』2 次ストレージ・システム上の SnapVault qtree を手動で更新することができます。

SnapVault または Open Systems SnapVault 2 次ボリュームの名前変更SnapVault または Open Systems SnapVault の更新は、SnapVault または Open

Systems SnapVault 2 次 (宛先) ボリュームが名前変更されると機能しません。


qtree が SnapVault, で qtree を構成するための snapvault start コマンドを使用して構成されていない場合、次のエラーが出されます。


Error: Not a snapvaulted qtree, ignoring.

qtree は SnapVault qtree レプリカではありません。

1. 次のコマンドを入力します。vol rename oldvolname newvolname

2. 変更を確認するには、次のコマンドを入力します。snapvault status snapvault

status によって新しいパスが表示されます。

3. 次のコマンドを入力して変更を確認します。snapvault status -c snapvault

status -c では、まだ新しいパスは表示されません。

4. 次のコマンドを入力します。snapvault start -S pri_filer:pri_qtree

sec_filer:sec_qtree Snapvault configuration for the qtree has been set.

Qtree /vol/newvolname/sec_qtree is already a replica.

5. 次のコマンドを入力します。 snapvault status -c

注: snapvault status -c によって新しいパスが表示されます。

6. 次のコマンドを入力して、変更が正常に行われたかどうか確認します。snapvault update sec_qtree

7. snapvault status -c の出力には、古いボリューム名のほか、新しいボリューム名を参照する項目が表示されます。snapvault stop コマンドを使用してこれらの項目を除去します。snapvault stop /vol/oldvolname/sec_qtree Snapvault

configuration for the qtree has been deleted. Could not delete qtree:

destination qtree does not existこの出力は、構成情報が削除されたことおよび qtree がディスクに存在しなかったことを示しています。ボリューム名が変更されたため、これは正常な状態です。

SnapVault データの 1 次ストレージ・システムへの復元1 次ストレージ・システムでデータ損失が発生した場合、データを 2 次ストレージ・システムから復元しなければならないことがあります。


SnapVault 2 次ストレージ・システムからデータを復元するには、次のコマンド行操作を行います。

v snapvault restore コマンドを使用して、2 次ストレージ・システムに保存されたバックアップ済み qtree を復元します。Data ONTAP 7.3 以降では、ベースライン復元またはインクリメンタル復元を使用して 1 次ストレージ・システム上の既存の qtree にデータを復元することができます。

– ベースライン復元: 1 次ストレージ・システムは Data ONTAP 7.3 以降を実行している必要があり、2 次ストレージ・システムは任意の Data ONTAP バージョンを実行できます。

– インクリメンタル復元: 1 次と 2 次の両方のストレージ・システムが Data

ONTAP7.3 以降を実行している必要があります。

注: Data ONTAP 7.3 以降では、復元操作がアプリケーションを中断しないように、復元される qtree 内のすべての LUN へのアプリケーションの SCSI 接続は


復元プロセス全体を通して維持されます。ただし、復元操作中の入出力操作は許可されません。中断を伴わないのは、同じ場所でのベースライン復元およびインクリメンタル復元のみです。

v データを正常に復元した後、snapvault start -r コマンドを使用して、復元されたqtree と 2 次ストレージ・システム上のバックアップ qtree の間の SnapVault 関係を再開します (データの SnapVault 保護を継続するため)。バックアップ関係を継続しない場合は、snapvault release コマンドを使用して、復元された qtree の後続のバックアップを取り消し、SnapVault 関係で使用されていた 2 次ストレージ・システム上のリソースを解放します。

v 同じボリューム内の異なる 1 次 qtree に対する複数の SnapVault 復元操作が同時に実行される場合、Snapshot コピーがさまざまな復元操作によってロックされるため、Snapshot クリーンアップが失敗する可能性があります。そのため、いくつかの不要な Snapshot コピーがボリュームに残されます。

回避策: これらの不要な Snapshot コピーを手動で削除できます。復元操作の基本Snapshot コピーを削除しないでください。

注: 関係を再開しない場合は、復元操作によって作成された Snapshot コピーを削除できます。SnapVault 操作を再開する場合、関係を正常に再開した後でSnapshot コピーを削除できます。

SnapVault 2 次ストレージ・システムから 1 次ストレージ・システムにデータを復元するには、以下のステップを実行します。

1. 1 次 qtree をバックアップ元の 1 次ストレージ・システム上の qtree の正確な場所に復元する場合、以下のいずれかのステップを実行できます。

v ベースライン復元 - ベースライン復元の宛先を既存の qtree または既存でない qtree にすることができます。

注: 既存の qtree へのベースライン復元の場合、復元操作によって qtree データが上書きされます。

v インクリメンタル復元 - インクリメンタル復元では、2 次 qtree から指定された 1 次 qtree に増分の変更のみが転送されます。

注: 既存の 1 次 qtree の上に復元する場合、最初にインクリメンタル復元を試行することをお勧めします。共通 Snapshot コピーがないためにインクリメンタル復元が失敗した場合に、同じ場所でのベースライン復元を試行してください。これは、インクリメンタル復元の方が効率的な復元であるためです。

2. 1 次ストレージ・システムで、次のコマンドを単一行で入力します。snapvault

restore [-f] [-k n] [-r] [-w] [-s snapname] -S sec_system:sec_qtree_path

[prim_system:]prim_qtree_path

-S [sec_system:]sec_qtree_path は、データを復元する元の 2 次ストレージ・システムおよび qtree パスです。

-f オプションは、最初にユーザーの確認を求めずにコマンドを強制的に続行します。

-k オプションは、最大転送速度 (キロバイト/秒) を設定します。


-r オプションは、インクリメンタル復元を試行します。インクリメンタル復元を使用して、2 次ストレージ・システムにある任意のバックアップ済みバージョン以降に 1 次ストレージ・システム qtree に行われた変更を復帰することができます。この方法は、2 次ストレージ・システムから 1 次ストレージ・システムに要求された変更のみを転送するため、ベースライン復元よりも効率的です。

-w オプションは、ベースライン転送の開始後にコマンドが返されないようにします。代わりに、転送が完了 (または失敗) するまで待ちます。その時点で、完了状況を出力してから戻ります。

-s オプションは、復元操作が 2 次ストレージ・システムの snapshot snapname

から行われる必要があることを指定します。

prim_system は、復元先とする 1 次ストレージ・システムの名前です。指定される場合、この名前はホスト・システムの名前と一致する必要があります。

prim_qtree_path は、復元先とする 1 次ストレージ・システム qtree の名前です。

snapvault restore コマンドのオプションについて詳しくは、na_snapvault(1) マニュアル・ページを参照してください。

3.

操作処置

1 次ストレージ・システム上の新しく復元された qtree の SnapVault バックアップを再開する


1 次ストレージ・システム上の新しく復元された qtree とその 2 次 qtree パートナーの間のバックアップ関係を中止する


4. 復元された qtree と 2 次ストレージ・システム上のバックアップ qtree の間のSnapVault 関係を再開するには、次のコマンドを単一行で入力します。snapvault

start -r [options] -S [prim_system:]prim_qtree_path

[sec_system:]sec_qtree_path

-r は、復元された 1 次ストレージ・システムからバックアップを再開するために必要です。snapvault コマンド構文について詳しくは、na_snapvault(1) マニュアル・ページを参照してください。

5. これで終了です。例 1 を参照してください。

6. 復元された qtree と 2 次ストレージ・システム上のバックアップ qtree の間のSnapVault 関係を中止するには、2 次ストレージ・システムで次のコマンドを入力します。snapvault release sec_qtree_path [prim_system:]prim_qtree_path

sec_qtree_path は、SnapVault 関係から解放する 2 次ストレージ・システムqtree の名前です。

[prim_system:]prim_qtree_path は、解放する 1 次ストレージ・システム qtree の名前です。

7. これで終了です。


SnapVault データを復元する例以下の例は、1 次ストレージ・システムで SnapVault データを復元する方法を示しています。

例 1

この例では、1 次ストレージ・システム (systemA) が 2 次ストレージ・システム(systemB) からのデータの復元を要求して、その後で 2 次ストレージ・システムがSnapVault バックアップ関係を再開する方法を示します。

インクリメンタル復元の場合:

systemA*> snapvault restore -r -s sv_backup.0 -S systemB:/vol/sv_vol/qtree3 systemA:/vol/vol1/qtree3Restore will overwrite existing data in /vol/vol1/qtree3.Are you sure you want to continue? yesTransfer started.Monitor progress with 'snapvault status' or the snapmirror log.

ベースライン復元の場合:

systemA*> snapvault restore -s sv_backup.0 -S systemB:/vol/sv_vol/qtree3 systemA:/vol/vol1/qtree3Restore will overwrite existing data in /vol/vol1/qtree3.Are you sure you want to continue? yesTransfer started.Monitor progress with 'snapvault status' or the snapmirror log.

ベースライン復元またはインクリメンタル復元のいずれかを実行した後で、関係を再開します。

systemB*> snapvault start -r -S systemA:/vol/vol1/qtree3 systemB:/vol/sv_vol/qtree3The resync base snapshot will be: sv_backup.0Resync may alter the data in this qtree.Are you sure you want to resync the qtree? yesTransfer started.Monitor progress with 'snapvault status' or the snapmirror log.

例 2

この例では、1 次ストレージ・システム(systemA) が 2 次ストレージ・システム(systemB) からのデータの復元を要求して、その後で 2 次ストレージ・システムが両方のストレージ・システムで SnapVault バックアップ関係を取り消して、使用されているリソースを解放する方法を示します。

systemA> snapvault restore -S systemB:/vol/sv_vol/qtree3

/vol/vol1/qtree3systemB> snapvault release /vol/sv_vol/qtree3

systemA:/vol/vol1/qtree3

残りの Snapshot コピーの削除snapvault restore コマンドを使用して 1 次 qtree を復元する場合、SnapVault は、復元された 1 次 qtree のボリュームに残りの SnapVault Snapshot コピーを配置します。この Snapshot コピーは自動的に削除されません。このボリュームを Data

ONTAP によって許可される最大 251 の Snapshot コピーを保持するように構成している場合、この残りの Snapshot コピーを手動で削除する必要があります。そうでないと、新しい Snapshot コピーを作成できません。


1. 復元された qtree のボリュームにあるすべての Snapshot コピー (残りのSnapshot コピーを含めて) を表示するには、次のコマンドを入力します。snap

list primaryvolume 残りの Snapshot コピーは、次の構文で区別されます。primaryhost (nvram_id)_primaryvolume_restoredqtree-dst.x prim_system

(1880911275)_vol1_mytree-dst.2

2. 残りの Snapshot コピーを削除するには、次のコマンドを入力します。snap

delete primaryvolume extrasnapshotname snap delete vol1 prim_system

(1880911275)_vol1_mytreedst.2

SnapVault 転送を中断する方法転送を後で行った方が都合がよい場合、または即時のシャットダウンまたは再始動が必要な場合には、snapvault abort コマンドを使用して進行中の SnapVault 転送を停止できます。

このコマンドは、1 次から 2 次のストレージ・システムへの SnapVault 転送(snapvault start コマンドまたは snapvault update コマンドによって起動された、または snapvault snap sched -x コマンドによってスケジュールに入れられた)、または2 次から 1 次のストレージ・システムに復帰する転送 (snapvault restore コマンドによって起動された) を進行中に停止できます。

snapvault abort コマンドは、1 次ストレージ・システムでも、2 次ストレージ・システムでも入力できます。

1 次から 2 次へのストレージ転送の中止snapvault abort コマンドを使用すると、snapvault start または snapvault update コマンドによって呼び出されたか、snapvault snap sched -x コマンドによってスケジュールされた進行中の 1 次から 2 次ストレージ・システムへの SnapVault 転送を停止できます。

1 次から 2 次ストレージ・システムへの転送を中止するには、1 次または 2 次のいずれかのストレージ・システム・コンソールで次のコマンドを入力します。snapvault abort [-f] [-h] [sec_system:]/vol/volx/sec_qtree

-f オプションは、最初にユーザーの確認を求めずに abort コマンドを強制的に続行します。-h オプションは、ハード中止を実行します。これは、SnapVault 2 次ストレージ・システムでのみ有効です。このオプションは、1 次ストレージ・システムで指定された場合は無視されます。

注: snapvault abort コマンドで -h オプション (ハード中止) を使用する場合、転送を再開できません。sec_system は、SnapVault 2 次ストレージ・システムの名前です。sec_qtree は、SnapVault start または update コマンドによるデータの転送先である2 次 qtree の名前です。


2 次から 1 次へのストレージ転送の中止snapvault abort コマンドを使用すると、snapvault restore コマンドによって呼び出された進行中の 2 次ストレージから 1 次ストレージへの SnapVault 転送を停止できます。

2 次から 1 次へのストレージ転送を中止するには、1 次または 2 次のいずれかのストレージ・システム・コンソールで次のコマンドを入力します。snapvault abort

[prim_system:]/vol/volx/prim_qtree

prim_system は、1 次ストレージ・システムの名前です。prim_qtree は、データの復元先である 1 次 qtree の名前です。

注: snapvault abort コマンドで -h オプション (ハード中止) を使用する場合、転送を再開できません。

SnapVault Snapshot コピーの作成の中止2 次ストレージ・システムで進行中の SnapVault Snapshot コピーの作成を中止できます。

2 次ストレージ・システムのコンソールで次のコマンドを入力します。snapvault

abort -s volx sv_snapname -s オプションは、このコマンドがボリューム volx でSnapshot コピーをベース名 sv_snapname で作成しようとする試行を中止することを指定します。

注: 2 次ストレージ・システムのボリュームおよび Snapshot コピーのベース名をsnapvault status -s 出力で取得することができます。

qtree の SnapVault バックアップの終了1 次ストレージ・システム qtree のデータを保護する必要がなくなった場合、snapvault stop コマンドを使用して、qtree の SnapVault バックアップ・プロセスを終了することができます。

2 次ストレージ・システムから、次のコマンドを入力します。snapvault stop

[sec_system:]sec_qtree_path [sec_system:]sec_qtree_path は、バックアップを止める qtree です。 systemB> snapvault stop systemB:/vol/sv_vol/qtree3 SnapVault

は、2 次ストレージ・システムでの qtree の更新を停止して、その qtree を削除します。2 次ストレージ・システム上の既存の Snapshot コピーは影響を受けませんが、新しい Snapshot コピーが古いものに置き換わると、バックアップが停止されたqtree のデータは表示されなくなります。

注: SnapVault 2 次ストレージ・システムからバックアップ・プロセスを終了した後、1 次ストレージ・システムの廃止になった Snapshot コピーを解放することができます。


関連タスク

『SnapVault 関係の解放』1 次 qtree とその 2 次 qtree バックアップ (最初に snapvault start コマンドで定義された) の間の SnapVault 関係が両方向で不要になった後、この関係を解放することができます。

SnapVault 関係の解放1 次 qtree とその 2 次 qtree バックアップ (最初に snapvault start コマンドで定義された) の間の SnapVault 関係が両方向で不要になった後、この関係を解放することができます。

このタスクについてv 2 次ストレージ・システムで snapvault stop コマンドが完了した後に、1 次ストレージ・システムで SnapVault 関係のシャットダウンの一環として行います。

v 2 次ストレージ・システムで、データが 1 次ストレージ・システムに復元された後、1 次と 2 次の qtree 間のバックアップ関係を再活動化しない場合に行います。

1. 1 次ストレージ・システムのコンソールで、次のコマンドを入力します。snapvault release prim_qtree_path sec_system:sec_qtree_path

2. 2 次ストレージ・システムのコンソールで、次のコマンドを入力します。snapvault release sec_qtree_path prim_system:prim_qtree_path systemB>

snapvault release /vol/sv_vol/qtree3 systemA:/vol/vol1/qtree3

SnapVault をオフにする1 次または 2 次ストレージ・システム上のファイルが重要または最新状態でなくなったため、あるいは別の場所に移動されたために、SnapVault をオフにする場合があります。

1 次ストレージ・システムまたは 2 次ストレージ・システムで SnapVault をオフにするには、次のコマンドを入力します。options snapvault.enable off このオプションは、再起動しても持続します。

Open Systems SnapVault の圧縮機能Open Systems SnapVault の圧縮機能を使用すると、ネットワーク上でネットワーク・データ圧縮が可能になります。この機能は、Open Systems SnapVault データ転送の帯域幅を最適化するために役立ちます。

Data ONTAP 7.3 以降では、圧縮機能を使用して Open Systems SnapVault の帯域幅最適化をサポートします。ただし、SnapVault 1 次ストレージ・システムは、帯域幅最適化をサポートしません。

ネットワーク・データを圧縮するかどうか指定するには、グローバルまたはローカルの圧縮オプションを使用します。


Open Systems SnapVault 関係に対して圧縮機能をグローバルに使用可能にする

すべての Open Systems SnapVault 関係に対してグローバルに帯域幅を最適化するための圧縮機能を使用可能にすることができます。

圧縮機能をグローバルに使用可能にするには、2 次ストレージ・システムで次のコマンドを入力します。options snapvault.ossv.compression on options

snapvault.ossv.compression on を指定すると、圧縮機能がローカル側で指定されていなかった Open Systems SnapVault 関係に対して圧縮が使用可能になります。

注: 圧縮機能は、関係ごとの圧縮オプションが使用可能または使用不可になっている関係のみに対して使用可能になります。

新しい Open Systems SnapVault 関係に対して圧縮機能を使用可能にする

新しい Open Systems SnapVault 関係に対して帯域幅を最適化するための圧縮機能を使用可能にすることができます。

2 次ストレージ・システムで、Open Systems SnapVault 関係のセットアップ時に次のコマンドを入力して圧縮オプションを指定します。snapvault start -o

compression=on -S prim_host:dirpath sec_host:sec_qtree_path

-o compression=on を指定すると、帯域幅を最適化するための圧縮機能が使用可能になります。-S は、1 次ストレージ・システムおよびパスを指定します。最初に qtree を構成するときに指定する必要があります。以前に構成された qtree の初期転送を再開する場合はオプションです。snapvault start -o compression=on -S systemA:C:¥dir3 systemB:/vol/vol1/

qtree3

既存の Open Systems SnapVault 関係に対して圧縮機能を使用可能にする

既存の Open Systems SnapVault 関係に対して帯域幅を最適化するための圧縮機能を使用可能にすることができます。

既存の Open Systems SnapVault 関係に対して圧縮機能を使用可能にするには、次のコマンドを入力します。snapvault modify -o compression=on [-S

[prim_host:]dirpath] [sec_system:]sec_qtree_path -S は、1 次ストレージ・システムおよびパスを指定します。最初に qtree を構成するときに指定する必要があります。以前に構成された qtree の初期転送を再開する場合はオプションです。snapvault modify -o compression=on /vol/vol1/qtree3

注: snapvault modify コマンドは、次回の転送時に初めて有効になります。進行中のSnapVault 転送は影響を受けません。


Open Systems SnapVault 関係に対して圧縮機能をグローバルに使用不可にする

すべての Open Systems SnapVault 関係に対してグローバルに帯域幅を最適化するための圧縮機能を使用不可にすることができます。

圧縮機能をグローバルに使用不可にするには、2 次ストレージ・システムで次のコマンドを入力します。 options snapvault.ossv.compression off options

snapvault.ossv.compression off を指定すると、圧縮機能がローカル側で指定されていなかった Open Systems SnapVault 関係に対して圧縮が使用不可になります。

注: 圧縮機能は、関係ごとの圧縮オプションが使用可能または使用不可になっている関係のみに対して使用不可になります。

新しい Open Systems SnapVault 関係に対して圧縮機能を使用不可にする

新しい Open Systems SnapVault 関係に対して圧縮オプションをローカル側で使用不可にすることができます。

それぞれの SnapVault 関係に対して圧縮オプションをローカル側で使用不可にするには、2 次ストレージ・システムで次のコマンドを入力します。snapvault start

-o compression=off -S prim_host:dirpath sec_host:sec_qtree_path

-S は、1 次ストレージ・システムおよびパスを指定します。最初に qtree を構成するときに指定する必要があります。以前に構成された qtree の初期転送を再開する場合はオプションです。-o compression=off は、圧縮機能を使用不可にします。snapvault start -o compression=off -S systemA:C:¥dir3 systemB:/vol/vol1/

qtree3

既存の Open Systems SnapVault 関係に対して圧縮機能を使用不可にする

既存の Open Systems SnapVault 関係に対して圧縮機能を使用不可にすることができます。

既存の Open Systems SnapVault 関係に対して圧縮機能を使用不可にするには、2 次ストレージ・システムで次のコマンドを入力します。snapvault modify -o

compression=off [-S [prim_system:]prim_qtree_path]

[sec_system:]sec_qtree_path -S は、1 次ストレージ・システムおよびパスを指定します。 snapvault modify -o compression=off /vol/vol1/qtree3

注: 既存の SnapVault 関係に対してグローバル圧縮オプションのデフォルト値を使用するには、次のコマンドを入力します。snapvault modify -o

compression=default sec_qtree_path snapvault modify コマンドは、次回の転送時に初めて有効になります。進行中の SnapVault 転送は影響を受けません。

圧縮機能のデフォルト値の設定ローカル側で圧縮が使用可能または使用不可になっている既存の Open Systems

SnapVault 関係に対して圧縮機能のデフォルト値を設定できます。


デフォルト値を設定するには、次のコマンドを入力します。snapvault modify -o

compression=default sec_qtree_path

v 圧縮機能がグローバルに使用可能になっている場合、圧縮はこの Open Systems

SnapVault 関係に対して使用可能になります。

v 圧縮機能がグローバルに使用不可になっている場合、圧縮はこの Open Systems

SnapVault 関係に対して使用不可になります。

Open Systems SnapVault 関係の圧縮状況の表示Open Systems SnapVault 関係の圧縮状況を表示できます。

それぞれの Open Systems SnapVault 関係の圧縮状況を表示するには、次のコマンドを入力します。snapvault status -c 関係ごとに compression=on またはcompression=off が表示されます (その関係に対して構成されている場合)。

注: それぞれの Open Systems SnapVault 関係の圧縮率を表示するには、snapvault

status -l コマンドを実行します。

SnapVault 2 次ストレージ・システムの保護SnapVault 2 次ストレージ・システムと SnapMirror 宛先ストレージ・システム、ニアライン・システム、またはテープ・バックアップ装置の間で SnapMirror 関係をセットアップすることによって、SnapVault 2 次ストレージ・システムのデータに対してバックアップ/スタンバイ・サービス、またはバックアップ/リストア保護を提供できます。

v SnapVault 用の SnapMirror バックアップ/スタンバイ・サービスは、SnapMirror

宛先デバイスをスタンバイ・デバイスとして使用し、オリジナルの 2 次ストレージ・システムが停止した場合に、代替の SnapVault 2 次ストレージ・システムとして活動化します。

v SnapVault 用の SnapMirror バックアップ/リストア保護は、SnapMirror 宛先デバイスをソースとして使用し、データ損失またはデータ破壊が発生した SnapVault

2 次ストレージ・システムに、このソースからバックアップ・データをリストアできます。

SnapMirror を使用して SnapVault データを複製する方法SnapVault 2 次ストレージ・システムは、そのソースで通常どおり SnapVault 操作を実行します。その後、スケジュールされたボリュームごとに、システムはSnapVault データをその SnapMirror 宛先パートナーまたはテープ・バックアップ装置に複製します。

この構成では、SnapVault は、1 次ストレージ・システム上の Snapshot バージョンが SnapVault 2 次ストレージ・ユニットからその SnapMirror 宛先に正常に複製されるまで、そのバージョンを削除しません。これにより、SnapVault 2 次ストレージ・システムが使用不可になった場合でも Snapshot バージョンを必ず取り出せることが保証されます。


関連概念

186ページの『ボリューム SnapMirror を使用した SnapVault 2 次システムの保護』ボリューム SnapMirror は、SnapVault 2 次ストレージ・システム上のボリュームから、Data ONTAP を実行するリモート (3 次) ストレージ・システム上のボリュームにデータをマイグレーションする SnapMirror 関係を作成して、SnapVault 2 次システムを保護します。 SnapMirror は、SnapVault 2 次データの正確なレプリカを 3

次ストレージ・システム上で提供します。

SnapVault のバックアップおよびスタンバイ・サービスの使用SnapVault 2 次ストレージ・システム用に SnapMirror バックアップおよびスタンバイ保護をセットアップすることができます。

1. license コマンドを使用して、SnapVault 2 次ストレージ・デバイスが SnapVault

2 次ストレージと SnapMirror フィーチャーの両方のライセンス交付を受けていることを確認します。

2. license コマンドを使用して、SnapMirror 宛先デバイスが SnapVault 2 次ストレージと SnapMirror フィーチャーの両方のライセンス交付を受けていることを確認します。

3. アクティブな SnapVault 2 次ストレージ・システムからディスク・ベースの宛先デバイス (別のストレージ・システムまたはニアライン・システム) へのSnapMirror 複製をセットアップします。

4. アクティブな SnapVault 2 次ストレージ・システムが損傷したり、破壊された場合、SnapMirror 宛先デバイスを代替の SnapVault 2 次システムに切り替えて、1

次ストレージ・システムからデータをバックアップするタスクを実行します。構成は次のとおりです。systemA (1 次) には systemB (2 次) への SnapVault バックアップがあり、systemB には systemC (3 次) への SnapMirror バックアップがあります。 systemB が障害を起こした場合は、SystemB と SystemC の間のSnapMirror バックアップを中断して、systemA で systemC への SnapVault バックアップが行われるように SnapVault 関係を再作成します。

5. データ損失または破壊の理由を評価した後、2 次ストレージ・システムを 3 次ストレージ・システムとしてのパスに戻すか、新しいストレージ・システムを 3

次ストレージとして追加します。

systemB を追加した後、構成は次のようになります。systemA (1 次) にはsystemC (2 次) への SnapVault バックアップがあり、systemC には systemB (3

次) への SnapMirror バックアップがあります。新しいストレージ・システムを追加した場合は、構成の systemB に取って代わります。

6. オプションのステップとして、ストレージ・システムを元の構成に戻すことができます。


関連タスク


『SnapVault 関係の再作成』下記の手順における元の構成では、systemA: /vol/vol1/qtree3 とsystemB:/vol/vol2/qtree3 の間に SnapVault 関係があり、SnapVault 宛先ボリューム systemB:vol2 が 3 番目のストレージ・システムにある別のボリュームsystemC:vol3 にバックアップされています。

245ページの『3 次ストレージ・システム SnapMirror バックアップを戻して追加する』どのような種類のバックアップ中断が発生したかに応じて、古い 2 次ストレージ・システムを 3 次ストレージ・システムとして再び使用できる場合と、新しいシステムの割り当てが必要になる場合があります。

245ページの『ストレージ・システムの元の構成への復帰』バックアップ構成を元の systemA、systemB、および systemC の構成に戻す必要がない可能性があるため、これはオプションの手順です。

SnapVault 関係の再作成下記の手順における元の構成では、systemA: /vol/vol1/qtree3 とsystemB:/vol/vol2/qtree3 の間に SnapVault 関係があり、SnapVault 宛先ボリューム systemB:vol2 が 3 番目のストレージ・システムにある別のボリュームsystemC:vol3 にバックアップされています。


1 次ストレージ・システムから 3 次ストレージ・システムまでの SnapVault 関係を再作成するには、以下のステップを実行します。

1. 新しい 2 次ストレージ・システム (systemC) 上のボリュームに対するボリュームの SnapMirror 関係を分断して、書き込み可能にします。 systemC から次のステップを実行します。snapmirror quiesce vol3 snapmirror break vol3

2. 新しい 2 次ストレージ・システム (systemC) 上の SnapMirror 関係の状況を検査します。 systemC から次のステップを実行します。snapmirror status

SnapMirror 関係は broken-off のはずです。

3. 新しい 2 次ストレージ・システム (systemC) 上の SnapVault 関係の状況を検査します。 snapvault status SnapVault 関係は snapvaulted のはずです。

4. snapvault start コマンドを使用して、SnapVault 構成情報を新しい 2 次ストレージ・システムに追加します。

注: これによって新しいベースラインが開始されるのではなく、レジストリーが更新されます。systemC (新しい 2 次システム) から次のステップを実行します。snapvault

start -S systemA:/vol/vol1/qtree3 systemC:/vol/vol3/qtree3

5. 新しい SnapVault 構成が存在することを確認します。 systemC から次のステップを実行します。snapvault status -c


6. 手動で systemC を更新することによって、新しい SnapVault 関係をテストします。 systemC から次のステップを実行します。snapvault update

systemC:/vol/vol3/qtree3

7. 古い 2 次ストレージ・システムで使用されていたスケジュールを新しい 2 次ストレージ・システムで再作成して、アクセス許可が設定されていることを確認します。

8. 除去された systemA から systemB の SnapVault 関係のために systemA でロックされていたリソースを解放します。 systemA から次のステップを実行します。 snapvault release /vol/vol1/qtree3 systemB:/vol/vol2/qtree3

3 次ストレージ・システム SnapMirror バックアップを戻して追加するどのような種類のバックアップ中断が発生したかに応じて、古い 2 次ストレージ・システムを 3 次ストレージ・システムとして再び使用できる場合と、新しいシステムの割り当てが必要になる場合があります。


3 次システムを追加した後、systemA では systemC への SnapVault バックアップが行われ、systemC には systemB (systemB を再使用できない場合は systemD) へのSnapMirror バックアップが行われます。

古いストレージ・システムを 3 次として追加するには、以下のステップを実行します。

1. 新しい 2 次ストレージ・システムの systemC と新しい 3 次ストレージ・システムの systemB の間の SnapMirror 関係を再同期します。 snapmirror resync

-S systemC:vol3 systemB:vol2

2. 古い 2 次ストレージ・システムから 3 次ストレージ・システムへの SnapMirror

関係のためにロックされていたリソースを解放します。 systemB から次のステップを実行します。snapmirror release vol2 systemC:vol3

関連概念


関連タスク


185ページの『ローカル・テープからの SnapVault の復元』SnapMirror のソースとして構成されている SnapVault 2 次ストレージ・ボリュームでデータ損失が起こった場合、snapmirror retrieve コマンドによって、SnapMirror を使用してテープに複製されたデータを SnapVault 2 次ストレージ・ボリュームに復元することができます。

ストレージ・システムの元の構成への復帰バックアップ構成を元の systemA、systemB、および systemC の構成に戻す必要がない可能性があるため、これはオプションの手順です。



元のバックアップ構成に戻す場合、以下のステップを実行してください。

1. 2 次ストレージ・システムへの SnapVault 更新を一時的にブロックすることによって、2 次ストレージ・システムおよび 3 次ストレージ・システムに同じデータがあることを確認します。 2 次ストレージ・システムの systemC から次のステップを実行します。snapvault snap unsched vol3

2. 2 次ストレージ・システムへの更新が 3 次ストレージ・システムに反映されるようにします。 3 次ストレージ・システムの systemB から次のステップを実行します。snapmirror update systemB:vol2

3. 2 次システムと 3 次システムの役割を反転させます。つまり、2 次の役割が 3

次ストレージ・システムになり、3 次の役割が 2 次ストレージ・システムになるようにします。新しい 3 次システム systemC から次のステップを実行します。snapmirror resync systemC:vol3

4. 除去された systemC から systemB の SnapMirror 関係のために systemC でロックされていたリソースを解放します。新しい 3 次ストレージ・システムのsystemC から次のステップを実行します。snapmirror release vol3

systemB:vol2

5. systemB 上の SnapMirror 関係を分断して、元の SnapVault 関係からのSnapVault 更新が行われるようにします。 systemB から次のステップを実行します。snapmirror break vol2

6. systemA から systemB への元の SnapVault 関係を再作成します。 systemB (元の 2 次システム) から次のステップを実行します。snapvault update

/vol/vol2/qtree3

7. systemB から systemC への元の SnapMirror 関係を再作成します。 systemC (元の 3 次システム) から次のステップを実行します。snapmirror update vol3

8. systemC から SnapVault 構成を除去します。 systemC から次のステップを実行します。snapvault stop -f /vol/vol3/qtree3 -f オプションは、2 次ストレージ・システムでのみ使用できます。これは、qtree を構成解除して qtree の更新がこれ以上行われないようにして、qtree をアクティブ・ファイル・システムから削除します。このオプションは、最初に確認を求めずに snapvault stop コマンドを強制的に続行します。

SnapVault を使用してボリューム SnapMirror 宛先を保護する方法SnapVault は、ボリューム SnapMirror 宛先を保護するために頻繁に使用されます。データを長期にわたって保存する場合、ボリューム SnapMirror 宛先から SnapVault

転送を実行できます。

このデプロイメント・シナリオでは、さまざまな 1 次ストレージ・システムからのデータが災害復旧の目的でリモート・サイトに複製されます。ボリュームSnapMirror により、ソースと宛先ストレージ・システムで同一のデータが確保されます。災害復旧サイトで長期保存する必要がある場合 (90 日以上)、SnapVault を使用してデータを SnapMirror 宛先からバックアップすることができます。

SnapVault を使用して SnapMirror 宛先ボリュームまたは qtree をバックアップする場合、以下の点を確認してください。


v SnapMirror 1 次に SnapMirror ライセンスがインストールされた。SnapMirror 宛先 (および SnapVault 1 次) に、SnapMirror および SnapVault の両方の 1 次ライセンスがインストールされた。SnapVault 2 次に、SnapVault 2 次ライセンスがインストールされた。

v SnapVault 操作は SnapMirror スケジュール更新同士の間に行われる。そうでなく、SnapVault 操作が進行中であるか開始されている場合、SnapMirror 更新は失敗します。

SnapVault 2 次ストレージ・システム上のスケジュールのみを構成します。SnapVault ソースは、ボリューム SnapMirror の一番最近の Snapshot コピーを転送する Snapshot コピーとして選択します (ボリューム SnapMirror カスケードに似ています)。SnapVault ソース・ボリュームが SnapMirror 宛先ボリュームである場合、Snapshot コピーを SnapVault 転送のソース Snapshot コピーとして指定できません。その場合、Data ONTAP は、SnapMirror が生成した Snapshot コピーをSnapVault ベースライン Snapshot コピーとして使用します。

1 次または災害復旧データの長期バックアップについて詳しくは、「SnapMirror

Async Overview and Best Practices Guide」を参照してください。

関連情報

http://www.netapp.com/us/library/technical-reports/tr-3446.html

ボリュームの vol lang 変更時のエラーSnapVault または qtree SnapMirror の宛先を含むボリュームでボリュームの言語設定が変更されるときに、警告メッセージが Data ONTAP CLI に表示されます。

qtree のレプリカが構成されている 2 次ストレージ・システムでボリュームの言語設定を変更した後で SnapVault または qtree SnapMirror 関係を更新すると、次のEMS エラー・メッセージが表示されます。

Volume language was changed before this transfer or it was changed before some previousupdate transfer for the relationship of qtree %s. This might create some problemswith further replication transfers of the relationship.

修正アクション: 転送用に新しいベースラインを作成します。

SnapVault for NetBackup についてSnapVault for NetBackup フィーチャーは、ニアライン 2 次ストレージ・システムを使用して、異種混合の 1 次ストレージ・システムのために最適化されたディスク・ベースのバックアップ・リポジトリーを提供します。ニアライン機能を備えたストレージ・システムとともに NetBackup ソフトウェアを使用すれば、最小限の量の 2 次ストレージを使用して多数のバックアップ・イメージを保管でき、データを迅速、容易にリカバリーできるバックアップ/リカバリー・ソリューションが実現します。

既存のバックアップ・トポロジーを変更せずに、SnapVault for NetBackup を容易に統合できます。NetBackup マスター・サーバー、メディア・サーバー、クライアントなど、トポロジー内のコンポーネントはすべて変更されません。 SnapVault for


http://www.netapp.com/us/library/technical-reports/tr-3446.html

NetBackup の追加は、従来型の NetBackup 磁気テープ装置またはディスク・ストレージ・ユニット (DSU) の追加と同様に行うことができます。

注: これは、NetBackup 6.0 MP5 以降を使用していることを前提としています。

Data ONTAP ソフトウェアを使用すると、NetBackup メディア・サーバーが、複数のプラットフォーム (またはクライアント) から、2 次ストレージ・システムとして構成され、ニアライン機能を使用可能に設定したストレージ・システムにデータをバックアップできます。

対象のクライアントには、AIX、Solaris、HP-UX、Linux、Novell、Windows Server

2000、または Windows 2003 Server システムが含まれます。この構成を次の図に示します。詳しくは、NetBackup 資料を参照してください。

SnapVault for NetBackup の利点SnapVault for NetBackup フィーチャーは、GUI 管理、2 次ストレージの最適化などの利点を備えています。

SnapVault for NetBackup フィーチャーには、次の利点があります。

v バックアップおよびリカバリーの管理を GUI ベースで行うことができます。

v UNIX、Linux、Novell、Solaris、Windows システムなど、異種混合の 1 次ストレージ・システムをバックアップできます。NetBackup アプリケーションによってサポートされるシステムについては、NetBackup の資料を参照してください。

v 即時アクセスが可能な多数のバックアップ・イメージをオンラインで作成できます。

図 21. SnapVault for NetBackup


v このフィーチャーは、アーカイブ Snapshot コピー内に 1 次ファイル・システムのポイント・イン・タイム・イメージを作成します。

v NFS および CIFS の両プロトコルで、ファイルおよびディレクトリーをドラッグ・アンド・ドロップしてリカバリーできます。

注: このフィーチャーを使用するには、NetBackup Enterprise 6.0 MP5 以降が必要です。

v このフィーチャーは、バックアップ・イメージ間の冗長データ・ブロックを排除することによって 2 次ストレージを最適化します。

v アクティブ/アクティブ構成でニアラインのストレージ・システムにバックアップを送信することによって、SnapVault for NetBackup の高可用性を実現できます。

v ボリューム SnapMirror をニアラインのストレージ・システム上で使用して、SnapVault for NetBackup 用の災害復旧ソリューションを構成できます。

SnapVault for NetBackup の用語SnapVault for NetBackup フィーチャーを説明する以下の用語を知っておく必要があります。

v アーカイブ Snapshot コピー ― SnapVault for NetBackup によって、バックアップされたファイル・システムのポイント・イン・タイム・コピーとして保存された Snapshot コピー。Data ONTAP は、Snapshot コピーを使用してアーカイブSnapshot コピーを作成します。

v クライアント - バックアップするデータが入ったストレージ・システム。

v マスター・サーバー - すべての管理アクションおよびバックアップ・スケジューリングを実行する NetBackup サーバー。

v メディア・サーバー - 2 次ストレージ・ユニットを管理するマスター・サーバーによって制御される NetBackup サーバー。

v ディスク・ストレージ・ユニット (DSU) - NetBackup がファイルおよびデータを保管するストレージ・デバイス。SnapVault for NetBackup フィーチャーの場合、ディスク・ストレージ・ユニット (DSU) は、2 次ストレージ・システム上のFlexVol ボリュームです。

v 1 次ストレージ・システム ― 「クライアント」を参照。

v ポリシー - 特定のクライアントまたはクライアント・グループのバックアップ基準を定義する一連のルール。

v 2 次ストレージ・システム ― データのバックアップ先となるストレージ・システム。

v 2 次システム qtree - 1 次ストレージ・システムからのデータのバックアップ先となる 2 次ストレージ・システムの qtree。

v Snapshot コピー ― SnapVault が一定の間隔で 2 次ストレージ・システム上に作成するバックアップ・イメージ。

NetBackup カタログとはNetBackup カタログは、NetBackup マスター・サーバーに常駐する内部データベースです。


このデータベースは、すべてのバックアップ・アクティビティーのレコード、およびメディアとストレージ・デバイスに関する情報を格納しています。 NetBackup カタログを使用して、SnapVault qtree アーカイブをモニターおよび表示できます。NetBackup カタログは、それぞれの qtree アーカイブに含まれるファイル個別のレコードは含みません。

詳しくは、NetBackup 資料を参照してください。

NetBackup が 2 次ストレージ・システムにデータを転送する方法

NetBackup マスター・サーバーまたはメディア・サーバーは、1 次ストレージ・システム (クライアント) から 2 次ストレージ・システムへのデータの流れを制御します。1 次ストレージ・システム上のクライアント・データは、ニアライン・2 次ストレージ・システム上の 2 次 qtree 内にバックアップされます。

NetBackup によって開始されるバックアップは、ポリシーに基づいています。ポリシーは、バックアップされる対象のデータ、データのバックアップ時期と頻度、バックアップ・データを保存する時間の長さ、およびバックアップ・データの格納場所を決定します。バックアップ・ポリシーについて詳しくは、NetBackup の資料を参照してください。

NetBackup を使用してファイル・システム・データをバックアップする方法

SnapVault for NetBackup を使用して、NetBackup クライアントによって生成されたUNIX、Linux、Solaris、および Windows のファイルおよびディレクトリーのデータをバックアップします。

NetBackup GUI には、バックアップ・モードのタイプを制御する 2 つのチェック・ボックスがあります。1 つ目のチェック・ボックスである「Enable Block Sharing(ブロック共有を使用可能にする)」チェック・ボックスは、ニアライン 2 次システムに送信される tar イメージを、ブロック共有のために Data ONTAP ブロック境界に合わせて調整するかどうかを制御します。2 つ目のチェック・ボックスである「File System Export (ファイル・システム・エクスポート)」チェック・ボックスは、NFS プロトコルまたは CIFS プロトコルを使用して、アンパックしたファイル・システムを 2 次ストレージ・システムにエクスポートするかどうか、およびバックアップをアーカイブ Snapshot コピーに取り込むかどうかを制御します。

SnapVault for NetBackup ファイル・システム・エクスポート・モードを使用して、NetBackup クライアントによって生成された UNIX、Linux、Solaris、およびWindows のファイルおよびディレクトリーのデータをバックアップしているとします。ファイル・システム・エクスポート・モードを使用するバックアップ tar イメージは、ブロック共有のために Data ONTAP ブロック境界に合わせて調整されます。バックアップ処理中に、コンテキスト依存のブロック共有によってブロックが共有されます。アンパックされたファイル・システムは、NFS プロトコルと CIFS

プロトコルを使用してエクスポートされ、「ドラッグ・アンド・ドロップ」によるリストア機能が有効になり、バックアップはアーカイブ Snapshot コピーに取り込まれます。


ファイル・システム・エクスポート・バックアップの場合は、「Enable BlockSharing (ブロック共有を使用可能にする)」と「ファイル・システム・エクスポート(File System Export)」の両チェック・ボックスを選択する必要があります。

関連概念

252ページの『アーカイブ Snapshot コピーを作成する方法』Data ONTAP 7.3.1 では、ユーザーによる構成が可能なオプションを使用して、データ転送の終了時にアーカイブ Snapshot コピーを作成しないように設定できます。

260ページの『バックアップがアーカイブ Snapshot コピーに保管される方法』SnapVault for NetBackup は、ポリシー、クライアント、およびバックアップが取られた時刻に基づいて各バックアップを一意的に識別します。特定のクライアント/ポリシー・ペアの各バックアップは、アーカイブ Snapshot コピーと呼ばれるSnapshot コピーに一意的に保管されます。

ニアライン 2 次システムがデータを処理する方法ニアライン 2 次ストレージ・システムがデータを処理する方法を理解することは重要です。

バックアップ・データ転送: ニアライン 2 次システムへのバックアップ・データ転送はそれぞれ、2 つのストリームで構成されます。これらは、ヘッダーとファイル・データを含む標準 NetBackup tar ストリーム、および tar ストリームの内容を記述するメタデータ・ストリームです。

tar データは、ニアライン 2 次ストレージ・システムに書き込まれ、ディスクに保管されます。ディスクに tar ストリームを保管することによって、NetBackup 管理コンソールから NetBackup によってリストアを開始できます。

メタデータ・ストリームを使用すると、tar ストリーム内のファイルとディレクトリーが、Data ONTAP 内の WAFL ファイル・システムにアンパックされます。アンパック処理によって、tar ストリームがニアライン 2 次ストレージ・システムに書き込まれるときに、Data ONTAP 内にファイルとディレクトリーが作成されます。アンパックされたファイル・システム内のファイル・データは、tar ストリームのデータ・ブロックをすべて共有するので、追加のブロックを消費しません。

コンテキストに応じた非重複化: Data ONTAP がファイル・データをアンパックするときには、コンテキストに応じた非重複化を実行します。コンテキストに応じた非重複化により、現在の tar ストリームとそれ以前の tar ストリームすべての間で共通のブロックが除去されます。したがって、新規 tar ストリーム内の新規または変更されたデータ・ブロックのみが、ニアライン 2 次システム上のディスクに書き込まれます。

Snapshot コピーの作成: すべてのデータがディスクに書き込まれ、tar ストリーム内のデータすべてがアクティブ・ファイル・システムにアンパックされた後、バックアップは Snapshot コピーに取り込まれます。このようにして、1 次ファイル・システムのバックアップは固有の Snapshot コピーに取り込まれ、前のバージョンのファイルまたはディレクトリーをリストアする必要がある場合には、これを参照できます。

Data ONTAP は、さまざまなポリシーのバックアップを単一の Snapshot コピーに合体させることによって、消費される Snapshot コピーの数を最適化します。例え


ば、異なるポリシーの 3 つのバックアップが、いずれかのバックアップの次回更新よりも前に完了した場合、Data ONTAP は 3 つのバックアップを 1 つの Snapshot

コピーに合体させます。

データのリストア: Data ONTAP 7.2 より前では、NetBackup 管理コンソールを使用して tar ストリームにアクセスすることによって、SnapVault for NetBackup ボリュームからデータをリストアすることのみが可能でした。

Data ONTAP 7.2 以降では、バックアップの完了後に NFS プロトコルまたは CIFS

プロトコルを使用して、アンパックされたファイル・システムにアクセスできます。これにより、別の方法で、つまり「ドラッグ・アンド・ドロップ」機能を使用して、ファイルとディレクトリーをバックアップからソースにコピーすることによって、データをリストアできます。

関連概念

260ページの『効率的なバックアップ・スケジュール』効率的なバックアップ・スケジュールは、最小数のアーカイブ Snapshot コピーで保持するバックアップの数を最大限に高める上で役立ちます。個々のスケジュールを計画するほか、同じボリュームに対するバックアップ・スケジュールを慎重に同期することが重要です。異なるクライアントまたはポリシーから同じボリュームへのスケジュールを調整すると、全体的なスペース節約を改善することができます。

270ページの『エクスポートされたファイル・システムからのデータ・リストア』Data ONTAP7.2 以降では、SnapVault for NetBackup ボリュームからの FSE バックアップのリストアをドラッグ・アンド・ドロップで実行できます。

アーカイブ Snapshot コピーを作成する方法Data ONTAP 7.3.1 では、ユーザーによる構成が可能なオプションを使用して、データ転送の終了時にアーカイブ Snapshot コピーを作成しないように設定できます。

アーカイブ Snapshot コピーを使用不可に設定しても、コンテキスト・ベースのブロック共有を使用してブロックを非重複化できます。ただし、ドラッグ・アンド・ドロップによるリストアは実行できません。ドラッグ・アンド・ドロップ機能が必要な場合は、ここで説明するアーカイブ Snapshot コピーを作成するためのオプションを使用可能に設定する必要があります。

このオプションは、デフォルトではオンに設定されています。このオプションをオフにすると、アーカイブ Snapshot コピーが作成されないようになります。ただし、DSU またはボリュームがアーカイブ Snapshot コピーの作成を停止した後、このオプションを再びオンに設定することはできません。

注: アーカイブ Snapshot コピーは、デフォルトではすべての新規ボリューム上で使用可能に設定されます。SnapVault for NetBackup バックアップを含むボリューム上でアーカイブ Snapshot コピーを再び使用可能に設定することはできないので、バックアップ・ソリューションの計画を立てる際にはアーカイブ Snapshot コピーの計画が必要です。

新しいボリューム用のデフォルト・オプションの構成options コマンドを使用して、新しいボリューム用にデフォルト・オプションを構成することができます。ボリュームごとに設定するには、vol options コマンドを使用できます。


このシステムでグローバル・デフォルトを設定または表示するには、次のコマンドを入力します。

新しいボリューム用指定のボリューム用

options

snapvault.nbu.archival_snap_default

{on|off}

vol options volume_name

nbu_archival_snap {on|off} [-f]

-f は、このコマンドの実行時に確認 (yes または no) を表示したくない場合に使用します。このオプションは、コマンドを rsh から実行する場合に特に有用です。注: アーカイブ Snapshot コピーを使用可能にできるのは、ボリュームに SnapVault for

NetBackup バックアップが存在しない場合だけです。アーカイブ Snapshot コピーを使用不可にすると、yes/no プロンプトを示す警告が表示されます。-f オプションを指定する場合も警告が表示されます。

ボリューム SnapMirror を使用して複製されたボリュームは、ソースで設定されたこのオプション値を継承します。このオプションは、SnapVault for NetBackup ボリュームとして使用するボリュームにのみ使用してください。Data ONTAP 7.3.1 へのアップグレード: ストレージ・システムを Data ONTAP7.3.1 にアップグレードすると、デフォルトでアーカイブ Snapshot コピーがすべての新しいボリュームで使用可能になります。既存の SnapVault for NetBackup ボリュームの構成は、アーカイブ Snapshot コピーがこれらのボリュームで使用可能になっていることを反映するように自動的に更新されます。そのため、Data ONTAP 7.3または Data ONTAP 7.2 ファミリーのリリースからアップグレードする場合、動作は同じままになります。以前の Data ONTAP リリースへの復帰: Data ONTAP 7.3.1 から Data ONTAP 7.3に復帰する場合、Data ONTAP 7.3.1 でのボリューム用のアーカイブ Snapshot コピーの設定に関係なく、すべてのボリュームが Snapshot コピーを作成します。

SnapVault for NetBackup の制限NetBackup ソフトウェアを使用してデータをニアライン 2 次ストレージ・システムにバックアップする際、以下の制限があります。

v NetBackup チェックポイント・リスタートはサポートされていません。バックアップが失敗した場合、そのバックアップは破棄されて、次のバックアップ操作がすべての以前のデータを再送信します。

v 同期 SnapMirror、半同期 SnapMirror、Qtree SnapMirror、または SnapVaultを使用して、DSU バックアップを 3 次ストレージ・システムに複製することはできません。

v NetBackup を使用してバックアップしたデータを、NDMP またはネイティブdump コマンドを使用してテープに複製することはできません。ただし、NetBackup Inline Tape Copy または NetBackup Vault オプションを使用して、NetBackup バックアップ・イメージの重複コピーを作成することはできます。

v NDMPcopy は、SnapVault for NetBackup ボリュームのマイグレーションでサポートされていません。

v サポートされる最大ボリューム・サイズは次のとおりです。


– N5200 システム ― 1 TB

– N5300 システム ― 3 TB

– N5500 システム ― 2 TB

– N5600 システム ― 6 TB

– N6040 システム ― 3 TB

– N6060 システム ― 16 TB

– N6070 システム ― 10 TB

– N7600 システム ― 10 TB

– N7700 システム ― 10 TB

– N7800 システム ― 16 TB

– N7900 システム ― 16 TB

v NetBackup クライアント・データを含むボリュームを非 NetBackup クライアント・データ (例えば、SnapVault 複製を使用して別の IBM ストレージ・システムによってバックアップされたデータなど) と共有することはできません。

v FlexVol ボリュームのみがサポートされます。従来型ボリュームおよび WORM

ボリュームはサポートされません。

v 通常、バックアップされたデータのサイズの約 1% のスペース・オーバーヘッドがあります。

v 大半が小さな容量のファイル (10 KB 未満のファイル) で構成されるデータ・セットをバックアップする場合、NetBackup から Data ONTAP へのブロック位置合わせオーバーヘッドが原因でストレージ効率が低下します。

v 1 つのノードが両方のノードに対する要求を処理する場合 (つまり、システムがテークオーバー・モードで稼働している場合)、2 つのノードが単一のストレージ・システムのリソースを共有するようになったため、それぞれのノードへのスループットが影響を受ける可能性があります。

v SnapVault for NetBackup は、Symantec Veritas NetBackup 6.5 ではサポートされていません。

NetBackup 6.5 のソフトウェアの問題により、SnapVault for NetBackup はNetBackup 6.5 と連動しません。Symantec は、NetBackup 6.5.1 でこの問題を修正しました。SnapVault for NetBackup は、NetBackup 6.0 MP5 以降またはNetBackup 6.5.1 と連動します。

SnapVault for NetBackup の使用法の推奨事項NetBackup を使用して NetBackup クライアント・データをニアライン 2 次システムにバックアップする際、検討すべきいくつかの推奨事項があります。

v 単一のボリュームに 100 を超える NetBackup ポリシーをバックアップしないでください。

v Windows バックアップを含むボリュームのセキュリティー設定が混合またはNTFS のいずれかになっていて、ACL およびストリームが組み込まれていることを確認してください。

v Windows バックアップ・データを含む SnapVault for NetBackupボリュームでcreate_unicode オプションが使用可能になっていることを確認してください。


v SnapVault for NetBackup ボリュームを他のタイプのデータ (SnapVault またはSnapMirror データなど) の宛先として使用しないでください。

関連概念

260ページの『効率的なバックアップ・スケジュール』効率的なバックアップ・スケジュールは、最小数のアーカイブ Snapshot コピーで保持するバックアップの数を最大限に高める上で役立ちます。個々のスケジュールを計画するほか、同じボリュームに対するバックアップ・スケジュールを慎重に同期することが重要です。異なるクライアントまたはポリシーから同じボリュームへのスケジュールを調整すると、全体的なスペース節約を改善することができます。

関連タスク

243ページの『SnapVault のバックアップおよびスタンバイ・サービスの使用』SnapVault 2 次ストレージ・システム用に SnapMirror バックアップおよびスタンバイ保護をセットアップすることができます。

スペースを節約するための推奨事項SnapVault for NetBackup を使用する際には、スペースを節約するためにいくつかの推奨事項を守ってください。

2 次ストレージ・システム上のボリュームの名前を変更しないでください。 2 次ストレージ・システム上のボリュームの名前を変更すると、ボリューム上に孤立したイメージが作成されることがあります。Data ONTAP 7.2.4 以降では、ボリュームの名前を変更すると、そのボリュームを宛先とする後続の SnapVault for NetBackup

バックアップが失敗します。

孤立イメージは、対応する NetBackup カタログ項目がないニアライン・ストレージ・システム上のバックアップ・イメージです。このことが起こる理由は、次のいずれかです。

v イメージの有効期限が切れると、NetBackup は DSU およびカタログからイメージを削除します。このイメージ削除操作が何らかの理由で失敗した場合、イメージがカタログからは削除され、DSU からは削除されない可能性があります。

v NetBackup バックアップが失敗し、DSU 上に不完全なイメージが残されている可能性があります。通常、NetBackup は失敗したバックアップのイメージの消去を試みますが、イメージが DSU 上に残されることがあります。

孤立イメージが作成されると、次の問題が生じる可能性があります。

v 孤立イメージはリストアできず、期限切れにもなりません。

v 孤立イメージは NetBackup を使用してリカバリーできないスペースを占有するため、ストレージに余分なオーバーヘッドがかかることがあります。

注: 孤立イメージからストレージ・スペースをリカバリーするには、ボリュームを破棄する必要があります。

NetBackup バックアップ・ポリシーの名前を変更しないでください。 SnapVault for

NetBackup は、コンテキスト依存の非重複化テクノロジーを使用してスペースの節約を実現します。このテクノロジーでは、同じコンテキストの複数のバックアップには重複するデータが含まれている可能性が高いと仮定しています。NetBackup ポリシー名は、バックアップのコンテキストのパラメーターです。つまり、名前が変更された場合、新しいポリシー名に基づくバックアップは、名前変更の前に行われ


たバックアップと同じコンテキストにあるとは見なされなくなります。名前変更の前に行われたバックアップは、必要より多くのストレージ・スペースを占有します。これは、非重複化処理をこれらのバックアップに対して使用できないからです。ポリシー名の変更前に作成されたイメージすべてが期限切れになるまで、ストレージ・スペースはリカバリーできません。

NetBackup ポリシーのソース・データ・セットの名前を変更しないでください。NetBackup ポリシーには、バックアップ選択項目が含まれます。これらの項目は、1

つ以上のソース・データ・セットを指すパスです。パスは、バックアップのコンテキストのパラメーターです。ポリシー名を変更する場合と同じように、パスを変更すると、パスが参照するデータのコンテキストも変更されます。コンテキストに変更があると、非重複化の機会が減り、使用されるストレージ・スペースの量が増えます。

基礎のディレクトリーまたはマウント・ポイントの名前を変更した場合、ポリシーのバックアップ選択項目の中でパスが変更される可能性があります。

注: バックアップ選択項目のテキストに何らかの変更があると、基礎のデータのコンテキストが変更されます。これは、変更後のバックアップ選択項目が、変更前と同じソース・データ・セットを指していても同様です。

マルチストリーム・バックアップを使用する場合の推奨事項マルチストリーム・バックアップは、NetBackup の機能の 1 つであり、単一クライアントの複数バックアップ (ストリーム) を 1 つ以上の DSU に対して同時に実行できるようにします。この機能により、大量のデータがあるクライアントが、データを逐次バックアップしていた場合には満たせない所定のバックアップ・ウィンドウの条件を満たすことができます。

これらのストリームが送信されるニアライン・システムには、一度に受信できる最大同時ストリーム数に限度があります。例えば、N7800 の同時ストリーム数の限度は 128 です。

SnapVault for NetBackup は、ファイル・システム・エクスポート・モードを使用してマルチストリーム・バックアップをサポートします。ただし、このようなマルチストリーム・バックアップの保守は困難です。

重要: マルチストリーミング・バックアップ構成はこのような問題があるので、実装しないようにしてください。ご使用のシステムに応じたマルチストリーム・バックアップの最適な数については、IBM 担当員にご相談ください。

NetBackup は、ポリシーのバックアップ選択リストにあるデータ・パスごとに、ストリームを作成します。それぞれのストリームには、ポリシー内のバックアップ選択項目の順序に基づいてタグが付けられます。バックアップ選択項目がリストの先頭にある場合と、同じバックアップ選択項目がリストの最後にある場合では、異なるタグが付けられます。ポリシーのバックアップ選択リスト内での位置を移動すると、コンテキストが変わります。バックアップ選択リストを再配列すると、再配列されたバックアップ選択項目のコンテキストが変更されます。コンテキストが変更されると、バックアップのストレージ要件が増加します。


バックアップ選択項目の順序を維持して、コンテキストに基づく非重複化のコンテキストを整合させるために、次の指針を守ってください。

v ポリシー内のバックアップ選択項目の順序は変更しないでください。

v 前のバックアップ操作に含まれていた場合は、リストからバックアップ選択項目を削除しないでください。

v 新規パスはバックアップ選択リストの最後にのみ追加します。

v バックアップ選択項目として ALL_LOCAL_DRIVES は使用しないでください。これは、このディレクティブがローカル・ホスト上のすべてのドライブにマップされるからです。ネットワーク・ドライブのマッピングまたはマッピング解除によってドライブ名の割り当てが変更されると、データ・セットの名前変更と同じような動作が生じます。

v データ選択リスト内でワイルドカードは使用しないでください。NetBackup がワイルドカードの展開結果ごとに 1 つのストリームを送信する場合に、ワイルドカードの展開結果の数が連続したバックアップ間で変化すると、バックアップ・コンテキストが変化し、バックアップ選択リストの中でデータ・セットを追加または削除した場合と同じような動作が生じます。

関連資料



SnapVault for NetBackup を使用する際のその他の推奨事項SnapVault for NetBackup を使用する際には、いくつかの推奨事項を守ってください。

ポリシーのグループ化に関する推奨事項: ポリシーを DSU に割り当てる際には、バックアップ・スケジュールの類似性、つまりバックアップの頻度と保存期間に基づいて、これらのポリシーをグループ化してください。

ポリシーのバックアップ頻度と保存期間の組み合わせによって、消費されるSnapshot コピーの数が決まります。ニアライン・ボリューム上に同時に存在できるSnapshot コピーの数は最大 250 なので、Snapshot コピーの消費を慎重に管理することは重要です。

注: アーカイブ Snapshot コピーのオプションが off に設定されている場合は、この推奨事項は適用されません。

snap reserve の設定に関する推奨事項: 最大限のディスク・スペースをバックアップに使用できるように、各 SnapVault for NetBackupボリューム上の Snapshot 予約スペースは 0 に設定してください。snap reserve コマンドを使用して、Snapshot 予約スペースを変更できます。

snap sched の設定に関する推奨事項: SnapVault for NetBackup は、SnapVault for

NetBackup ボリューム上にあるすべての Snapshot コピーを管理します。さらに


snap sched コマンドを使用して Snapshot コピーのスケジュールが設定されている場合、不要な Snapshot コピーが作成され、保管されます。不要な Snapshot コピーが作成されないように、それぞれの SnapVault for NetBackup ボリューム上でSnapshot コピーのスケジューリングをオフにしてください。snap sched コマンド(snap sched volume_name 0 0) を使用して、通常の Snapshot コピーのスケジューリングを使用不可に設定できます。

別個の DSU の使用に関する推奨事項: 言語および命名に関して起こりうる問題を避けるために、Windows NetBackup クライアントと UNIX NetBackup クライアントには別々の SnapVault for NetBackup DSU を使用してください。

同様に、異なる言語設定で構成された NetBackup クライアントには、別々のSnapVault for NetBackup DSU を使用してください。 vol lang コマンドを使用して、言語設定を表示できます。

注: ボリュームの言語設定は初期セットアップ手順であり、バックアップを含むボリュームに対して言語設定を変更することはできません。

関連タスク

252ページの『新しいボリューム用のデフォルト・オプションの構成』options コマンドを使用して、新しいボリューム用にデフォルト・オプションを構成することができます。ボリュームごとに設定するには、vol options コマンドを使用できます。

SnapVault for NetBackup 転送を構成する方法ニアライン 2 次ストレージ・システムへの SnapVault for NetBackup 転送をセットアップするには、システム構成がいくつかの要件を満たしている必要があります。

v ストレージ・システムがニアライン・システムであるか、ニアライン機能を使用可能に設定したストレージ・システムであることが必要です。

v ニアライン・ストレージ・システムは、Data ONTAP 7.1 以降を実行している必要があります。「ドラッグ・アンド・ドロップ」技法を使用してファイルとディレクトリーをリストアする場合は、ニアライン・ストレージ・システムが Data

ONTAP 7.2 以降を実行している必要があります。

v SnapVault 2 次ライセンスが、ニアライン・ストレージ・システム上で有効になっている必要があります。

v SnapVault for NetBackup ボリュームは FlexVol ボリュームであることが必要です。

v NetBackup Enterprise 6.0 MP5 以降がマスター・サーバーおよびメディア・サーバー上で実行されている必要があります。

v NetBackup クライアント・システムは NetBackup 5.0 以降を実行している必要があります。

ニアラインの 2 次ストレージ・システムとしての構成2 次ストレージ・システムとして構成できます。



2 次ストレージ・システムがニアライン・システムでない場合、ニアライン機能ライセンスが使用可能になっていることを確認する必要があります。

1. SnapVault 2 次ライセンスをセットアップします。次のコマンドを入力します。license add sv_ontap_sec_license

2. Backup Operators useradmin グループ・リストに新しいバックアップ・ユーザーを追加します。次のコマンドを入力します。useradmin user add backupuser -g

″Backup Operators″

3. 新規ユーザーの NDMP パスワードを生成します。次のコマンドを入力します。ndmpd password backupuser NDMP パスワードは、NetBackup メディア・サーバーをニアライン・ストレージ・システムに対して認証するために使用されます。このパスワードは、NetBackup 管理ステーションでのニアラインのセットアップで必要です。

注: root パスワードは暗号化されず、ストレージ・システムの保全性が失われる可能性があるため、root パスワードを NDMP パスワードとして使用しないことが重要です。デフォルトは NDMP バージョン 4 ですが、ndmpd version

version_number コマンドを実行して NDMP バージョンが設定されていることを確認してください。ここで、version_number は 4 です。

NDMP の使用について詳しくは、「Data ONTAP Data Protection Tape Backup

and Recovery Guide」を参照してください。

4. SnapVault を使用可能にします。次のコマンドを入力します。options

snapvault.enable on

5. options snapvault.access コマンドを使用して、NetBackup メディア・サーバーの名前を指定します。次のコマンドを入力します。options snapvault.access

host=netbackup_server1,netbackup_server2 ...

注: NetBackup クライアント接続要求は TCP ポート 10571 で受信されます。

6. 適切なグローバル・オプションを確認または設定するには、次のコマンドを入力します。options snapvault.nbu.archival_snap_default {on|off}

関連資料

88ページの『ニアライン・システムとして使用されるストレージ・システム - ニアライン機能』ストレージ・システムをバックアップの目的でのみ使用する場合、システムをバックアップ用に最適化することをお勧めします。そうすると、使用される転送リソースが少なくなります。

データ転送の管理SnapVault for NetBackup を使用したデータ転送を管理するには、バックアップのスケジューリング、ファイルの命名、qtree 状況のモニター、データ転送の状況の検査、スペース節約効果の表示などを行います。

バックアップのスケジュールData ONTAP は、NetBackup インターフェースからの要求に応答する際、すべてのデータ転送を管理します。ただし、バックアップ・ポリシーは、NetBackup 管理コ


ンソールを使用してスケジュールされます。ポリシーは、特定のクライアントまたはクライアント・グループのバックアップ基準を定義する 1 組のルールです。例えば、NetBackup ポリシーは、バックアップ間隔、バージョンの数、および特定のアーカイブを保持する期間を制御します。バックアップ・ポリシーについ詳しくは、NetBackup 資料を参照してください。


バックアップの場合、それぞれの DSU が類似のバックアップ・スケジュールを持つポリシーからバックアップを受信することが重要です。類似のバックアップ・スケジュールのみを DSU に指示すると、スペース節約が最適化されます。また、消費される Snapshot コピーの数を制限するバックアップ・スケジュールを選択することも重要です。

関連概念

『効率的なバックアップ・スケジュール』効率的なバックアップ・スケジュールは、最小数のアーカイブ Snapshot コピーで保持するバックアップの数を最大限に高める上で役立ちます。個々のスケジュールを計画するほか、同じボリュームに対するバックアップ・スケジュールを慎重に同期することが重要です。異なるクライアントまたはポリシーから同じボリュームへのスケジュールを調整すると、全体的なスペース節約を改善することができます。

261ページの『Snapshot コピーによる消費を管理する方法』Data ONTAPが許容するSnapshot コピーの最大数は、1 つのボリュームに対して255 ですが、バックアップに使用できる Snapshot コピーの推奨最大数は 250 です。これは、他の Data ONTAP サービスが Snapshot コピーを必要とするからです。さまざまな方法を使用して、Snapshot コピーによる消費を最適化できます。

効率的なバックアップ・スケジュール効率的なバックアップ・スケジュールは、最小数のアーカイブ Snapshot コピーで保持するバックアップの数を最大限に高める上で役立ちます。個々のスケジュールを計画するほか、同じボリュームに対するバックアップ・スケジュールを慎重に同期することが重要です。異なるクライアントまたはポリシーから同じボリュームへのスケジュールを調整すると、全体的なスペース節約を改善することができます。

アーカイブ Snapshot コピーは FSE モードのバックアップの場合にのみ保持されるため、この情報は FSE モードのストレージ・システムにのみ適用されます。アーカイブ Snapshot コピー・オプションがオンに設定されていることを確認してください。

関連タスク

252ページの『新しいボリューム用のデフォルト・オプションの構成』options コマンドを使用して、新しいボリューム用にデフォルト・オプションを構成することができます。ボリュームごとに設定するには、vol options コマンドを使用できます。

バックアップがアーカイブ Snapshot コピーに保管される方法SnapVault for NetBackup は、ポリシー、クライアント、およびバックアップが取られた時刻に基づいて各バックアップを一意的に識別します。特定のクライアント/ポリシー・ペアの各バックアップは、アーカイブ Snapshot コピーと呼ばれるSnapshot コピーに一意的に保管されます。


次の情報は、FSE バックアップにのみ適用されます。それぞれの Snapshot コピーは、多くの異なるクライアント・ポリシー・ペアのバックアップを保管できます。

Data ONTAP ソフトウェアは、すべてのバックアップを一意的に Snapshot コピーで収集するために必要な最小数の Snapshot コピーを保持します。

以下の例では、マルチストリーミングは使用されません。

例: 2 つのクライアント client_1 および client_2 を同じ 2 次ボリュームにバックアップするポリシーがあります。client_1 へのバックアップの後、Data ONTAP は、これを保持するために Snapshot コピー (例えば、Snap_1) を作成します。次に、client_2 へのバックアップが行われます。client_2 へのバックアップの後、Data

ONTAP は、これを保管するために別の Snapshot コピー (例えば、Snap_2) を作成します。client_1 へのバックアップの後で client_2 へのバックアップが行われたため、Snap_2 には両方のバックアップが入っています。client_1 へのバックアップがSnap_2 でも保持されているため、Data ONTAP は Snap_1 を削除できます。

その後で client_1 へのバックアップを行うと、別の Snapshot コピー (例えば、Snap_3) が作成されます。ただし、Snap_3 および Snap_2 には、同じクライアント(client_1) のそれぞれ異なるバックアップが入っているため、両方とも保持する必要があります。

Snapshot コピーによる消費を管理する方法Data ONTAPが許容するSnapshot コピーの最大数は、1 つのボリュームに対して255 ですが、バックアップに使用できる Snapshot コピーの推奨最大数は 250 です。これは、他の Data ONTAP サービスが Snapshot コピーを必要とするからです。さまざまな方法を使用して、Snapshot コピーによる消費を最適化できます。

バックアップ・ポリシーを定める際には、同じ宛先ボリュームを指すクライアントとポリシーのペアに関して、バックアップ・スケジュール、保存期間、およびバックアップ頻度を慎重に決定する必要があります。これにより、個々の宛先ボリュームに保管されるバックアップの数が最大になり、Snapshot コピーを使い切るリスクがなくなります。

次の例では、マルチストリーミングは使用しません。これらの例では、Snapshot コピーの最適化と、バックアップ・スケジュール、保存期間、バックアップ頻度、および FlexVol ボリュームの使用が及ぼす影響を例示する、さまざまなバックアップ方法を示します。

例 1: 複数のクライアント用の 1 つのポリシー、1 つの宛先ボリューム:

この戦略では、1 つの NetBackup ポリシーを使用して、1 日に 1 回、いくつかのクライアントを同じ宛先ボリュームにバックアップします。

構成: 複数のクライアント (client1 から client5)。1 つのポリシーを使用して、5 つのすべてのクライアントが 1 日に 1 回同じ宛先ボリュームにバックアップされることを指定します。

結果: 毎日の終わりに、5 つの各クライアントのバックアップを含む 1 つの新しいSnapshot コピーが作成されます。例えば、1 日目の終わりに、クライアントごとに1 つずつ、5 つのバックアップを含む 1 つの Snapshot コピーが作成されます。次


の日に終わりには、2 つの Snapshot コピーが作成されます。1 つは 1 日目のもので、もう 1 つの新しい Snapshot コピーには各クライアントの別のバックアップが含まれています。以下、同様になります。5 日後には、5 つのクライアントの 25

の固有のバックアップが 5 つの Snapshot コピーにバックアップされます。視覚的に説明すると、次の表のようになります。

アーカイブ Snapshot コピー内容

snapshot1―day 1 クライアント 1、クライアント 2、クライアント 3、クライアント 4、クライアント 5





ボリュームに保存されるバックアップの最大数: この戦略を使用すると、250 のSnapshot コピー、つまり各クライアントの 250 のバックアップ (それぞれのSnapshot コピーの各クライアントの 1 つのバックアップ) に 250 日で達します。

最も古い Snapshot コピーを除去するためのバックアップの期限切れ: 250 のSnapshot コピーは推奨されるボリューム当たりの最大数であるため、250 日目の後に、NetBackup から最も古い 5 つのバックアップ (各クライアントの 1 つ) を期限切れにする (削除する) 必要があります。これにより、最初の Snapshot コピーが削除され、Snapshot コピーの合計数は 249 に減ります。これで、5 つの各クライアントのバックアップをさらに取り、後続の Snapshot コピーを保存することができます。250 日目の後は、毎日、各クライアントの最も古いバックアップを期限切れにして、5 つのクライアントの将来の更新に Snapshot コピーを使用できるようにする必要があります。ボリュームの Snapshot コピーの制限を超過するリスクを防止するために、各クライアント・バックアップの保存期間は 250 日を超えてはなりません。

例 2: 複数のクライアント用の複数のポリシー、1 つの宛先ボリューム:

この戦略では、複数の NetBackup ポリシーを使用して、1 日に 1 回、いくつかのクライアントを同じ宛先ボリュームにバックアップします。

構成: 5 つのクライアントがバックアップされます。複数 (最大 5 つ) のNetBackup ポリシーを使用して、5 つのすべてのクライアントが 1 日に 1 回同じ宛先ボリュームにバックアップされることを指定します。1 日のいつでもポリシーが実行されるようにスケジュールすることができますが、5 つのすべてのクライアントのバックアップが 1 日以内に取られるようにします。

結果: この戦略の結果は例 1 と同じです。毎日の終わりに、5 つの各クライアントのバックアップを含む 1 つの新しい Snapshot コピーが作成されます。5 日後には、5 つのクライアントの 25 の固有のバックアップが 5 つの Snapshot コピーにバックアップされます。視覚的に説明すると、次の表のようになります。








ボリュームに保存されるバックアップの最大数: この戦略を使用すると、250 のSnapshot コピー、つまり各クライアントの 250 のバックアップ (それぞれのSnapshot コピーの各クライアントの 1 つのバックアップ) に 250 日で達します。

最も古い Snapshot コピーを除去するためのバックアップの期限切れ: 250 のSnapshot コピーは推奨される最大数であるため、250 日目の後に、NetBackup から5 つの各クライアントの最も古いバックアップを期限切れにする (削除する) 必要があります。これにより、最初の Snapshot コピーが削除され、Snapshot コピーの合計数は 249 に減ります。これで、5 つの各クライアントのバックアップをさらに取り、後続の Snapshot コピーに保存することができます。 250 日目の後は、毎日、5

つの各クライアントの最も古いバックアップを期限切れにして、将来のバックアップに Snapshot コピーを使用できるようにする必要があります。

ボリューム当たりの許可される Snapshot コピーの最大数を超えないように、各クライアント・バックアップの保存期間は 250 日を超えてはなりません。

例 3: 2 つのポリシー、異なるスケジュール、複数のクライアント、1 つの宛先ボリューム:

この戦略では、2 つの NetBackup ポリシーを使用して 2 つのクライアントのセットを同じ宛先ボリュームにバックアップします。1 つのポリシーは、1 日に 1 回のバックアップをスケジュールします。もう 1 つのポリシーは、1 日に 2 回のバックアップをスケジュールします。

構成: 5 つのクライアントがバックアップされます。1 つのポリシー (policy_1) を使用して、client1、client2、および client3 を 1 日に 1 回バックアップします。もう 1 つのポリシー (policy_2) を使用して、client4 および client5 を 1 日 2 回バックアップします。両方のポリシーは、5 つのすべてのクライアントが同じ宛先ボリュームにバックアップされることを指定します。

結果: policy_1 の最初のスケジュール・バックアップにより、client1、client2、および client3 のバックアップ・コピーが作成されます。Data ONTAP は、3 つのバックアップを保存するための Snapshot コピーを作成します。

policy_2 の最初のスケジュール・バックアップにより、client4 および client5 のバックアップ・コピーが作成されます。Data ONTAP は、別の Snapshot コピーを作成して、これらの 2 つのバックアップだけでなく、policy_1 の最初のスケジュー


ル・バックアップによって作成されたクライアント 1 から 3 までの 3 つのバックアップも保存します。そのため、Data ONTAP は、最初の Snapshot コピーを削除して、2 番目の Snapshot コピーを保持します。

policy_2 の 2 回目のスケジュール・バックアップの後、クライアント client4 および client5 のバックアップが再び作成され、別の Snapshot コピーが作成されます。この Snapshot コピーでは、client1、client2、および client3 は最初の Snapshot コピーのバックアップと同じですが、client4 および client5 のバックアップは異なります。そのため、Data ONTAP は、この Snapshot コピーも保持して、Snapshot コピーは合計で 2 つになります。

1 日の終わりに、2 つの Snapshot コピーが同じ宛先ボリューム上に 5 つのクライアントのそれぞれ固有のバックアップを 7 つ保管しています。 1 つ目の Snapshot

コピーには、5 つのすべてのクライアントに対する固有の更新が含まれています。2

つ目の Snapshot コピーには、client1、client2、および client3 の変更されていない3 つのバックアップと、client4 および client5 の 2 つの固有のバックアップが含まれています。

5 日後には、5 つのクライアントの 35 の固有のバックアップが 10 の Snapshot コピーに保管されることになります。視覚的に説明すると、次の表のようになります。



snapshot2―day 1 client1 (変更なし)、client2 (変更なし)、client3 (変更なし)、client4、client5









ボリュームに保存されるバックアップの最大数: この戦略を使用する場合、250 のSnapshot コピーの制限に 125 日で達します。client4 および client5 のバックアップはすべての Snapshot コピーに存在しますが、client1、client2、および client3 のバックアップは半分の Snapshot コピーに存在します。分かりやすく説明するために、


Snapshot コピーが期限切れにならないと想定します。250 の Snapshot コピーの制限に達するとき、250 の Snapshot コピーには client4 および client5 のバックアップが含まれていて、125 の Snapshot コピーには client1、client2、および client3 のバックアップが含まれています。

最も古い Snapshot コピーを除去するためのバックアップの期限切れ: 125 日目の最後に、さらにバックアップを取る前に NetBackup から 5 つのクライアントの最も古い 2 つのバックアップを期限切れにする (削除する) 必要があります。これにより、最も古い 2 つの Snapshot コピーが削除され、Snapshot コピーの合計数は 123

に減ります。これで、5 つのすべてのクライアントのバックアップをさらに取って、いくつかの後続の Snapshot コピーに保存することができます。125 日目の後は、毎日、5 つのすべてのクライアントの最も古い 2 つのバックアップを期限切れにして、5 つのクライアントの将来のバックアップに 2 つの Snapshot コピーを使用できるようにする必要があります。

例 4: 2 つのポリシー、異なるスケジュール、複数の宛先 FlexVol ボリューム:

この戦略では、2 つの NetBackup ポリシーを使用して 2 つのクライアントのセットを 2 つの FlexVol ボリュームにバックアップします。1 つのポリシーは、1 日に1 回のバックアップをスケジュールします。もう 1 つのポリシーは、1 日に 2 回のバックアップをスケジュールします。

構成: 5 つのクライアント client1 から client5 がバックアップされます。1 つのポリシー (policy_1) を使用して、client1、client2、および client3 を 1 日に 1 回バックアップします。もう 1 つのポリシー (policy_2) を使用して、client4 およびclient5 を 1 日 2 回バックアップします。policy_1 ではクライアントは FlexVol ボリューム volA にバックアップされ、policy_2 ではクライアントは FlexVol ボリューム volB にバックアップされます。

結果: policy_1 の最初のスケジュール・バックアップにより、client1、client2、および client3 のバックアップ・コピーが作成されます。Data ONTAP は、3 つのバックアップを保存するための Snapshot コピーを作成します。5 日後には、3 つのクライアントの 15 の固有のバックアップが FlexVol volA の 5 つの Snapshot コピーに保管されることになります。視覚的に説明すると、次の表のようになります。

表 8. FlexVol ボリューム volA


snapshot1―day 1 クライアント 1、クライアント 2、クライアント 3





policy_2 の最初のスケジュール・バックアップにより、client4 および client5 のバックアップ・コピーが作成されます。Data ONTAP は、2 つのバックアップを保存するための Snapshot コピーを作成します。policy_2 でスケジュールされた 2 回目のバックアップのセットが終了した後、更新された client4 および client5 のバックアップが作成されます。Data ONTAP は、更新されたバックアップを保存するため


の 2 つ目の Snapshot コピーを作成します。前の Snapshot コピーには固有のクライアント更新が含まれているため、削除できません。そのため、1 日当たり 2 つのSnapshot コピーが保持されます。

5 日後には、2 つのクライアントの 20 の固有のバックアップが FlexVol volB の10 の Snapshot コピーに保管されることになります。視覚的に説明すると、次の表のようになります。

表 9. FlexVol ボリューム volB


snapshot1―day 1 クライアント 4、クライアント 5










ボリュームで保存されるバックアップの最大数: FlexVol ボリューム volA は、1 日当たり 1 つのアーカイブ Snapshot コピーを保存して、250 日後に SnapShot コピーの最大数の制限に達します。FlexVol ボリューム volB は、1 日当たり 2 つのSnapshot コピーを保存して、125 日後に制限に達します。別々の FlexVol ボリュームを使用する利点は、バックアップ頻度が異なるバックアップを同じアグリゲートに送り、古いバックアップの期限切れを開始する前に 250 の固有の更新を保管できることです。

最も古い Snapshot コピーを除去するためのバックアップの期限切れ: 250 日目の終わりに、FlexVol ボリューム volA は、推奨される最大数の 250 の Snapshot コピーに達します。250 日目の後に、NetBackup から 3 つの各クライアントの最も古いバックアップを期限切れにして (削除して)、Snapshot コピーの数を 249 に減らし、Data ONTAP が次の日に Snapshot コピーを作成できるようにする必要があります。FlexVol ボリューム volA にバックアップされるクライアントの最大保存期間は 250 日です (ボリューム内の Snapshot コピーが不足するのを防止するため)。

125 日目の終わりに、FlexVol ボリューム volB は、推奨される最大数の 250 のSnapshot コピーに達します。125 日目の後に、NetBackup から 2 つの各クライアントの最も古い 2 つのバックアップを期限切れにして (削除して)、Snapshot コピーの数を 248 に減らし、Data ONTAP が次の日に 2 つの Snapshot コピーを作成できるようにする必要があります。FlexVol ボリューム volB にバックアップされるクライアントの最大保存期間は 125 日間です。

スペース節約効果を最適化するためにスケジュールを調整する方法複数のポリシーから単一のボリュームにバックアップを送る場合は、これらのバックアップに同じようなバックアップ頻度と保存期間が指定されていることを確認し


てください。バックアップは保存期間に基づいて期限切れになりますが、これらのバックアップが Snapshot コピー内で消費するスペースは、同じ Snapshot コピー内にある他のすべてのバックアップ (さまざまなポリシーからの) が期限切れになるまでは解放されない場合があります。

アーカイブ Snapshot コピーは、ボリューム全体を対象に作成されます。ボリュームには複数のポリシーからのバックアップが含まれることがあります。つまり、異なるポリシーからのバックアップが、同じアーカイブ Snapshot コピーに取り込まれることがあります。SnapVault for NetBackup は、取り込んだバックアップがすべて保存期間の終わりに達したときにのみ、既存のアーカイブ Snapshot コピーを削除します。このため、保存期間の最も長いバックアップによって、アーカイブ Snapshot コピーが削除される時期が決まります。他のバックアップに割り振られたスペースは、Snapshot コピーが削除されるまでは引き続き消費されます。

例

2 つのポリシー、PolA と PolB を考えましょう。PolA の保存期間は 1 年で、PolB

の保存期間は 3 カ月です。これら両方のポリシーのフルバックアップ後、1 つのアーカイブ Snapshot コピー、SnapX が作成されます。SnapX は、これら両方のポリシーからのバックアップを取り込んでいます。PolA と PolB の両方からのバックアップが期限切れになった場合に限り、SnapX は削除されます (これによって、割り振られたストレージ・スペースが再利用されます)。この結果、ストレージの節約効果が最適ではなくなる可能性があります。この例では、PolB に対応するバックアップのために割り振られたスペースは、3 カ月のみ保持されるように要求されていますが、実際は 1 年間保持されます。このことが起こる理由は、PolA と PolB の両方が共通のアーカイブ Snapshot コピー (SnapX) を共有していて、この SnapX は、PolA と PolB の両方からのバックアップが期限切れになった後にのみ削除されるからです。この問題を避けるには、同じようなバックアップ頻度と保存期間をもつバックアップのみを同じボリュームに送るようにします。

並行転送の限度モデルごとに、SnapVault for NetBackup の並行転送の数に限度があります。

モデルごとの並行転送の最大数を次の表に示します。

表 10. ニアライン・ライセンスがある場合の並行ストリームの最大数

モデルSnapVault for NetBackup に対してサポートされる並行転送の最大数

N5200 32

N5300 64

N5500 64

N5600 128

N6040 64

N6060 128

N6070 128

N7600 96

N7700 96

N7800 128


関連資料



SnapVault for NetBackup qtree イメージのファイル・システムによる命名SnapVault for NetBackup qtree イメージは、次に示すデフォルトのファイル・システムの命名規則に従います。

.nbu_image_data は、それぞれの qtree に関連した tar イメージに固有の情報を含む特殊な qtree です。

nbu_basename_policyname_suffix は、それぞれの名前が NetBackup クライアントとポリシー設定に固有である qtree 命名規則です。

nbu_online_data は、データがアンパックされる先のディレクトリーです。これは、nbu_basename_policyname_suffix qtree のサブディレクトリーです。Data ONTAP 7.2

以降では、この qtree 内のバックアップ・データの表示がサポートされます。

詳しくは、NetBackup 資料を参照してください。

qtree 状況のモニター宛先 qtree がストレージ・システム上で作成されたことを確認するには、qtree status

コマンドを使用して SnapVault for NetBackup ボリューム状況を表示します。

コマンド system*> qtree status を入力します。

例system*> qtree status

Volume Tree Style Oplocks Status-------- -------- ----- -------- ---------vol0 unix enabled normalflexsle unix enabled normalp3 mixed enabled normalp3 .nbu_image_data mixed enabled snapvaultedp3 nbu_ibmx123_C1_F1.CLF_daily_0000 mixed enabled snapvaultedp3 nbu_sunv240_C1_F1.CLF_daily_0000 mixed enabled snapvaultedp3 nbu_ibmx123_C1_HDR.IMG_daily_0000 mixed enabled snapvaultedp3 nbu_sunv240_C1_HDR.IMG_daily_0000 mixed enabled snapvaultedp3 nbu_ibmx200_C1_F1.CLF_daily_0000 mixed enabled snapvaulted

データ転送の状況の検査データ転送の状況を検査するには、snapvault status コマンドを使用します。



この画面を使用して、最新のバックアップ・アクティビティーを表示し、転送の状況を確認することができます。

system*> snapvault status

Snapvault secondary is ON.Source Destination State Lag Statussystem1:daily client:/vol/p3/nbu_client_1_daily_0000 Snapvaulted 00:35:32 Idlesystem2:daily client:/vol/p3/nbu_client_2_daily_0000 Snapvaulted 00:35:32 Idlesystem:daily client:/vol/p3/nbu_client_daily_0001 Snapvaulted 00:35:32 Idlesystem:daily client:/vol/p3/nbu_client_daily_0002 Snapvaulted 00:35:32 Idlesystem:daily client:/vol/p3/nbu_client_daily_0003 Snapvaulted 00:35:32 Idle

スペース節約の表示snapvault status –b コマンドを使用して、DSU ごとにスペース節約をモニターすることができます。

節約されたスペースの量を表示するには、2 次ストレージ・システムのコンソールで次のコマンドを入力します。snapvault status -b

タスクの結果

snapvault status -b 操作が完了するのにかかる時間は、ボリュームで作成されたバックアップの数によって異なります。そのため、操作の完了までに長い時間がかかる場合があります。

例

下記は、snapvault status -b コマンドの出力例です。

filer1> snapvault status -b

Snapvault secondary is ON.Volume actual used saved %saved ratio------ ------ ---- ----- ------ -----subvol3_dst 50403MB 3525MB 46877MB 93% 14.29:1

snapvault status -b 操作を中止するには、随時、次のコマンドを入力します。Cntl+C

snapvault status -b コマンドの結果として、NetBackup クライアント・データおよびスペース節約に関する情報を含むボリュームのリストが表示されます。次のリストで、snapvault status -b コマンドによって表示される情報について説明します。

v actual ― NetBackup アプリケーションから送信されたすべての tar ファイルによって使用されたボリューム上の合計ディスク・スペース。この値は、tar イメージ・ファイルのみを表しており、バックアップに関連付けられている可能性がある内部メタファイルを含みません。

v used ― アクティブ・ファイル・システムおよび Snapshot コピーによって使用されたボリューム上の合計ディスク・スペース。この値は、アクティブ・ファイル・システムおよび Snapshot コピーが使用したスペースに関する df コマンドによって返された値の合計に相当します。


v saved ― ボリューム上の節約された合計スペース。これは、actual 値から used

値を減算した値に相当します。actual 値が used 値より低い場合、このフィールドは 0 です。

v %saved ― 節約されたストレージのパーセント。スペース節約がない場合、このフィールドは 0 です。

v ratio ― 非共有データ・ブロックに対する共有データ・ブロックの比率。スペース節約がない場合、このフィールドは 1:1 です。

エクスポートされたファイル・システムからのデータ・リストアData ONTAP7.2 以降では、SnapVault for NetBackup ボリュームからの FSE バックアップのリストアをドラッグ・アンド・ドロップで実行できます。

注: ここでの説明は、FSE モードのバックアップのみに適用されます。ただし、アーカイブ・スナップショット・オプションが off に設定されている場合は、ここでの説明が適用されなくなります。次のいずれかの方法で、FSE バックアップからデータをリストアできます。

v NetBackup 管理コンソールを使用する。

v ボリュームをマウントするか (NFS)、共有を作成して (CIFS)、データをコピーまたはドラッグすることによって、SnapVault for NetBackup ボリュームにアクセスする。

NetBackup 管理コンソールを使用したデータのリストアについては、NetBackup の資料を参照してください。

エクスポートされたファイル・システムが置かれる場所: Data ONTAP 7.2 以降のソフトウェアでは、NetBackup クライアント・ファイル・システムがエクスポートされ、このファイル・システムを使用してバックアップ済みの NetBackup クライアント・ファイルにアクセスできます。NetBackup を使用する際に、Data ONTAP ソフトウェアは TAR ストリームをディスクに転送するほかにファイル・データをアンパックします。Data ONTAP は、バックアップ転送 qtree 内で、nbu_online_data

という名前のサブディレクトリーにアンパックしたデータを置きます。

バックアップ・ファイル・システムには次のような命名規則があります。

nbu_basename_policyname_suffix

basename は NetBackup クライアント名です。

policyname は NetBackup ポリシー名です。

suffix は 4 桁の番号です。

例: nbu_client1.CLF_backup1_0000

client1 は NetBackup クライアント名、backup1 はポリシー名です。

バックアップされたファイル・システムへのアクセスSnapVault for NetBackup を使用してバックアップされたファイル・システム・データにアクセスできます。


1. SnapVault for NetBackup ボリュームをマウントします。 mount

filer4:/vol/clientvol /t/filer4/clientvol

2. アクセスする qtree にナビゲートします。 cd /t/filer4/clientvol/

nbu_clientvol.CLF_unixbackup_0000

タスクの結果

Snapshot コピーにアクセスすることもできます。Snapshot ディレクトリーは、バックアップされた qtree と同じディレクトリー・レベルにあります。SnapVault for

NetBackup が使用する Snapshot のリダイレクト手段は、SnapVault ソフトウェアが使用するものと同じです。このリダイレクト手段では、移行中のデータは表示されません。代わりに、整合性を維持するために、バックアップの前回のエクスポート内容が表示されます。データ転送が完了すると、新しいデータが表示されます。

注: 転送に失敗した場合は、新しい転送に成功するまで、前回の整合した状態のバックアップが引き続き表示されます。

バックアップ・ファイル・システムからのデータの復元エクスポートされたファイル・システムにアクセスした後でのみ、ディレクトリーまたはファイルを復元できます。

1. エクスポートされたファイル・システムからディレクトリーまたはファイルをコピーします。

2. データの復元先とする場所にナビゲートします。

3. ディレクトリーまたはファイルを貼り付けます。

SnapVault for NetBackup ボリュームの除去アーカイブとして使用しなくなった SnapVault for NetBackup ボリュームを破棄することができます。

1. NetBackup アプリケーションを使用して、このボリュームとして構成されているストレージ・ユニットへのすべてのバックアップを期限切れにします。詳しくは、NetBackup 資料を参照してください。

注: NetBackup アプリケーションですべてのバックアップが期限切れになっていることが示される場合がありますが、ニアラインストレージ・システムでボリュームからデータを破棄するプロセスが進行中の可能性があります。すべてのファイル・データがボリュームから完全に破棄されるまで、ボリュームを破棄できない場合があります。

2. ボリュームをオフラインにするには、次のコマンドを入力します。vol offline

volume_name

3. ボリュームを破棄するには、次のコマンドを入力します。vol destroy

volume_name

バックアップが期限切れになる前のボリュームの破棄NetBackup アプリケーションを使用して、バックアップが期限切れになる前にボリュームを破棄する場合があります。その場合、失効した情報が NetBackup カタログおよびニアライン・ストレージ・システムに残ります。



このボリュームとして構成されているストレージ・ユニットとニアライン・ストレージ・システムにある失効した情報を除去するには、以下のステップを行います。

1. NetBackup アプリケーションを使用して、このボリュームとして構成されているストレージ・ユニットへのすべてのバックアップを期限切れにします。詳しくは、NetBackup 資料を参照してください。

2. 次のコマンドを使用して、破棄されたボリュームに入っている失効した情報を判別します。system1> snapvault status -c

system1> snapvault status -c

Snapvault secondary is ON./vol/p3/nbu_clientname_C1_F1.CLF_daily_0000source=clientname_C1_F1.CLF:daily/vol/p3/nbu_clientname_C1_TIR.IMG_daily_0000source=clientname_C1_TIR.IMG:daily/vol/p3/nbu_clientname_C1_HDR.IMG_daily_0000source=clientname_C1_HDR.IMG:daily/vol/p3/nbu_clientname_C1_F1.CLF_weekly_0000source=clientname_C1_F1.CLF:weekly/vol/p3/nbu_clientname_C1_TIR.IMG_weekly_0000source=clientname_C1_TIR.IMG:weekly/vol/p3/nbu_clientname_C1_HDR.IMG_weekly_0000source=clientname_C1_HDR.IMG:weekly

3. リストされたボリュームの qtree ごとに、次のコマンドを入力します。snapvault stop -f qtree_path

system> snapvault stop -f

/vol/p3/nbu_clientname_C1_F1.CLF_daily_0000

ボリュームを破棄せずに再使用するSnapVault for NetBackup ボリュームをアーカイブとして使用しなくなったときに、破棄して再作成せずに別の目的で再使用する場合があります。


注: ボリュームを破棄せずに再使用することは推奨されません。推奨される手順は、ボリュームを破棄してからボリュームを再作成する方法です。

1. NetBackup アプリケーションを使用して、このボリュームとして構成されているストレージ・ユニットへのすべてのバックアップを期限切れにします。詳しくは、「VERITAS NetBackup System Administrator’s Guide」を参照してください。

注: NetBackup アプリケーションですべてのバックアップが期限切れになっていることが示される場合がありますが、ニアライン・ストレージ・システムでボリュームからデータを破棄するプロセスが進行中の可能性があります。すべてのファイル・データがボリュームから完全に破棄されるまで、ボリュームを破棄できない場合があります。

2. NetBackup アプリケーションを使用して、このボリューム用に構成されているNetBackup ストレージ・ユニットを削除します。詳しくは、「VERITAS

NetBackup System Administrator’s Guide」を参照してください。


3. 次のコマンドを入力して、ボリューム上に qtree が残っているかどうか検査します。qtree status volume_name volume_name は、ボリュームの名前です。

4. qtree ごとに次のコマンドを入力して、.nbu_image_data qtree 以外の示されているすべての qtree を除去します。snapvault stop -f qtree_path

5. 次のコマンドを入力して、.nbu_image_data qtree を除去します。snapvault stop

-f /vol/volume_name/.nbu_image_data

6. 次のコマンドを入力して、非重複化がボリュームで使用可能になっているかどうか検査します。sis status /vol/volume_name

7. 次のコマンドを入力して、ボリューム上のすべての非重複化アクティビティーを終了します。sis off /vol/volume_name

8. 次のコマンドを入力して、自動的な Snapshot コピー作成のスケジュールをリセットします。snap sched volume_name snap sched vol1 0 2 6@8,12,16,20

9. スペースが Snapshot コピー用に予約されていることを確認するには、ボリュームに対する snap reserve 設定をリセットします。snap reserve volume_name

[percent_reserve] percent_reserve は、Snapshot コピー用に予約するスペースのパーセントです。 snap reserve vol1 20

関連タスク

271ページの『SnapVault for NetBackup ボリュームの除去』アーカイブとして使用しなくなった SnapVault for NetBackup ボリュームを破棄することができます。

271ページの『バックアップが期限切れになる前のボリュームの破棄』NetBackup アプリケーションを使用して、バックアップが期限切れになる前にボリュームを破棄する場合があります。その場合、失効した情報が NetBackup カタログおよびニアライン・ストレージ・システムに残ります。

アクティブ/アクティブ構成での SnapVault for NetBackupData ONTAP7.2.1 以降では、アクティブ/アクティブ構成に含まれるシステム上にあるボリュームに対して NetBackup ストレージ・ユニットを構成することが可能でしたが、SnapVault for NetBackup のフェイルオーバーはサポートされませんでした。Data ONTAP 7.3 以降では、SnapVault for NetBackup 機能のフェイルオーバーがサポートされます。

テークオーバーとギブバックのシナリオが SnapVault for NetBackup の環境でどのように進行するか確認するには、次に示す例を参照してください。例を読み進める前に、「Data ONTAP Active/Active Configuration Guide」に記載されている、Data

ONTAP アクティブ/アクティブ構成に関する一般情報を確認することをお勧めします。

SnapVault for NetBackup のテークオーバー/ギブバックの例: 次のことを前提とします。

v NetBackup ディスク・ストレージ・ユニット (DSU_A) は、SystemA 上にあるボリュームを指しています。

v SystemA はアクティブ/アクティブ構成に含まれ、SystemB はそのパートナーです。


DSU_A へのバックアップの進行中に SystemA に障害が起こった場合の動作:

SystemA に障害が起こると、NetBackup から SystemA へのすべての接続が強制終了します。SystemB は SystemA が停止していることを検出し、テークオーバーを開始します (つまり、SystemB が SystemA をテークオーバーします)。テークオーバーの完了後、NetBackup は SystemA が停止したときに強制終了した要求をすべて再試行します。NetBackup 内で、失敗したバックアップの自動再試行を構成できます。(自動再試行を構成する方法について詳しくは、NetBackup の資料を参照してください。)

注: テークオーバーの発生時に NetBackup 内での構成変更は必要ありません。これは、SystemA が SystemB によってテークオーバーされている間も、同じ IP アドレスによって SystemA に引き続き接続できるからです。テークオーバーは、NetBackup 上では SystemA の再始動として認識されます。

SystemA が引き続き停止していて、SystemB がテークオーバー・モードにあるときの動作: テークオーバー・モードでは、SnapVault for NetBackup のバックアップ、リストアなど、テークオーバー対象のノード (SystemA) に対して NetBackup から開始されるすべての操作が、テークオーバー・モードでない場合と同じ方法で処理されます。 NetBackup の観点から見れば状況はすべて同じです。ただし、SystemB

によってテークオーバーされているときの SystemA には、次のような制限が適用されます。

テークオーバー・モード時には、いくつかの同時接続が SystemA と SystemB の間で共有されます。テークオーバー・モード時には、SystemA と SystemB の両方のパフォーマンスが低下する可能性があります。これは、SystemA と SystemB の両方のサービスが、単一のシステムのリソースによって処理されるようになるからです。

テークオーバー・モード時に DSU_A に送信されるバックアップは、SystemA に障害が起こる前と同じディスクのセットに書き込まれます。テークオーバー時に変更されるものは、これらのディスクを制御する物理エンティティーのみです。したがって、リストアされるバックアップが SystemA の障害発生の前または後のどちらに作成されたかに関係なく、リストアは機能します。

SystemA のシステムがオンラインになったときの動作: SystemA が元々存在していたシステムがオンラインになると、SystemB は SystemA へのギブバックを開始できます。ギブバックを開始する方法については、「Data ONTAP Active/Active

Configuration Guide」を参照してください。SystemA のギブバックは、NetBackup のノード再始動と同様の処理です。進行中の NetBackup 接続は中断されます。ギブバック操作が完了した後、NetBackup からこれらの接続を復元する必要があります。

注: SystemB への接続は、ギブバック操作の影響を受けません。

ニアラインストレージ・システム上でボリューム SnapMirror を使用した災害復旧

NetBackup および IBM ボリューム SnapMirror テクノロジーを使用して、ディスク・ストレージ・ユニット (DSU) の災害復旧ソリューションを提供できます。

SnapVault for NetBackup とボリューム SnapMirror の組み合わせにより、非常に効率的な災害復旧が可能になります。非重複化されたボリューム・ブロックは、


SnapMirror ソースから SnapMirror 宛先までネットワーク経由で 1 回限り送信され、ソースからの非重複化プロパティーは宛先でも保存されます。

NetBackup の範囲外でボリューム SnapMirror フィーチャーを使用して災害復旧(DR) 状況のフェイルオーバー・サポートを可能にするには、一方のニアラインストレージ・システム (SystemA) から他方のニアラインストレージ・システム(SystemB) に DSU を複製する必要があります。SystemA 上のボリュームがリカバリー不能になる障害が発生した場合は (つまり、SystemA ストレージ・システム全体が停止した場合、または SystemA 上のボリュームが破壊され、リカバリーできない場合)、SnapMirror 関係を手動で分断する必要があります。これにより、SystemB

上の複製されたボリュームに対して読み取りおよび書き込みのアクセスが可能になります。複製されたボリュームのみがリカバリー可能です。NetBackup 内でいくつか構成の調整を行った後、複製されたボリュームに対する以降のバックアップとリストアはすべて、SystemB によって提供されるようになります。

後で NetBackup を再構成して、リストア、検証、削除、およびバックアップが再びSystemA によって提供されるようにできます。災害復旧計画には、NetBackup カタログのバックアップとリストアの手順を含める必要があります。カタログのバックアップとリストアについて詳しくは、「NetBackup Administrators Guide」を参照してください。

IBM ボリューム SnapMirrorを使用する SnapVault for NetBackupの構成ボリューム SnapMirrorを使用して SnapVault for NetBackup の災害復旧ソリューションをセットアップするには、DSU のボリューム SnapMirror 関係を構成してニアライン・ストレージ・システムで保護されるようにする必要があります。


保護が必要な DSU ごとに、ニアライン・システム上の DSU のボリュームをボリューム SnapMirror 関係のソースとして構成する必要があります。ボリュームSnapMirror 関係の構成方法について詳しくは、本書のボリューム SnapMirror のセクションを参照してください。各ボリューム SnapMirror 関係の宛先は、ソースと異なるニアライン・システムに常駐して、ソース・ボリュームと同じ名前を付けられている必要があります。

注: ソース・ボリュームと宛先ボリュームの名前を同じにすることは、SnapVault for

NetBackupのコンテキストの外部で使用する場合はボリューム SnapMirror の一般的な要件ではありません。これは、ボリューム SnapMirror 関係の構成時にいかなる方法でも強制されません。ただし、SnapVault for NetBackupのコンテキスト内でフェイルオーバーが機能するためには、SnapMirror のソースと宛先でボリューム名が同じである必要があります。

1. SnapVault for NetBackup およびボリューム SnapMirrorを許可するために必要なライセンスおよびオプション設定を指定して、両方のニアライン・ストレージ・システム (SystemA および SystemB) を構成します。ボリューム SnapMirror に必要なライセンスおよびオプションについては、本書のボリューム SnapMirror

のセクションを参照してください。

2. NetBackup については、初期構成は同じままです。 SystemA をニアライン・サーバーとして指定する DSU の NetBackup ポリシーを作成します。データを


SystemA のボリュームにバックアップする通常の構成のほか、NetBackup のNDMP ホストのリストに必ず SystemB を追加してください。ニアライン・ストレージ・システムを NetBackup の NDMP ホストとして追加する方法について詳しくは、NetBackup 資料を参照してください。

3. 災害復旧計画の一部としてカタログを保護する場合は、カタログ・バックアップを構成します。カタログ・バックアップの構成については、特定のプラットフォーム用の「NetBackup Administrator’s Guide」を参照してください。

4. SystemB で、SystemA で保護されるボリュームと同じ名前でボリュームを作成します。

5. SystemB で、保護するボリュームごとに 1 つの SnapMirror 関係を構成します。ボリュームごとに、SystemA のボリュームがソースとなり、SystemB のまったく同じ名前のボリュームが宛先となります。

注: 災害発生時におけるソースと宛先の間でのデータ不一致を最小限に抑えるために比較的頻繁な更新を指定して SnapMirror スケジュールを構成します。詳しくは、このガイドで SnapMirror 関係およびスケジュールの構成方法を参照してください。

関連概念

173ページの『SnapMirror ソースの移動について』ボリューム SnapMirror ソースまたは qtree SnapMirror ソースのどちらを新規ストレージ・システムまたは新規ドライブに移動する場合にも、ソースと宛先に共通のSnapshot コピーが存在していれば、移動は円滑に進みます。

ニアライン・ストレージ・システムの障害発生時に必要なアクションSystemA が使用不可になった場合、バックアップ管理者は、SystemA の該当するSnapMirror 関係を手動で分断してから、NetBackup が SystemA のボリュームからSystemA のボリュームにフェイルオーバーするように NetBackup でいくつかの構成調整を行います。

1. SystemA の複製されたボリュームへの読み取りおよび書き込みアクセス権を使用可能にするには、SystemA の複製された各ボリュームに対して snapmirror break

コマンドを発行することにより、SnapMirror 関係を分断します。

2. SystemA が SystemA にバックアップされたイメージを復元できるようにするには、UNIX の場合は /usr/openv/netbackup/bp.conf ファイルに項目を追加して、Windows の場合は下記の例で説明されているようにマルチストリング・タイプのレジストリー・キーを追加します。複製されたボリュームごとに 1 つの項目またはレジストリー・キーが必要で、影響を受けるすべてのメディア・サーバーを更新する必要があります。項目またはレジストリー・キーの正確な内容は、本セクションの災害復旧の例で説明されています。

3. SnapMirror の複製は非同期的に行われるため、SystemA が停止する前にイメージが完全に複製されていない可能性は非常に低いものです。NetBackup のbpstsinfo コマンド行ユーティリティーの新しいオプションは、NetBackup カタログの内容をニアライン・ストレージ・システムによって報告されたイメージのリストと比較します。このコマンドは、障害を起こした SystemA のボリュームおよび現在の SystemA のボリューム上のイメージのカタログ項目を比較します。SystemA のイメージのリストをプルして、そのリストを SystemA が報告するイメージと比較します。カタログと SystemA の両方に存在しないすべてのイメージのほか、そのイメージがカタログとメディアのどちらにだけ存在するのか、そ


の場所を出力します。これにより、管理者に矛盾が通知されるため、適切なアクションを実行することが可能になります。

4. SystemA からのそれぞれの NetBackup ストレージ・ユニットのニアライン・サーバー・フィールドを SystemA に変更します。

5. カタログが SystemA にバックアップされており、災害が発生したためにカタログの復旧が必要になった場合、プラットフォーム用の「NetBackup Administrators

Guide」でカタログの復旧に関する情報を参照してください。

注: カタログ・バックアップは、ファイル・システム公開が使用可能になっていないニアライン・ストレージ・システムに制限されています。

関連資料

278ページの『フェイルオーバー・プロセスで使用されるコマンドのユース・ケース』下記のユース・ケースは、次の代表的な環境に基づいています。2 つのメディア・サーバー (mediaserver1 および mediaserver2) がボリュームをニアライン・ストレージ・システム (SystemA) にバックアップします。SystemA には、SnapMirrorを使用して別のニアライン (SystemB) に複製されるボリュームが入っています。Mediaserver1 は SystemA の volume1 にバックアップして、mediaserver2 はSystemA の volume2 にバックアップします。

障害を起こしたシステムの復旧後の初期セットアップへの復帰SystemA がバックアップされている場合、ニアラインストレージ・システムのNetBackup 設定および SnapMirror 関係を再び調整して、NetBackup が SystemA のボリュームにバックアップを送信する初期構成を復元することができます。これらのボリュームは SystemB に複製されます。

始める前に

NetBackup を変更する前に、SystemA のボリュームを SystemB の対応するボリュームの現在の内容によって最新状態にする必要があります。これが完了した後、NetBackup を構成して SystemA にバックアップを送信するようにします。

1. それぞれの SystemA のボリュームを SystemB の対応するボリュームの最新内容に同期するには、以前に複製されたボリュームごとに snapmirror resync コマンドを発行して、再同期のソースとして SystemB を指定します。

2. 再同期が完了した後、SystemA の複製された各ボリュームに対して snapmirror

release コマンドを実行し、SystemA の複製された各ボリュームの SnapMirror

関係を解放します。

3. SystemB で、ボリュームごとに、最初に SystemA から SystemB へのデータ転送時に SnapMirror によって使用された基本 Snapshot コピーを削除します。

4. SystemA の該当する各ボリュームに対して snapmirror update コマンドを発行し、関係が損なわれていないことを確認します。

5. SystemA の該当するボリュームごとに複製された関係を分断します。

6. 各ボリュームを SystemB から元の SystemA に再同期して、SystemA の DSU

ボリュームごとに snapmirror resync コマンドを実行します。

7. snapmirror break コマンドを使用して、SystemA の該当するボリュームごとにSnapMirror 関係を分断します。


8. 該当する各ボリュームを SystemA から SystemB に再同期します。

9. SystemB でステップ 2 から 4 を繰り返します。

10. フェイルオーバー手順で追加された bp.conf 項目または Windows レジストリー・キーを更新して、SystemB に対して行われたバックアップのアクセスをSystemA にリダイレクトします。

11. 影響を受けるそれぞれの NetBackup ストレージ・システムでニアライン・サーバー・フィールドを SystemB から SystemA に変更します。

フェイルオーバー・プロセスで使用されるコマンドのユース・ケース下記のユース・ケースは、次の代表的な環境に基づいています。2 つのメディア・サーバー (mediaserver1 および mediaserver2) がボリュームをニアライン・ストレージ・システム (SystemA) にバックアップします。SystemA には、SnapMirrorを使用して別のニアライン (SystemB) に複製されるボリュームが入っています。Mediaserver1 は SystemA の volume1 にバックアップして、mediaserver2 はSystemA の volume2 にバックアップします。

ユース・ケース: 災害復旧のフェイルオーバー・シナリオ:

SystemA が使用不可になり、SystemB が新しい DSU として構成されています。


下記のユース・ケースは、次の代表的な環境に基づいています。

v 2 つのメディア・サーバー (mediaserver1 および mediaserver2)。ニアライン・ストレージ・システム (SystemA) のボリュームにバックアップします。

v SystemA には、SnapMirror を使用して別のニアライン・ストレージ・システム(SystemB) に複製されるボリュームが入っています。

1. SystemB を使用可能にするには、次のように SystemB の 2 つのボリュームに対して snapmirror break コマンドを発行します。SystemB> snapmirror break

volume1SystemB> snapmirror break volume2

2. それぞれの UNIX メディア・サーバーでフェイルオーバーされた各ボリュームに bp.conf 項目を追加します。

メディア・サーバーbp.conf 項目 (UNIX)/レジストリー・キー(Windows) の内容

mediaserver1 NEARSTORE_FAILOVER_SERVER =

SystemA:/vol/volume1 SystemB:/vol/volume1

mediaserver2 NEARSTORE_FAILOVER_SERVER =

SystemA:/vol/volume2 SystemB:/vol/volume2

Mediaserver1

v mediaserver1 が UNIX サーバーである場合、次のNEARSTORE_FAILOVER_SERVER 項目を /usr/openv/netbackup/bp.conf ファイルに追加します。NEARSTORE_FAILOVER_SERVER = SystemA:/vol/volume1

SystemB:/vol/volume1


v mediaserver1 が Windows サーバーである場合、レジストリー・キーを次の場所に追加します。KEY_LOCAL_MACHINE¥SOFTWARE¥VERITAS¥NetBackup¥Concurrent Version¥Config

キーの名前は NEARSTORE_FAILOVER_SERVER で、タイプはマルチストリング値であることが必要です。値は、次のとおりです。SystemA:/vol/volume1


Windows のレジストリー・キーの正確な場所については、「NetBackup

Administrators Guide」を参照してください。

Mediaserver2

v mediaserver2 が UNIX サーバーである場合、次のNEARSTORE_FAILOVER_SERVER 項目を /usr/openv/netbackup/bp.conf ファイルに追加します。 NEARSTORE_FAILOVER_SERVER=SystemA:/vol/volume2


v mediaserver2 が Windows サーバーである場合、レジストリー・キーを次の場所に追加します。KEY_LOCAL_MACHINE¥SOFTWARE¥VERITAS¥NetBackup¥Concurrent Version¥Config

キーの名前は NEARSTORE_FAILOVER_SERVER で、タイプはマルチストリング値であることが必要です。

値は、次のとおりです。SystemA:/vol/volume2 SystemB:/vol/volume2

ニアライン・ホストの名前は、NetBackup の「Storage Device (ストレージ・デバイス)」 → 「NDMP Hosts (NDMP ホスト)」セクションのリストと一致する必要があります。例えば、NetBackup の「Storage Device (ストレージ・デバイス)」に NDMP ホストとして SystemA を SystemA の名前で追加して、SystemB

を SystemB.domain.com の名前で追加した場合、項目は次のようになります。SystemA:/vol/volume2 SystemB.domain.com:/vol/volume2

3. カタログの内容の相違部分および各メディア・サーバー上の DSU の内容を表示するには、bpstsinfo –comparedbandstu コマンドを発行します。次に、mediaserver1 に対するコマンドを示します。 /usr/openv/netbackup/bin/

admincmd/bpstsinfo –comparedbandstu -oldservervolume SystemA:/vol/

volume1 –servername SystemB –serverprefix ntap: -lsuname /vol/volume1 次に、mediaserver2 に対するコマンドを示します。 /usr/openv/netbackup/bin/

admincmd/bpstsinfo –comparedbandstu -oldservervolume SystemA:/vol/

volume2 –servername SystemB –serverprefix ntap: -lsuname /vol/volume2 カタログのイメージとニアライン・ボリュームのイメージの間に矛盾がない場合、出力にイメージはリストされません。出力にはデバッグ・ロギングのみが表示されます。

STS: STH_ESDEBUG: comparedbandstu: libsts openp() 06/09/12 10:48:37:opening module /usr/openv/lib/libstspibasicdiskMT.soSTS: STH_ESDEBUG: comparedbandstu: libsts openp() 06/09/12 10:48:38:opening module /usr/openv/lib/libstspinearstoreMT.soNearstore disk subtype


例えば、SystemA が停止する前に 1 つのイメージが SystemB に複製されなかった場合などの不一致が存在する場合、出力には次のような追加情報が示されます。

STS: STH_ESDEBUG: comparedbandstu: libsts openp() 06/09/12 10:39:37:opening module /usr/openv/lib/libstspibasicdiskMT.soNearstore disk subtypeONLY IN CATALOGimagename:mediaserver1_1157990060 policy:powerpoint_backup copy_num:1frag_num:0 is_header:TRUE resume_num:0ONLY IN CATALOGimagename: mediaserver1_1157990060 policy: powerpoint_backup copy_num:1frag_num:1 is_header:FALSE resume_num:0

NetBackup GUI を使用するか、bpexpdate コマンドを実行して、このイメージの項目を NetBackup カタログから除去します。

注: 2 つのイメージがリストされていますが、これらは 1 つのバックアップのみを表しています。ヘッダー用と実際のバックアップ・データ用に別々のファイルがあります。このバックアップが True Image Restore で使用可能になると、3

つのイメージが出力されます。imagename フィールドを調べることが重要です。両方のイメージには同じイメージ名が付けられています。これは、これらのイメージが同じバックアップの一部であることを意味しています。

次に、カタログから項目を除去するための bpexpdate コマンドを示します。/usr/openv/netbackup/bin/admincmd/bpexpdate -backupid

mediaserver1_1157990060 -d 0

4. SystemA の元のボリュームの復旧が必要でない場合 (つまり、ボリュームをバックアップするための SnapMirror 再同期が行われない)、次の手順を実行して、ボリューム (volume1 および volume2) での SnapMirror 転送で使用されていたSnapshot コピーを手動で削除します。

a. SystemB の宛先ボリュームに対して snapmirror status –l を発行します。SystemB> snapmirror status –l vsmtest1 次の出力例に似た出力が表示されます。

SystemB> snapmirror status -l volume1SnapMirror is on.

Source: SystemA:volume1Destination: SystemB:volume1Status: IdleProgress: -State: Broken-offLag: 00:05:28Mirror Timestamp: Fri Sep 29 10:39:28 PDT 2006Base Snapshot: SystemB(0101178726)_volume1.2Current Transfer Type: -Current Transfer Error: -Contents: ReplicaLast Transfer Type: ResyncLast Transfer Size: 72 KBLast Transfer Duration: 00:00:03Last Transfer From: SystemA:volume1

b. ボリュームに関連する基本 Snapshot コピーを削除します。SystemB> snap

delete volume1 SystemB(0101178726)_volume1.2

c. volume2 についてもこの手順を繰り返します。


5. これらのボリュームの snapmirror.conf ファイルに追加されたすべてのSnapMirror スケジュールを除去します。

6. 次のコマンドを使用して、最初に SystemA のボリュームに対して構成されたストレージ・ユニットを再構成し、SystemB のストレージ・ユニットを指すようにします。/usr/openv/netbackup/bin/admincmd/bpsturep -label storage unit

label -nh SystemB

ユース・ケース: 災害復旧の再同期シナリオ:

SystemA がある期間 (おそらく保守のために) 停止して、SystemB が新しい DSU

として構成されています。


管理者は、災害復旧のフェイルオーバー・シナリオに概要が示されている手順を実行して、SystemB を新しい一時的な DSU として使用可能にします。後で、SystemA

がオンラインに戻され、再び DSU として使用されます。SystemA を DSU として再び使用可能にする前に、SystemA が使用不可になっている間に SystemB にバックアップされたすべてのデータをこの時点で元の SystemA に転送する必要があります。下記のユース・ケースは、次の代表的な環境に基づいています。

v 2 つのメディア・サーバー (mediaserver1 および mediaserver2)。ニアライン・ストレージ・システム (SystemA) のボリュームにバックアップします。

v SystemA には、SnapMirror を使用して別のニアライン・ストレージ・システム(SystemB) に複製されるボリュームが入っています。

データを SystemB から元の SystemA に転送して、それを NetBackup の DSU として使用するには、以下のステップを実行します。

1. ボリュームを SystemB から SystemA に再同期します。SystemA> snapmirror

resync -S SystemB:volume1 volume1 SystemA> snapmirror resync -S

SystemB:volume2 volume2

2. SystemA が複製のソースではなくなったため、SystemA の両方のボリュームに対して snapmirror release コマンドを実行します。SystemA> snapmirror release

volume1 SystemB:volume1 SystemA> snapmirror release volume2

SystemB:volume2

3. SystemB にある基本 Snapshot コピー(SnapMirror がデータを SystemA からSystemB に転送するために使用したもの) が不要になったため、これらのSnapshot コピーを削除します。詳しくは、『災害復旧のフェイルオーバー・シナリオ』ユース・ケースのステップ 4 に従ってください。

4. 関係が損なわれていないことを確認するには、SystemA の両方のボリュームに対して次のコマンドを実行します。SystemA> snapmirror update -S

SystemB:volume1 volume1 SystemA> snapmirror update -S SystemB:volume2

volume2

5. SystemA の複製された関係を分断します。SystemA> snapmirror break volume1

SystemA> snapmirror break volume2

6. ボリュームを SystemA から SystemB に再同期します。SystemB> snapmirror

resync -S SystemA:volume1 volume1 SystemB> snapmirror resync -S

SystemA:volume2 volume2


この操作により、次のようなメッセージが表示され、再同期操作が失敗する可能性があります。

The resync base snapshot will be: SystemA(0101179629)_volume1.4These older snapshots have already been deleted from the source and will be deleted from the destination:

SystemB(0101178726)_volume1.20699SystemB(0101178726)_volume1.20698

Are you sure you want to resync the volume? yWed Sep 27 12:30:24 PDT [SnapMirror.dst.resync.success:notice]:SnapMirror resync of volume1 to SystemA:volume1 successful.Transfer started.Monitor progress with 'snapmirror status' or the SnapMirror log.SystemB> Wed Sep 27 12:30:26 PDT [SnapMirror.dst.snapDelErr:error]:Snapshot SystemB(0101178726)_volume1.20699 in destination volume volume1 is in use, cannot delete.Wed Sep 27 12:30:27 PDT [SnapMirror.dst.err:error]:SnapMirror destination transfer from SystemA:volume1 to volume1 :SnapMirror transfer failed to complete.

このような場合は、次のステップを実行して問題を解決します。

a. SnapMirror の再同期操作によってボリュームが複製された可能性があります。そのため、snapmirror break コマンドを発行して、複製を中断します。SystemB> snapmirror break volume1

b. 適切な Snapshot コピーを手動で削除します。SystemB> snap delete volume1

SystemB(0101178726)_volume1.20699

c. 再同期操作を再試行します。

Snapshot コピーに起因する問題が再同期操作で発生しなくなるまで、これらのステップを数回繰り返さなければならない可能性があります。

7. SystemB でステップ 2 から 4 を繰り返します。

8. フェイルオーバーのセットアップ時に追加されたNEARSTORE_FAILOVER_SERVER 項目を bp.conf ファイル (または Windows

のレジストリー・キー) を除去します (『災害復旧のフェイルオーバー』ユース・ケースのステップ 2 で追加されたものを除去します)。これらの項目を除去した後、パスを SystemB から SystemA にリダイレクトします。この新しいパスにより、SystemA が使用不可になったときに SystemB で作成されたバックアップに適切にアクセスすることができます。各メディア・サーバーの最終的な構成は次のとおりです。

メディア・サーバー bp.conf 項目 (UNIX)/レジストリー・キー (Windows) の内容

mediaserver1 NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume1

SystemA:/vol/volume1

mediaserver2 NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume2


Mediaserver1

v mediaserver1 が UNIX サーバーである場合、『災害復旧のフェイルオーバー』ユース・ケースのステップ 2 で追加された bp.conf 項目を除去してから、次の新しい NEARSTORE_FAILOVER_SERVER 項目を/usr/openv/netbackup/bp.conf ファイルに追加します。NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume1 SystemA:/vol/volume1

v mediaserver1 が Windows サーバーである場合、『災害復旧のフェイルオーバー』ユース・ケースのステップ 2 で追加されたレジストリー・キーを除去してから、レジストリー・キーを次の場所に追加します。


KEY_LOCAL_MACHINE¥SOFTWARE¥VERITAS¥NetBackup¥Concurrent Version¥Config

名前は NEARSTORE_FAILOVER_SERVER で、タイプはマルチストリング値であることが必要です。値は、次のとおりです。SystemB:/vol/volume1

SystemA:/vol/volume1 Windows のレジストリー・キーの正確な場所については、「NetBackup Administrators Guide」を参照してください。

Mediaserver2

v mediaserver2 が UNIX サーバーである場合、『災害復旧のフェイルオーバー』ユース・ケースのステップ 2 で追加された bp.conf 項目を除去してから、次の新しい NEARSTORE_FAILOVER_SERVER 項目を/usr/openv/netbackup/bp.conf ファイルに追加します。NEARSTORE_FAILOVER_SERVER = SystemB:/vol/volume2 SystemA:/vol/volume2

v mediaserver2 が Windows サーバーである場合、『災害復旧のフェイルオーバー』ユース・ケースのステップ 2 で追加されたレジストリー・キーを除去してから、レジストリー・キーを追加します。新しいキーは次の場所に配置する必要があります。KEY_LOCAL_MACHINE¥SOFTWARE¥VERITAS¥NetBackup¥Concurrent Version¥Config

名前は NEARSTORE_FAILOVER_SERVER で、タイプはマルチストリング値であることが必要です。値は、次のとおりです。SystemB:/vol/volume2


9. 次のコマンドを使用して、最初に SystemB のボリュームに対して構成されたストレージ・ユニットを再構成し、SystemA のストレージ・ユニットを指すようにします。/usr/openv/netbackup/bin/admincmd/bpsturep -label storage unit

label -nh SystemA

SnapVault for NetBackup ボリュームのレプリカ上でバックアップにアクセスする方法

ボリューム SnapMirror 複製は、SnapVault for NetBackup ボリューム全体を、読み取り専用ボリュームとして別のストレージ・システムにバックアップします。この読み取り専用のバックアップ・ボリュームには、NetBackup を使用してアクセスできます。この機能は、読み取り専用ボリュームから別の NetBackup マスター・サーバーとメディア・サーバーの組み合わせにバックアップをリストアする場合、およびリストアしたバックアップを NetBackup によって管理される磁気テープ・メディアに長期アーカイブとして転送する場合に役立ちます。

SnapVault for NetBackup のトラブルシューティングトラブルシューティングを行うには、2 次ストレージ・システム・コンソールに表示されるエラー・メッセージを参照してください。また、/etc/log/nbu_snapvault

log ファイルまたは /etc/log/snapmirror log ファイルの 2 つのログ・ファイルのいずれかも参照できます。

注: テークオーバー・モードでは、ローカル・ノードの代わりに実行されるすべてのアクションがローカル・ノードの /etc/log/xxx ファイルに書き込まれます。パートナー・ノードの代わりに実行されるアクションは、パートナー・ノードの/etc/log/xxx ファイルに書き込まれます。


SnapVault for NetBackup エラー・メッセージ以下のエラー・メッセージは、SnapVault for NetBackup に関連しています。修正アクションがある場合は記載されています。

ギブバック取消エラー:

取消エラー「SnapVault for NetBackup transfer to the taken-over node is in progress;

canceling giveback. (テークオーバーされたノードへの SnapVault for NetBackup 転送が進行中です。ギブバックを取り消します。)」を解決できます。

修正アクション ― giveback コマンドを発行するときに、テークオーバーされたノードが関与する SnapVault for NetBackup のバックアップ操作が進行中でないことを確認してください。あるいは、giveback -f コマンドを発行してから、giveback コマンドの後で中断されたすべてのバックアップを再開してください。

ギブバック拒否エラー:

ギブバック・エラー「Cluster monitor: nbu: giveback cancelled due to active state (クラスター・モニター: nbu: ギブバックがアクティブ状態のために取り消されました)」を解決できます。

修正アクション ― giveback コマンドを発行するときに、テークオーバーされたノードが関与する SnapVault for NetBackup のバックアップ操作が進行中でないことを確認してください。あるいは、giveback -f コマンドを発行してから、中断されたすべてのバックアップを再開してください。

プロトコル・ログ・ファイルへの書き込み障害:

エラー「An error was encountered writing to the Veritas protocol log file. (Veritas プロトコル・ログ・ファイルへの書き込み中にエラーが発生しました。)」を解決できます。

修正アクション ― ルート・ボリュームが満杯でないことを確認してください。

qtree 削除エラー:

NetBackup を使用して作成された SnapVault qtree の削除が DSU で失敗しました。

修正アクション ― ボリューム上に十分な空きスペースを作成して、qtree を手動で削除します。

スペースを作成して qtree を削除するには、以下のステップを行います。

1. システム・コンソールで df コマンドを使用して、qtree が置かれているボリュームが満杯であるかどうかを調べます。

2. ボリュームが満杯の場合は、スペースを解放するか、さらに多くのディスクをボリュームに追加します。

UTF 変換エラーの修正:

エラー「A file or directory name in a backup was either longer than 255 unicode

characters or the name is not a valid UTF-8 byte sequence. (バックアップ内のファ


イルまたはディレクトリー名が 255 Unicode 文字より長かったか、名前が有効なUTF-8 バイト・シーケンスではありません。)」を解決できます。


修正アクション ― NetBackup クライアントで、ファイルまたはディレクトリーを名前変更して有効な UTF-8 文字を使用します。

1. ニアライン・システム・コンソールで、snapvault status コマンドを使用してバックアップのベース名およびポリシー名を取得します。ベース名は、NetBackup クライアントの名前を示している必要があります。 snapvault status

/vol/volname/qtreename

注: ベース名は、NetBackup クライアントの名前を示している必要があります。

2. NetBackup クライアントで、エラー・メッセージにリストされているファイルまたはディレクトリーへの絶対パスを使用してファイルまたはディレクトリーを見つけます。

3.

状況処置

NetBackup クライアントが Microsoft オペレーティング・システムを実行していない場合

ファイルまたはディレクトリーの名前を 255

バイト以下のものに変更します。

NetBackup クライアントが Microsoft オペレーティング・システムを実行している場合

NetBackup クライアントが Microsoft オペレーティング・システムを実行している場合、ファイル・ディレクトリーを名前変更するか、データ・ストリームを 255 以下のUnicode 文字に変更します。それぞれのUnicode 文字は、UTF-8 文字セットの 3 バイト以下に変換されます。(ASCII 文字を使用する名前はこの要件を満たします。)

ボリューム言語の警告:

エラー「A file or directory name containing characters that SnapVault interprets as

UTF-8 characters, was backed up to a volume whose volume language setting does

not specify UTF-8 as the NFS character set. (SnapVault が UTF-8 文字として解釈する文字を含むファイルまたはディレクトリー名が、ボリューム言語設定で UTF-8 をNFS 文字セットとして指定しないボリュームにバックアップされました。)」を解決できます。

修正アクション ― ボリューム言語設定で UTF-8 を NFS 文字セットとして指定するボリュームにバックアップしてください。これは 2 とおりの方法のいずれかで実行できます。

ボリューム言語の警告の修正:

ボリュームに NetBackup DSU qtree 以外のものが含まれている場合でも、ボリューム言語の警告を修正できます。


1. ニアライン・システム・コンソールで、snapvault status コマンドを使用してバックアップのベース名およびポリシー名を取得します。snapvault status

/vol/volname/qtreename ベース名は、NetBackup クライアントの名前を示している必要があります。

2. UTF-8 文字を NFS 文字セットとして使用するニアライン・システム上のボリュームを検索または作成します。

3. NetBackup GUI または CLI を使用して、このベース名およびポリシー名に対する将来の操作を、UTF-8 文字を NFS 文字セットとして使用するボリュームに指示します。

4. ステップ 2 で確認したボリュームへのフルバックアップを実行します。

ボリューム言語の警告の解決:

ボリュームに NetBackup DSU qtree のみが含まれている場合、ボリューム言語の警告を解決できます。

1. vol lang コマンドを使用して、ボリューム言語のタイプを判別します。 vol

lang vol1 Volume language is C (POSIX)

2. vol lang コマンドを使用して、UTF-8 を付加することによってボリューム言語を変更します。 vol lang vol1 C.UTF-8

3. 新しい言語設定を有効にするために、ニアライン・システムをリブートします。

4. SnapVault for NetBackup を使用する DSU の各 2 次 qtree のフルバックアップを実行します。

プラットフォーム不一致エラー:

エラー「A NetBackup media server attempted to establish a connection to the DSU

on an unsupported storage system. (NetBackup メディア・サーバーが、サポートされないストレージ・システム上の DSU への接続を確立しようとしました。)」を解決できます。

修正アクション ― 2 次ストレージ・システムが、ニアライン機能ライセンスが使用可能になっているストレージ・システムのいずれかであることを確認してください。その他に必要なすべてのライセンスが使用可能になっていることを確認してください。

エクスポートされたファイル・システムに関連する既知の問題:

下記に、SnapVault for NetBackup でエクスポートされたファイル・システムの実装に伴う既知の問題を示します。

v NetBackup は、NetBackup 4.5 クライアントを使用してバックアップされた特定のファイルを不透明なファイルとして送信します。不透明なファイルは、エクスポートされたファイル・システムに存在しないのに tar イメージに存在するファイルです。

v パイプおよび FIFO などの UNIX 特殊ファイルは、エクスポートされたファイル・システムに存在しませんが、tar イメージに存在します。

v Windows のスパース・ファイルおよび暗号化されたファイルのサイズは、エクスポートされたファイル・システムでゼロと表示されます。


Snapshot コピーが不足した場合の処置:

Snapshot コピーが不足した場合、アーカイブ Snapshot コピーを手動で削除しないでください。代わりに、NetBackup を使用してこれらの Snapshot コピーを削除してください。

Snapshot コピーの不足は共通問題であり、以下のガイドラインに従うと回避できます。

v 異なるバックアップ・スケジュールがポリシーで指定されているデータを別々のボリュームに配置します。例えば、1 つのポリシーは週ごとのフル・スケジュールを指定し、もう 1 つのポリシーは月ごとのフル・スケジュールを指定する場合、バックアップしたデータを別々のボリュームに送信します。

v 異なる保存期間がポリシーで指定されているデータを別々のボリュームに配置します。例えば、1 つのポリシーの保存期間が 2 カ月で、もう 1 つのポリシーの保存期間が 6 カ月の場合、バックアップしたデータを別々のボリュームに送信します。

v アーカイブ Snapshot オプションをオフにします。

関連概念

261ページの『Snapshot コピーによる消費を管理する方法』Data ONTAPが許容するSnapshot コピーの最大数は、1 つのボリュームに対して255 ですが、バックアップに使用できる Snapshot コピーの推奨最大数は 250 です。これは、他の Data ONTAP サービスが Snapshot コピーを必要とするからです。さまざまな方法を使用して、Snapshot コピーによる消費を最適化できます。

トラブルシューティング・ツールNetBackup 環境での問題を解決するために 2 つのトラブルシューティング・ツールがあります。1 つのツールは NetBackup 環境の不要なイメージを識別するもので、もう 1 つのツールはバックアップ・モニタリング情報を集約するためのものです。

NetBackup 環境の不要なイメージを識別するツール

孤立イメージまたは失効データは不要なイメージで、DSU がすぐに満杯になって後続の DSU へのバックアップが失敗する原因となります。このツールを使用して、指定された DSU 内の孤立イメージおよび失効イメージを見つけることができます。このツールを実行した結果に基づいて、DSU から孤立イメージおよび失効イメージを手動で除去できます。

注: 失効イメージは、その保存期間を超えて DSU および NetBackup カタログに存在するバックアップ・イメージです。失効イメージは不必要にストレージを使用するため、これらのイメージを除去する必要があります。

バックアップ・モニタリング情報を集約するツール

DSU のサイズを適切に設定して、SnapVault for NetBackup フィーチャーがスムーズに実装されるようにするには、以下の情報を知る必要があります。

v 増分バックアップの変更率

v 2 つの連続したフルバックアップ間のスペース節約の量

v 増分バックアップのスペース節約


v フルバックアップのサイズの差異

v クライアント・レベルまたはポリシー・レベルでのスペース節約

バックアップ・モニタリング・ツールを使用すると、この情報を集約でき、サイズ設定および実装アクティビティーに役立ちます。これらのツールについて詳しくは、技術サポートにお問い合わせください。


非重複化

非重複化とは非重複化は Data ONTAP のオプション・フィーチャーで、重複データ・ブロックを除去して、データの保管に使用されるストレージ・スペースの量を減らします。

非重複化は、FlexVol ボリュームに対してのみ使用できます。スケジュールに従って非重複化操作を実行することも、コマンドを使用して非重複化操作を開始することもできます。

非重複化を使用するには、適切なライセンスをインストールする必要があります。

非重複化の使用に関する考慮事項非重複化は、ニアライン機能をサポートするすべてのシステムで実行できます。非重複化を使用するボリュームには、最大ボリューム・サイズと最大データの制限があります。

次の表に、非重複化を使用する場合と使用しない場合のさまざまなストレージ・システムで許可される最大ボリューム・サイズをリストします。

表 11. 非重複化を使用する場合と使用しない場合のさまざまなストレージ・システムで許可される最大ボリューム・サイズ


非重複化を使用しないボリュームの最大サイズ (TB)

非重複化を使用するボリュームの最大サイズ (TB)

非重複化を使用するボリュームの合計データ・サイズ (TB)

N3300 16 1 17

N3600 16 2 18

N5200 16 2 18

N5300 16 4 20

N5500 16 3 19

N5600 16 16 32

N6040 16 4 20

N6060 16 16 32

N6070 16 16 32

N7600 16 16 32

N7700 16 16 32

N7800 16 16 32

N7900 16 16 32

注:

v 上の表にリストされたすべてのストレージ・システムで、非重複化を使用するためにはニアライン機能ライセンスが使用可能になっている必要があります。


v 同期 SnapMirror を使用して、非重複化を使用するボリュームを複製することはできません。

手動または autogrow オプションを使用して、非重複化されたデータを含むボリュームのサイズを上の表のサポートされる最大サイズを超えて増やすことはできません。また、ボリュームのサイズがサポートされる最大ボリューム・サイズより大きい場合、ボリュームで非重複化を使用可能にすることはできません。ただし、Data

ONTAP 7.3.1 以降では、ボリュームをサポートされるサイズの制限内に縮小した後で、非重複化を使用可能にすることができます。

非重複化は、アクティブ/アクティブ構成でサポートされます。アクティブ/アクティブ構成の各ノードで許可される同時非重複化操作の最大数は 8 です。ノードの 1

つが障害を起こした場合、もう 1 つのノードが、障害ノードの操作を引き継ぎます。テークオーバー・モードでは、機能しているノードが非重複化操作を通常どおりに続行します。ただし、機能しているノードは、障害ノードの非重複化操作を開始しません。

注: 非重複化が使用可能になっているボリュームの変更ロギングは、テークオーバー・モードの障害ノードに対して続行されます。そのため、障害ノードがアクティブになった後で、テークオーバー・モード中に書き込まれたデータに対して非重複化操作を実行でき、スペース節約は失われません。障害ノードに属するボリュームの変更ロギングを使用不可にするには、それらのボリュームに対する非重複化をオフにします。また、テークオーバー・モードの障害ノードの非重複化対応ボリュームの状況を表示することができます。

非重複化メタデータの配置変更Data ONTAP 7.3 以降では、メタデータの一部はボリューム内に置かれ、他の部分はボリューム外部のアグリゲートに置かれます。指紋データベースと変更ログ・ファイルはボリューム外部のアグリゲートに置かれるため、Snapshot コピー内に固定されることはありません。

この変更により、非重複化のスペース節約効果がさらに高まります。ただし、非重複化操作中に作成される他のいくつかの一時メタデータ・ファイルは、引き続きボリューム内部に置かれます。これらの一時メタデータ・ファイルは、非重複化操作の完了後に削除されます。これらの一時メタデータ・ファイルが、非重複化操作中に作成される Snapshot コピー内に固定される可能性があります。これらのメタデータ・ファイルは、Snapshot コピーが削除されるまで固定されたままになります。

次のように、ボリュームの論理データ全体で非重複化メタデータが占める割合は最大 6% です。

v ボリュームの論理データ全体のうち最大 2% はボリューム内に置かれます。

v ボリュームの論理データ全体のうち最大 4% はアグリゲートに置かれます。

したがって、ボリューム SnapMirror、vol copy、FlexClone、ボリューム SnapRestore

などのブロック・レベル・コピー操作の動作にいくつか変更点があります。


関連概念

『ボリューム SnapMirror と非重複化の併用』ボリューム SnapMirror を使用して、非重複化したボリュームを 2 次ストレージ・システム (宛先) に複製できます。

非重複化構成データの配置変更Data ONTAP7.3 以降では、指定されたボリュームに対する非重複化構成データは、そのボリューム内のメタファイルに配置されます。Data ONTAP 7.3 より前では、構成データはルート・ボリュームのレジストリー内に配置されていました。

この変更点は、ボリューム SnapMirror、snap restore、vol copy、vol clone などのボリューム・レベル操作が、宛先のボリュームに関する非重複化構成データをソース・ボリュームと整合させるために役立ちます。

非重複化ライセンスの活動化非重複化は、Data ONTAP のオプション・フィーチャーです。Data ONTAP をインストールした後で非重複化ライセンスを活動化することができます。


非重複化ライセンスは、ニアライン機能ライセンスをサポートする IBM N シリーズ・ストレージ・システムによってサポートされます。N シリーズ・システムでは、非重複化ライセンスをインストールする前にニアライン機能ライセンスをインストールする必要があります。

次のコマンドを入力します。license add xxxxxxx xxxxxxx は、非重複化ライセンスのコードです。

次のタスク

license コマンドについて詳しくは、na_license(1) マニュアル・ページを参照してください。

注: 非重複化は、Data ONTAP 7.2.5.1 以降のリリースでサポートされます。

非重複化を他の Data ONTAP フィーチャーと組み合わせて使用する場合の考慮事項

非重複化と、他の Data ONTAP フィーチャー (例えば、ボリュームSnapMirror、qtree SnapMirror、SnapVault など) を組み合わせて使用する場合には、いくつかの考慮事項に留意する必要があります。

ボリューム SnapMirror と非重複化の併用ボリューム SnapMirror を使用して、非重複化したボリュームを 2 次ストレージ・システム (宛先) に複製できます。

非重複化 291

1 次ストレージ・システム (ソース) 上で、非重複化とニアライン機能のライセンスを有効にする必要があります。Data ONTAP 7.3.1 以降では、宛先ストレージ・システム上でニアライン機能のライセンスは不要です。

注: 非重複化ライセンスは、宛先ストレージ・システム上では不要です。ただし、1

次ストレージ・システムが使用不可になり、2 次ストレージ・システムが新しく 1

次になった場合、非重複化を続行するには、2 次ストレージ・システム上で非重複化のライセンスを有効にする必要があります。したがって、ベスト・プラクティスとしては、両方のストレージ・システム上で非重複化のライセンスを有効にしてください。

非重複化の使用可能化、実行、および管理は、1 次ストレージ・システムからのみ実行できます。ただし、2 次ストレージ・システムの FlexVol ボリュームは、非重複化属性とストレージの節約効果をすべて SnapMirror を通じて継承します。

共有ブロックは 1 回限り転送されるので、非重複化によってネットワーク帯域幅の使用量も削減されます。

ボリューム SnapMirror の更新スケジュールは、非重複化スケジュールに関連していません。

ソース・ボリュームと宛先ボリュームのうち、小さい方の最大ボリューム・サイズ限度に基づいて、最大ボリューム・サイズ限度が適用されます。2 つの異なるモデルのストレージ・システム間で SnapMirror 関係を作成する際には、非重複化を使用する最大ボリューム・サイズが、2 つのモデルのうち小さい方の最大ボリューム・サイズ限度に設定されていることを確認してください。

例

N5200 システムは、非重複化を使用する場合の最大ボリューム・サイズとして 2

TB をサポートします。一方、 N5500 システムは 3 TB をサポートし、N5200 から N5500 へのボリューム SnapMirror 関係が確立されています。この構成では、2

TB (N5200) のボリューム SnapMirror 関係が確立されていることを確認してください。

フェイルオーバー後、N5500 システム上のボリューム・サイズが増大して 2 TB を超えた場合、ストレージ・システム間で新規のベースライン転送または再同期を実行できなくなります。これは、非重複化を使用する N5200 システムの最大ボリューム・サイズが 2 TB であるからです。

Data ONTAP 7.3.1 以降では、ボリューム・サイズが非重複化のためにサポートされる限度を超えて増大した後、サポートされる限度内に縮小した場合、このボリュームは SnapMirror 1 次ストレージ・システムと 2 次ストレージ・システムの一部になることができます。

ボリューム SnapMirror と非重複化を構成する際には、非重複化スケジュールとボリューム SnapMirror のスケジュールを考慮する必要があります。ベスト・プラクティスとしては、非重複化ボリュームのボリューム SnapMirror 転送は、非重複化の完了後に開始します (つまり、非重複化操作の途中ではなく)。このステップを行うことにより、非重複化されたデータと追加の一時メタデータ・ファイルがネットワーク経由で送信されないようになります。ソース・ボリューム内の一時メタデータ・フ


ァイルが Snapshot コピー内に固定されている場合、これらのファイルはソースと宛先のボリューム内でも余分のスペースを消費します。

qtree SnapMirror と非重複化の併用qtree SnapMirror は、個々の qtree SnapMirror 転送が完了するたびに非重複化操作を自動的には開始しません。非重複化スケジュールは、qtree SnapMirror 転送スケジュールとは独立してセットアップできます。

qtree SnapMirror と非重複化を併用する場合は、次の点に注意してください。

v 非重複化と SnapMirror の両方のライセンスを使用可能にする必要があります。

v 非重複化は、ソース・システムまたは宛先システム、あるいは両方のシステム上で使用可能に設定できます。

v ソース・システム上で非重複化を使用可能に設定した場合にも、重複ブロックは宛先システムに送られます。

このため、ネットワーク帯域幅の節約効果はありません。

v 非重複化操作が完了した後に SnapMirror 転送が開始されるように、非重複化とSnapMirror のスケジュールをセットアップする必要があります。このようにしなければ、非重複化されたブロックが SnapMirror 基本 Snapshot コピー内に固定されたままになります。

注: 基本 Snapshot コピーは、qtree SnapMirror 関係ごとに 1 つずつ存在します。

v 非重複化スケジュールは qtree SnapMirror 更新とは関連しておらず、ボリュームの非重複化スケジュールとまったく同様に構成できます。

SnapVault に対する非重複化非重複化フィーチャーは、SnapVault 2 次ストレージと統合されています。このフィーチャーによって、データ・バックアップの効率が向上し、2 次ストレージがより適切に使用されるようになります。

SnapVault に対する非重複化の動作は、qtree SnapMirror に対する非重複化の動作と同様ですが、次の点が異なります。

v Data ONTAP 7.3 以降では、非重複化は SnapVault 宛先ボリューム上でもサポートされます。

v 非重複化スケジュールは、宛先システム上の SnapVault スケジュールに関連しています。ソース・システム上の非重複化スケジュールは SnapVault 更新スケジュールとは関連しておらず、ボリューム上で独立して構成できます (qtree

SnapMirror の場合と同様)。

v SnapVault 更新 (ベースラインまたはインクリメンタル) のたびに、アーカイブSnapshot の作成後、宛先システム上で非重複化プロセスが開始されます。

v 宛先で非重複化の実行が完了した後、アーカイブ Snapshot コピーは新規Snapshot コピーに置き換えられます。(この新規 Snapshot コピーの名前はアーカイブ・コピーの名前と同じですが、このコピーの作成時刻が変更されます。)

v 宛先システム上で非重複化スケジュールを手動で構成したり、sis start コマンドを実行したりすることはできません。ただし、宛先システム上で sis start -s コマンドを実行することはできます。

非重複化 293

v SnapVault 更新は非重複化操作に関連していません。つまり、直前のバックアップからの宛先ボリュームに対する非重複化操作がまだ進行している間にも、後続のインクリメンタル更新を続行できます。この場合、非重複化操作は続行しますが、非重複化操作の完了後にアーカイブ Snapshot コピーは置き換えられません。

注: ストレージ・システム上では、最大 8 つの非重複化操作を同時に実行できます。この数には、SnapVault ボリュームにリンクした非重複化操作と、SnapVault ボリュームにリンクしていない操作が含まれます。

注: Protection Manager と非重複化は、サポートされる構成ではありません。

qtree SnapMirror または SnapVault ソースが非重複化の後で未変更ブロックを転送する

ソース・ボリュームで非重複化が完了する前に qtree SnapMirror または SnapVault

更新が実行される場合、ソースは次回の更新時に、実際に変更されたブロックのほかに、いくつかの未変更のブロックを宛先に転送する可能性があります。

宛先ボリュームで非重複化が実行されていない場合、転送された冗長データは、宛先ボリュームでさらに多くのストレージを占有します。

ソース・ボリュームで非重複化を使用可能にする前に、以下のベスト・プラクティスに従うことをお勧めします。

v ソース・ボリュームで非重複化が実行されている場合、qtree SnapMirror またはSnapVault 宛先ボリュームで非重複化が実行されていることを確認します。

v ソース・ボリューム上の非重複化が終了した後でのみ転送が実行されるように更新転送をスケジュールします。

詳しくは、「SnapVault Best Practices Guide」を参照してください。

関連情報

http://media.netapp.com/documents/tr_3487.pdf

非重複化およびテープ・バックアップNDMP またはネイティブ dump コマンドを使用するテープへのバックアップは、非重複化を保持しません。そのため、テープから復元したボリュームですぐにスペース節約の再取得を開始する場合、復元されたボリュームで非重複化操作を実行する必要があります。

非重複化の実行方法コマンドを使用してボリュームに対する非重複化を実行できます。また、指定する時間に非重複化を実行するためのスケジュールを作成することもできます。

非重複化操作がニアライン・システムの FlexVol ボリュームで使用可能になっている場合、非重複化操作は次の状況で実行されます。

v 作成されたスケジュールどおり

v 深夜 12 時 (デフォルトのスケジュール)


http://media.netapp.com/documents/tr_3487.pdf

非重複化スケジュールの作成非重複化操作は、デフォルトで 1 日 1 回深夜 12 時に、使用可能になっているFlexVolボリュームに対して実行されます。非重複化を別の時刻に実行する場合、非重複化スケジュールを作成できます。

次のコマンドを入力します。sis config -s schedule path schedule は、非重複化が実行される曜日と時間をリストします。スケジュールは、以下の形式にすることができます。

v day_list[@hour_list]

hour_list が指定されない場合、非重複化は、スケジュールされた各曜日の朝にあたる深夜 12 時に実行されます。

v hour_list[@day_list]

day_list が指定されない場合、非重複化は毎日指定された時間に実行されます。

v -

ハイフン (-) を指定すると、指定された FlexVol ボリュームに対する非重複化操作が使用不可になります。

v auto

(手動または自動で実行された) 前回の非重複化操作以降に追加または変更されたブロックの数が非重複化によって既に処理された合計ブロック数の約 20% を超えると、非重複化は自動的に実行されます。

注: デフォルトのしきい値は 20% です。この値は、sis config -s auto@num

/vol/volname コマンドを使用して構成できます。

ここで、num は、パーセントを指定する 2 桁の数値です。

path は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。次のコマンドにより、非重複化操作が月曜日から金曜日の午後 11 時に開始します。sis

config -s mon-fri@23 /vol/vol1 非重複化操作のスケジュールについて詳しくは、na_sis(1) マニュアル・ページを参照してください。

既存データに対する非重複化の実行既存の FlexVol ボリューム上の重複ブロックを手動でスキャンして除去することができます。

非重複化操作を開始するには、次のコマンドを入力します。sis start -s path path

は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。詳しくは、sis(1) マニュアル・ページを参照してください。

注: sis start -s コマンドを実行するときに既にボリュームに対する非重複化操作が実行中である場合 (例えば、スケジュールされた非重複化操作が開始している場合)、コマンドは失敗します。前の操作の前に存在した重複ブロックを除去するには、前の非重複化操作が完了した後でこのコマンドを実行します。

非重複化 295

事前設定されたスケジュール外部での非重複化の実行システムが使用中でない場合や、特定の操作に対する非重複化の影響をテストする場合、事前設定されたスケジュール外部で非重複化を開始することがあります。

次のコマンドを入力します。sis start path path は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。詳しくは、sis(1) マニュアル・ページを参照してください。

非重複化チェックポイント機能チェックポイント機能は、非重複化操作の実行プロセスを定期的にログに記録するために使用されます。非重複化操作が何らかの理由 (システム停止、パニック、リブート、前回の非重複化操作の失敗または停止など) で停止し、チェックポイント・データが存在する場合は、最新のチェックポイント・ファイルから同じ非重複化プロセスを再開できます。

この機能を使用すると、次のコマンドを使用してチェックポイントから再開できます。

v sis start -s

v sis start (手動または自動)

チェックポイントは、非重複化プロセスの各ステージまたはサブステージの最後に作成されます。また、sis start -s コマンドの場合、チェックポイントはスキャン・フェーズ中に 1 時間ごとに作成されます。

チェックポイントがスキャン・ステージ (sis start -s コマンドが実行されるときのフェーズ) に対応していて、経過時間が 24 時間を超える場合、非重複化操作は直前のチェックポイントから自動的に再開しません。この場合、非重複化操作は最初から開始します。ただし、過去 24 時間内にボリュームに大きな変更が発生しなかったことが分かっている場合は、sis start -s コマンドの -p オプションを使用すれば、チェックポイントの経過時間を検査せずに直前のチェックポイントから再開できます。

sis start コマンドをチェックポイント機能と使用する非重複化操作の開始sis start コマンドをチェックポイント機能と一緒に使用して非重複化操作を開始できます。

次のコマンドを入力します。sis start [-s] [-f] [-d] [-sp] /vol/volname -s オプションは、ボリュームを完全にスキャンして、ボリュームに対して非重複化を開始するかどうかの確認を求めるプロンプトを表示します。 -f オプションは、プロンプトを表示せずにボリュームに対する非重複化を開始します。 -d オプションは、既存のチェックポイント情報を削除した後に新しい非重複化操作を開始します。 p

オプションは、チェックポイントの古さに関係なく、以前のチェックポイントを使用して非重複化操作を開始します。

注: このオプションは、-s も指定する場合にのみ使用してください。これは、チェックポイント・データが収集ステージに対応している場合に適用可能です。


非重複化の管理

非重複化の管理コマンドを使用すると、以下を実行できます。

v 非重複化操作を使用可能にする。

v ボリュームの非重複化状況を表示する。

v 非重複化のスペース節約を表示する。

v 非重複化を停止する。

非重複化操作を使用可能にする非重複化ライセンスを活動化するほか、非重複化機能を使用する FlexVol ボリュームを指定する必要があります。

次のコマンドを入力します。sis on path path は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。

非重複化操作の開始sis start コマンドを使用して、ボリュームに対する非重複化操作を開始できます。

次のコマンドを入力します。sis start [-s] [-f] [-d] [-sp] /vol/volname ―s

オプションは、ボリュームを完全にスキャンして、ボリュームに対して非重複化を開始するかどうかの確認を求めるプロンプトを表示します。 ―f オプションは、プロンプトを表示せずにボリュームに対する非重複化を開始します。 ―d オプションは、既存のチェックポイント情報を削除した後に新しい非重複化操作を開始します。 p オプションは、チェックポイントの古さに関係なく、以前のチェックポイントを使用して非重複化操作を開始します。

注: このオプションは、-s も指定する場合にのみ使用してください。これは、チェックポイント・データが収集ステージに対応している場合に適用可能です。

ボリュームの非重複化状況の表示sis status コマンドを使用して、ボリュームに対する非重複化操作の状況を表示できます。

次のコマンドを入力します。sis status -l path path は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。sis status コマンドは基本コマンドです。sis status コマンドについて詳しくは、sis(1) マニュアル・ページを参照してください。次の表に、sis status -l コマンドの実行後に表示される可能性がある状況と進行状況メッセージのリストと説明を示します。

メッセージ (メッセージ・タイプ) 意味

Idle (状況および進行状況) 非重複化アクティビティーはありません。

Pending (状況) ストレージ・システムまたは vFiler ユニットに許可される最大並行非重複化操作の制限に達しました。この制限を超えて要求された非重複化操作はキューに入れられます。

Active (状況) 非重複化操作は実行中です。

非重複化 297

メッセージ (メッセージ・タイプ) 意味

size Scanned (進行状況) ボリューム全体のスキャンが実行中で、そのうち size が既にスキャンされました。

size Searched (進行状況) 重複データの検索が実行中で、そのうち size

が既に検索されました。

size (pct) Done (進行状況) 非重複化操作により、size の量のデータが保存されました。pct は、検索ステージでディスカバーされた重複データ全体のうち保存されたパーセントです。

size Verified (進行状況) 処理済みデータ・ブロックのメタデータの検証が実行中で、そのうち size が既に検証されました。

pct% merged (進行状況) 非重複化操作により、処理済みデータ・ブロックの検証されたすべてのメタデータのうちpct% パーセントが高速非重複化操作をサポートする内部形式にマージされました。

非重複化スペース節約の表示df -s コマンドを使用すると、非重複化によって節約したスペースの量が分かります。


df -s コマンドは、アクティブ・ファイル・システム内のスペース節約のみを表示します。Snapshot コピー内のスペース節約は、この計算に含まれません。

次のコマンドを入力します。df -s volname volname は、FlexVol ボリュームの名前です。例えば vol1 です。df コマンドについて詳しくは、df(1) マニュアル・ページを参照してください。

注: 非重複化を使用しても、ボリュームの割り当て量には影響がありません。割り当て量は、論理レベルで報告され、未変更のままになります。

非重複化操作の停止非重複化は処理中に帯域幅を消費します。そのため、複製、バックアップ、アーカイブ、または復元などの重要なファイル操作の実行中に非重複化を停止する必要が生じる場合があります。

次のコマンドを入力します。sis stop path path は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。

タスクの結果

このステップにより、現在アクティブな非重複化操作のみが停止します。非重複化操作が使用可能になっている限り、その他の非重複化操作はそのスケジュールされた時刻に実行されます。


非重複化を使用不可にする実現したスペース節約と比較して特定ボリュームの非重複化のオーバーヘッドが高い場合、そのボリュームに対する非重複化を使用不可にすることができます。また、非重複化ライセンスを除去する前に非重複化を使用不可にする必要があります。

1. ボリュームに対するアクティブな非重複化操作が行われている場合、次のコマンドを入力して操作を中止します。sis stop path path は、FlexVol ボリュームへの完全パスです。例えば、/vol/vol1 です。

2. 次のコマンドを入力します。sis off path sis コマンドについて詳しくは、sis(1)

マニュアル・ページを参照してください。

非重複化ライセンスを削除する前に非重複化を使用不可にする設定非重複化ライセンスを削除する前に、sis off コマンドを使用して、すべてのFlexVol ボリューム上で非重複化を使用不可に設定する必要があります。このようにしなければ、このフィーチャーを使用不可にするように求める警告メッセージが出されます。

注: ライセンスを削除する前に行われたボリューム非重複化は、すべて変更されずに残ります。

sis auto スケジュールを使用可能にする(手動または自動で実行された) 前回の非重複化操作以降に追加または変更されたブロックの数が非重複化によって既に処理された合計ブロック数の約 20% を超えると、非重複化は自動的に実行されます。このパーセントを変更してストレージ節約および CPU のパフォーマンスを調整することができます。

自動的な非重複化を使用可能にするには、次のコマンドを入力します。sis config

-s auto@num /vol/volname num は、パーセントを指定する 2 桁の数値です。値が指定されない場合、デフォルト値の 20% が使用されます。sis config -s auto

/vol/volname

非重複化と vFiler ユニットの統合Data ONTAP 7.3.1 以降では、vFiler ユニット上での非重複化が完全にサポートされています。また、非重複化コマンドは、すべての vFiler コンテキストで使用可能です。vFiler ユニット上での非重複化のサポートにより、vFiler ユニット内の冗長データ・ブロックを削減できます。

非重複化はボリューム・レベル操作です。非重複化フィーチャーは、FlexVol ボリュームに対してのみサポートされます。vFiler ユニット内の FlexVol ボリューム上で、非重複化を使用可能に設定できます。vFiler ユニット上での非重複化のサポートにより、1 つの vFiler ユニットが所有するストレージに他の vFiler ユニットがアクセスできないようになります。このように非重複化が統合されているので、vFiler

災害復旧と vFiler マイグレーションでの非重複化のサポートが確実なものになります。ソース vFiler ユニット内のボリュームに対して非重複化が使用可能に設定されている場合、すべての非重複化属性が宛先の vFiler ユニットに伝搬されます。

非重複化 299

vFiler 災害復旧: 宛先 vFiler ユニットにあるすべての FlexVol ボリュームが、ソース vFiler ユニットの非重複化属性を継承します。

vFiler マイグレーション: ソース vFiler ユニット上の FlexVol ボリュームの非重複化属性が、宛先 vFiler ユニットにマイグレーションされます。

1 次ストレージ・システム上で非重複化のライセンスを有効にする必要があります。2 次ストレージ・システム上でも非重複化のライセンスを有効にすることをお勧めします。これらのライセンスにより、障害が発生して 2 次 vFiler ユニットが1 次ストレージ・システムになった場合に、非重複化操作を中断せずに継続できます。

非重複化フィーチャーを使用するには、ストレージ・システム上で次のライセンスをアクティブにする必要があります。

v multistore

v a_sis

注: vFiler 災害復旧および vFiler マイグレーションについて詳しくは、「Data

ONTAP MultiStore Management Guide」を参照してください。

vFiler ユニットに対してサポートされる非重複化コマンドvFiler ユニットに対して非重複化コマンドを実行する方法はいくつかあります。

注: すべての非重複化コマンドが、vFiler 境界検査を実行します。この仕組みにより、要求側の vFiler ユニットに属さないストレージへのアクセスを防止できます。

次の方法で、vFiler ユニットに対して非重複化コマンドを実行できます。

v CLI を使用する

v rsh/SSH を使用する

– vFiler コンテキストを使用する

– vfiler run コマンドを使用する

CLI を使用した vFiler ユニット上での非重複化の実行コマンド行インターフェースを使用して、vFiler ユニット上で非重複化を実行できます。

コマンド行インターフェース (CLI) を使用すると、次の非重複化コマンドが使用できます。

v sis on

v sis off

v sis start

v sis config

v sis status

v sis stop


すべての非重複化コマンドが、vFiler 境界検査を実行します。この仕組みにより、要求側の vFiler ユニットに属さないストレージへのアクセスを防止できます。非重複化を使用可能にするには、非重複化対象の FlexVol ボリュームを所有する vFiler

ユニットの vFiler コンテキストに切り替える必要があります。これにより、FlexVol

ボリューム上で非重複化コマンドを実行できます。

例:

FlexVol ボリューム vola および volb は、それぞれ vFiler ユニット vf1 およびvf2 が所有しています。コンテキストを切り替えるには、次のコマンドを発行します。

v vfiler context vf1

v sis on /vol/vola

v sis start -s /vol/vola

これで、vf1 および vola に対して非重複化コマンドを実行できます。一方、vf2 または volb に対してコマンドを実行することはできません。これらのコンテキストがvf1 ではなく vf2 であるからです。したがって、コマンド vfiler context vf1 sis

on /vol/volb は失敗します。

このコマンドが失敗する理由は、コンテキストが vf1 であるからです。

これらのコマンドの出力は、vfiler コンテキスト固有です。これらのコマンドは、現在の vFiler コンテキストの vFiler ユニット内にあるすべてのボリュームに関する情報を表示します。

v sis config―ボリューム名が指定されていません。

v sis status―ボリューム名が指定されていません。

vfiler run コマンドを使用する場合は、コマンドのターゲット vFiler ユニットを引数として指定できます。これにより、非重複化コマンドを実行する前に正しい vfiler

context が確実に割り当てられます。

vfiler run は、その後に続くコマンドを指定された vFiler コンテキストで実行します。

vfiler run [-q] vfilertemplate sis_command [args]

run サブコマンドは、vfilertemplate 内で指定された vFiler ユニットに対してコマンドを実行します。複数の vFiler ユニットが指定されている場合、コマンドはそれぞれの vFiler ユニットに対して別個に実行されます。任意の vFiler 固有のコンソール・コマンドを使用できます。コマンドが vFiler 固有でない場合は、エラー・メッセージがログに記録され、コマンドは失敗します。

rsh または SSH を使用した vFiler ユニット上での非重複化の実行

rsh または SSH を使用して非重複化コマンドを実行できます。この場合、ユーザー要求は宛先 vFiler ユニットの IP アドレスと IPspace をもつネットワーク・スタックに送られます。

非重複化 301

vFiler ユニットごとの非重複化セッションの最大数を設定する方法option sis.max_vfiler_active_ops コマンドを使用して、vFiler ユニットごとに同時に実行できる非重複化セッションの数を指定できます。

注: ストレージ・システムごとに同時に実行できる非重複化操作の最大数は 8 です。コマンドはまず物理ストレージ・システム上で sis ops を検査し、次に vFiler

ユニット上で検査します。


ボリューム・コピー

ボリューム・コピーについてボリューム・コピーは、アクティブ・ファイル・システムのデータとストレージ・システムのデータの両方をボリューム間でコピーする方法です。ソース・ボリュームと宛先ボリュームは、同じタイプ (従来型または flex) でなければなりません。

vol コマンドのファミリーはボリュームを管理します。ボリュームはストレージの論理装置であり、ファイル・システム・イメージおよび関連する管理オプション(Snapshot スケジュールなど) が入っています。ボリュームが占有するディスク・スペース (および受け取る RAID 保護の特性) は、アグリゲートによって提供されます (na_aggr(1) を参照)。

ボリューム・コピーは vol copy start コマンドによって開始できます。このコマンドにより、同一または異なるストレージ・システム上にあるボリューム間でデータをコピーすることができます。その結果、制限付きボリュームに、コピー操作の開始時にソース・ボリュームにあったのと同じデータが含まれます。

vol copy コマンド・セットの利点: cpio などのクライアント・プログラムを使用したり、Data ONTAP dump および restore コマンドを使用してストレージ・システム上のデータをコピーすることもできますが、vol copy コマンドは以下を提供します。利点:

v vol copy コマンドがデータの読み取り/書き込みを行う場合、Data ONTAP はシステム上のディレクトリーを全探索しません。データは、ディスクから直接ブロック単位でコピーされます。つまり、Data ONTAP は他の方法よりも早くコピーを終了することができます。

v vol copy コマンドを使用すると、Data ONTAP はソース・ボリュームの Snapshot

データを保存します。将来、ユーザーがデータがボリューム間でコピーされる前に作成された Snapshot コピーを使用する必要が生じた場合、vol copy コマンドを使用してデータをマイグレーションすることができます。例えば、ユーザーが誤ってファイルを削除し、それらをリカバリーする必要がある場合、保存されたデータからリカバリーすることができます。

同時ボリューム・コピーの最大数: ボリューム・コピーには、SnapMirror 複製と同じ同時コピーの制限があります。詳しくは、『並行複製操作の最大数』を参照してください。


関連資料



ボリュームをコピーする時期ボリュームのコピーは、特定の状況で役立ちます。

次の表で、ボリュームのコピーが役立ついくつかの状況について説明します。

状況ボリューム間でコピーする理由

データをストレージ・システム間でマイグレーションする。

宛先ストレージ・システムの方がストレージが大きいか、新しいテクノロジーをサポートするモデルである。

同じストレージ・システム上のディスク・セット間でボリュームを移動する。

以下を行う。

v ボリュームの分割

v ストレージの拡張

例: vol0 ボリュームを vol1 ボリュームにコピーしてから、それらのボリューム内の重複したファイルおよびディレクトリーを削除して、vol0 の元の内容を 2 つのボリュームに分割できます。

vol0 ボリューム用の 6 つの 9 GB ディスクと 4 つの 18 GB スペア・ディスクがあります。 vol0 を 4 つの 18 GB ディスクにマイグレーションして、すべての 9 GB ディスクを大容量ディスクに置き換えることができます。


状況ボリューム間でコピーする理由

データをストレージ・システム間で定期的にコピーして、高度なデータ可用性を確保する。

データをコピーした後、クライアントは次のシナリオで宛先ストレージ・システムに切り替えることができます。

v ソフトウェアまたはハードウェアのアップグレードのためにストレージ・システムをシャットダウンする場合、または自然災害などの理由でストレージ・システムを使用できない場合、宛先ボリュームをオンラインにしてファイル・サービスを続行することができます。

v ネットワーク・クライアント・プロセスによってストレージ・システム上の多数のファイルが誤って削除された場合、クライアントは引き続き宛先ストレージ・システム上のファイルにアクセスして、その間にソース・システムにファイルを復元することができます。

注: このシナリオは、SnapMirrorでも適用すると役立ちます。

ボリュームをコピーする前の前提条件ボリューム・コピー操作に関係するストレージ・システムは、いくつかの要件を満たす必要があります。

次のリストに、これらの要件の要旨を示します。

v ソース・ボリュームと宛先ボリュームは、同じタイプ (両方とも従来型であるか、両方とも FlexVol ボリューム) でなければなりません。

v 宛先ボリュームの容量は、ソース・ボリュームの容量より大か等しい必要があります。

v ソースおよび宛先ストレージ・システムの間に相互の信頼関係が必要です。

v 宛先ボリュームは存在している必要があり、ルート・ボリュームであってはなりません。

v ソース・ボリュームはオンラインでなければならず、宛先ボリュームが制限付きでなければなりません。

v リモート・シェル・アクセスが使用可能になっている必要があります。

v 宛先ボリュームに、保持するデータが入っていてはなりません。

このセクションの残りの部分には、ソース・ボリュームと宛先ボリュームがこれらの要件を満たしているかどうかの検証についての詳細情報が記載されています。

必要なデータを上書きしないように注意してください。宛先ボリュームが新しいボリュームでない場合、将来必要となるデータが含まれていないことを確認します。Data ONTAP がソース・ボリュームのコピーを開始すると、宛先ボリューム全体を

ボリューム・コピー 305

上書きします。アクティブ・ファイル・システムおよび宛先ボリュームの Snapshot

コピーにあるすべてのデータは、Data ONTAP がデータのコピーを開始した後で失われます。

ボリューム・コピーを配置できる場所: コピーのソース・ボリュームおよび宛先ボリュームは、同一または異なるストレージ・システムに配置できます。

ボリュームのコピーに関する推奨事項: ストレージ・システムが異なるストレージ・システム上の 2 つのボリューム間でデータをコピーする場合、2 つのストレージ・システム間のネットワークでパケットのフラッディングを行います。ボリューム・コピー操作に関係するストレージ・システムのユーザーは、コピー中に応答時間の低下に気付く場合があります。ソースおよび宛先のストレージ・システム間でコピーするためのプライベート・ネットワークは、別のストレージ・システムにコピーする場合のネットワーク関連のパフォーマンス上の問題を回避する上で役立ちます。

各ボリュームのサイズの検査あるボリュームのデータを別のボリュームにコピーまたは複製できるかどうかを調べるために、2 つのボリュームのファイル・システム・サイズを比較する必要があります。

1. ソース・ストレージ・システムで、次のコマンドを入力します。vol status -b

volume_name volume_name は、ソース・ボリュームの名前です。結果: Data

ONTAP は、ボリュームのブロック・サイズ (バイト単位)、RAID ボリューム・サイズ、および Write Anywhere File Layout (WAFL) ファイル・システム・サイズを表示します。ボリューム名が指定されない場合、すべてのボリュームの情報が表示されます。

2. 宛先ストレージ・システムでステップ 1 を繰り返して、volume_name を宛先ボリュームの名前に置き換えます。

3. ファイル・システム (FS) の数値を比較します。宛先のファイル・システム・サイズがソースのファイル・システム・サイズ以上である場合、vol copy コマンド(または SnapMirror) を使用してデータをソースから宛先に転送できます。

例vol status -bVolume Block Size (bytes) Vol Size (blocks) FS Size (blocks)------ ------------------ ----------------- ---------------sourcevol 4096 4346752 4346752destvol 4096 4346752 4346752

ストレージ・システム間の関係の確認ストレージ・システム間の関係を確認できます。


ボリューム・コピー操作のソース・ボリュームと宛先ボリュームが 2 つの異なるストレージ・システムにある場合、これらのシステム間で相互の信頼関係が必要です。各ストレージ・システムをもう一方のトラステッド・ホストとして指定するには、以下のステップを実行します。


1. FilerView を使用するか、ストレージ・システムを NFS でマウントすることによって、ソース・システムの /etc/hosts.equiv ファイルに宛先システムのホスト名を入力します (まだ存在しない場合)。/etc/hosts.equiv ファイルには、それぞれ別の行に示されているホスト名のリストが含まれています。このファイルにホスト名が存在することは、システムがそのホストにリモート操作の実行を許可していることを意味します。

2. 宛先ストレージ・システムでステップ 1 を繰り返して、ソース・ストレージ・システムのホスト名を /etc/hosts.equiv ファイルに入力します (まだ存在しない場合)。

ソース・ボリュームおよび宛先ボリュームの状況の確認と変更ソース・ボリュームがオンラインであるかどうか、および宛先ボリュームが存在して制限付きであることを確認できます。また、必要に応じてボリュームの状況を変更できます。

1. 宛先ボリュームが存在して制限付きであることを確認するには、宛先ストレージ・システムで次のコマンドを入力します。vol status dest_volume

dest_volume は、状況を検査するボリュームの名前です。

ボリューム名を指定しない場合、コマンドは、ストレージ・システムのすべてのボリュームの状況を表示します。

ボリュームが存在しない場合、Data ONTAP はエラーを返します。ボリュームの作成方法については、「Data ONTAP System Administration Guide」を参照してください。

注: 宛先ボリュームはルート・ボリュームにあってはなりません。これは、Data

ONTAP が vol copy コマンドを実行するときに宛先ボリュームはオフラインになっている必要があり、一方でルート・ボリュームは常にオンラインでなければならないためです。

2. ソース・ボリュームがオンラインであることを確認するには、ソース・ストレージ・システムでステップ 1 を繰り返します。その際、dest_volume をソース・ボリュームの名前に置き換えます。

3. ステップ 1 の結果としてボリュームの状況を変更する必要が生じた場合、宛先ストレージ・システムで次のコマンドを入力します。vol restrict dest_volume

dest_volume は、宛先ボリュームの名前です。

4. ステップ 2 の結果としてボリュームの状況を変更する必要が生じた場合、ソース・ストレージ・システムで次のコマンドを入力します。vol online

source_volume source_volume は、ソース・ボリュームの名前です。

5. ステップ 3 またはステップ 4 を実行する必要がある場合、行った変更を確認するためにステップ 1 またはステップ 2 を再び実行することができます。


例systemA> vol status

Volume State Status Optionsvol0 online normal rootvol1 online normal raidsize=14vol2 online restricted

volextra offline

リモート・アクセスを使用可能にする同じストレージ・システム上のボリューム間でのボリューム・コピーを実行するには、リモート・シェル・サービスが使用可能になっている必要があります。そうでないと、ボリューム・コピーは失敗します。

リモート・シェル・サービスを使用可能にするには、次のコマンドを入力します。options rsh.enable on

ボリュームのコピーボリューム・コピー操作を生成するには、vol copy start コマンドを使用します。これにより、操作の進行状況を示す画面メッセージが生成されます。

それぞれの vol copy start コマンドは、それぞれ番号を割り当てられる次の 2 つのボリューム・コピー操作を生成します。

v 1 つの操作では、ソース・ボリュームからデータを読み取ります。vol copy コマンドによって表示される画面メッセージでは、この操作は volcopy dump 操作と呼ばれます。

v もう 1 つの操作では、宛先ボリュームにデータを書き込みます。vol copy コマンドによって表示される画面メッセージでは、この操作は volcopy restore 操作と呼ばれます。

ボリューム・コピー操作番号を使用するとき: ボリューム・コピー操作を停止したり、ボリューム・コピー操作の速度を変更する場合に、ボリューム・コピー操作番号が必要になります。ボリューム・コピー操作番号を取得する方法については、『ボリューム・コピー操作の状況の検査』セクションを参照してください。

関連タスク

312ページの『ボリューム・コピー操作の状況の検査』vol copy status コマンドを使用して、ボリューム・コピー操作の状況を検査できます。

サポートされる vol copy 操作の数Data ONTAP が vol copy start コマンドを実行できるかどうかは、vol copy start コマンドで指定されたストレージ・システムで既に進行されているボリューム・コピー操作の数によります。

ボリュームをローカルでコピーするために、4 つの同時コピー操作をサポートするストレージ・システムで次の 2 つの vol copy start コマンドを入力できます。


vol copy start vol0 vol1vol copy start vol2 vol3

これらのコマンドの進行中に追加の vol copy start コマンドを入力すると、既にシステムで 4 つのボリューム・コピー操作が実行されているため、これらのコマンドは失敗します。2 つの操作は vol0 および vol2 ボリュームを読み取るためのもので、2 つの操作は vol1 および vol3 ボリュームを書き込むためのものです。

systemA というストレージ・システムで次の 3 つの vol copy start コマンドを入力して、ボリュームを systemB という別のストレージ・システムにコピーするとします。

vol copy start vol0 systemB:vol0vol copy start vol1 systemB:vol1vol copy start vol2 systemB:vol2

これらのコマンドの進行中に、systemA はボリュームを読み取るために 3 つのボリューム・コピー操作を実行して、systemB はボリュームを書き込むために 3 つのボリューム・コピー操作を実行します。

systemA と systemB の間でコピーするための追加の vol copy start コマンドは成功します。このコマンドは、各ストレージ・システムにさらに 1 つのボリューム・コピー操作を追加するためです。

ただし、systemA または systemB のいずれかでローカルにボリュームをコピーするために追加の vol copy start コマンドを入力すると、失敗します。これは、追加のコマンドによって、ローカル・コピーを実行するストレージ・システムに 2 つのボリューム・コピー操作 (読み取りのために 1 つ、書き込みのために 1 つ) が作成されるためです。

vol copy start コマンドによる Snapshot コピーのコピー次の表に、vol copy start コマンドで使用するオプションによって異なる、ソース・ボリュームからコピーされる Snapshot コピーと、宛先ボリューム上に作成されるSnapshot コピーを示します。

オプションソース・ボリュームからコピーする Snapshot コピー

宛先ボリュームの Snapshot

ファイル・システム内のSnapshot コピー

なし Snapshot コピーはコピーされません。vol copy start コマンドを入力した後で作成された Snapshot コピーのみがコピーされます。

snapshot_for_volcopy.n という名前の Snapshot コピーが作成されます。ここで、n は、0 で始まり、vol copy 操作が作成されるたびに整数 1 ずつ増分する番号です。

-S ソース・ボリュームのSnapshot ファイル・システム内のすべての Snapshot コピーと、vol copy start コマンドを入力した後で作成されるSnapshot コピーがコピーされます。

ソース・ボリューム内のSnapshot コピーおよびsnapshot_for_volcopy.n がコピーされます。ここで、n は、0 で始まり、vol copy 操作が行われるたびに整数 1 ずつ増分する番号です。


オプションソース・ボリュームからコピーする Snapshot コピー

宛先ボリュームの Snapshot

ファイル・システム内のSnapshot コピー

-s と、それに続く Snapshot

コピーの名前指定された Snapshot コピーがコピーされます。

指定された Snapshot コピーが作成されます。

注: vol copy start -S コマンドは、コピーの進行中に作成された Snapshot コピーをコピーしません。例えば、コピーが 11:45 p.m. から翌日の 1:00 a.m. まで行われ、Data ONTAP が深夜 12 時に nightly.0 という名前の Snapshot コピーを作成する場合、Data ONTAP は nightly.0 Snapshot コピーをコピーしません。

ボリューム間でのコピー1 つのボリュームを別のボリュームにコピーするには、次のステップを実行します。

次のコマンドを入力します。vol copy start [-S | -s snapshot_name]

source_volume dest_volume

-S および -s 引数は、コピーする Snapshot コピーを指定します。source_volume および dest_volume は、ソース・ボリュームと宛先ボリュームの名前です。ボリュームが別のストレージ・システムにある場合、ボリューム名の前にシステム名とコロンを付けてください。ボリューム名の指定方法を説明する例については、次の表の「vol copy start コマンドの例」を参照してください。

注: 2 つのストレージ・システム間でコピーが行われる場合、ソースまたは宛先のいずれかのストレージ・システムで vol copy start コマンドを入力することができます。ただし、ソース・ボリュームまたは宛先ボリュームが含まれない 3 番目のストレージ・システムでコマンドを入力することはできません。

vol copy start コマンドの例

次の表に、vol copy start コマンドのいくつかの例を示します。

操作コマンド

すべての Snapshot コピーを同じストレージ・システム上の vol0 ボリュームから vol1

ボリュームにコピーする

vol copy start -S vol0 vol1

夜間 Snapshot コピーを同じストレージ・システム上の vol0 ボリュームから vol1 ボリュームにコピーする

vol copy start -s nightly.1 vol0 vol1

同じストレージ・システム上の vol1 ボリュームにコピーされる Snapshot コピーを vol0

ボリュームに作成する

vol copy start vol0 vol1

すべての Snapshot コピーを vol0 ボリュームから systemA という別のストレージ・システム上の vol1 ボリュームにコピーする

vol copy start -S vol0 systemA:vol1


vol copy start コマンドによって生成されるエラー・メッセージストレージ・システムがボリュームをコピーするための要件を満たしていない場合、vol copy start コマンドは 1 つ以上のエラー・メッセージを生成します。

次の表で、考えられるエラー・メッセージとその意味を説明します。

エラー・メッセージ意味

Permission denied. VOLCOPY: Could not

connect to system systemB

ソース・システムに、宛先ストレージ・システムにコピーするための許可がありません。

アクション: ストレージ・システムに相互の信頼関係があることを確認します。

VOLCOPY: volcopy restore: volume is

online, aborting

宛先ボリュームがオンラインです。

アクション: 宛先ボリュームをオフラインにします。

VOLCOPY: volcopy restore: volume is too

small, aborting

宛先ボリュームがソース・ボリュームより小さくなっています。

アクション: 宛先ボリュームにさらに多くのディスク・スペースを追加するか、十分な容量を持つ別の宛先ボリュームを選択します。

write: setting up STDERR broken pipe ローカル・ボリューム・コピーが開始しようとしましたが、ストレージ・システムでリモート・シェル・アクセスが使用可能になっていません。

アクション: ストレージ・システムでリモート・シェル・アクセスを使用可能にして、rsh

コマンドを受け取ることができるようにします。

LUN をコピーするためのボリューム・コピーの使用vol copy コマンドを使用して LUN をコピーすることができますが、そのためには、コピー操作の前に LUN にアクセスしているアプリケーションを静止してオフラインにする必要があります。

始める前に

ストレージ・システムで vol copy コマンドを実行する前に、ホスト・ファイル・システム・バッファーの内容をディスクに保存する必要があります。


vol copy コマンドを使用すると、データを 1 つの WAFL ボリュームから同じストレージ・システム内または別のストレージ・システムにある WAFL ボリュームにコピーすることができます。vol copy コマンドの結果として、制限付きボリュームに、コピー操作の開始時にソース・ストレージ・システムにあったのと同じデータが含まれます。


LUN を含むボリュームを同じまたは別のストレージ・システムにコピーするには、次のコマンドを入力します。vol copy start -S source:source_volume

dest:dest_volume

-S は、ソース・ボリューム内のすべての Snapshot コピーを宛先ボリュームにコピーします。ソース・ボリュームに Snapshot コピーにバッキングされた LUN がある場合は、-S オプションを使用して、Snapshot コピーが宛先ボリュームに確実にコピーされるようにする必要があります。2 つのストレージ・システム間でコピーが行われる場合、ソースまたは宛先のいずれかのストレージ・システムで vol copy start コマンドを入力することができます。ただし、ソース・ボリュームまたは宛先ボリュームが含まれない 3 番目のストレージ・システムでコマンドを入力することはできません。

vol copy start -S /vol/vol0 filerB:/vol/vol1

ボリューム・コピー操作の状況の検査vol copy status コマンドを使用して、ボリューム・コピー操作の状況を検査できます。


このコマンドは、指定されたボリューム・コピー操作の状況を表示します。操作番号を指定しない場合、コマンドは進行中のすべてのボリューム・コピー操作の状況を表示します。コマンド出力で、それぞれの操作は固有のボリューム・コピー操作番号によって区別されます。

制限: ボリューム・コピー状況を検査する際、以下の制限事項に注意してください。

v ボリューム・コピー操作をシステム・コンソールから開始する場合、コピー操作の進行中は rsh コマンドを介してのみ、vol copy status コマンドを入力できます。これは、Data ONTAPがボリュームをコピーしている間はコンソール上のシステム・プロンプトへのアクセス権がないためです。

v 2 つのストレージ・システム間でデータがコピーされている場合、いずれかのストレージ・システムへのリモート・シェル接続を使用して vol copy status コマンドを入力できます。読み取りと書き込みは 2 つの異なる操作として見なされるため、ソース・ストレージ・システムと宛先ストレージ・システムで表示される操作番号は異なります。

進行中のボリューム・コピー操作の状況を検査するには、次のステップを実行します。

次のコマンドを入力します。vol copy status [ operation_number ]

operation_number は、特定のボリューム・コピー操作です。現在のすべてのボリューム・コピー操作の状況を表示するには、operation_number を省略してください。操作には 0 から 3 の番号が付けられています。


vol copy start コマンドからの状況メッセージの例

次の例は、vol0 ボリュームを同じストレージ・システム上の vol1 にコピーするvol copy start コマンドを示しています。操作が進行中の間、ボリューム・コピー操作の状況が表示されます。

systemA>vol copy start -S vol0 vol1Copy Volume: vol0 on machine 127.0.0.1 to Volume: vol1Reading the dump streamVOLCOPY: Starting on volume 1.This dump contains 257 blocks10:04 pm : volcopy restore 1 : begun.10:04 pm : volcopy restore 1 : 5 % done. Estimate 3 minutesremaining....10:04 pm : volcopy restore 1 : 95% done. Estimate 1 minutesremaining.

rsh を使用する vol copy status コマンドの例

次の例で示すように、プロンプトが再び表示される前にストレージ・システムのトラステッド・ホストで vol copy status コマンドを使用することができます。

rsh systemA vol copy status10:04 pm : volcopy dump 0 : 99 % done. Estimate 1 minutes remaining.10:04 pm : volcopy restore 1 : 99 % done. Estimate 1 minutes remaining.No operation 2 in progress.No operation 3 in progress.

上記の例で、画面に volcopy dump 0 と示されているボリューム・コピー操作 0

は、vol0 ボリュームからデータを読み取ります。画面で volcopy restore 1 と示されているボリューム・コピー操作 1 は、vol1 ボリュームにデータを書き込みます。

ボリュームのコピーの現在速度の表示現在の設定を判別するためにボリュームをコピーする速度を表示して、設定を変更する前に速度を確認することができます。この手順により、すべてのボリューム・コピー操作のデフォルト速度を確認することができます。

ボリュームをコピーする速度を表示するには、次のコマンドを入力します。options

vol.copy.throttle 結果: すべてのボリューム・コピー操作で使用される値 10 (フルスピード) から 1 (フルスピードの 10 分の 1) が表示されます。デフォルト値は10 です。

ボリューム・コピー操作の速度の制御ボリューム・コピー操作を開始する前およびボリューム・コピー操作中に、ボリューム・コピー操作の速度を制御できます。


ソース・ボリュームからデータを読み取る速度と宛先ボリュームにデータを書き込む速度は異なる場合があります。 2 つのうち遅い方の値が、Data ONTAP がデータ


のコピーを終了するのに必要な時間を決定します。ストレージ・システムでパフォーマンス上の問題が起こる可能性があると考えられる場合、ボリューム・コピー操作の速度を変更できます。

注: vol.copy.throttle オプションを変更すると、後続のすべてのボリューム・コピー操作のデフォルト速度が変更されます。

ボリューム・コピー操作の速度を制御するには、次のステップを実行します。

ボリューム・コピーの速度を制御する場合処置

コピー操作を開始する前次のコマンドを入力します。options

vol.copy.throttle value

value は、希望の特定の速度です。

コピー操作中リモート・シェルから次のコマンドを入力します。

vol copy throttle [operation_number]

value

operation_number は、速度を調整する特定のボリューム・コピー操作です。

操作番号を指定しない場合、コマンドは進行中のすべてのボリューム・コピー操作に適用されます。

value は、希望の特定の速度です。

例

次の例では、リモート・シェルを介して、進行中のすべてのボリューム・コピー操作の速度をフルスピードの 10 分の 1 に変更します。

rsh systemA vol copy throttle 1volcopy operation 0: Throttle adjusted from 100% to 10%.volcopy operation 1: Throttle adjusted from 100% to 10%.

ボリューム・コピー操作の中止2 つのストレージ・システム間でデータがコピーされている場合、いずれかのストレージ・システムで vol copy abort コマンドを実行することによってコピーを停止できます。ボリューム・コピー操作をシステム・コンソールから開始した場合は、rsh コマンドを介してのみ、vol copy abort コマンドを入力できます。これは、コピー中にコンソール上のシステム・プロンプトへのアクセス権がないためです。

始める前に

特定のボリューム・コピー操作を中止するには、操作番号を指定する必要があります。操作番号は、vol copy status 出力で見ることができます。


ボリューム・コピー操作を中止するには、次のコマンドを入力します。vol copy

abort [all | operation_number] operation_number は、中止される特定のボリューム・コピー操作です。すべての操作を中止するには、all を指定してください。

注: ボリューム・コピー操作が不完全であるため、宛先ボリュームには使用不可のデータが残されます。


SyncMirror の管理

SyncMirror についてSyncMirrorは、Data ONTAP のオプション・フィーチャーです。 SyncMirror を使用して、従来型ボリュームに組み込まれているアグリゲートおよび FlexVol ボリュームを含むアグリゲートをミラーリングすることができます。

SyncMirror は、同じ WAFL ファイル・システムの 2 つのコピーで構成されるアグリゲートまたは従来型ボリュームを作成します。SyncMirror は、プレックスと呼ばれる 2 つのコピーを同時に更新します。そのため、コピーは常に同一です。

アグリゲートおよびボリュームについて詳しくは、「Data ONTAP ストレージ管理ガイド」を参照してください。

SyncMirror を使用する利点2 つのアグリゲートまたは従来型ボリュームの間の SyncMirror 関係は、高水準のデータ可用性を提供します。2 つのプレックスが別々のシェルフで物理的に分離され、シェルフが別々のケーブルとアダプターを使用してストレージ・システムに接続されるためです。各プレックスには、固有のスペア・ディスクの集合があります。

プレックスが物理的に分離されているため、二重ディスク・エラーまたはディスク接続の損失が発生した場合にデータ損失から保護できます。影響を受けないプレックスはデータの提供を続行し、その間に障害の原因を修正することができます。修復された後、2 つのプレックスを再同期して、ミラー関係を再確立することができます。

ミラーリングされたプレックスのもう 1 つの利点は、再ビルド時間が高速になることです。

対照的に、SnapMirror を複製のために使用するアグリゲートまたは従来型ボリュームが停止した場合、その SnapMirror パートナーは自動的にファイル提供機能を引き継ぐことができず、前回の Snapshot コピーの作成時の状態にデータを復元することしかできません (パートナーのデータを使用可能にするにはコマンドを発行する必要があります)。

SyncMirror の欠点は、ミラーリングされたアグリゲートまたは従来型ボリュームには、ミラーリング解除されたアグリゲートまたは従来型ボリュームの 2 倍の数のディスクが必要になることです。2 つのプレックスのそれぞれにディスクのフルセットが必要です。例えば、100 GB の従来型ボリュームをミラーリングするには、200

GB (ミラーリングされた従来型ボリュームの各プレックスに 100 GB) のディスク・スペースが必要です。また、1,440 GB のアグリゲートをミラーリングするには、2,880 GB のディスク・スペースが必要です。


ミラーリングされたアグリゲートおよび従来型ボリュームについてミラーリングされたアグリゲートまたは従来型ボリュームは、ディスク上に物理的に分離されて同期された 2 つの最新コピーを持つ単一の WAFL ストレージ・ファイル・システムです。これらのコピーは、プレックスと呼ばれます。Data ONTAP

は、自動的に 1 つ目のプレックスに plex0、2 つ目のプレックスに plex1 という名前を付けます。

各プレックスは、同じ WAFL ファイル・システムの物理コピーであり、1 つ以上の RAID グループで構成されます。SyncMirror は完全な WAFL ファイル・システムを複製するため、SyncMirror フィーチャーを FlexVol ボリュームで使用することはできません。アグリゲート (全体が FlexVol ボリュームで構成されるものも含む)

または従来型ボリュームのみがサポートされます。次の図は、従来型 SyncMirror 関係におけるプレックスの概念を示しています。

次の図は、アグリゲート SyncMirror 関係におけるプレックスの概念を示しています。各プレックスにはアグリゲートに含まれる FlexVol ボリュームのコピーが入っていることに注意してください。

図 22. 従来型 SyncMirror 関係のプレックス

注: ミラーリングされたボリューム vol0 に 2 つのプレックス vol0/plex0 および vol0/plex1 があります。

図 23. アグリゲート SyncMirror 関係のプレックス


ミラーリングされたボリュームを使用するための前提条件ミラーリングされたアグリゲートまたは従来型ボリュームを使用する前に、SyncMirror ライセンス、SyncMirror フィーチャーをサポートするストレージ・システム、およびディスク・シェルフの適切な構成が必要です。

以下は、ミラーリングされたアグリゲートまたは従来型ボリュームを使用するための前提条件です。

v SyncMirror フィーチャーを使用可能にする前に、SyncMirror ライセンスを使用可能にして重要な製品情報を受信する必要があります。

SyncMirror ライセンスは無償で入手可能です。

v ストレージ・システム、またはアクティブ/アクティブ構成のストレージ・システムは、SyncMirror フィーチャーをサポートしている必要があります。

注: N3700 シリーズストレージ・システムは、SyncMirror 構成をサポートしません。

v ディスク・シェルフを、ミラーリングされたボリュームをサポートする構成でストレージ・システムに接続する必要があります。

ミラーリングされたアグリゲートまたは従来型ボリュームをサポートする構成について詳しくは、「Data ONTAP Active/Active Configuration Guide」を参照してください。

さまざまなストレージ・システムでサポートされるストレージ拡張ユニットおよびその他のハードウェアについて詳しくは、IBM NAS サポート・サイトの適切なハードウェアとサービスのガイド、およびインターオペラビリティー・マトリックスを参照してください。

関連資料

98ページの『同期 SnapMirrorを使用する前の考慮事項』SnapMirror を同期複製のために使用する計画の場合、以下の点を覚えておいてください。

関連情報


ミラーリングされたボリューム・プレックスによるディスクの取得場所ミラーリングされたボリュームが作成される場合、Data ONTAP は、ディスク・プールと呼ばれるディスクの集合からスペア・ディスクを pool0 および pool1 という2 つのディスク・プールに分離します。

ディスクをプールに割り当てる際、Data ONTAP は、ディスク用のシェルフを判別して、pool0 のディスクが pool1 のディスクと異なるシェルフから取得されるようにします。そのため、SyncMirrorを使用可能にする前に、ディスクが最小 2 つのシェルフに取り付けられ、シェルフが別々のケーブルとアダプターを使用してストレージ・システムに接続されていることを確認してください。ミラーリングされたボリュームの高可用性を確保するために、ディスク・プールは物理的に離れている必要があります。

SyncMirror の管理 319


pool0 のディスクは plex0 を作成するために使用され、pool1 のディスクは plex1

を作成するために使用されます。

アクティブ/アクティブ構成のホスト・ノードのローカル側にあるプレックスは、pool0 という名前のディスク・プールに接続される必要があります。 pool0 は、スロット 3 から 7 のホスト・アダプターに接続されたストレージで構成されます。スイッチを使用する MetroCluster 構成のプールのルールは異なります。

ストレージ・システムのスロット割り当てについて詳しくは、IBM NAS サポート・サイトの適切なハードウェアとサービスのガイド、およびインターオペラビリティー・マトリックスを参照してください。

SyncMirror ライセンスを使用可能にするミラーリング機能のライセンス・コード名は syncmirror_local です。ミラーリング・ライセンスを使用可能にするには、以下のステップを行います。

1. 次のコマンドを入力します。license add xxxxxxx xxxxxxx は、購入したsyncmirror_local ライセンス・コードです。

2. システムをリブートします。

従来型ボリュームの SyncMirror ライセンスを使用不可にするミラーリングされたボリュームまたはミラーリングされたアグリゲートが存在してオンラインである場合、ミラーリング・ライセンスを使用不可にすることはできません。ミラーリング・ライセンスを使用不可にする前に、ミラーリングされたボリュームまたはミラーリングされたアグリゲートごとに 1 つのプレックスをオフラインにして、それを破棄する必要があります。

1. ミラーリングされたボリュームごとに、オフラインするプレックスを決定します。

注: ミラーリング・ライセンスを使用不可にするには、その前に、ミラーリングされたボリュームごとに 1 つのプレックスをオフラインにして破棄する必要があります。

2. 次のコマンドを入力して、オフラインにすることを決定した各プレックスをオフラインにします。vol offline plex-name plex-name は、ミラーリングされたプレックスのうちの 1 つの名前です。

注: オフラインにできるプレックスは一度に 1 つのみです。

3. 次のコマンドを入力して、オフラインにしたプレックスを破棄します。vol

destroy plex-name plex-name は、ミラーリングされた plex のうちの 1 つの名前です。

4. 次のコマンドを入力します。license delete syncmirror_local


ミラーリングされたアグリゲートの SyncMirror ライセンスを使用不可にする

ミラーリングされたボリュームまたはミラーリングされたアグリゲートが存在してオンラインである場合、ミラーリング・ライセンスを使用不可にすることはできません。ミラーリング・ライセンスを使用不可にする前に、ミラーリングされたボリュームまたはミラーリングされたアグリゲートごとに 1 つのプレックスをオフラインにして、それを破棄する必要があります。

1. ミラーリングされたアグリゲートごとに、オフラインするプレックスを決定します。

注: ミラーリング・ライセンスを使用不可にするには、その前に、ミラーリングされたアグリゲートごとに 1 つのプレックスをオフラインにして破棄する必要があります。

2. 次のコマンドを入力して、オフラインにすることを決定したプレックス内のそれぞれの FlexVol ボリュームをオフラインにします。vol offline vol-name

vol-name は、FlexVol ボリュームの名前です。

注: オフラインにできる FlexVol ボリュームは一度に 1 つのみです。

3. 次のコマンドを入力して、オフラインにすることを決定したプレックスからFlexVol ボリュームを除去します。vol destroy vol-name vol-name は、FlexVol

ボリュームの名前です。

注: オフラインにできる FlexVol ボリュームは一度に 1 つのみです。

4. 次のコマンドを入力して、オフラインにすることを決定した各プレックスをオフラインにします。aggr offline plex-name plex-name は、ミラーリングされたplex のうちの 1 つの名前です。


5. 次のコマンドを入力して、オフラインにしたプレックスを破棄します。aggr

destroy plex-name plex-name は、ミラーリングされた plex のうちの 1 つの名前です。

6. 次のコマンドを入力します。license delete syncmirror_local

ミラーリングされたアグリゲートおよび従来型ボリュームの作成以下のいずれかの方法によって、ミラーリングされたアグリゲートまたは従来型ボリュームを作成することができます。

v 2 つのプレックスを持つ新しいアグリゲートまたは従来型ボリュームを作成できます。

v ミラーリング解除された既存のアグリゲートまたは従来型ボリュームにプレックスを追加できます。

注: ミラーリングされたアグリゲートまたは従来型ボリュームは 2 つを超えるプレックスを持つことができません。

ミラーリングされたアグリゲートまたは従来型ボリュームを作成する方法に関係なく、作成したり、ディスクを追加する場合は、Data ONTAP が使用するディスクを


判別します。Data ONTAP は、ミラーリングされたアグリゲートまたは従来型ボリュームのためにディスクを選択する際、以下のポリシーを使用します。

v 各プレックス用に選択されるディスクは別々のディスク・プールのものです。

v 1 つのプレックス用に選択されるディスクの数は、もう 1 つのプレックス用に選択されるディスクの数と同じです。

v ディスクは、最初に同一のセクター当たりのバイト数 (bps) のサイズに基づいて選択され、次にディスクのサイズに基づいて選択されます。

v サイズが等しいディスクがない場合、Data ONTAP は容量が大きい方のディスクを選択してそのサイズを減らします。

注: ミラーリング解除されたボリュームを作成する場合、Data ONTAP は、使用可能なディスクが最も多いプレックスからディスクを選択します。使用するディスクを指定することによって、この選択ポリシーを指定変更できます。

Data ONTAP では、ミラーリングされたアグリゲートまたは従来型ボリュームを作成する場合、およびそれらにディスクを追加する場合にユーザーがディスクを選択することができます。ミラーリングされたアグリゲートまたは従来型ボリュームのためにディスクを選択する際、Data ONTAP が従うのと同じディスク選択ポリシーに従う必要があります。

ミラーリングされたアグリゲートまたは従来型ボリュームの作成方法に関係なく、Data ONTAP が、ミラーリングされたアグリゲートまたは従来型ボリュームに名前を付けます。

関連概念

318ページの『ミラーリングされたアグリゲートおよび従来型ボリュームについて』ミラーリングされたアグリゲートまたは従来型ボリュームは、ディスク上に物理的に分離されて同期された 2 つの最新コピーを持つ単一の WAFL ストレージ・ファイル・システムです。これらのコピーは、プレックスと呼ばれます。Data ONTAP

は、自動的に 1 つ目のプレックスに plex0、2 つ目のプレックスに plex1 という名前を付けます。

関連資料

324ページの『ミラーリングされたボリュームの作成方法』以下のいずれかの方法によって、ミラーリングされたアグリゲートまたは従来型ボリュームを作成することができます。

328ページの『既存のミラーリング解除されたアグリゲートまたは従来型ボリュームへのプレックスの追加』以下のいずれかの方法により、既存のミラーリング解除されたアグリゲートまたは従来型ボリュームにプレックスを追加することができます。

プレックスおよびディスク・プールの表示プレックス内のディスクまたはディスク・プール内のスペア・ディスクを表示すると、ディスクをプレックスに追加するときや、プレックスによって使用されているディスク・プールを識別する際に役立ちます。

以下のコマンドのいずれかを入力します。 sysconfig -r

または


aggr status -r

またはvol status -r この例では、aggr status -r コマンドを使用して、プレックス内のディスクおよびディスク・プール内のスペア・ディスクを表示します。

system1> aggr status -r

Aggregate vol0 (online, raid4) (block checksums)Plex /vol0/plex0 (online, normal, active, pool1)RAID group /vol0/plex0/rg0 (normal)

RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---parity 9a.16 9a 1 0 FC:A 1 FCAL 10000 34000/69632000 34data 9a.17 9a 1 1 FC:A 1 FCAL 10000 600/1228800 76data 9a.20 9a 1 4 FC:A 1 FCAL 10000 34000/69632000 34

Aggregate GreG (online, raid4) (block checksums)Plex /GreG/plex0 (online, normal, active, pool1)RAID group /GreG/plex0/rg0 (normal)

RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---parity 9a.18 9a 1 2 FC:A 1 FCAL 10000 34000/69632000 34data 9a.19 9a 1 3 FC:A 1 FCAL 10000 34000/69632000 34

Pool1 spare disks

RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---Spare disks for block or zoned checksum traditional volumes or aggregatesspare 9a.24 9a 1 8 FC:A 1 FCAL 10000 34000/69632000 34spare 9a.29 9a 1 13 FC:A 1 FCAL 10000 34000/69632000 34

Pool0 spare disks (empty)

Partner disks

RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---partner 9b.25 9b 1 9 FC:B 1 FCAL 10000 0/0 34partner 9b.16 9b 1 0 FC:B 1 FCAL 10000 0/0 34partner 9b.17 9b 1 1 FC:B 1 FCAL 10000 0/0 34partner 9b.21 9b 1 5 FC:B 1 FCAL 10000 0/0 34partner 9b.18 9b 1 2 FC:B 1 FCAL 10000 0/0 34partner 9b.22 9b 1 6 FC:B 1 FCAL 10000 0/0 34

tpubs-cf1>

この例では、vol status -r コマンドを使用して、プレックス内のディスクおよびディスク・プール内のスペア・ディスクを表示します。


system1> vol status -r

Volume vol0 (online, raid4) (block checksums)Plex /vol0/plex0 (online, normal, active, pool1)

RAID group /vol0/plex0/rg0 (normal)

RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---parity 9a.16 9a 1 0 FC:A 1 FCAL 10000 34000/69632000 34data 9a.17 9a 1 1 FC:A 1 FCAL 10000 600/1228800 76data 9a.20 9a 1 4 FC:A 1 FCAL 10000 34000/69632000 34

Aggregate aggrz (online, raid4) (block checksums)Plex /aggrz/plex0 (online, normal, active, pool1)

RAID group /aggrz/plex0/rg0 (normal)

RAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---parity 9a.25 9a 1 9 FC:A 1 FCAL 10000 34000/69632000 34data 9a.26 9a 1 10 FC:A 1 FCAL 10000 34000/69632000 34data 9a.27 9a 1 11 FC:A 1 FCAL 10000 34000/69632000 34data 9a.28 9a 1 12 FC:A 1 FCAL 10000 34000/69632000 34

Pool1 spare disksRAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---Spare disks for block or zoned checksum traditional volumes or aggregatesspare 9a.24 9a 1 8 FC:A 1 FCAL 10000 34000/69632000 34spare 9a.29 9a 1 13 FC:A 1 FCAL 10000 34000/69632000 34

Pool0 spare disks (empty)

Partner disksRAID Disk Device HA SHELF BAY CHAN Pool Type RPM Used (MB/blks) Ph)--------- ------ ------------- ---- ---- ---- ----- -------------- ---partner 9b.25 9b 1 9 FC:B 1 FCAL 10000 0/0 34partner 9b.16 9b 1 0 FC:B 1 FCAL 10000 0/0 34partner 9b.17 9b 1 1 FC:B 1 FCAL 10000 0/0 34partner 9b.21 9b 1 5 FC:B 1 FCAL 10000 0/0 34partner 9b.18 9b 1 2 FC:B 1 FCAL 10000 0/0 34partner 9b.22 9b 1 6 FC:B 1 FCAL 10000 0/0 34partner 9b.23 9b 1 7 FC:B 1 FCAL 10000 0/0 34

関連資料

『ミラーリングされたボリュームの作成方法』以下のいずれかの方法によって、ミラーリングされたアグリゲートまたは従来型ボリュームを作成することができます。


ミラーリングされたボリュームの作成方法以下のいずれかの方法によって、ミラーリングされたアグリゲートまたは従来型ボリュームを作成することができます。

v Data ONTAP に、アグリゲートまたは従来型ボリュームのミラーリングに使用するディスクを選択させます。

v ユーザーが、アグリゲートまたは従来型ボリュームのミラーリングに使用するディスクを選択できます。

v Data ONTAP が使用するディスクをプレビューします。その後、表示された選択内容を使用するか、ディスクの選択を変更することができます。


Data ONTAP がディスクを選択する場合のミラーリングされたアグリゲートまたは従来型ボリュームの作成

使用されるディスクを Data ONTAP に選択させてミラーリングされたアグリゲートまたは従来型ボリュームを作成するには、以下のステップを実行します。

次のコマンドを入力します。{ aggr | vol } create { aggrname | volname } -m

ndisks[@disk-size] aggrname は、新しいアグリゲートの名前です。volname は、新しい従来型ボリュームの名前です (/vol/ 接頭部を除きます)。-m は、Data ONTAP に対してミラーリングされたアグリゲートまたは従来型ボリュームを指定します。ndisks は、使用するディスクの数です。最小 4 で、偶数でなければなりません。ndisks によって指定されるディスクの半分が 1 つのディスク・プールから 1 つのプレックスに割り当てられ、残りの半分が別のディスク・プールからもう 1 つのプレックスに割り当てられるため、偶数であることが必要です。disk-size は、ディスク容量をギガバイト単位で示します。このオプションを使用する場合、このサイズのディスクが両方のディスク・プールで使用可能でなければなりません。

注: disk-size オプションを使用する場合、最初に vol status -r コマンドを使用してディスク・プール内のスペア・ディスクのサイズを判別してください。次のコマンドは、2 つのプレックスで構成され、それぞれのプレックスに 3 個のディスクが含まれるミラーリングされたアグリゲートを作成します。aggr create

aggrA -m 6

ユーザーがディスクを選択する場合のミラーリングされたアグリゲートの作成

始める前に

ミラーリングされたアグリゲートの作成に使用されるディスクを選択する場合、各プールから正しい数とサイズのディスクを選択してください。

ユーザーが選択するディスクを使用してミラーリングされたアグリゲートを作成するには、次のコマンドを入力します。aggr create aggrname -m -d disk-list -d

disk-list aggrname は、ミラーリングするアグリゲートの名前です。-m は、Data ONTAP に対してミラーリングされたアグリゲートを指定します。disk-list は、複数の使用可能なディスクのディスク ID で構成されます。複数のディスクはスペース文字で区切ります。両方の -d オプションを、それぞれのプレックスに 1 つずつ使用する必要があります。

注: -d オプションを使用して 1 つのディスク・セットのみを指定すると失敗します。次のコマンドによって、1 つのプレックスのディスク 6.1 および 6.2、もう 1 つのプレックスのディスク 8.1 および 8.2 が含まれる aggrA というミラーリングされたアグリゲートを作成します。aggr create aggrA -m -d 6.1 6.2 -d 8.1 8.2


ユーザーがディスクを選択する場合のミラーリングされた従来型ボリュームの作成

始める前に

ミラーリングされた従来型ボリュームを作成するために使用されるディスクを選択する場合、各プールから正しい数とサイズのディスクを選択する必要があります。

ユーザーが選択するディスクを使用してミラーリングされた従来型ボリュームを作成するには、次のコマンドを入力します。vol create volname -m -d disk-list -d

disk-list volname は、ミラーリングするボリュームの名前です (/vol/prefix を除きます)。-m は、Data ONTAP に対してミラーリングされたボリュームを指定します。disk-list は、複数の使用可能なディスクのディスク ID で構成されます。複数のディスクはスペース文字で区切ります。両方の -d オプションを、それぞれのプレックスに 1 つずつ使用する必要があります。

注: -d オプションを使用して 1 つのディスク・セットのみを指定すると失敗します。この例では、次のコマンドによって、1 つのプレックスのディスク 6.1 および6.2、もう 1 つのプレックスのディスク 8.1 および 8.2 が含まれる vol A というミラーリングされたボリュームを作成します。

vol create volA -m -d 6.1 6.2 -d 8.1 8.2

ユーザーが Data ONTAP の支援によってディスクを選択する場合のミラーリングされたアグリゲートの作成

Data ONTAP がミラーリングされたアグリゲートを作成する場合に選択するディスクをプレビューすることができます。

1. 次のコマンドを入力します。aggr create aggrname -n -m ndisks[@disk-size]

aggrname は、作成するミラーリングされたボリュームの名前です。

-n は、Data ONTAP に対して、ミラーリングされたボリュームを作成せずに、ミラーリングされたボリュームを作成する場合に使用するディスクを表示するように指示します。

-m は、Data ONTAP に対してミラーリングされたアグリゲートを指定します。

ndisks は、使用するディスクの数です。ndisks は、偶数でなければなりません。

disk-size は、ディスク容量をギガバイト単位で示します。指定するサイズの使用可能なディスクが十分にある必要があります。 Data ONTAP は、ディスクを指定する aggr create コマンドを返します。

2. 必要に応じて、以下の選択項目のいずれかを使用します。

状況処置

Data ONTAP によって指定されたディスクを使用する

プロンプトが表示されたら、指定された aggr

create コマンドを入力します。


状況処置

Data ONTAP によって指定された 1 つ以上のディスクを他のディスクに置換する

プロンプトが表示されたら、aggr create コマンドを入力して、指定された 1 つ以上のディスクを他のディスクに置換します。

次のコマンドでは、Data ONTAP が 4 個のディスクで構成される aggrB というミラーリングされたアグリゲートを作成する場合に使用するコマンドをプレビューします。

aggr create aggrB -n -m 4

Data ONTAP は、次のコマンドを返します。

aggr create aggrB -m -d 5.1 5.3 -d 8.3 8.4

ユーザーが Data ONTAP の支援によってディスクを選択する場合のミラーリングされた従来型ボリュームの作成

Data ONTAP がミラーリングされた従来型ボリュームを作成する場合に選択するディスクをプレビューすることができます。

1. 次のコマンドを入力します。vol create volname -n -m ndisks[@disk-size]

volname は、作成するミラーリングされたボリュームの名前です (/vol/ 接頭部を除きます)。

-n は、Data ONTAP に対して、ミラーリングされたボリュームを作成せずに、ミラーリングされたボリュームを作成する場合に使用するディスクを表示するように指示します。

-m は、Data ONTAP に対してミラーリングされたボリュームを指定します。

ndisks は、使用するディスクの数です。ndisks は、偶数でなければなりません。

disk-size は、ディスク容量をギガバイト単位で示します。指定するサイズの使用可能なディスクが十分にある必要があります。 Data ONTAP は、ディスクを指定する vol create コマンドを返します。

2. 必要に応じて、以下の選択項目のいずれかを使用します。

状況処置


プロンプトが表示されたら、指定された vol

create コマンドを入力します。


プロンプトが表示されたら、vol create コマンドを入力して、指定された 1 つ以上のディスクを他のディスクに置換します。

次のコマンドでは、Data ONTAP が 4 個のディスクで構成される volB というミラーリングされたボリュームを作成する場合に使用するコマンドをプレビューします。

vol create volB -n -m 4


Data ONTAP は、次のコマンドを返します。

vol create volB -m -d 5.1 5.3 -d 8.3 8.4

既存のミラーリング解除されたアグリゲートまたは従来型ボリュームへのプレックスの追加

以下のいずれかの方法により、既存のミラーリング解除されたアグリゲートまたは従来型ボリュームにプレックスを追加することができます。

v Data ONTAP に、ボリュームのミラーリングに使用するディスクを選択させます。

v ユーザー自身が、アグリゲートまたは従来型ボリュームのミラーリングに使用するディスクを選択します。

v Data ONTAP が使用するディスクをプレビューして、それらのディスクを使用するか、1 つ以上のディスクをユーザーが選択するディスクに置き換えます。

注: ミラーリングするミラーリング解除されたボリュームが異なる容量のディスクを使用する場合、Data ONTAP は、最も小さい容量と一致するディスクを別のディスク・プールから選択できます。ディスク・プールにその容量のディスクが十分にない場合、Data ONTAP は、それよりも大きな容量のディスクを選択してそのサイズを減らします。

関連資料

321ページの『ミラーリングされたアグリゲートおよび従来型ボリュームの作成』以下のいずれかの方法によって、ミラーリングされたアグリゲートまたは従来型ボリュームを作成することができます。

324ページの『ミラーリングされたボリュームの作成方法』以下のいずれかの方法によって、ミラーリングされたアグリゲートまたは従来型ボリュームを作成することができます。

Data ONTAP がディスクを選択する場合のアグリゲートまたは従来型ボリュームへのプレックスの追加

Data ONTAP にディスクを選択させるのは最も簡単なミラーリングの方法ですが、Data ONTAP によってどのディスクが選択されるかを制御することはできません。

ボリュームのミラーリングに使用されるディスクを Data ONTAP に選択させて、アグリゲートまたは従来型ボリュームをミラーリングするには、次のコマンドを入力します。{ aggr | vol } mirror { aggrname | volname } aggrname は、ミラーリングするアグリゲートの名前です。volname は、ミラーリングする従来型ボリュームの名前です (/vol/ prefix を除きます)。

ユーザーがディスクを選択する場合のアグリゲートまたは従来型ボリュームへのプレックスの追加

ボリュームをミラーリングするために使用されるディスクを選択する場合、正しい数とサイズのディスクを選択する必要があります。これらのディスクは、ミラーリ


ングするアグリゲートまたは従来型ボリュームのプレックスによって使用されているのとは異なるプールから選択する必要があります。

ユーザーが選択するディスクを使用してアグリゲートまたは従来型ボリュームをミラーリングするには、次のコマンドを入力します。{ aggr | vol } mirror {

aggrname | volname } -d disk-list aggrname は、ミラーリングするアグリゲートの名前です。volname は、ミラーリングする従来型ボリュームの名前です (/vol/ 接頭部を除きます)。disk-list は、1 つ以上の使用可能なディスクのディスク ID で構成されます。複数のディスクはスペース文字で区切ります。

ユーザーが Data ONTAP の支援によってディスクを選択する場合のアグリゲートまたは従来型ボリュームへのプレックスの追加

Data ONTAP がアグリゲートまたは従来型ボリュームをミラーリングする場合に選択するディスクをプレビューすることができます。

1. Data ONTAP が使用するディスクをコマンド例の形式でプレビューして、既存のアグリゲートまたは従来型ボリュームをミラーリングするには、次のコマンドを入力します。{ aggr | vol } mirror { aggrname | volname } -n aggrname

は、ミラーリングするアグリゲートの名前です。

volname は、ミラーリングする従来型ボリュームの名前です (/vol/prefix を除きます)。

-n は、Data ONTAP に対して、ミラーリングされたアグリゲートまたは従来型ボリュームを作成せずに、ミラーリングされたアグリゲートまたは従来型ボリュームを作成する場合に使用するディスクを表示するように指示します。 Data

ONTAP は、アグリゲートまたは従来型ボリュームをミラーリングするために使用できるディスクの必要な数とタイプを指定する aggr mirror コマンドまたはvol mirror コマンドを返します。

2.

状況処置


指定された aggr mirror コマンドまたは vol

mirror コマンドを入力します。


aggr mirror コマンドまたは vol mirror コマンドを入力して、指定された 1 つ以上のディスクを他のディスクに置換します。

次のコマンドを使用して、Data ONTAP がアグリゲート aggrA をミラーリングする場合に使用するディスクをプレビューします。aggr mirror aggrA -n

Data ONTAP は、次のコマンドを返します。aggr mirror aggrA -d 8.1 8.2 8.3

次のコマンドを使用して、Data ONTAP が従来型ボリュームの volA をミラーリングする場合に使用するディスクをプレビューします。vol mirror volA -n

Data ONTAP は、次のコマンドを返します。vol mirror volA -d 8.1 8.2 8.3


ミラーリングされたアグリゲートまたは従来型ボリュームへのディスクの追加

以下のいずれかの方法により、ミラーリングされたアグリゲートまたは従来型ボリュームにディスクを追加できます。

v Data ONTAP にディスクを選択させます。

v ユーザー自身がディスクを選択します。

v Data ONTAP が使用するディスクをプレビューして、それらのディスクを使用するか、1 つ以上のディスクをユーザーが選択するディスクに置き換えます。

ミラーリングされたアグリゲートまたは従来型ボリュームにディスクを追加する際に従うルール

ミラーリングされたアグリゲートまたは従来型ボリュームにディスクを追加する場合、以下のルールに従う必要があります。

v ディスクの数は偶数でなければならず、ディスクは 2 つのプレックス間で均等に分割される必要があります。

v 各プレックスのディスクは別々のディスク・プールのものでなければなりません。

v 追加するディスクのセクター当たりのバイト数 (bps) のサイズは同一でなければなりません。

新しいディスクを RAID グループに追加する場合、新しいディスクの使用率は、使用されている RAID レベルによって異なります。新しいディスクのストレージ容量が RAID グループに既にあるディスクより大きい場合、容量が大きい方のディスクは RAID グループに合わせてサイズを減らされる可能性があります。

v RAID-DP: 容量が大きい方のディスクは、パリティー・ディスクのサイズまでサイズを減らされます。

v RAID-4: 容量が大きい方のディスクをパリティー・ディスクに置き換えることができます。

Data ONTAP がディスクを選択する場合のミラーリングされたボリュームへのディスクの追加

Data ONTAP が選択したディスクをミラーリングされたボリュームに追加することを選択できます。

次のコマンドを入力します。{ aggr | vol } add { aggrname | volname }

ndisks[@disk-size] aggrname は、ディスクを追加するアグリゲートの名前です。volname は、ディスクを追加する従来型ボリュームの名前です。ndisks は、使用するディスクの数です。ディスクが奇数の場合、新規ディスクの追加は失敗します。disk-size は、ディスク容量をギガバイト単位で示します。これらのディスクの半分が各ディスク・プールに入っている必要があります。

注: disk-size オプションを使用する場合、最初に aggr status -r または vol status -r

コマンドを使用してディスク・プール内のスペア・ディスクのサイズを判別してください。


ユーザーがディスクを選択する場合のミラーリングされたアグリゲートまたは従来型ボリュームへのディスクの追加

ミラーリングされたアグリゲートまたは従来型ボリュームに追加する新規ディスクを選択する場合、正しいサイズのディスクを正しい数だけ追加する必要があります。ディスクは同じチェックサム互換性を備えている必要があり、各プレックスのディスクを別々のプールに入れる必要があります。

1. 次のコマンドを入力して、使用可能なスペア・ディスクをリストします。{ aggr

| vol } status -r

2. 追加するスペア・ディスクを選択します。

3. 次のコマンドを入力します。{ aggr | vol } add { aggrname | volname } -d

disk-list -d disk-list aggrname は、ディスクを追加するアグリゲートの名前です。

volname は、ディスクを追加する従来型ボリュームの名前です (/vol/ 接頭部を除きます)。

disk-list は、1 つ以上の使用可能なディスクのディスク ID で構成されます。複数のディスクはスペース文字で区切ります。両方の -d オプションを、それぞれのプレックスに 1 つずつ使用する必要があります。Data ONTAP は、自動的にディスクを適切なプレックスに割り当てます。

注: -d オプションを使用して 1 つのディスク・セットのみを指定すると失敗します。この例では、次のコマンドを使用して、ミラーリングされたアグリゲート aggrD

の 1 つのプレックスにディスク 3.1 を追加し、もう 1 つのプレックスにディスク 8.1 を追加します。aggr add aggrD -d 6.1 -d 8.1 この例では、次のコマンドを使用して、ミラーリングされた従来型ボリューム volD の 1 つのプレックスにディスク 3.1 を追加し、もう 1 つのプレックスにディスク 8.1 を追加します。vol add volD -d 6.1 -d 8.1

関連資料

330ページの『ミラーリングされたアグリゲートまたは従来型ボリュームにディスクを追加する際に従うルール』ミラーリングされたアグリゲートまたは従来型ボリュームにディスクを追加する場合、以下のルールに従う必要があります。

ユーザーが Data ONTAP の支援によってディスクを選択する場合のミラーリングされたアグリゲートまたは従来型ボリュームへのディスクの追加

Data ONTAP が新規ディスクをミラーリングされたアグリゲートまたは従来型ボリュームに追加する場合に選択するディスクをプレビューすることができます。

1. 次のコマンドを入力します。{ aggr | vol } add { aggrname | volname } -n

ndisks[@disksize] aggrname は、ディスクを追加するミラーリングされたアグリゲートの名前です。

volname は、ディスクを追加するミラーリングされた従来型ボリュームの名前です (/vol/ 接頭部を除きます)。


ndisks は、使用するディスクの数です。ディスクが奇数の場合、新規ディスクの追加は失敗します。

disk-size は、ディスク容量をギガバイト単位で示します。これらのディスクの半分が各ディスク・プールに入っている必要があります。

注: disk-size オプションを使用する場合、最初に vol status -r コマンドを使用してディスク・プール内のスペア・ディスクのサイズを判別してください。Data ONTAP は、ミラーリングされたボリュームのそれぞれの plex に追加するディスクを指定する aggr add または vol add コマンドを返します。

2.

操作処置


指定された aggr add または vol add コマンドを入力します。


aggr add または vol add コマンドを入力して、指定された 1 つ以上のディスクを他のディスクに置換します。

この例では、次のコマンドにより、Data ONTAP が 2 つの新しい 36 GB ディスクをミラーリングされたアグリゲートの aggrA に追加する場合に使用するディスクをプレビューします。aggr add aggrA -n 2@36

Data ONTAP は、次のコマンドを返します。aggr add aggrA -d 6.4 -d 8.6 この例では、次のコマンドにより、Data ONTAP が 2 つの新しい 36 GB ディスクをミラーリングされたボリュームの volA に追加する場合に使用するディスクをプレビューします。vol add volA -n 2@36

Data ONTAP は、次のコマンドを返します。vol add volA -d 6.4 -d 8.6

プレックスの状態プレックスは、オンライン状態またはオフライン状態のいずれかになります。オンライン状態では、プレックスを読み取りまたは書き込みアクセスのために使用でき、プレックスの内容は最新状態です。オフライン状態では、プレックスを読み取りまたは書き込みのために使用できません。

オンラインのプレックスは以下の状態になります。

v アクティブ - プレックスは使用可能です。

v ディスクの追加中 - Data ONTAP がディスクを RAID グループまたはプレックスのグループに追加しています。

v 空 - プレックスは作成中のアグリゲートまたは従来型ボリュームの一部であり、Data ONTAP はディスクをプレックスに追加する前にアグリゲートまたは従来型ボリュームのターゲットとなる 1 つ以上のディスクを消去する必要があります。

v 障害 - プレックス内の 1 つ以上の RAID グループに障害が起きています。

v 非アクティブ - プレックスは使用可能ではありません。

v 正常 - プレックス内のすべての RAID グループが機能しています。

v 期限切れ - プレックスの内容が期限切れで、アグリゲートまたは従来型ボリュームのもう 1 つのプレックスで障害が起きています。


v 再同期中 - プレックスの内容がアグリゲートまたは従来型ボリュームのもう 1

つのプレックスの内容と再同期されています。

プレックスの状況の表示いつでも特定のプレックスの状況を表示することができます。プレックスの状況を表示するには、プレックスがオンラインである必要があります。

プレックスの状況を表示するには、以下のコマンドのいずれかを入力します。sysconfig -r または aggr status -r または vol status -r

プレックスの状態の変更Data ONTAP は、ミラーリングされたアグリゲートまたは従来型ボリュームの 2 つのプレックスを同期する際、プレックスの状態を再同期中として指定します。


例えば、ミラーリング解除されたアグリゲートまたは従来型ボリュームにプレックスを追加することによってミラーリングされたアグリゲートまたは従来型ボリュームを作成する場合、Data ONTAP は、追加されたプレックスを再同期中の状態にします。

Data ONTAP では、プレックスの状態をオフラインからオンラインに、およびオンラインからオフラインに変更することができます。

プレックスの状態を変更するには、次のコマンドを入力します。{ aggr | vol }

online | offline plexname

ミラーリングされたアグリゲートまたは従来型ボリュームの分割ミラーリングされたアグリゲートまたは従来型ボリュームを分割すると、2 つのプレックス間の関係が除去され、ミラーリング解除された 2 つの独立したアグリゲートまたは従来型ボリュームが作成されます。分割の後、両方のアグリゲートまたは従来型ボリュームがオンラインになります。


以下のいずれかの理由により、ミラーリングされたアグリゲートまたは従来型ボリュームを分割することがあります。

v アグリゲートまたは従来型ボリュームのミラーリングを停止する。

v ミラーリングされたアグリゲートまたは従来型ボリュームを別の場所に移動する。

v ミラーリングされたアグリゲートまたは従来型ボリュームを変更して、適用前に変更をテストする。プレックスの分割されたコピーで変更を適用およびテストしてから、変更されていない元のプレックスにそれらの変更を適用することができます。

注: ミラーリングされたアグリゲートまたは従来型ボリュームを分割する前に、実行中のアプリケーションを停止する必要はありません。


ミラーリングされたアグリゲートまたは従来型ボリュームをミラーリング解除された 2 つの独立したアグリゲートまたは従来型ボリュームに分割するには、以下のステップを実行します。

注: 分割しようとしているミラーリングされたアグリゲートまたは従来型ボリュームの両方のプレックスがオンラインかつ作動可能であることを確認します。

次のコマンドを入力します。{ aggr | vol } split plexname { aggrname |

volname } plexname は、ミラーリングされたボリュームのプレックスのうちの 1

つの名前です。aggrname は、新しいアグリゲートの名前です。volname は、新しい従来型ボリュームの名前です。この例では、次のコマンドを使用して、ミラーリングされたアグリゲートの aggr0

から plex0 を分割し、新しいアグリゲートに aggrNew という名前を付けます。aggr split aggr0/plex0 aggrNew

分割した後、ミラーリング解除された 2 つのアグリゲートの aggr0 およびaggrNew が存在することになります。この例では、次のコマンドを使用して、ミラーリングされたボリュームの vol0 からplex0 を分割して、新しいボリュームに volNew という名前を付けます。vol split

vol0/plex0 volNew

分割した後、ミラーリング解除された 2 つのボリュームの vol0 および volNew が存在することになります。

タスクの結果

分割する前は、ミラーリングされたアグリゲートまたは従来型ボリュームには plex0

および plex1 という 2 つのプレックスがあります。分割した後、ミラーリング解除された新しい名前の新しいアグリゲートまたは従来型ボリュームには plex0 という1 つのプレックスがあります。ミラーリング解除された元の名前の新しいアグリゲートまたは従来型ボリュームにも、plex0 または plex1 の 1 つのプレックスがあります。

ミラーリング解除されたアグリゲートまたは従来型ボリュームでは、アグリゲートまたは従来型ボリュームに 1 つのプレックスしかないため、プレックスの名前は重要ではありません。これらのミラーリング解除されたアグリゲートまたはボリュームのいずれかを再びミラーリングする場合、結果として作成されるプレックスの名前は常に plex0 および plex1 になります。


関連タスク

『分割されたアグリゲートまたは従来型ボリュームの再結合』強制的に分割を行ったために、分割されたアグリゲートまたは従来型ボリュームを再結合する場合があります。これが該当するケースとして、MetroCluster 構成でアクティブ/アクティブ構成をセットアップしていて、災害によってアクティブ/アクティブ構成が分断された場合が挙げられます。

336ページの『ミラーリングされたアグリゲートからのプレックスの除去』プレックスに問題がある場合、そのプレックスをミラーリングされたアグリゲートから除去することができます。

336ページの『ミラーリングされた従来型ボリュームからのプレックスの除去』プレックスに問題がある場合、そのプレックスをミラーリングされた従来型ボリュームから除去することができます。

333ページの『プレックスの状態の変更』Data ONTAP は、ミラーリングされたアグリゲートまたは従来型ボリュームの 2 つのプレックスを同期する際、プレックスの状態を再同期中として指定します。

関連資料


分割されたアグリゲートまたは従来型ボリュームの再結合強制的に分割を行ったために、分割されたアグリゲートまたは従来型ボリュームを再結合する場合があります。これが該当するケースとして、MetroCluster 構成でアクティブ/アクティブ構成をセットアップしていて、災害によってアクティブ/アクティブ構成が分断された場合が挙げられます。


分割された従来型ボリュームを再結合する場合、Data ONTAP は、1 つのボリュームから別のボリュームにデータをミラーリングして、再結合前にそのボリュームに存在したデータを破棄します。同様に、分割されたアグリゲートを再結合する場合、Data ONTAP は、1 つのアグリゲートから別のアグリゲートにデータをミラーリングして、再結合前にそのアグリゲートに存在したデータを破棄します。

1. データを保持するアグリゲートまたは従来型ボリューム、およびデータを上書きするアグリゲートまたは従来型ボリュームを決定します。

2. データを上書きするボリュームまたはアグリゲートがオンラインである場合、分割されたボリュームまたはアグリゲートごとに次のコマンドを入力してオフラインにします。{aggr | vol} offline {aggrname | volname} aggrname は、アグリゲートの名前です。

volname は、従来型ボリュームの名前です。

注: アグリゲートまたはボリュームが既にオフラインである場合はエラー・メッセージが表示されます。


3. 分割されたアグリゲートまたは従来型ボリュームごとに次のコマンドを入力して、ミラーリングされたアグリゲートまたは従来型ボリュームを再作成します。{aggr | vol} mirror {aggrname1 |volname1} -v {aggrname2 |volname2}

aggrname1 は、データを保持するアグリゲートの名前です。

volname1 は、データを保持する従来型ボリュームの名前です。

aggrname2 は、データを aggrname1 で上書きするアグリゲートの名前です。

volname2 は、データを volname1 で上書きする従来型ボリュームの名前です。

ミラーリングされたアグリゲートからのプレックスの除去プレックスに問題がある場合、そのプレックスをミラーリングされたアグリゲートから除去することができます。


プレックスの障害の原因となる二重ディスク障害が発生した場合、ミラーリングされたアグリゲートからプレックスを除去して、問題を修正し、再作成することができます。また、問題を修正できない場合は、別のディスク・セットを使用して再作成することもできます。

アグリゲートのミラーリングを停止する場合も、ミラーリングされたアグリゲートからプレックスを除去することができます。

1. 次のコマンドを入力して、オフラインにすることを決定したすべてのプレックスをオフラインにします。aggr offline plex-name plex-name は、ミラーリングされた plex のうちの 1 つの名前です。


2. 次のコマンドを入力して、オフラインにしたプレックスを破棄します。aggr

destroy plex-name

タスクの結果

プレックスをミラーリングされたアグリゲートから除去して破棄すると、アグリゲートのプレックスが 1 つのみになるため、ミラーリング解除されたアグリゲートになります。

プレックスを除去した後、Data ONTAP は、プレックスによって使用されていた良好なディスクをホット・スペア・ディスクに変換します。

ミラーリングされた従来型ボリュームからのプレックスの除去プレックスに問題がある場合、そのプレックスをミラーリングされた従来型ボリュームから除去することができます。

始める前に

除去するプレックスがオフラインであることを確認します。



プレックスの障害の原因となる二重ディスク障害が発生した場合、ミラーリングされた従来型ボリュームからプレックスを除去して、問題を修正し、再作成することができます。また、問題を修正できない場合は、別のディスク・セットを使用して再作成することもできます。

従来型ボリュームのミラーリングを停止する場合も、ミラーリングされた従来型ボリュームからプレックスを除去することができます。

ミラーリングされた従来型ボリュームからプレックスを除去するには、次のコマンドを入力します。vol destroy plexname plexname は、除去するプレックスの名前です。次のコマンドを使用して、プレックス vol0/plex1 をオフラインにした後でプレックス vol0/plex1 をミラーリングされたボリュームの vol0 から除去して破棄します。vol destroy vol0/plex1

タスクの結果

プレックスをミラーリングされた従来型ボリュームから除去して破棄すると、従来型ボリュームのプレックスが 1 つのみになるため、ミラーリング解除された従来型ボリュームになります。

プレックスを除去した後、Data ONTAP は、プレックスによって使用されていた良好なディスクをホット・スペア・ディスクに変換します。

ミラーリングされたアグリゲートまたは従来型ボリュームのプレックスの比較

ミラーリングされたアグリゲートまたは従来型ボリュームのプレックスは、ほぼ常に同期されています。そのため、ミラーリングされたアグリゲートまたは従来型ボリュームのプレックスを比較する必要はほとんどありません。

始める前に

プレックスを比較するには、その前にミラーリングされたアグリゲートまたは従来型ボリュームがオンラインになっている必要があります。


プレックスの比較は、ストレージ・システムのパフォーマンスに影響を与える可能性があります。

ミラーリングされたアグリゲートまたは従来型ボリュームの 2 つのプレックスを比較する場合、以下のいずれかのオプションを選択できます。

v Data ONTAP によってプレックスを比較し、相違部分を修正しない。これはデフォルトの動作です。

v Data ONTAP によってプレックスを比較して、検出された相違部分を修正する。相違部分を修正するには、修正するプレックスを指定します。プレックスは、plexnumber (0、1 など) として指定されます。


重要: このプロセスでは、高度な Data ONTAP コマンドを使用する場合があります。このオプションを使用して相違部分を修正する前に、技術サポートに連絡してください。

ミラーリングされたアグリゲートまたは従来型ボリュームの 2 つのプレックスを比較するには、以下のステップを実行します。

状況処置

Data ONTAP によって相違部分を修正する次のコマンドを入力します。{ aggr | vol }

verify start { aggrname | volname } {-f

plexnumber}

aggrname は、プレックスを比較している、ミラーリングされたアグリゲートの名前です。

volname は、プレックスを比較している、ミラーリングされたボリュームの名前です。注: aggrname または volname が指定されない場合、オンラインになっているすべてのミラーリングされたボリュームのプレックスが比較されます。

Data ONTAP によって相違部分を修正しない

次のコマンドを入力します。{ aggr | vol }

verify start { aggrname | volname } -n

aggrname も volname も指定されない場合、Data ONTAP は、すべてのアグリゲートまたは従来型ボリュームに対してミラーリングされたアグリゲートまたは従来型ボリュームのプレックスを比較します。

プレックス比較の停止Data ONTAP でミラーリングされたアグリゲートまたは従来型ボリュームのプレックス比較を停止する必要が生じることがあります。比較を停止する理由として、ストレージ・システムのパフォーマンスへの影響が考えられます。

Data ONTAP でプレックス比較を停止するには、次のコマンドを入力します。{

aggr | vol } verify stop { aggrname | volname }

注: aggrname または volname が指定されない場合、Data ONTAP は、すべてのアグリゲートまたは従来型ボリュームのプレックス比較を停止します。

プレックス比較の中断Data ONTAP でミラーリングされたアグリゲートまたは従来型ボリュームのプレックス比較を停止するのではなく、プレックスの比較を中断することができます。比較を再開または停止するまで、あるいはシステムをリブートするまで、比較は中断されたままになります。

プレックス比較を中断するには、次のコマンドを入力します。{ aggr | vol }

verify suspend { aggrname | volname }


注: aggrname または volname が指定されない場合、Data ONTAP は、すべてのアグリゲートまたはボリュームのプレックス比較を中断します。

プレックス比較の再開プレックス比較を中断した後、比較を再開または停止するまで、あるいはシステムをリブートするまで、比較は中断されたままになります。

中断されたプレックス比較を再開するには、次のコマンドを入力します。{ aggr |

vol } vol verify resume { aggrname | volname }

注: aggrname または volname が指定されない場合、Data ONTAP は、すべてのアグリゲートまたはボリュームのプレックス比較を再開します。

プレックス比較の状況の表示プレックス比較状況は、プレックス比較が完了したパーセント、およびミラーリングされたアグリゲートまたは従来型ボリュームのプレックス比較が中断されているかどうかを示します。

プレックス比較の状況を表示するには、次のコマンドを入力します。{ aggr | vol

} verify status { aggrname | volname }

注: aggrname または volname が指定されない場合、Data ONTAP は、現在プレックスが比較されているすべてのアグリゲートまたはボリュームの状況を表示します。


NVFAIL を使用したデータベース保護

次に、Data ONTAP が nvfail オプションを使用して提供するデータベース保護について説明します。

nvfail オプションを使用すると、ブート時またはアクティブ/アクティブ・フェイルオーバー構成でのテークオーバー時に、Data ONTAP は不揮発性 RAM (NVRAM)

の不整合を検出できます。この機能を使用して、データベースの妥当性を損なうNVRAM の問題をデータベース管理者に知らせることができます。 Data ONTAP

が何らかの問題を検出すると、データベース・インスタンスは応答を停止するかシャットダウンし、Data ONTAP はデータベースの状態を確認するように警告するエラー・メッセージをコンソールに送信します。

NVFAIL によるデータベース・ファイルの保護ブート時またはフェイルオーバー構成でのテークオーバー時に、Data ONTAP は、NVRAM エラーがない場合はファイル・サービスを正常に開始して、NVRAM エラーが検出された場合はデータベース・インスタンスの応答を停止します。

nvfail オプションを使用可能にすると、以下のいずれかのプロセスがブート時に行われます。

条件プロセス

Data ONTAP が NVRAM エラーを検出しない場合

ファイル・サービスは正常に開始します。

Data ONTAP が NVRAM エラーを検出して、オプションの nvfail_rename ファイルを使用する場合

1. Data ONTAP は、データベースへのアクセスを試行している NFS クライアントに失効ファイル・ハンドル (ESTALE) エラーを返します。これにより、アプリケーションは応答を停止して、異常終了するか、シャットダウンします。Data ONTAP

は、その後でシステム・コンソールおよびログ・ファイルにエラー・メッセージを送信します。

2. Data ONTAP は、nvfail_rename ファイルで指定されている元のデータベース・ファイル名に .nvfail を付加してファイルを名前変更し、それらのファイルを CIFS

および NFS の両方のクライアントで使用できないようにします。


条件プロセス

Data ONTAP が NVRAM エラーを検出して、オプションの nvfail_rename ファイルを使用しない場合

1. Data ONTAP は、データベースへのアクセスを試行している NFS クライアントに失効ファイル・ハンドル (ESTALE) エラーを返します。これにより、アプリケーションは応答を停止して、異常終了するか、シャットダウンします。Data ONTAP

は、その後でシステム・コンソールおよびログ・ファイルにエラー・メッセージを送信します。

2. データベース・ファイルは名前変更されません。アプリケーションが再始動すると、ファイルは有効性を検証されない場合でも CIFS クライアントで使用可能になります。NFS クライアントの場合、ファイル・システムが再マウントされるまでファイルはアクセス不能なままです。

Data ONTAP が LUN を含むボリュームでNVRAM エラーを検出して、オプションのnvfail_rename ファイルを使用する場合

1. Data ONTAP は、NVRAM エラーが起こったボリュームの LUN をオフラインにします。

2. Data ONTAP は、それらの LUN のiSCSI または FCP 経由のエクスポートを停止します。

3. Data ONTAP は、Data ONTAP が LUN

をオフラインにしたこと、または NFS ファイル・ハンドルが失効していることを示すエラー・メッセージをシステム・コンソールおよびログ・ファイルに送信します (LUN が NAS プロトコルを介してアクセスされる場合に有用です)。

4. Data ONTAP は、nvfail_rename ファイルで指定されている元の LUN 名に .nvfail

を付加して LUN を名前変更します。


条件プロセス

Data ONTAP が LUN を含むボリュームでNVRAM エラーを検出して、オプションのnvfail_rename ファイルを使用しない場合

1. Data ONTAP は、NVRAM エラーが起こったボリュームの LUN をオフラインにします。

2. Data ONTAP は、それらの LUN のiSCSI または FCP 経由のエクスポートを停止します。

3. Data ONTAP は、Data ONTAP が LUN

をオフラインにしたこと、または NFS ファイル・ハンドルが失効していることを示すエラー・メッセージをシステム・コンソールおよびログ・ファイルに送信します (LUN が NAS プロトコルを介してアクセスされる場合に有用です)。

4. データベース・ファイルは名前変更されません。アプリケーションが再始動すると、ファイルは有効性を検証されない場合でも CIFS クライアントで使用可能になります。NFS クライアントの場合、ファイル・システムが再マウントされるまでファイルはアクセス不能なままです。

データベース・ファイル保護を使用可能にするData ONTAP が NVRAM の問題を検出して、データベース・インスタンスの応答を停止するかシャットダウンし、データベース管理者にデータベースの状態を確認するように警告するエラー・メッセージをコンソールに送信するために構成するには、vol options コマンドの nvfail オプションを使用します。nvfail オプションは、ブート時またはアクティブ/アクティブ構成のフェイルオーバーでのテークオーバー時に NVRAM の不整合を検出します。

次のコマンドを入力します。vol options volume_name nvfail [on|off]

volume_name は、ボリュームの名前です。保護を使用可能にするには on を使用して、使用不可にするには off を使用します。デフォルト設定は off です。

データベース・ファイル検証の手順の参照先データベース・ファイルの妥当性を検査する手順については、ご使用のデータベース・ソフトウェアの資料を参照してください。

追加のデータベース・ファイル保護の追加nvfail オプションを使用してデータベース・ファイルおよび LUN を保護するほか、Data ONTAP で保護するデータベース・ファイルおよび LUN を名前変更することができます。データベース・ファイルおよび LUN を名前変更すると、データベースの自動的な再始動を防止でき、クライアントがファイルにアクセスする前にファイルに不整合がないかどうか調べることができます。

NVFAIL を使用したデータベース保護 343

始める前に

nvfail オプションを使用可能にします。


Data ONTAP は、保護するファイルの名前を入れる /etc/nvfail_rename というファイルを要求します。

1. エディターを使用して、ストレージ・システム’s /etc ディレクトリーにnvfail_rename ファイルを作成するか、ファイルを変更します。

2. 保護するデータベース・ファイルのパス名とファイル名を、nvfail_rename ファイル内で 1 行に 1 ファイルずつリストします。任意の数のファイルをリストできます。 /vol/vol1/home/dbs/oracle-WG73.dbf

3. このファイルを保存します。

次のタスク

データベース・ファイルの妥当性を調べる手順については、ご使用の特定のデータベース・ソフトウェアの資料を参照してください。

データベースで LUN が使用されている場合、NVRAM 障害の後で LUN をホストからアクセス可能にするステップを検討してください。

関連タスク

『NVRAM 障害の後で LUN をホストからアクセス可能にする』NVRAM 障害の後、ホストは LUN 上のデータにアクセスできなくなります。データベースが LUN にアクセスするには、その前にいくつかのアクションを実行する必要があります。

NVRAM 障害の後で LUN をホストからアクセス可能にするNVRAM 障害の後、ホストは LUN 上のデータにアクセスできなくなります。データベースが LUN にアクセスするには、その前にいくつかのアクションを実行する必要があります。

1. LUN を調べて、データ不整合がある場合は解決します。

2. /etc/nvfail_rename ファイルを使用して LUN を名前変更した場合、lun move

コマンドを使用して LUN を名前変更することによって .nvfail 拡張子を除去します。

3. LUN をオンラインにします。

4. それぞれの LUN を手動でイニシエーターにエクスポートします。


SnapValidator を使用したデータベース保護

次に、Data ONTAP が SnapValidator を使用して Oracle データベースを保護する方法を説明します。

SnapValidator が検査する内容SnapValidator ソフトウェアは Oracle H.A.R.D. 検査を実装しており、無効な Oracle

データをストレージ・システムへの書き込み前に検出してリジェクトします。

SnapValidator は、次に示す Oracle H.A.R.D の妥当性検査を実装しています。

v 破損したデータ・ファイル・ブロックの書き込みを検査します。この検査には、チェックサム値、およびブロック内の選択したフィールドの妥当性検査が含まれます。

v 破損した再実行ログ・ブロックの書き込みを検査します。この検査には、チェックサム値、およびブロック内の選択したフィールドの妥当性検査が含まれます。

v 破損した制御ファイル・ブロックの書き込みを検査します。この検査には、チェックサム値、およびブロック内の選択したフィールドの妥当性検査が含まれます。

v Oracle データの書き込み内容が、ターゲット・デバイスの有効な Oracle ブロック・サイズの倍数であるかどうか検査します。

注: SnapValidator は、Snapshot テクノロジーをベースとしていません。

サポートされるプロトコル

SnapValidator 検査は、次のプロトコルの場合にサポートされています。

v ファイルへの NFS プロトコルによるアクセス

v LUN への FCP または iSCSI プロトコルによるアクセス

Data ONTAP ソフトウェアをアップグレードする際、または前のバージョンに戻す際に設定される SnapValidator 検査の状態

Data ONTAP ソフトウェアをアップグレードする際、または前のバージョンに戻す際に、Data ONTAP は SnapValidator のオプションを既知の状態にします。

Data ONTAP 7.0 より前のリリースから Data ONTAP 7.0 以上にアップグレードする際には、すべてのボリューム上で SnapValidator のすべてのオプションが使用不可に設定されます。LUN のオフセット属性 (svo_offset オプション) も使用不可になります。

Data ONTAP の前のバージョンに戻す際には、すべてのボリューム上でSnapValidator のすべてのオプションが使用不可に設定されます。LUN オフセットの値は保存されますが、Data ONTAP の旧バージョンではこの値が適用されません。


SnapValidator 用のデータベースの準備SnapValidator を使用して Oracle データベースを保護する前に、実稼働環境の中断を避けるために、テスト環境で SnapValidator 検査用にデータベースを準備する必要があります。

1. 実稼働環境ではなく、必ずテスト環境で作業してください。

2. Oracle データ・ファイルまたは LUN が単一ボリューム内にあることを確認してください。

3. Oracle データと同じボリュームに次のタイプのファイルをプルしていないことを確認してください。

v Oracle 構成ファイル

v Oracle 所有でないファイルまたは LUN (例えば、スクリプトまたはテキスト・ファイル)

v Oracle ソフトウェア

既存のデータベースの場合、構成ファイルおよびその他の Oracle 以外のデータを別の仮想ボリュームに移動する必要があります。

4. 新しい LUN を Oracle データ用に使用していて、LUN が Windows 以外のホストによってアクセスされている場合、LUN マルチプロトコル・タイプ(ostype) を適切なホスト・オペレーティング・システム(solaris、hpux、aix、linux、netware、または vmware) に設定します。LUN がWindows ホストによってアクセスされている場合、ostype は、ご使用のWindows のバージョンが GPT パーティション方式を使用するかどうかに応じて、windows または windows_gpt でなければなりません。既存のデータベース内の LUN は、ostype に関係なく使用できます。 LUN マルチプロトコル・タイプについて詳しくは、「Data ONTAP ブロック・アクセス管理ガイド (iSCSI

および FC 用)」を参照してください。

5. Oracle アプリケーション・サーバーを稼働するホストで Oracle H.A.R.D. 検査が使用可能になっていることを確認します (init.ora ファイルのdb_block_checksum 値が true に設定されています)。

6. SnapValidator をライセンス交付してから使用可能にして、SnapValidator 検査を実施します。

7. 次のコマンドを入力して、SnapValidator がすべての無効な操作に関してすべてのエラーをストレージ・システム・コンソールに記録するように設定します。vol options volume-name svo_reject_errors off

8. データをストレージ・システムに書き込むことによって、環境をテストします。

9. 次のコマンドを入力して、SnapValidator が無効な操作を拒否してエラーをホストに返し、すべての無効な操作に関してエラーをストレージ・システム・コンソールに記録するように設定します。vol options volume-name

svo_reject_errors on

10. データベースを実動状態にします。


関連タスク

『SnapValidator のライセンス交付』SnapValidator を使用するには、その前にライセンスをストレージ・システムにインストールする必要があります。

『ボリュームに対する SnapValidator 検査を使用可能にする』SnapValidator 検査をボリューム・レベルで使用可能にします。

SnapValidator 検査の実施Oracle Hardware Assistant Resilient Data (H.A.R.D.) 検査を実施して、無効な Oracle

データをストレージ・システムへの書き込み前に検出して拒否することにより、ストレージ・システムに保管されている新しい Oracle データベースを保護できます。

SnapValidator のライセンス交付SnapValidator を使用するには、その前にライセンスをストレージ・システムにインストールする必要があります。

始める前に

SnapValidator ライセンスの購入時に受け取ったライセンス・コードがあることを確認します。

次のコマンドを入力します。license add license_code license_code は、SnapValidator ライセンスの購入時に受け取ったライセンス・コードです。

ボリュームに対する SnapValidator 検査を使用可能にするSnapValidator 検査をボリューム・レベルで使用可能にします。

始める前に

SnapValidator がストレージ・システムでライセンス交付されていることを確認します。

1. ストレージ・システムのコマンド行で、次のコマンドを入力して SnapValidator

を使用可能にします。vol options volume-name svo_enable on チェックサムを除き、ボリュームで SnapValidator 検査が使用可能になります。

2. 以下のステップの全部または一部を実行することによって、さらに SnapValidator

をボリューム・レベルで構成します。

v ボリュームに対するデータ・チェックサムを使用可能にする場合、次のコマンドを入力します。vol options volume-name svo_checksum on

v ボリュームに Oracle Recovery Manager (RMAN) バックアップ・データが含まれているためにブロック番号検査を使用不可にする場合は、次のコマンドを入力します。vol options volume-name svo_allow_rman on

v SnapValidator がすべての無効な操作に関してエラー・ログをホストおよびストレージ・システム・コンソールに返すように設定する場合。データベースを実動状態にする前に、SnapValidator のテスト中にこれを行う場合は、次のコマンドを入力します。vol options volume-name svo_reject_errors off

SnapValidator を使用したデータベース保護 347

このオプションを Off に設定する場合、SnapValidator は、エラーを記録するだけで、無効な操作を拒否しません。

v SnapValidator がすべての無効な操作を拒否して、エラー・ログをホストおよびストレージ・システムのコンソールに返すように設定するには、次のコマンドを入力します。vol options volume-name svo_reject_errors on

このオプションが On に設定されない場合、SnapValidator は、無効な操作を検出しますが、それらをエラーとして記録するだけです。下記に、ストレージ・システム・コンソールに表示される SnapValidator エラーの例を示します。

Thu May 20 08:57:08 GMT [filer_1: wafl.svo.checkFailed:error]:SnapValidator: Validation error Bad Block Number:: v:9r2 vol:flextest inode:98length:512 Offset: 1298432

LUN に対する SnapValidator 検査を使用可能にするデータベース LUN を含むボリュームに対して SnapValidator を使用可能にする場合は、SnapValidator が Oracle 書き込み操作と同様にディスク・ラベルまたはパーティション領域への書き込み操作を検査しないように、LUN に対してもSnapValidator 検査を使用可能にする必要があります。


オフセットを定義するには、最初にホストのオフセットを確認してから、そのオフセットをストレージ・システムに対して定義する必要があります。

Solaris ホストのディスク・オフセットの確認Solaris ホストを使用している場合、Solaris ホストのディスク・オフセットを判別します。

1. ホストで次のコマンドを入力します。prtvtoc /dev/rdsk/device_name 次の出力例は、ディスク c3t9d1s2 のパーティション・マップを示しています。

prtvtoc /dev/rdsk/c3t9d1s2* /dev/rdsk/c3t9d1s2 partition map** Dimensions:* 512 bytes/sector* 384 sectors/track* 16 tracks/cylinder* 6144 sectors/cylinder* 5462 cylinders* 5460 accessible cylinders** Flags:* 1: unmountable* 10: read-only** First Sector Last* Partition Tag Flags Sector Count Sector Mount Directory

0 0 00 0 6144 61432 5 01 0 33546240 335462396 0 00 6144 33540096 33546239

ホスト・コンソールにディスクのパーティション・マップが表示されます。


2. 使用しているパーティションの最初のセクターの値に、「Dimensions (ディメンション)」にリストされているバイト/セクター値を乗算することによって、オフセット値を得ます。ステップ 1 で示す例では、スライス 6 が使用され、ディスク・オフセットは 6144* 512 = 3145728 です。

他のホストのディスク・オフセットの確認Solaris 以外のホストを使用している場合、そのホストのディスク・オフセットを判別します。

1. 例えばロー・ボリュームをセットアップすることによって、Oracle データを保管するために LUN を準備します。

2. ホスト・コンソールで次のコマンドを入力します。dd if=/dev/zero

of=/dev/path_to_storage bs=4096 count=1 conv=notrunc path_to_storage は、ホスト上の LUN へのパスです。ホストは、ゼロの Oracle 4K ブロックをストレージ・システムに書き込みます。

3. ストレージ・システムのコンソールに表示される SnapValidator エラー・メッセージを調べます。エラー・メッセージにオフセットが表示されます。次のエラー・メッセージの例は、ディスク・オフセットが 1,048,576 バイトであることを示しています。

filerA> Thu Mar 10 16:26:01 EST [filerA:wafl.svo.checkFailed:error]:SnapValidator: Validation error Zero Data:: v:9r2 vol:test inode:3184174 length:4096Offset: 1048576

ストレージ・システム上のディスク・オフセットの定義ホスト・システムのディスク・オフセットを判別した後、ストレージ・システムのオフセットを定義します。

1. ご使用のホスト OS 用のボリューム・マネージャー・ツールを使用して、オフセットの値を得ます。オフセットの取得の詳細情報については、ご使用のボリューム・マネージャーのベンダー提供資料を参照してください。

2. ストレージ・システムのコマンド行で、次のコマンドを入力します。lun set

svo_offset lun_path offset offset はバイト単位で指定され、オプションの乗数接尾部 (c (1)、w (2)、b (512)、k (1,024)、m (k*k)、g (k*m)、t (m*m)) を指定できます。

SnapValidator を使用不可にする無効な Oracle データに対する確認が優先事項ではなくなった場合、ボリューム・レベルまたは LUN レベルでの SnapValidator 検査をオフにすることができます。

ボリュームに対して SnapValidator を使用不可にするすべての検査を使用不可にするか、ボリュームに対するすべての検査のオプションを変更する場合、SnapValidator 検査または特定の SnapValidator オプションを使用不可にします。

以下のいずれかのステップを実行します。


v ボリュームに対する SnapValidator 検査を使用不可にする場合、ストレージ・システムのコマンド行で次のコマンドを入力します。vol options volume-name

svo_enable off

SnapValidator は、ファイルまたは LUN への Oracle 書き込み操作を検査しません。各タイプの検査 (チェックサムなど) の設定は使用不可になりません。SnapValidator を再び使用可能にすると、各タイプの検査の設定が保存されます。

v 特定の SnapValidator オプションを使用不可にする場合、ストレージ・システムのコマンド行で次のコマンドを入力します。vol options volume-name option

off

option は、以下のいずれかです。

– svo_checksum ― ボリュームに対するデータ・チェックサムを使用不可にします。

– svo_allow_rman ― ボリュームに対するブロック番号検査を許可します。ボリュームに RMAN データが含まれていない場合、このオプションを使用不可にします (off に設定します)。

– svo_reject_errors ― 無効な操作を検出しますが、拒否しません。無効な操作は、エラーとして記録されるだけです。

LUN に対して SnapValidator を使用不可にする選択した LUN に無効な Oracle データがあるかどうか確認せずに、その他の LUN

に対する確認を続行する場合、個々の LUN に対する SnapValidator 検査を使用不可にします。

ストレージ・システムのコマンド行で、次のコマンドを入力します。lun set

lun_path svo_offset disable

無効データ・エラー・メッセージのトラブルシューティングSnapValidator 検査がエラー・メッセージを返す場合、他の理由を調査する前に、SnapValidator を正しく構成したことを検査してください。


Data ONTAP は、SnapValidator が次の領域で問題を検出した場合に無効データ・エラー・メッセージを送信します。

v チェックサム・エラー

v 誤ったブロック番号

v 誤ったマジック番号

v 有効なブロック・サイズがない

v ログ書き込みの無効な長さ

v ゼロのデータ

v 1 のデータ

v 書き込みの長さが有効なブロック・サイズに合わせて調整されていない

v 書き込みオフセットが有効なブロック・サイズに合わせて調整されていない


1. SnapValidator が無効データを検出または拒否したことを示すメッセージを受け取った場合、次のことを検査してください。

v データ・ファイルが入ったボリュームに対して SnapValidator 検査を使用可能にした。

v SnapValidator 検査を正しく設定した。例えば、svo_allow_rman volume オプションを on に設定した場合は、ボリュームに Oracle Recovery Manager

(RMAN) バックアップ・データが含まれていることを確認してください。このオプションが設定されていないボリュームに RMAN データを保管する場合、SnapValidator が無効データを検出したことを示すエラー・メッセージを受け取る可能性があります。

2. ストレージ・システムで SnapValidator オプションが正しく設定されているのに、上記のエラーを受け取る場合、以下の問題について検査してください。

v ホストが無効データをストレージ・システムに書き込んでいる。データベース管理者に相談して、ホスト上の Oracle 構成を検査してください。

v ネットワーク接続または構成に問題がある。システム管理者に相談して、ホストとストレージ・システムの間のネットワーク・パスを検査してください。

3. LUN への書き込み操作が失敗したことを示すメッセージを受け取った場合、LUN のディスク・オフセットを正しく設定したことを確認してください。ディスク・オフセットを確認して、LUN に対する SnapValidator 検査を使用可能にしたときに使用した手順を用いて、LUN 用に定義されたオフセットをリセットします。 SnapValidator は、LUN への書き込み操作が失敗した場合に次のような 2 つのメッセージを表示します。

v 最初のメッセージは、SnapValidator によって生成され、ストレージ・システムが無効データを検出したことを示しています。このエラー・メッセージには、LUN への絶対パスは表示されません。以下に、エラー・メッセージの例を示します。

Thu May 20 08:57:08 GMT [n5500: wafl.svo.checkFailed:error]:SnapValidator: Validation error Bad Block Number:: v:9r2vol:dbtest inode:98 length:512 Offset: 1298432

v 2 番目のエラー・メッセージは、scsitarget.write エラーであり、LUN への絶対パスを示します。以下は、特定の LUN への書き込みが失敗したことを示すエラー・メッセージの例です。

Thu May 20 14:19:00 GMT [n5500: scsitarget.write.failure:error]:Write to LUN /vol/dbtest/oracle_lun1 failed (5)

関連タスク

348ページの『LUN に対する SnapValidator 検査を使用可能にする』データベース LUN を含むボリュームに対して SnapValidator を使用可能にする場合は、SnapValidator が Oracle 書き込み操作と同様にディスク・ラベルまたはパーティション領域への書き込み操作を検査しないように、LUN に対してもSnapValidator 検査を使用可能にする必要があります。

347ページの『ボリュームに対する SnapValidator 検査を使用可能にする』SnapValidator 検査をボリューム・レベルで使用可能にします。


CIFS のウィルス保護

CIFS のウィルス・スキャンの機能Data ONTAP では、CIFS クライアントにファイルのオープンを許可する前にファイルをスキャンするために、準拠アンチウィルス・アプリケーションを実行する PC

クライアントのウィルス・スキャンを行うことができます。

CIFS ウィルス・スキャンは、ユーザーが選択する Data ONTAP 準拠アンチウィルス・アプリケーションを実行する専用 PC クライアントで行われます。ストレージ・システムで Data ONTAP を使用してウィルス・スキャン・プロセスを使用可能にすると、ウィルス・スキャン・アプリケーションがファイル・スキャン要求を送信するようにストレージ・システムに通知します。

ウィルス・スキャン・アプリケーションはストレージ・システムからの要求を監視します。指定するタイプのファイルがストレージ・システムで開かれたり、変更されるたびに、Data ONTAP は、ファイルをスキャンする要求を PC クライアントに送信します。

Data ONTAP ウィルス・スキャン・プロセスは、複数のストレージ・システムを単一の PC クライアントからスキャンすることができます (ご使用のウィルス・スキャン・アプリケーションがこの機能を実行する場合)。特定のウィルス・スキャン・アプリケーションが複数のストレージ・システムのスキャンに対応しているかどうかについて詳しくは、ご使用のウィルス・スキャン・アプリケーションの製造元にお問い合わせください。

デフォルトでスキャンされるファイル・タイプスキャンするファイル・タイプのリストを作成する前に、デフォルトでスキャンされるファイル・タイプのリストを参照してください。デフォルト・ファイル・タイプのリストには、スキャンするすべてのファイル・タイプが含まれている可能性があります。また、いくつかのファイル・タイプを追加または除去するとほぼ十分なリストになるか、アクセスを迅速化するために小さなリストを作成する場合もあります。

表 12. デフォルト・ファイル・タイプ

??_ DL? IM? OFT SMM

ARJ DOC INI OLE SWF

ASP DOT JS? OV? SYS

BAT DRV LZH PIF VBS

BIN EML MD? POT VS?

CAB EXE MPP PP? VXD

CDR GMS MPT RAR WBK

CL? GZ? MSG RTF WPD

COM HLP MSO SCR XL?


表 12. デフォルト・ファイル・タイプ (続き)

CSC HT? OCX SHS XML

注: この表の「?」文字は、すべての文字と一致するか、どの文字とも一致しないワイルドカードです。例えば、「C??」は、「C」、「CL」、「CPP」、「C++」などと一致します。

重要: すべてのファイルをスキャンするには、「???」を使用します。ただし、こうするとパフォーマンスが著しく低下するため、推奨されません。

デフォルト・リストにないファイル拡張子をスキャンしたり、デフォルトのファイル拡張子のサブセットのみをスキャンするように Data ONTAP を構成することもできます。

ウィルス・スキャンのセットアップおよび開始ストレージ・システムのファイル内のウィルスを確実に除去するために、1 つ以上のウィルス・スキャン・クライアントをセットアップします。

ウィルス・スキャン・クライアントとしての PC クライアントのセットアップ

ウィルスをスキャンするには、その前に市販の Data ONTAP 準拠ウィルス・スキャン・ソフトウェアを購入、セットアップ、および始動して、Data ONTAP ウィルス・スキャン機能を使用可能にする必要があります。

始める前に

Data ONTAP 準拠ウィルス・スキャン・ソフトウェアを入手します (まだ入手していない場合)。

1. ウィルス・スキャン・クライアントとして構成する PC クライアントのオペレーターがウィルス・スキャンを実行するストレージ・システム上で「Backup

Operators」以上として構成されていることを確認してください。

2. Data ONTAP 向けにカスタマイズされた市販のウィルス・スキャン・ソフトウェアを、ウィルス・スキャン・クライアントとして構成する PC にインストールします。ウィルス・スキャン・ソフトウェア製品に添付されている指示に従ってください。

3. PC 上のウィルス・スキャン・ソフトウェアのインストールおよび構成が完了した後、ウィルス・スキャン・クライアントとして構成された PC の IP アドレスをリストすることによって、インストールの正常終了を確認します。ストレージ・システムのコンソールで、次のコマンドを入力します。vscan scanners システムにより、このストレージ・システムのアクティブなウィルス・スキャン・クライアントの IP アドレスのリストが表示されます。

4. ウィルス・スキャン・クライアントをオンの状態でウィルス・スキャン操作を実行しているストレージ・システムまたは複数のストレージ・システムに接続されたままにします。


ストレージ・システムでウィルス・スキャンを使用可能にするウィルス・スキャン・ソフトウェアを使用する前に、Data ONTAP のウィルス・スキャン機能を開始する必要があります。

次のコマンドを入力します。vscan on [-f][on|off] -f は、ファイルをスキャンするために使用できるウィルス・スキャン・クライアントがない場合でも、強制的にウィルス・スキャンを使用可能にします。

2 次スキャン・クライアントのセットアップストレージ・システム上のファイルをスキャンするように複数のウィルス・スキャン・クライアントを構成した場合、これらの追加のクライアントを、1 次ウィルス・スキャン・クライアントが停止しない限りアクティブにウィルスをスキャンしないスタンバイ・クライアントとして指定できます。

1. このシステムでスキャンするように構成されているウィルス・スキャン・クライアントをリストします。システム・コンソールで次のコマンドを入力します。vscan scanners

>vscan scannersVirus scanners(IP and Name) P/S ...----------------------------------------132.132.59.12 ¥¥XLAB-WTS Pri ....

2. 次のコマンドを入力して、スタンバイ・ウィルス・スキャナーとして機能させるPC クライアントを IP アドレス別に指定します。vscan scanners

secondary_scanners scanner_ip[, scanner_ip...] scanner_ip は、以下のいずれかにすることができます。

v ステップ 1 で示された、1 つ以上の構成済みウィルス・スキャン・クライアントの IP アドレス

v まだウィルス・スキャン・クライアントとして構成されていない PC の IP アドレス

注: 入力した IP アドレスがまだこのストレージ・システム用のウィルス・スキャン・クライアントとして構成されていない PC に属する場合、この設定を有効にするために、この PC を構成する必要があります。

vscan scanners secondary_scanners 132.132.59.14

3. vscan scanners コマンドを使用して構成を確認します。

>vscan scannersVirus scanners(IP and Name) P/S ...----------------------------------------132.132.59.14 ¥¥BORIS-PC Sec ...132.132.59.12 ¥¥XLAB-WTS Pri ....

Secondary scanners IP address list132.132.59.14,10.20.30.40

注: この例で、アドレス 10.20.30.40 は、スタンバイ・スキャナーとして使用可能になっているがオンになっていない PC のものです。そのため、「Virus

scanners (IP and Name) (ウィルス・スキャナー (IP および名前))」テーブルには

CIFS のウィルス保護 355

リストされず、「Secondary scanners IP address list (2 次スキャナーの IP アドレス・リスト)」にリストされています。

IBM ストレージ・システムの McAfee スキャン検出プロパティーのセットアップ

AV スキャナーは Data ONTAP を実行するストレージ・システムに正常に登録されますが、スキャナーはストレージ・システムの共有をスキャンしません。


Data ONTAP 7.1 以降を搭載した IBM ストレージ・システム用に McAfee

VirusScan をセットアップする場合、検出の種類を指定します。

1. VirusScan コンソールを開きます。

2. 「Task (タスク)」 → 「On-Access Scan Properties (オン・アクセス・スキャン・プロパティー)」 → 「All Processes (すべてのプロセス)」 → 「Goto’Detection’ Tab (「検出」タブに進む)」をクリックします。「Detection (検出)」ダイアログが開きます。

3. 「Scan Files (ファイルのスキャン)」セクションで、「When reading from disk(ディスクからの読み取り時)」および「On network drives (ネットワーク・ドライブ上)」を選択します。

注: ストレージ・システムの共有をスキャンするには、両方のオプションを選択する必要があります。

この情報は、VSNA 7.1 ヘルプ・メニューに記載されています。

「Help (ヘルプ)」 → 「On-Access Scanning (オン・アクセス・スキャン)」 →

「Configuring the on-access scanner (オン・アクセス・スキャナーの構成)」 →

「All processes and default processes (すべてのプロセスおよびデフォルト・プロセス)」 → 「Detection Properties (検出プロパティー)」を開きます。

スキャン対象ファイル・タイプの指定スキャンされるファイル・タイプのデフォルト・リストが十分に包括的でないか、包含リストと合わせて除外リストを使用する計画の場合、スキャンされるファイル・タイプのリストを変更できます。

スキャン対象ファイル・タイプの表示ファイル・タイプのリストを表示して、リストに追加したり、リストから除去したり、スキャンする他のファイル・タイプとリストを置換する必要があるかどうかを判別できます。

次のコマンドを入力します。vscan extensions include スキャンされる拡張子の現在のリストが表示されます。

スキャン対象ファイル・タイプの追加ストレージ・システムに保管する必要があるファイル・タイプが拡張子リストに含まれていない場合、ファイル・タイプをリストに追加することができます。



ウィルス・スキャンを使用可能にすると、ファイル拡張子のデフォルト・リストが使用可能になります。ただし、デフォルト・リストにない追加のファイル拡張子を指定することができます。

次のコマンドを入力します。vscan extensions include add ext[,ext...] ext は、追加する拡張子です。

例

vscan extensions include add txt

注: ファイル拡張子リストには最大 255 のファイル拡張子を含めることができます。

スキャン対象ファイル・タイプの置換スキャンから除外するファイル・タイプのリストも指定している場合、除外リストのファイル・タイプを短いリストに置換することができます。

次のコマンドを入力します。vscan extensions include set ext[,ext...] ext は、設定する拡張子です。

スキャン対象ファイル・タイプの除去スキャンから除外するファイル・タイプも指定している場合、拡張子リストからファイル・タイプを除去することができます。

次のコマンドを入力します。vscan extensions include remove ext[,ext...] ext

は、除去する拡張子です。

スキャン対象ファイル・タイプのリセットスキャンされるファイル・タイプのデフォルト・リストに戻す場合、スキャンされるファイル・タイプのリストをリセットすることができます。

次のコマンドを入力します。vscan extensions include reset ファイル拡張子のリストがデフォルト・リストに設定されます。


関連資料

353ページの『デフォルトでスキャンされるファイル・タイプ』スキャンするファイル・タイプのリストを作成する前に、デフォルトでスキャンされるファイル・タイプのリストを参照してください。デフォルト・ファイル・タイプのリストには、スキャンするすべてのファイル・タイプが含まれている可能性があります。また、いくつかのファイル・タイプを追加または除去するとほぼ十分なリストになるか、アクセスを迅速化するために小さなリストを作成する場合もあります。

スキャン対象からのファイル・タイプの除外ストレージ・システムに保管される可能性がある新しいファイル・タイプ (新しいファイル名の拡張子) が急増しているため、ウィルス・スキャンに組み込むファイル・タイプではなく、除外するファイル・タイプを指定する方が好ましい場合があります。

スキャンから除外するファイル・タイプの表示スキャンから除外するファイル・タイプのリストを表示して、リストに追加したり、リストから除去する必要があるかどうかを判別できます。

次のコマンドを入力します。vscan extensions exclude ウィルス・スキャンから除外される拡張子の現在のリストが表示されます。

スキャンから除外するファイル・タイプのリストの作成除外機能を単独で、または包含機能と組み合わせて使用する場合、ウィルス・スキャンから除外するファイル・タイプのリストを作成できます。

次のコマンドを入力します。vscan extensions exclude set ext[,ext...] ext は、ウィルス・スキャンから除外するファイル・タイプのリストに設定する拡張子 (複数可) です。

注: set パラメーターを使用すると、除外リスト内のすべての既存のファイル・タイプ拡張子がこのコマンドで指定した拡張子に完全に置換されます。除外リストが既に存在していて、それに追加するだけの場合は、vscan extensions exclude add コマンドを使用してください。

スキャンから除外するファイル・タイプの追加あるファイル・タイプが安全でウィルス・スキャンを必要としないと判断する場合、ウィルス・スキャンから除外するファイル・タイプを追加できます。

次のコマンドを入力します。vscan extensions exclude add ext[,ext...] ext は、ウィルス・スキャンから除外するファイル・タイプのリストに追加する拡張子です。

例

vscan extensions exclude add txt


注: ファイル拡張子リストには最大 255 のファイル拡張子を含めることができます。

スキャンから除外するファイル・タイプの除去あるファイル・タイプが安全でなく、ウィルス・スキャンが必要であると判断する場合、ウィルス・スキャンから除外するファイル・タイプを除去できます。

次のコマンドを入力します。vscan extensions exclude remove ext[,ext...] ext

は、ウィルス・スキャンから除外されるファイル・タイプのリストから除去する拡張子です。

除外ファイル・タイプ・リストの空へのリセット除外リスト内のファイル・タイプのいずれも安全でなく、除外リストを除去する場合、除外ファイル・タイプ・リストをリセットできます。

次のコマンドを入力します。vscan extensions exclude reset ファイル拡張子のリストがデフォルトの空の値に設定されます。

除外リストと組み合わせた包含リストの使用新しいファイル・タイプが急増しているため、安全と見なすすべてのファイル・タイプをスキャンせず、システム上に保管される新しい聞き慣れないファイル・タイプをすべてスキャンすることができます。


包含リストを使用して一般的なウィルス・スキャンを指定し、除外リストを使用して一般的なウィルス・スキャンから除外されるファイル・タイプを指定することができます。

1. システム・コンソールで次のコマンド行を入力し、ウィルス・スキャンから除外するすべてのファイル・タイプの拡張子を指定します。vscan extensions

exclude set ext[,ext...]

2. 次のコマンド行を入力して、その他すべてのファイル・タイプのウィルス・スキャンを指定します。vscan extensions include set ??? このコマンド行は、ウィルス・スキャン・プログラムに対してシステム上に保管されているすべてのファイル・タイプをスキャンするように指示します。しかし、「exclude」および「include」の両方のコマンド行を同時に実行すると、結果として、ステップ 1

で説明した vscan extensions exclude コマンド行で指定された拡張子を持つファイル・タイプを除くすべてのファイル・タイプがスキャンされることになります。

スキャン対象の共有の指定トラステッド・ユーザーのみが共有を使用する場合、ファイルが読み取り専用モードに制限されている場合、または安全性よりもアクセスの速度の方が重要である場合、共有内のファイルに対するウィルス・スキャンをオフにすることができます。


すべてのアクセスに対するウィルス・スキャンをオフにするトラステッド・ユーザーのみが共有を使用する場合、または安全性よりもアクセスの速度の方が重要である場合、共有内のファイルに対するウィルス・スキャンをオフにすることができます。


共有に対するウィルス・スキャンはデフォルトでオンになっています。

次のコマンドを入力します。cifs shares -change share_name -novscan

share_name は、ウィルス・スキャンをオフにする対象の共有の名前です。クライアントがこの共有のファイルを開く場合、アプリケーションはウィルス・スキャンを実行しません。設定は、再起動後も持続します。

注: cifs.homedir を共有名として使用することにより、これらの共有の属性をすべての CIFS ユーザー・ホーム・ディレクトリーに対して設定することができます(例えば、cifs shares -change cifs.homedir -novscan)。

すべてのアクセスに対するスキャンをオンにするトラステッド・ユーザー以外のユーザーが共有を使用する場合、またはアクセスの速度よりも安全性の方が重要である場合、共有内のファイルに対するウィルス・スキャンをオンにすることができます。

次のコマンドを入力します。cifs shares -change share_name -vscan share_name

は、ウィルス・スキャンをオンにする対象の共有の名前です。クライアントがこの共有のファイルを開くと、アプリケーションはウィルス・スキャンを実行します。設定は、再起動後も持続します。

注: cifs.homedir を共有名として使用することにより、これらの共有の属性をすべての CIFS ユーザー・ホーム・ディレクトリーに対して設定することができます(例えば、cifs shares -change cifs.homedir -vscan)。

読み取り専用アクセスに対するスキャンをオフにするファイルが読み取り専用モードに制限されている場合、または安全性よりもアクセスの速度の方が重要である場合、共有内のファイルに対するウィルス・スキャンをオフにすることができます。



次のコマンドを入力します。cifs shares -change share_name -novscanread

share_name は、ウィルス・スキャンをオフにする対象の共有の名前です。クライアントがこの共有のファイルを読み取りアクセスのために開く場合、アプリケーションはウィルス・スキャンを実行しません。設定は、再起動後も持続します。

読み取り専用アクセスに対するスキャンをオンにするアクセスの速度よりも安全性の方が重要である場合、共有内のファイルに対するウィルス・スキャンをオンにすることができます。


次のコマンドを入力します。cifs shares -change share_name -vscanread

share_name は、ウィルス・スキャンをオンにする対象の共有の名前です。クライアントがこの共有のファイルを読み取りアクセスのために開く場合、アプリケーションはウィルス・スキャンを実行します。設定は、再起動後も持続します。

ウィルス・スキャンがオフになっている共有の追加トラステッド・ユーザーのみが共有を使用する場合、ファイルが読み取り専用モードに制限されている場合、あるいは安全性よりもアクセスの速度の方が重要である場合、ウィルス・スキャンがオフになっている共有を追加できます。



次のコマンドを入力します。cifs shares -add share_name /path -novscan

share_name は、ウィルス・スキャンがオフになっている、作成する共有の名前です。 path は、共有を作成する場所を指定します。 Data ONTAP は、ウィルス・スキャンがオフになっている共有を作成します。

注: バックアップの目的で、同じディレクトリー上に 2 つの共有を作成できます。1 つの共有は、スキャンが使用不可で、バックアップ・アカウントへのアクセスのみを許可する共有レベルのアクセス制御リスト (ACL) を使用します。もう 1 つの共有は、通常のユーザーが使用可能で、スキャンが使用可能になっています。ウィルス・スキャンが行われず、パフォーマンスが優れている共有でバックアップを実行できます。一方、通常のユーザーは引き続き通常の共有を使用してデータにアクセスし、ウィルス保護を得ることができます。

読み取り専用アクセスに対するウィルス・スキャンがオフになっている共有の追加

トラステッド・ユーザーのみが共有を使用する場合、ファイルが読み取り専用モードに制限されている場合、あるいは安全性よりもアクセスの速度の方が重要である場合、ウィルス・スキャンがオフになっている共有を追加できます。



次のコマンドを入力します。cifs shares -add share_name /path -novscanread

share_name は、ウィルス・スキャンがオフになっている、作成する共有の名前です。 path は、共有を作成する場所を指定します。 Data ONTAP は、読み取り専用アクセスに対するウィルス・スキャンがオフになっている共有を作成します。

注: バックアップの目的で、同じディレクトリー上に 2 つの共有を作成できます。1 つの共有は、スキャンが使用不可で、バックアップ・アカウントへのアクセスのみを許可する共有レベルのアクセス制御リスト (ACL) を使用します。もう 1 つの共有は、通常のユーザーが使用可能で、スキャンが使用可能になっています。ウィルス・スキャンが行われず、パフォーマンスが優れている共有でバックアップを実行できます。一方、通常のユーザーは引き続き通常の共有を使用してデータにアクセスし、ウィルス保護を得ることができます。


スキャナー・リストの表示スキャナー・リストを調べることによって、スキャナー・クライアントが要求を受信してファイルをスキャンしているかどうかを判別できます。

次のコマンドを入力します。vscan scanners システムは、次の段落で示すように、ウィルス・スキャン・クライアントの名前と情報をディスプレイに出力します。

例Virus scanners(IP and Name) Connect time Reqs Fails

(dd:hh:mm)------------------------------------------------------------------10.61.155.118 ¥¥WIN2K-NAN 00:02:23 2 010.60.129.152 ¥¥WIN2K-RTB 00:00:01 0 0

Connect time フィールドには、スキャナーがシステムに接続されている時間の長さが表示されます。

Reqs フィールドには、システムによってそのスキャナーに送信された要求の合計数が表示されます。

Fails フィールドには、失敗した要求の数が表示されます。

リストされない 1 次ウィルス・スキャナー場合によっては、1 次ウィルス・スキャナーを構成した後で、スキャナーがクライアント要求に対応しなくなり、IBM ストレージ・システム CLI で vscan scanners

を実行してもリストに表示されなくなることがあります。ただし、以前の構成を古い AutoSupport メッセージで見ることができます。この問題を解決するには、以下のステップを実行します。

1. ウィルス・スキャナーを ping して、ストレージ・システムとウィルス・スキャナーの間にネットワーク接続が存在するかどうかを判別します。接続が存在する場合、ステップ 2 に進みます。

2. ウィルス・スキャン・ソフトウェアが適切にインストールおよび構成されているかどうかを判別します。適切に機能していない場合は、ウィルス・スキャナー資料を参照するか、製造元の技術サポート・スタッフに連絡して問題を判別および修正してください。問題がない場合は、ステップ 3 に進みます。

3. ウィルス・スキャン・ソフトウェア・サービスが開始されていることを確認します。開始していない場合、ウィルス・スキャン・サーバーで IBM 認識ウィルス・スキャン・アプリケーションを再始動します。

注: サービスが開始しているように見えてもフリーズしている可能性があります。サービスを再開すると、サービスがストレージ・システムに再登録されます。1 次スキャナーは、2 次ストレージ・システム側で構成されていません。2

次ウィルス・スキャナーは、vscan scanner secondary_scanners コマンドを使用して 2 次ストレージ・システムでのみ構成されています。


vscan 情報の検査ウィルス・スキャナーがオンであるかどうか、ウィルス・スキャナーがどの程度良好に機能しているか、およびスキャンされているファイル拡張子とスキャンされないファイル拡張子を素早く判別することができます。

次のコマンドを入力します。vscan システムは、次の段落で示すように、vscan のオン/オフ状況、ウィルス・スキャン・クライアントに関する情報、スキャン対象の拡張子のリスト、およびスキャン済みファイルの数とスキャン失敗の数をディスプレイに出力します。

例systemA> vscan

Virus scanning is enabled.

Virus scanners(IP and Name) Connect time Reqs Fails(dd:hh:mm)

------------------------------------------------------------------10.61.155.118 ¥¥WIN2K-NAN 00:02:23 2 010.60.129.152 ¥¥WIN2K-RTB 00:00:01 0 0

List of extensions to scan: ??_,ASP,BAT,CDR,COM,CSC,DL?,DOC,DOT,EXE,GMS,GZ?,HLP,HT?,IM?,INI,JS?,MD?,MPP,MPT,MSG,MSO,OCX,OLE,OV?,POT,PP?,RTF,SCR,SHS,SMM,SYS,VBS,VS?,VXD,WBK,WPD,XL?,XML

List of extensions not to scan:

Number of files scanned: 28Number of scan failures: 0

注: 出力の最初の表に示されているスキャン要求および失敗の数は、この接続セッションを表しています。出力の終わりにある 2 番目の数値一式は、vscan がオンになってからのスキャンおよび失敗の合計数を反映しています。

ウィルス・スキャンの要求タイムアウトの設定およびリセットData ONTAP がスキャンの状況を要求する前にウィルス・スキャンの終了を待機する時間を変更できます。この状況は、ネットワークが低速であるか、ウィルス・スキャナーが低速で、スキャン要求が時期尚早にタイムアウトになるのを回避する場合に起こります。


要求は、スキャンが完了するか、ホストが待機をやめるまで、必要な回数にわたって繰り返されます。デフォルトでは、ウィルス・スキャン・タイムアウトは 10 秒です。

新しいスキャン要求タイムアウト値を設定するか、以前に設定した値をデフォルト値にリセットすることができます。

v 新しいスキャン要求タイムアウト値を設定するには、次のコマンドを入力します。vscan options timeout set value

value は、1 から 45 秒です。推奨される設定値は 8 から 12 秒です。


v スキャン要求タイムアウト値をデフォルト値の 10 秒にリセットするには、次のコマンドを入力します。vscan options timeout reset

スキャンを実行できない場合のファイル・アクセスの許可スキャナーを使用できない場合またはスキャン要求がタイムアウトになった場合にファイルにアクセスできることを指定できます。


デフォルト設定では、スキャンを正常に実行できない場合にはファイル・アクセスは拒否されます。つまり、オプションは On に設定されます。このオプションがOff に設定される場合、スキャンを正常に実行できない場合でもアクセスが許可されます。

次のコマンドを入力します。vscan options mandatory_scan [on|off]

vFiler ユニットによるホスト・ストレージ・システムのウィルス・スキャナーの使用の制御

セキュリティー上の問題に応じて、それぞれの vFiler ユニットをウィルス・スキャナーに登録するか、vFiler ユニットがホスト・ストレージ・システムのウィルス・スキャナーを使用できるようにすることができます。


デフォルトで、vFiler ユニットは、ホスト・ストレージ・システムに接続されているウィルス・スキャナーを使用してファイルをスキャンすることができます。vFiler

ユニットについて詳しくは、「Data ONTAP MultiStore Management Guide」を参照してください。

以下の 2 とおりの方法のいずれかでウィルス・スキャナーを登録できます。

v 複数の vFiler ユニットがそれぞれ別の組織によって所有されており、セキュリティー上の問題がある場合は、ウィルス・スキャナーをそれぞれの vFiler ユニットに登録することができます。詳しくは、ご使用のウィルス・スキャン・ソフトウェア資料を参照してください。

v セキュリティー上の問題がない場合は、ウィルス・スキャナーを物理ストレージ・システムにのみ登録することができます。この方法では、ストレージ・システムのみがウィルス・スキャナーを認証します。

vFiler コンソールから次のコマンドを入力します。vscan options

use_host_scanners [on|off]

注: このコマンドは、デフォルトの vFiler ユニットでは実行されません。

ウィルス・スキャン・オプションの状況の検査使用するウィルス・スキャン・オプションが希望の値に設定されているかどうかを素早く判別できます。


次のコマンドを入力します。vscan options ストレージ・システムは、次のようにウィルス・スキャン・オプションの状態を画面に出力します。

vscan options mandatory_scan onvscan options timeout: 12 secvscan options use_host_scanners on

注: use_host_scanners オプションは、vFiler ユニットにのみ適用され、vscan options

コマンドが vFiler ユニットに対して実行された場合にのみ表示されます。

ウィルス・スキャナー・セッションの停止ストレージ・システムで CIFS を終了する必要がある場合、またはアンチウィルス・プログラムを新規バージョンにアップグレードする場合、スキャナー・セッションを停止できます。

次のコマンドを入力します。vscan scanners stop scanner_IP scanner_IP は、停止するウィルス・スキャナーの IP アドレスです。

スキャン済みファイル・キャッシュのリセット新しいウィルス・スキャン・シグニチャー・ファイルがある場合、キャッシュをリセットして、古いシグニチャー・ファイルを使用してスキャンされたファイルを再スキャンすることができます。


Data ONTAP は、以前にスキャンされたファイルに関する情報をキャッシュに入れて、それらのファイルの再スキャンを回避します。

次のコマンドを入力します。vscan reset

ウィルス・スキャン・メッセージを CIFS クライアントで使用可能にするストレージ・システム上で実行されているウィルス・スキャン・アプリケーションにより、CIFS がアクセスしようとしているファイルがウィルスに感染していることが検出された場合、明示的なウィルス警告メッセージを送信することによって CIFS

クライアント・ユーザーに通知することができます。


この機能が使用可能になっていない場合、ウィルス・スキャンによって検出されたウィルス感染ファイルにアクセスしようとする CIFS クライアントは、単に一般的な「ファイルを利用できません」というメッセージを受け取ります。

次のコマンドを入力します。vscan options client_msgbox {on|off} on により、ウィルス警告メッセージの表示が使用可能になります。off により、ウィルス警告メッセージの表示が使用不可になります。


ウィルス・スキャン・サーバー・エラー・メッセージウィルス・スキャン・サーバーは頻繁に切断および再接続して、エラー・メッセージを表示します。

症状: 以下のいずれかの症状が見られます。

v ウィルス・スキャン・サーバーがストレージ・システム上のファイルをスキャンできなかった。

v ウィルス・スキャン・サーバーが短期間の後に切断および再接続する。

v ウィルス・スキャン・サーバーがポート 139 エラーで頻繁に切断および再接続する。

この問題の原因:

v NetBIOS over TCP がサーバー・サイドで使用可能になっていない。

v サーバー・サービスが停止された。

解決策:

1. サーバーで NetBIOS over TCP を使用可能にします。この手順について詳しくは、Microsoft TechNet の記事「NetBIOS over TCP/IP」を参照してください。

2. サーバー・サービスを自動にします。

3. サービスを開始します。

関連情報

http://technet.microsoft.com/en-us/library/bb727013.aspx


http://technet.microsoft.com/en-us/library/bb727013.aspx

用語集

Data ONTAP フィーチャーに関しては、次に示す用語が使用されます。

アクティブ・ファイル・システム (active file system)Snapshot コピーを除くファイル・システム。

アグリゲート (aggregate)1 つまたは 2 つのプレックスからなる、RAID 保護ストレージの管理可能な単位。単一の従来型ボリューム、または複数の FlexVol ボリュームを含むことができる。

オープン・システム SnapVault エージェント (Open Systems SnapVault agent)システムにインストールできるソフトウェア・モジュールで、そのシステムが SnapVault 2 次ストレージ・システムにデータをバックアップできるようにする。

オープン・システム・プラットフォーム (Open Systems platform)SnapVault 2 次ストレージ・システムにバックアップできるデータをもつシステム。例えば、Solaris、HP-UX、または Windows を実行するサーバー。

共有 (share)ネットワーク・ユーザーに対して提供され、CIFS クライアント上ではドライブ名にマップできる、ストレージ・システム上のディレクトリーまたはディレクトリー構造。

コンソール (console)

ストレージ・システムのシリアル・ポートに接続され、ストレージ・システムの操作のモニターおよび管理に使用される端末。

サブツリー (subtree)ボリュームまたは qtree 内のディレクトリー。

磁気テープ装置 (tape device)磁気テープ・ドライブまたはテープ・スタッカーを取り付ける際に、磁気テープ装置名に情報を指定することによって作成する、物理磁気テープ・ドライブの特定機能。

ソース・ストレージ・システム (source storage system)データを複製する元のストレージ・システム。

増分チェーン (increment chain)同じパスの増分バックアップの系列。

ダンプ・パス (dump path)バックアップする 1 つのボリューム、qtree、またはサブツリーを指定するパス。

テープ・スタッカー (tape stacker)スタックからテープ・カートリッジにアクセスできるハードウェア。

テープ・ファイル (tape file)ファイル・マークによって区切られるテープ上のデータ。


テープ・ブロック (tape block)1,024 バイトのデータ。

テープ・メディア・チェンジャー (tape medium changer)テープ・カートリッジをロードおよびアンロードできるハードウェア。

テープ・ライブラリー (tape library)テープ・カートリッジにランダムにアクセスできるハードウェア。

ファイル・マーク (file mark)テープ・ファイルの境界を示すテープ上のデータ。

プレックス (plex)ファイル・システムの物理コピー。ミラーリングが解除されたボリュームにはプレックスが 1 つ存在し、ミラーリングされたボリュームには同一のプレックスが 2 つ存在する。

ブロック化因数 (blocking factor)書き込み操作のたびに転送されるテープ・ブロックの数。

ボリューム (volume)1 つのファイル・システム。

ボリューム・コピー (volume copy)

アクティブ・ファイル・システム内のデータと、Snapshot コピー内のデータを、両方ともボリューム間でコピーする手段。

ミラー (mirror)別のボリューム (通常は別のストレージ・システム上にある) のアクティブ・ファイル・システムにあるデータの読み取り専用コピーを格納するボリューム。

リモート・シェル (Remote Shell)一方のシステムのユーザーが、他方のシステム上でプログラムを実行できるようにするプログラム。リモート・シェル接続は、通常は対話式ではない。

リモート磁気テープ装置 (remote tape device)テープ操作を実行するストレージ・システムに直接接続されていない磁気テープ・ドライブに関連して実行される、プログラムに基づいた機能。

ルート・ボリューム (root volume)ストレージ・システム全体を制御する情報を含むボリューム。通常、その情報は /etc/rc ファイル内にある。

ローカル磁気テープ装置 (local tape device)テープ操作を実行するストレージ・システムに直接接続された磁気テープ・ドライブに関連して実行される、プログラムに基づいた機能。

割り当て量 (quota)特定のユーザー ID (UID) またはグループ ID (GID) をもつファイルによるディスク・スペースの使用量を制限する、ファイル・システムに対して定められた限度。

1 次ストレージ・システム (primary storage system)SnapVault によってバックアップされるデータをもつシステム。


2 次ストレージ・システム (secondary storage system)SnapVault によってデータがバックアップされる先のストレージ・システム。

ACL アクセス制御リスト (Access control list)。それぞれの共有に対するユーザーまたはグループのアクセス権限を含むリスト。

CIFS Common Internet File System。PC のネットワーキング用のプロトコル。

DNS ドメイン・ネーム・サービス (Domain Naming Service)。IP アドレスを検索するためのインターネット・サービス。

HTTP HyperText Transfer Protocol。インターネット Web 転送プロトコルの 1

つ。

inode ストレージ・システム上のファイル、および UNIX ファイル・システム内のファイルに関する情報を含むデータ構造。

MD5 Message Digest 5。インターネット標準に関する提案である RFC (Request

For Comments) 1321 に記述されたチェックサム・アルゴリズム。

NDMP Network Data Management Protocol。Data ONTAP を実行するストレージ・システムとバックアップ・アプリケーションの通信を可能にし、複数のテープ・バックアップ・デバイスのロボット装置を制御する機能を提供するプロトコル。

NFS ネットワーク・ファイル・システム (Network File System)。UNIX ベース・コンピューターのネットワーキング用のプロトコル。

NIS

ネットワーク情報サービス (Network Information Service)。従来はイエロー・ページと呼ばれていた。ネットワークの管理データベース。

NVFAILデータベースの妥当性について警告を出し、データベースが自動的に再始動しないようにデータベースの名前を自動的に変更するソフトウェア。

NVRAMストレージ・システム内の不揮発性 RAM。入力される書き込みデータとNFS 要求をログに記録するために使用される。システム・パフォーマンスを高め、ストレージ・システム障害または電源障害が発生した場合にデータ損失を防止する。

qtree 特殊な属性をもつ仮想サブボリュームとして機能する、ボリュームのルートの特殊なサブディレクトリー。

RAID 新磁気ディスク制御機構 (Redundant Array of Independent Disks)。アレイ内のディスクすべての内容に基づいてパリティー情報を計算することによって、ディスクを障害から保護する技法。 Data ONTAP ソフトウェアを実行するストレージ・システムは、RAID レベル 4 を使用する。このレベルでは、すべてのパリティー情報が単一のディスクに保管される。

SnapMirror同じまたは別個のディスクまたはストレージ・システムに対して、ボリュームの自動ファイル・システム複製を実行するソフトウェア。

用語集 369

SnapRestoreボリューム全体を、前に作成された Snapshot コピーに記録された状態にリストアするソフトウェア。

Snapshot コピー (Snapshot copy)ファイル内容を重複させずに、不測の削除または変更からファイルを保護する、ファイル・システム全体のオンライン読み取り専用コピー。 Snapshot

コピーにより、ユーザーはファイルをリストアでき、管理者はシステムを使用しながらテープにバックアップできる。

Snapshot 予約量 (Snapshot reserve)Snapshot コピー用に予約されている、ボリュームのディスク・スペースの一部分。


��

Printed in Japan

GC88-8110-00

data ontap 7.3 データ保護バックアップとリカバ …...ibm system storage n シリーズ...

Documents