こんにちは。
ヒゲダルマです。
とある案件で久しぶりにテープ(LTO)を使ったデータ移行を行うことになりました。
昔、ネットワークが細かった当時にはテープメディアを使ったデータ移行って良く有ったと思うのですが、最近はネットワークが太くなったことも有り、データ移行って殆どネットワーク経由で行うようになり、データ移行にテープメディアを使うケースは全くと言ってよいくらい無くなってしまいました。
しかし、今回は移行元と移行先のネットワークがWAN超えの為、非常に細く、TB単位のデータ移行には使えないというケースです。
こういったケースでは USB HDD を使うのが最近では一般的かなと思うのですが、お客様の規則により USB 媒体は NG ということから、サーバーに内蔵したデータバックアップ用の LTO6 を使ってデータ移行を行うことになった次第です。
そこで、作業計画を立案する為に、検証環境で各種所要時間を計測してみましたので、備忘録兼ねて、下記致します。
ちなみに、弊社では各種サーバーの構築/移行/切替を数多く手掛けております。
ご用の際はお気軽にお問い合わせ下さい。
▼検証環境
- Machine:HPE ProLiant ML350 Gen10
- CPU:XeonS 4208 2.1GHz 1P8C CPU
- Memory:64GB
- HDD:SAS 900GB 15krpm × 10(RAID5)
- Tape:LTO6 Ultrium 6250 (内蔵型)
- OS:Windows Server 2016 Standard Edition
- Backup S/W:VERITAS Backup Exec 21.1
▼検証概要
- 移行元で1TB(10MB×102400ファイル)のデータをTape1へフルバックアップ
- 移行先でTape1をカタログ処理
- 移行先でTape1からフルリストア
- 移行元で1TB中100GB分(10MB×10240ファイル)のデータを更新(削除/追加)
- 移行元でTape2へ増分バックアップ
- 移行先でTape2をカタログ処理
- 移行先でTape2から増分リストア
検証は以上のステップで行いました。
実際のデータ移行と同様のシナリオで、事前にフルバックアップ&フルリストアを行っておき、サーバー切替のタイミングでは増分バックアップ&増分リストアにて切替に伴うダウンタイムの最小に抑える計画です。
なお、データは “ランダム文字列ファイル大量生成ツール” でランダムな文字列のダミーファイルを上記数量生成しました。OS 標準の fsutil コマンドでダミーファイルを生成することも可能ですが、ゼロ書き込みのファイルとなり、LTO へのバックアップ時に圧縮が効き過ぎるのでは?と思い、上記ツールを使用しました。
バックアップオプションはハードウェア圧縮有り、事後検証有りの設定で行いました。
▼結果
移行元で1TB(10MB×102400ファイル)のデータをTape1へフルバックアップ
⇒ 3時間50分
LTO6 のカタログスペック上の最大転送速度が非圧縮で 160MB/s なことを考えると少々遅いようにも見えますが、バックアップ後の検証込みで約74MB/s 出ていますので、まあこんなものかと思います。
移行先でTape1をカタログ処理
⇒ 3m
移行先でリストアを行うにはカタログ処理が必要となります。
カタログ処理とは Tape のヘッダーに書かれた “どのようなバックアップが当該メディアに含まれるのか” という情報を Backup Exec に読み込ませてあげる処理です。
バックアップとリストアが同一サーバーで有れば不要ですが、今回のように移行元と移行先でサーバーが異なるケースではリストア処理の前に先ずカタログ処理を行う必要があります。
移行先でTape1からフルリストア
⇒ 1時間1分
約280MB/s のスループットとなりました。
書き込み先の HDD のスペックにもよるでしょうが、バックアップと比較して半分以下の時間で処理を終えました。
移行元でTape2へ増分バックアップ
⇒ 18分
バックアップ後の検証込みで約94MB/s 出ました。
フルバックアップよりも若干スループットは良かったことになります。
移行先でTape2をカタログ処理
⇒ 3m
前述の通り、Tape のヘッダーを読むだけなので、フルバックアップの Tape1 と増分バックアップの Tape2 で違いは出ませんでした。
移行先でTape2から増分リストア
⇒ 8m
約213MB/s のスループットとなりました。
フルリストアと比べると若干遅くなりました。
今回は検証に使用したファイルが 10MB と比較的大きなファイルだったのでスループットは悪くなかったのでは?と思います。
もっと小さなファイルが大量にあるというケースではスループットが低下するものと推察します。
とは言え、一般的なファイルサーバーであれば、今回の検証結果のスループットと大差無いように思いますので、バックアップやリストアの所要時間の参考になるのでは無いでしょうか。
ところで、Backup Exec については、以下の記事もございますので、お暇な時にご一読下さい。
Backup Exec 16 インストール
Backup Exec 16が起動しない
VERITAS Backup Exec 21.0 をインストールしてみた
VERITAS Backup Exec 21.1 をインストールしてみた
以上、駄文散文ではございましたが、ご拝読ありがとうございました。
GFCのホームページはこちら!
Backup Execに関連するGFCのサービスはこちらから。
お問い合わせフォームはこちらから。