はじめに

こんにちは、2018年新卒入社の中本です。

掲題の通り、本稿ではテープバックアップ/リストアについてご紹介したいと思います。なぜこのクラウドネイティブな時代にテープバックアップ/リストア！？という意見もあるかと思われますが、影を潜めつつあるテープバックアップ/リストアを振り返り、

ご存じの方はノスタルジーを、知らない方はテクノロジーを感じていただければ幸いです。

内容

以下の順で進めていきます。

テープバックアップ/リストアとは
主なバックアップソフトウェア
テープバックアップ/リストアのメリット/デメリット
テープリストアの流れ
主なリストアコマンド
個人的にハマったポイント

テープバックアップ/リストアとは？

テープバックアップ/リストアとはその名の通り磁気テープを利用した長期保存・大容量・低コストなバックアップ/手法の一つです。

>`HPE StoreEver MSL2024 テープライブラリ`

テープマガジンを取り出し、都度テープを入れ替えることでバックアップを取得していきます。
※オートローダのテープ装置では、ロボットが自動的にバックアップ用テープを読込み、バックアップを自動化します。

>`HPE StoreEver MSL2024 テープマガジン`

オフラインでバックアップを行うため、ウイルス感染や人為的なオペミスによるバックアップ領域への影響などの懸念はありません。
また、磁気テープ規格であるLTOのストレージ容量は2020年現在で2.5TB～最大30TBまであり、将来的には数百TBにまで拡張するロードマップも公表されています。

＜ご参考＞
LTO6：非圧縮容量2.5TB、圧縮容量6.25TB
LTO7：非圧縮容量6TB、圧縮容量15TB
LTO8：非圧縮時12TB、最大30TB

主なバックアップソフトウェア

テープバックアップを支える主なバックアップソフトウェアです。

Data Protector（HPE）
NetBackup（VERITAS）
Backup Exec（VERITAS）
ARCSERVE BACKUP(arcserve)
NetVault Backup(Quest Software)

本稿では、***NetBackup***をベースにテープバックアップ/リストアについてご紹介いたします。

テープバックアップ/リストアのメリット/デメリット

メリット	デメリット
テープメディアの容量単価が安い	磁気ヘッドなどのゴミ除去の定期メンテナンスが必要
電力消費がディスクより少ない	物理的なテープ交換などの人的コストが掛かる
記録容量が大きい	磁気テープのためランダムアクセスできない
遠隔地バックアップなど可搬性に優れている	遠隔地で送付・保管する諸々のコストが掛かる
耐久性に優れている	テープ装置が必要なため環境に依存する
-	ファイル単位での個別リストアに不向き
-	クラウド化に伴い知見が少ない

「リストアする頻度は限りなく少なく、仮に戻したとしても即時性を要求しないので、大容量データを安価でバックアップしたい」といったデータの二次的な保管に向いているように思えます。

でも、戻せないと意味がない

安価で大容量のバックアップを可能にするのがテープバックアップということは理解しました。ただ、バックアップとして保管する以上、リストア出来なければバックアップ装置として意味がありません。

障害時にリストアしようとしたが、データを復旧できなかったといったことにならないように、テープのリストアの流れとハマったポイントについて確認し、今後の参考にしていただければと思います。

テープリストアフロー

テープスロットにあるテープの一覧取得
→　スロットに装填されているテープの一覧情報を取得し、対象テープの情報を取得する。
指定テープのデータ情報を取得（IMPORTフェーズ1）
→　テープメディア情報のカタログエントリのリストを作成する。
テープデータのインポート（IMPORTフェーズ2）
→　フェーズ1で作成したイメージのリストから、インポートするイメージを選択する。
リストア（全量、もしくはファイル単位）

主なリストアコマンド

VMQUERY

テープスロットに挿入されているテープメディア情報を取得するコマンド

$/usr/openv/volmgr/bin/vmquery -pn プール名 -b
================================================================================
media   media  robot  robot  robot  side/  optical  # mounts/      last
 ID     type   type     #    slot   face   partner  cleanings    mount time
-------------------------------------------------------------------------------
1161L4  HCART  TLD      0       2     -       -           1     2017/07/03 08:59
1168L4  HCART  TLD      0       7     -       -           1     2017/10/02 08:21
1174L4  HCART  TLD      0       5     -       -           1     2018/01/08 09:39
1181L4  HCART  TLD      0       4     -       -           1     2018/04/02 07:54

