カテゴリー: Backup

投稿日:

NetBackupクライアントの接続エラーに関して調査

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

Veritas NetBackupにおいて、NetBackupクライアントとの接続に問題があった場合の調査手法についてメモ書き

1.1 マスタサーバ/メディアサーバ上での名前解決確認

マスタサーバ/メディアサーバ上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

ここで予期しないIPアドレスが出てきてしまうのであれば、ホスト名/IPアドレス/DNS設定を見直すこと。

続いて問題が発生しているクライアントについての名前解決状況を確認する。

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

クライアントホスト名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は　hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にクライアントホスト名のエントリを追加すること。

追加後は、再度bpclntcmdを実行して、状況が変化したことを確認する。

1.2. クライアント上での名前解決確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、自身の名前解決状況を確認する。 

# bpclntcmd -hn クライアントホスト名
# bpclntcmd -hn ドメイン名付きのクライアントホスト名
# bpclntcmd -ip クライアントのIPアドレス

通常はクライアント自身については正常に情報が取得できるはずです。

続いてマスタサーバ/メディアサーバについての名前解決状況を確認

# bpclntcmd -hn マスタサーバ/メディアサーバ名
# bpclntcmd -hn ドメイン名付きのマスタサーバ/メディアサーバ名
# bpclntcmd -ip IPアドレス

マスタサーバ上で実行した結果と異なる場合は、名前解決情報のキャッシュが残存している可能性があるため、「bpclntcmd -clear_host_cache」を実行してキャッシュ削除した上で、再度、名前解決状況を確認する。

マスタサーバ/メディアサーバ名からIPアドレスが取得できないようであれば、DNS設定を見直し、DNS関連の設定変更ができない場合は　hostsファイル(/etc/hosts, C:\Windows\System32\drivers\etc\hosts)にマスタサーバ/メディアサーバ 名のエントリを追加すること。

1.3. クライアント上でマスタサーバが認識している情報の確認

クライアント上で、/usr/openv/netbackup/bin/bpclntcmd もしくは C:\Program Files\Veritas\NetBacku\bin\bpclntcmd.cmd を実行して、NetBackupが認識しているホスト名情報を確認する。

# bpclntcmd -pn -verbose

2.1. 接続テストを実施

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd/bptestbpcd もしくは C:\Program Files\Veritas\NetBacku\bin\admin\bptestbpcd を実行して、 マスターサーバからクライアントへの接続テストを実施します。

# bptestbpcd -client クライアントホスト名 -verbose -debug

(Veritas KB: How to test client connections using the bptestbpcd command)

2.2 接続テスト2

マスタサーバ上で /usr/openv/netbackup/bin/bptestnetconn もしくは C:\Program Files\Veritas\NetBacku\bin\bptestnetconn.exe を実行して、接続を確認

# bptestnetconn -asp -H クライアントホスト名

(Veritas KB: Best Practices for bptestnetconn including arguments and outputs by NetBackup version )
(Veritas KB: Using bptestnetconn to test connectivity between NetBackup hosts )

おまけ: クライアントの情報が取得できるか確認

マスタサーバ上で、/usr/openv/netbackup/bin/admincmd か C:\Program Files\Veritas\NetBacku\bin\admin にある bpgetconfig を実行して、マスタサーバからクライアント上のNetBackup Agentのインストール情報を確認します。

# bpgetconfig -g クライアントホスト名 -L

出力内に、Agentのインストール先やバージョンが表示されれば接続できています。

(Veritas KB: Command line option to get client NetBackup version, OS, and hardware type)

おまけ2: 複数NICがある場合の設定に関する資料

・How to follow best practices when using Preferred Network entries
　調査時に使うbplocaladdrsコマンド, bptestnetconnコマンド, bptestbpcdコマンドの出力サンプルあり

・Best Practices when assigning an IP address to the appliance management interface
　bp.confにPREFERRED_NETWORK=～というエントリを追加する、という話

・Required Interface or Preferred Network settings seem to cause connections between non-routed networks on weakhost platforms
　bp.confにPREFERRED_NETWORKかREQUIRED_INTERFACE設定をする
　(PREFERRED_NETWORKはNBU7.xで追加された設定項目)

・How to force backups over multiple specific networks interfaces instead of all those available.

NetBackup 8.xでの証明書関連エラー対応

クライアントインストール時にサーバとの通信がうまくいかなかったけど、無視してインストールを完了した場合、サーバの証明書が、クライアント側に保存されておらず、バックアップを行うとエラーになる。

1: (7660) ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません 

2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Connecting host:  NBUサーバ
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] ConnectionId: {149DAA97-CA51-4AC8-8E38-F4F253D9B113}:OUTBOUND
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] pid: 2556
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Received status: 7660 with message 証明書のマッピングファイルを読み込めません。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) ホスト ( NBUクライアント) 上のピアプロキシで使用可能な証明書が見つかりませんでした。 証明書が正常に配備されていない可能性があります。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] 処理中 (CertProtocol) にエラーが発生しました (CERT_PROTOCOL_SELECT_COMMON_CA_ROOT)。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956)  NBUクライアント の bpcd が状態 7660 で終了しました: ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Connecting host:  NBUサーバ
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] ConnectionId: {84C7C072-EC87-4247-AE80-9066320C5EA5}:OUTBOUND
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] pid: 2556
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] Received status: 7660 with message 証明書のマッピングファイルを読み込めません。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) ホスト ( NBUクライアント) 上のピアプロキシで使用可能な証明書が見つかりませんでした。 証明書が正常に配備されていない可能性があります。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956) [PROXY] 処理中 (CertProtocol) にエラーが発生しました (CERT_PROTOCOL_SELECT_COMMON_CA_ROOT)。
2022/10/24 10:28:10 - エラー bpbrm (pid=1956)  NBUクライアント の BPCD が状態 61 で終了したため、メールを送信できません: VNETD プロキシでエラーが発生しました
2022/10/24 10:28:10 - 情報 bpbkar32 (pid=0) done. status: 7660: ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません
2022/10/24 10:28:10 - 推定で 0 KB 必要です
2022/10/24 10:28:10 - 情報 nbjm (pid=4240) started backup (backupid= NBUクライアント_1666574889) job for client  NBUクライアント, policy  NBUクライアント, schedule Full on storage unit diskstorage
2022/10/24 10:28:10 - 開始されたプロセス bpbrm (pid=1956)
2022/10/24 10:28:10 - 書き込みの終了
ピアプロキシは証明書プロトコルの使用可能な証明書を見つけることができません  (7660)

このエラーに関するKB 「How to resolve communication problems due to certificate errors after upgrading to 8.1 from a previously re-installed 8.0 host」「How to manually obtain a host ID Certificate.」「How to re-issue a token on a NetBackup 8.1.x client that has been reinstalled」

上記からNetBackupクライアントから証明書取得のコマンドを実行してみる

# /usr/openv/netbackup/bin/nbcertcmd  -getCertificate -host  NBUクライアント -server NBUサーバ
nbcertcmd: The -getCertificate operation failed for server NBUサーバ
EXIT STATUS 8500: Connection with the web service was not established.
#

これはNetBackupサーバ側でポートが正しく空いていないためだった(Status Code:8500 Error when trying to install agent on new server)

今回はWindows Server上だったので、Windows FIrewallに対して、ポート1556とポート13724を開けた。(NetBackup master server portsをみるともポート 13782 もあった方がよさそう)

再実行すると下記となる

# /usr/openv/netbackup/bin/nbcertcmd  -getCertificate -host  NBUクライアント -server NBUサーバ
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

これは証明書管理にホストが登録されていないために発生しています

新規トークンを発行します

ここで表示されるトークン値を使います

# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token QWRNKOHALAKDPAGF
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

なんだろと調査をいろいろしてみるとnbcertcmd -displayCACertDetailの実行結果で問題が・・・

# /usr/openv/netbackup/bin/nbcertcmd -displayCACertDetail -server NBUサーバ