※プール名での問い合わせが可能な[pn]オプション
※ボリューム情報が簡易形式で出力される[b]オプション

BPIMPORT

テープメディア情報のカタログエントリの作成（Phase1）、データのインポート（Phase2）を行うコマンドVMQUERYで確認したmediaIDを指定する。

$ /usr/openv/netbackup/bin/admincmd/bpimport -id [mediaID]
Import phase 1 started 2020年07月13日 11時13分46秒
11:13:46 INF - Create DB information for media id [mediaID].
11:13:46 INF - Initiation of bptm process to phase 1 import media id [mediaID] was successful.
11:13:49 INF - Waiting for mount of media id [mediaID] on server XXXXXXX for reading.
.
.
Import phase 2 started 2020年07月13日 11時23分49秒
11:23:51 INF - If Media id [mediaID] is not in a robotic library administrative interaction may be required to satisfy this mount request.
11:23:53 INF - Waiting for mount of media id [mediaID] on server XXXXXXX  for reading.
11:25:01 INF - Waiting for positioning of media id [mediaID] on server XXXXXXX  for reading.
11:25:02 INF - Beginning import on server XXXXXXX of client XXXXXXX .

BPLIST

テープ内のファイルを確認するコマンド
※上記でテープ情報のインポートが完了している対象のみ実行可能

$ /usr/openv/netbackup/bibplist -C ＜クライアント名＞ -R -s ＜検索範囲開始日時＞ -e ＜検索範囲終了日次＞ ＜検索対象パス＞
-rw-r----- 200       200         24884756K  3月 20  2019 /XXX/XXX/XXX
-rw-r----- 200       200         24884756K  3月 20  2019 /XXX/XXX/XXX
-rw-r----- 200       200         24884756K  3月 20  2019 /XXX/XXX/XXX
-rw-r----- 200       200         24884756K  3月 20  2019 /XXX/XXX/XXX

BPRESTORE

テープ内のファイルをオリジナルと同一のパスへ上書きリストアを行うコマンド

$ /usr/openv/netbackup/bin/bprestore -C ＜バックアップ元クライアント名＞ -D ＜バックアップ先クライアント名＞ -s ＜検索範囲開始日時＞ -e ＜検索範囲終了日次＞
11:10:40 (43724.xxx) Restore job id 43724 will require 1 image.
11:10:40 (43724.xxx) Media id [mediaID] is needed for the restore.

11:11:14 (43724.001) Restoring from image created 2020年07月14日 08時14分33秒
11:11:15 (43724.001) TAR STARTED
11:11:15 (43724.001) INF - If Media id [mediaID] is not in a robotic library administrative interaction may be required to satisfy this mount request.
11:11:17 (43724.001) INF - Waiting for mount of media id [mediaID] on server XXXXXXX for reading.
11:12:25 (43724.001) INF - Waiting for positioning of media id [mediaID] on server XXXXXXX for reading.
11:12:26 (43724.001) INF - Beginning restore from server XXXXXXX to client XXXXXXX.

※[R]オプション + ＜リストア先対象パス＞で別のパスにリストア可能

個人的にハマったポイント

上記コマンドがあればテープからローカルサーバへのリストアは最低限可能です。ここからは個人的にハマった箇所について共有したいと思います。

＜テープリストアをするに至った経緯＞
基盤更改後の稼働していない旧オンプレミス基盤にて、テープバックアップにより長期保管されている過去10年分の特定データを抽出。
テープ装置がマウントされているバックアップサーバにてCUIベースでリストアを行い、抽出したデータをバックアップサーバから外部メディア（DVD等）にエクスポートという抽出作業を実施。（テープ → バックアップサーバ → 外部メディア）

テープメディア内のファイルを表示するBPLISTコマンドはIMPORTフェーズを終えてからでないと、正しく表示されない。