CA Certificate received successfully from server NBUサーバ.

         Subject Name : /CN=nbatd/OU=root@NBUサーバ/O=vx
           Start Date : 10月 20 04:36:48 2022 GMT
          Expiry Date : 10月 15 05:51:48 2042 GMT
     SHA1 Fingerprint : E4:3C:2E:12:4C:66:DF:62:28:98:C1:D3:EB:5A:E0:44:4F:52:64:62
 CA Certificate State : Not Trusted

# /usr/openv/netbackup/bin/nbcertcmd -displayCACertDetail -server NBUサーバ.adosakana.local
The target server NBUサーバ.adosakana.local could not be authenticated.
The server name does not match any of the host names listed in the server's certificate.
Names listed in the server's certificate are:
DNS:NBUサーバ
Failed to display CA certificate details

nbcertcmd: The -displayCACertDetail operation failed.
EXIT STATUS 8509: The specified server name was not found in the web service certificate
#

NetBackupサーバ上の証明書がドメイン無しで発行されているのにたいして、NetBackupクライアント側からはドメイン有りで接続しようとしているのでエラーとなっていた模様。

NetBackupサーバ側の証明書変更手法が分からないのでNetBackupクライアント側のbp.confのSERVER記述をドメイン無しに書き換えて再実行

# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token QWRNKOHALAKDPAGF -force
nbcertcmd: The -getCertificate operation failed for server NBUサーバ.
EXIT STATUS 8508: List of trusted Certificate Authorities could not be fetched.
#

これだけではなかった模様

「nbcertcmd -getCACertificate」を実行して取り込みした上で「nbcertcmd -getCertificate -token」で成功

# /usr/openv/netbackup/bin/nbcertcmd -getCACertificate
Authenticity of root certificate cannot be established.
The SHA1 fingerprint of root certificate is E4:3C:2E:12:4C:66:DF:62:28:98:C1:D3:EB:5A:E0:44:4F:52:64:62.
Are you sure you want to continue using this certificate ? (y/n): y
The validation of root certificate fingerprint is successful.
CA certificate stored successfully from server NBUサーバ.
# /usr/openv/netbackup/bin/nbcertcmd -getCertificate -token
QWRNKOHALAKDPAGF -force
Host certificate and certificate revocation list received successfully from server NBUサーバ
#

GUI上にも登録できた

投稿日:

QUADSTOR VLTを使ってみた

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

2024/11/12追記

2024年10月上旬頃よりquadstorにあったDownloadページがなくなった。

その前ぐらいから、quadstor vtlで新規にVTLを作成する場合に使用していたテープライブラリ定義が含まれなくなっていた。変更記録に特になにも書いてないから、ミスなのかな？とか思ってたが、ずっとその状態。

フリーで提供するのを止めた、ということなんだろうか・・・

以前「オープンソース版もあるVTLソフトウェアQUADSTOR」という記事を作成したが、使ってはいなかった。

よく見てみたら、ローカルのテープ装置/テープライブラリとしてエミュレートしてくれる機能もあったので、NetBackup Linuxでテープライブラリを使う案件が来たついでに、練習のためQUADSTORを使ってみた。

QUADSTORの注意点

  • CGIを使うWebインタフェースのプログラム(標準はポート80使用)
  • Webインタフェースに認証機能がないので要注意（アクセスすれば誰でも消せます)
  • SELinux環境下で使う場合、後述のSELinuxコマンドを実行すること
  • 仮想テープのデータを保存する領域はRAWデバイスディスクが必要(OSからマウントされない)
  • QUADSTORの起動に時間がかかる（うちの環境では10分かかった)

セットアップ実施

セットアップは簡単で、「Installation/Upgrading on RHEL/CentOS 6/7, SLES 12 SP2 and Debian 7/8」に書いてあるものをそのまま実行した形である。

# yum install httpd gcc perl kernel-devel sg3_utils
# rpm -ivh quadstor-vtl-ext-3.0.31.1-rhel.x86_64.rpm

プログラムの自動起動で以下を実行

# systemctl enable httpd.service
# systemctl enable quadstorvtl.service

SELinux環境で動作するように下記の設定を実行

# setsebool -P httpd_enable_cgi 1
# semanage permissive -a httpd_t

なお「semanage」は標準ではインストールされていないので「yum install policycoreutils-python」を実行して、追加インストールする必要がある。

Webインタフェースにアクセスする為に、firewallに穴を開けます。

# firewall-cmd --permanent --zone=public --add-service=http

iSCSIデバイスとして動作するので、iSCSIで使用するポートについても設定します。

# firewall-cmd --permanent --zone=public --add-service=iscsi-target

また、Webインタフェースには認証機能がなく、誰でも使用できる状態であるため「Accessing the Web Management Interface」の「SECURING ACCESS TO THE WEB INTERFACE」に記載されているように.htpasswdを使ってアクセス制限をかけましょう。

QUADstorとhttpdを起動します。

# systemctl start quadstorvtl
# systemctl start httpd

起動後、Webインタフェースにアクセスすると、以下の様な感じの画面がでてきます。

「Server Status: Server initialized and running」となっていればQUADstorの起動が完了しています。

まず「Physical Storage」タブにアクセスすると、いまマウントされているなローカルディスクが表示されます。

[Add]をクリックし、下記画面からQUADstor管理下に設定します。

指定したディスクの初期化が始まります。

なお、初期化中にさらなる追加を行おうとすると「ERROR: Reply from server is “Cannot add a disk when another is being configured “」とエラーになります。

初期化が終わると、下記の様になります。(なお、表示は自動更新されるますので、ブラウザの手動更新は不要です)

もう片側のディスクも同様に登録し、完了するのを待ちます。

次に「Virtual Libraries」から「Add VTL」よりテープチェンジャーを作成します。

[Add VTL]をクリックし、作成するテープチェンジャの設定を指定します。

登録したテープチェンジャーは下記の様に見えます。

作成した状態では中にテープメディアが入っていない状態です。

テープメディアは「VCartridge Information」にある[Add VCartridge]から行います。

テープメディアの種類はLTOドライブの選択に従って自動的に行われています。

指定するのは、作成する本数(Number of VCartridges)と、メディアにつけるバーコードラベルの書式指定です。

バーコード書式は英数6文字で、例えばLTO1カートリッジを10本、ラベル:BK0000と指定した場合「BK0000L1」～「BK0009L1」のテープメディアが登録されることになります。

iSCSIのテープ装置としては作成されましたので、Linuxサーバから接続してみます。

CentOS7だったら、まずは「yum install iscsi-initiator-utils」で接続に必要なソフトウェアをインストールします。

続いて、iSCSI接続を永続化するため「systemctl enable iscsid」を実行します。

「iscsiadm -m discovery -t sendtargets -p ＜IPアドレス＞」を実行し、検出したあと、「iscsiadm -m node –login -p ＜IPアドレス＞」でログインします。

# iscsiadm -m discovery -t sendtargets -p ＜IPアドレス＞
# iscsiadm -m node --login -p ＜IPアドレス＞

接続するとLinux上からは下記の様に見えるようになります。

# cat /proc/scsi/scsi
＜略＞
Host: scsi34 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: ULT3580-TD1      Rev: D711
  Type:   Sequential-Access                ANSI  SCSI revision: 06
Host: scsi33 Channel: 00 Id: 00 Lun: 00
  Vendor: ADIC     Model: Scalar 24        Rev: 6.24
  Type:   Medium Changer                   ANSI  SCSI revision: 03
#

NetBackupのコマンドで確認してみると、下記の様にみえました。