多くのテープメディアから特定のファイルを探したいときに最も利用したいと考えるのが、テープメディア内のファイル情報を取得するBPLISTコマンドだと思います。しかし、BPLISTコマンドはテープメディア情報のカタログエントリを作成するインポート作業（BPIMPORT）を経てからでないと、実行結果が正常に返ってきません。
コマンド実行してもリストが取得できない原因がわからず少しハマってしまいましたが、原因判明後も20～30分程度要するIMPORT作業がテープ単位で必要ということを知り、さらにへこんでしまいました。

大容量ファイルをリストアしようとするとリストア時のメモリ確保に失敗し、処理が中断される。

BPRESTOREコマンドを利用して、oracleDBから作成されたフルバックアップのdmpファイル（80GB程度）のリストアを試みたところ、以下のエラーメッセージが出て、処理が中断されてしまいました。

valoc failed for hp_save_area_errno(12) (cannot allocate memory)

どうやらリストアを開始するに差し当たって、最初にメモリを確保してから、リストア作業を開始するようなので、ファイル容量が10GB程度のものでも試行してみましたが、こちらもダメ。オンプレミス環境でメモリ増強対応も不可能であったため、メモリを食わずに本エラーを解消する手段がないか確認するためサポートへ問合せしたところ、サポートからの回答は、

リストア時のメモリ確保に失敗したと推察されます。
メーカナレッジを確認した所、Linux環境にて同様にメモリ確保に失敗する以下のバグが確認されています。
BUG REPORT: During some restores on Linux clients using VERITAS NetBackup (tm) 6.5 or 6.5.1, a memory leak can occur, causing the restore to fail.

お客様ご利用のバージョンは6.5GA(パッチ無し)となっておりましたので、上記でご案内したBugに該当していると考えられます。

回避方法は、パッチ適用かバージョンアップ以外には確認できませんでしたが、6.5はかなり古いバージョンのため、メーカサイト上には見つけられず、パッチの入手が困難となっております。

とのこと。既存バグで回避はパッチ適用のみだが、利用バージョンが古くパッチが入手不可という結果に。。
結果的にギリギリエラーが出ない2～3GB程度に分割されたdmpファイルが偶然見つかったので、そちらでなんとかリストアは出来ましたが、一時はどうなることやらとかなり肝を冷やしました。。
※コマンド実行からメモリ不足エラーが出るまで、1時間から長くて5時間程度要してしまうのも悩みの種でした。。

＜実行環境＞
対象サーバ：HP Proliant DL 385 G5（バックアップサーバ）
搭載メモリ：8GB
プロダクト：Veritas
製品名：NetBackup 6.5

複数テープを連続的にリストアしようとすると、「`Restore Started`」のメッセージ出力されて以降、処理が開始されないことがある。

複数テープのリストアを続けて実行しようとしたところ、1本目では「Restore Started」のメッセージ後即座にリストアが開始されたのですが、2本目になると「Restore Started」後、後続処理が開始されず、リストアjobの状態も「Queued」から変化なし。

何度か様々なパターンで試行しましたが、2本目で本事象が高頻度で発生するため、サポートに問い合わせをしました。
サポートからの回答は、

リストアジョブがアクティブになるまでにかかる時間は、主に復元されるファイルの数によって異なります。リストアするファイルの数が多いほど、ジョブがQueued状態に留まる時間が長くなります。

リストアジョブのStateが「Queued」は、マスターサーバー（CPU、メモリ、およびイメージカタログを保持するディスク）の仕様と、ファイルのリストを作成している間にリストアジョブで使用できるリソース量にも依存します。
マスターサーバーが頻繁にスワップしている場合や、マスターサーバーで他の多くのジョブが実行されている場合は、ジョブがQueued状態に留まる時間が大幅に増加します。

・・・。
釈然としない回答でしたが、時間を空けてコマンド再実行を行うと事象としては解消されました。
複数テープの連続的リストアを行うためにシェルスクリプト等で自動化を図る場合には、別途策を講じる必要がありそうです。

以上、私がテープリストア時にハマったポイントでした。

終わりに

上記で上げたハマりポイントなど不便なところはたくさんありますが、一方で、安価で大容量なテープメディアや可搬性に優れている点などから磁気テープによるオフラインでのバックアップ/リストアは近年再評価されていると言われています。

テープ装置での運用を導入する際には、メモリ依存で処理エラーが発生するバグなども念頭に置き、本番運用を想定したリストアのテストも抜かりなく実施できればと思います。