# /usr/openv/volmgr/bin/tpautoconf -t
TPAC60 IBM     ULT3580-TD1     D711 2688700001 -1 -1 -1 -1 /dev/nst0 - -
# /usr/openv/volmgr/bin/tpautoconf -r
TPAC60 ADIC    Scalar 24       6.24 26887167A2DC4D54B8910000 -1 -1 -1 -1 /dev/sg4 - -
# /usr/openv/volmgr/bin/scan
************************************************************
*********************** SDT_TAPE    ************************
*********************** SDT_CHANGER ************************
************************************************************
------------------------------------------------------------
Device Name  : "/dev/sg4"
Passthru Name: "/dev/sg4"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "ADIC    Scalar 24       6.24"
Vendor ID  : "ADIC    "
Product ID : "Scalar 24       "
Product Rev: "6.24"
Serial Number: "26887167A2DC4D54B8910000"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "ADIC    26887167A2DC4D54B8910000"
Device Type    : SDT_CHANGER
NetBackup Robot Type: 8
Removable      : Yes
Device Supports: SCSI-3
Number of Drives : 1
Number of Slots  : 20
Number of Media Access Ports: 1
Drive 1 Serial Number      : "2688700001"
Flags : 0x0
Reason: 0x0
------------------------------------------------------------
Device Name  : "/dev/nst0"
Passthru Name: "/dev/sg3"
Volume Header: ""
Port: -1; Bus: -1; Target: -1; LUN: -1
Inquiry    : "IBM     ULT3580-TD1     D711"
Vendor ID  : "IBM     "
Product ID : "ULT3580-TD1     "
Product Rev: "D711"
Serial Number: "2688700001"
WWN          : ""
WWN Id Type  : 0
Device Identifier: "IBM     ULT3580-TD1     2688700001"
Device Type    : SDT_TAPE
NetBackup Drive Type: 3
Removable      : Yes
Device Supports: SCSI-6
Flags : 0x0
Reason: 0x0
#

ドキュメントを確認すると、「Data deduplication best practices」というのがあり、重複排除が行われた状態でRAWストレージに格納されている模様。

2019/11/01追記

QUADstorをアップデートする場合の注意点。

「rpm -Uvh quadstor*.rpm」といったアップデートはできない。

一度、アンインストールした上で、再インストールする必要がある。

ここまでは「Installation or Upgrading the VTL software」にも書かれているのだが、実際にやろうとするとスクリプトの実行に失敗する場合がある。

アンインストール時、quadstorによりinitrd imageに組み込まれたモジュールを削除するために、quadstorの停止とモジュールのアンロードが実施されるのだが、モジュールの使用状況によってはアンロードが失敗する場合がある。

その場合は、一度OSを再起動して、モジュールがロードされていない状態にしないとアンインストールができなかった。

CentOS7の場合、以下の手順で行った。

(1) 「systemctl mask quadstorvtl」で再起動時にQUADstorが起動しない様に設定(maskしなくでも大丈夫な場合もある)
(2) OS再起動
(3) 「rpm -ev quadstor-vtl-ext-3.0.36-rhel.x86_64」といった感じでパッケージ削除
(4) 「rpm -ivh quadstor-vtl-ext-3.0.37-rhel.x86_64.rpm」といった感じでパッケージインストール
(5) 「 systemctl unmask quadstorvtl」 「systemctl enable quadstorvtl」で有効化
(6) OS再起動

2021/10/21追記

QUADStorVTLではなくて普通のiSCSIストレージに接続するために、Oracle Linux 8環境で「iscsiadm -m discovery -t sendtarget -p IPアドレス」を実行したら何も見つからなかった。

RHEL6ドキュメントを見直してみると「-t sendtarget」ではなく「-t st」だったのでこちらでやってみたら通った。というメモ書き

[root@oraclelinux ~]# iscsiadm -m discovery -t sendtarget -p 172.17.73.21 -o new
iscsiadm: Discovery record [172.17.73.21,3260] not found!
[root@oraclelinux ~]# iscsiadm -m discovery -t sendtarget -p 172.17.73.21 -d 5
iscsiadm: Max file limits 1024 262144
iscsiadm: Could not open /var/lib/iscsi/send_targets/172.17.73.21,3260: No such file or directory
iscsiadm: Discovery record [172.17.73.21,3260] not found!
[root@oraclelinux ~]# iscsiadm -m discovery -t st -p 172.17.73.21 -o new
172.17.73.21:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.1.200:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.11.3:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
192.168.12.1:3260,2460 iqn.2007-11.com.nimblestorage:test-v371c7edc5d1bd1e3.000000c8.6a07af3f
172.17.73.21:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.1.200:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.11.3:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
192.168.12.1:3260,2460 iqn.2007-11.com.nimblestorage:vmwarestorage-v371c7edc5d1bd1e3.00000063.6a07af3f
[root@oraclelinux ~]#
投稿日:

MSSQL Always on構成でのデータベースリカバリ手順の概要

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

MSSQL Always on構成で、バックアップソフトを使ってデータベースバックアップを行っている場合、リストア/リカバリをどのように行うのか、わかりにくかったのでメモ。

(1) SQLマネージメントスタジオでAlways on設定から該当データベースを削除

(2) フェールオーバークラスタマネージャーにてSQLの役割を全て停止（一部だけだとうまくいかないケースあり)

(3)バックアップソフトからリストア実施

(4)フェールオーバークラスタマネージャーにてSQLの役割を開始

(5)SQLマネージメントスタジオでAlways on設定に該当データベースを追加

投稿日:

SQL Management Studioでunixtimeを１分おきにINSERTするSQL文

Check
Facebook にシェア
このエントリーをはてなブックマークに追加

バックアップの試験のため、定期的にMSSQLデータベースの指定テーブル上にデータをインサートさせる必要が出た。

データベース「pubs」にテーブル「test3」を作り、そこに数字を格納する「counter」を作成。 

create table [pubs].[dbo].[test3](
[counter][CHAR](128)NULL
) on [PRIMARY]

そして、ここに対して、１分おきにunixtimeで時刻を追加していく、というもの

下記はとりあえず４０分実行するサンプル 

declare @i int
declare @date numeric
set @i = 1
while @i < 40
begin
 SELECT @date = DATEDIFF(s,'1970/1/1', GETUTCDATE() );
 insert into [pubs].[dbo].[test3](counter)values (@date);
 set @i = @i + 1
 waitfor delay '00:01:00' 
end

なお、データを確認する場合は、以下を実行する

select * from [pubs].[dbo].[test3];
投稿日:

NetBackupのマスターサーバを新しくする場合の資料

Check
Facebook にシェア
このエントリーをはてなブックマークに追加



NetBackupのサーバを新しく置き換える場合の資料に関して

基本：「How to migrate the NetBackup catalog information from one platform to another (UNIX to Windows or vice versa), rename a Master Server, cluster an existing Master Server, or merge multiple NetBackup domains.」
ここに資料がまとまっている。
・Windows環境を新しくする場合「Using catalog backup and recovery to transfer NetBackup catalogs between Windows master servers as part of a hardware refresh」
・Unix/Linux環境を新しくする場合「Using catalog backup and recovery to transfer NetBackup catalogs between UNIX or Linux master servers as part of a hardware refresh」
・Windows環境<=>Unix/Linux環境の置き換えは、コンサルタントサービス契約が必要
なお、結構な金額と１ヶ月以上の作業工期がかかるそうです

環境を新しくする際、メディアサーバも変わることが多い。
その場合、無くなるメディアサーバは、マスタサーバが古い状態の時に、オフライン扱いにしておかないと、メディア管理上めんどうなことになる。
→「What is the process for decommissioning a NetBackup 6.5 or 7.x media server?」
(NBU8.x環境では不要？)

NetBackup 8.1.2で、HP-UXとAIXがNetBackupのマスタサーバ/メディアサーバになれなくなる
このため、サポートが継続されるLinuxかSolaris環境へ移行するためのドキュメントが公開されている。
現在サポートされているNetBackup 7.7～8.1.1までのバージョンを対象としているが、それ以前でもだいたい同じとなる。
・マスタサーバ向け「NetBackup Master Server Migration Guide」
・メディアサーバ向け「NetBackup Media Server Migration Guide」