今さら教えてくれる人がいない仮想テープライブラリ(VTL)の容量設計

#はじめに
この記事は、適当にバックアップストレージを選定したらテープ形式だった、テープとディスクの違いって何、という数か月前の私のような人に贈ります。



#テープバックアップとは
＃ぐぐれば出てくるので割愛



#仮想テープバックアップとは
テープバックアップ技術を仮想化して、書き込む媒体にはHDDなどを用いるバックアップ方式です。仮想化することでデジタル重複削除機能などが利用でき、テープバックアップよりもストレージ容量を少なく出来たりします。
~~主に既存バックアップ装置が物理テープバックアップをしていないと技術選定の優位性がないよ！~~



#仮想テープバックアップ装置の各呼称
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/9be9407d-7b05-017c-c43b-bac8672230f2.png)

**テープ**
仮想化された磁気テープ。容量は10GB、100GB、1000GB…と選択可能なため、設計して設定する必要がある。別名としてカートリッジやスロットとも。

**メディアグループ**
テープをまとめた範囲。

**仮想テープライブラリ(VTL)**
メディアグループをまとめた範囲。仮想テープライブラリの構成要素としてドライブが存在し、ドライブ数はメディアグループ（テープ）書き込みの多重度に等しくなる。

**デバイス**
仮想テープライブラリの集合体（少なくともこの記事ではその意味で使います）。

**ＨＤＤ**
仮想テープバックアップ装置の記憶装置。

**ＨＤＤプール**
仮想テープバックアップ装置の記憶領域。抽象化されて仮想テープとして利用される。

※基本的に仮想テープからHDDに書き込まれる際にはストレージの重複削除機能なので容量縮小されるため、仮想テープ容量>>>HDD容量となる。~~体感で1/20～1/40ではないでしょうか。~~重複削除率などは各バックアップストレージのカタログスペックなどを確認ください。

#仮想テープを利用したバックアップデータの書き込みイメージ
テープストレージはシーケンシャル書き込みになるので、基本的にテープの頭から書き込まれて容量が消費されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/3e035346-bd98-589d-03b7-c1c415cf0230.png)

また、複数のテープにまたがったデータ書き込みも可能です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/3c53e79d-2f11-b6c3-bd5a-cd58e4c9bdce.png)


#仮想テープを利用したバックアップデータの再利用イメージ
バックアップ期間を過ぎたりして、仮想テープ内のデータが必要なくなることをリタイアを呼びます。
リタイアしたテープは再利用するため、内容を消去します。これをブランク処理といいます。
ブランク処理された仮想テープは、次のバックアップ領域として活用されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/3e3277fc-289a-fd4d-7c55-8eadae8984a5.png)



#システムバックアップ時の仮想テープ容量設計
具体例としてシステムバックアップを例に考えます。
なお、システムバックアップ容量は100GB、バックアップ世代は2世代とします。

###①テープ容量>システムバックアップ容量の場合(2倍以下)
テープ容量を120GBとして考えます。
1回目バックアップ(計100GB)は1テープ(計120GB)にて賄える形になります。
2回目(計200GB)は2テープ(計240GB)が必要になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/edb35768-0024-2411-d566-b22e67cf29b6.png)


ただし、以降は少し検討が必要になります。
3回目のバックアップ完了後は2回目+3回目の2世代分で200GBしか利用しませんが、
バックアップ最中は1回目+2回目+3回目(書き込み中)で3世代の最大300GBを利用します。
よって3回目は3テープ必要です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/de2b1f33-e4d6-ceb1-4d34-c422e9b18529.png)

4回目のバックアップについても3回目と同様ですが、ここからはテープの使いまわしの考えが必要です。
テープの使いまわしのためには、事前に使わなくなったテープのブランク化(データ消去)が必要になります。
ただし、4回目のバックアップ前にブランク化を行うとデータ喪失が発生します。
（4回目のバックアップが失敗すると、1世代分しか残存していません）

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/2f018103-0955-8b59-6cea-ffa9ecaee1d8.png)

よって、4回目のバックアップの際にはデータ喪失を防ぐために追加でテープを準備しておき、
4回目のバックアップが完了したのち、完全に使わなくなったテープをブランク化します。
このブランク化したテープは再利用するため、最終的にテープ本数は4本あれば十分となります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/bf76eca1-f03e-bb22-c1b4-3cb99c836aac.png)


###②テープ容量>システムバックアップ容量の場合(2倍以上)
テープ容量とシステムバックアップ容量に２倍以上の差がある場合、
テープ数は2本で済みます。

イメージ図は長くなるので折り畳み。
<details>
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/9986be45-4da7-96b3-9fb2-41bb9fada0f6.png)
</details>


###③テープ容量>システムバックアップ容量の場合(テープ先頭書き込み)
ストレージによっては**テープ先頭書き込み**というものもあります。
この場合、イメージとしては相当シンプルとなります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/bd8540c9-2a04-7b27-ec18-76b6a58ffb36.png)

よって、テープ容量>システムバックアップ容量の際、
テープ本数は3本となります。


#データバックアップ時の仮想テープ容量設計
こちらも具体例で考えます。
なお、データバックアップ容量は200GBとして、バックアップ世代は以下とします。
　バックアップ期間：1か月
　フルバックアップ：週1回（日曜日）
　増分バックアップ：週6回（月曜日～土曜日）
　データ更新率　　：10%

>※増分バックアップと差分バックアップの違いは以下。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/d1ae69df-a41b-c449-ecdd-47107b9a8dc0.png)

###①データフルバックアップ容量
週1回を1か月ということで、5週、つまり5回のフルバックアップが行われます。
```31日 / 7日 ≒ 4.4週 < 5週```

また、６回目のフルバックアップ中については、**５回分の過去バックアップ＋６回目の進行中バックアップ**がストレージ内に存在することになるので、結果として６回分の容量が必要となります。

必要バックアップ回数は　**世代数＋１**　となります。
よって容量としては、６回×１００ＧＢ＝６００ＧＢ　が必要です。


###②データ増分バックアップ容量
週６回を１か月ということで、５週×６日で３０回の増分バックアップが発生します。
また、３１回目以降のバックアップを考慮し、３１回分の容量が必要です。

必要バックアップ回数は　**世代数＋１**　となります。

また、増分バックアップで必要なものがデータ更新率になります。フルバックアップに対しどれだけ変更が発生するかという要素です。こちらも既存システム等で調査したり、業務要件から仮定できればいいですが、一般値として５～２０％程度を想定しておけば一旦は良いのではないでしょうか。今回は１０％と仮定します。

よって容量としては、310GBが必要です。
```31回 * 100GB * 10% = 310GB```

###③データバックアップとテープ本数
データバックアップ容量としては以下となりました。
　フルバックアップ容量：600GB
　増分バックアップ容量：310GB
　合計容量　　　　　　：910GB

あとはテープ容量によって本数が決まります。

####③の１ １本のテープ容量＜バックアップ総容量
テープ容量が100GBの場合、10本あればバックアップ可能となります。
```910GB / 100GB = 9.1本 < 10本```

ただし、リタイア／ブランク処理のための予備領域が必要です。厳密に考えるなら1本となりますが、1本のテープ容量＜バックアップ容量となる場合は、全体の本数に1.2倍～1.5倍程度の本数を準備しておけばまず間違いないかと思います。
ここでは最低10本にバッファとして1.2倍をかけて、12本準備することとします。
```10本 * 1.2 = 12本```

####③の２ １本のテープ容量＞バックアップ総容量
テープ容量が1000GBの場合、1本あればバックアップ可能となります。
```910GB / 1000GB = 0.9本 < 1本```

ただし、リタイア／ブランク処理のための予備領域が必要です。1本追加して、合計2本が必要になります。
```1本 * 1本 = 2本```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/201787/b930f99f-a59d-5287-cf1f-77c5fc548380.png)


#メディアグループの設計
これまではシステムバックアップやデータバックアップのテープ数を考えましたが、これらのテープのまとまりに名前を付けたものがメディアグループとなります。

例えば、以下のようなグループ分けなどで区別して管理します。

```
mediagroup1_sv_web1 :ウェブサーバのシステムバックアップ領域、テープ1～3を利用
mediagroup2_sv_ap1  :APサーバのシステムバックアップ領域、テープ4～6を利用
mediagroup3_sv_db1  :DBサーバのシステムバックアップ領域、テープ7～9を利用

mediagroup4_dt_web1_sys :ウェブサーバのデータバックアップ領域(システム領域)、テープ10～20を利用
mediagroup6_dt_web1_low :ウェブサーバのデータバックアップ領域(データ領域)、テープ21～30を利用
mediagroup5_dt_web1_log :ウェブサーバのデータバックアップ領域(ログ領域)、テープ31～40を利用
```

#仮想テープライブラリ(VTL)の設計
VTLはメディアグループをまとめたものです。ここでの設計要素としては以下があります。

**ドライブ**
並走書き込みの重複度。2以上だとパラレル書き込みによる複数バックアップ処理の同時実行が可能。ただし、**ドライブ数を上げるとライセンスが必要になる場合があるので注意。**

**テープ容量**
今までのテープ容量ですが、**VTL単位で揃える必要があります。**なので、どのメディアグループ／どのバックアップをどのVTLに搭載するかの検討が必要になります。特にシステムバックアップとデータバックアップを同じVTLに搭載する際には両方のバックアップに適合する容量を選定する必要があります。

**テープ本数**
テープ本数についても、VTL全体としての制約がある場合があります。例えばVTL内の最大テープ本数は1024本など。あまり小さいテープ容量で設計すると、テープ本数制約に掛かる可能性がありますので、それぞれのストレージ製品マニュアルを参照の上、設計するようしてください。

**メディアグループ数**
メディアグループ数についても、VTL全体としての制約がある場合があります。ストレージ製品マニュアルを参照の上、設計するようしてください。

**VTL数**
VTL数についても、VTL全体としての制約がある場合があります。ただし、VTLについてはライセンス購入で追加できる場合もあります。ストレージ製品マニュアルを参照の上、設計するようしてください。

これらの特性があるので、VTLを複数作成するのも有効です。VTLごとにドライブは別ですので、**VTLを分けるとバックアップ処理が並列実行できます。**以下に例を記載します。

```
VTL1_SYS1_SYS   :Aシステムのシステムバックアップ領域。ドライブ数2。
VTL2_SYS1_DATA  :Aシステムのデータバックアップ領域。ドライブ数1。

VTL3_SYS2_SYS   :Bシステムのシステムバックアップ領域。ドライブ数1。
VTL4_SYS2_DATA1 :Bシステムのデータバックアップ領域その１。ドライブ数1。
VTL5_SYS2_DATA2 :Bシステムのデータバックアップ領域その２。ドライブ数1。
```
例1) VTL1のAサーバシステムバックアップとBサーバシステムバックアップは**同時実行可**。
例2) VTL2のAサーバデータバックアップとBサーバデータバックアップは**同時実行不可**。
例3) VTL4のCサーバデータバックアップとVTL5のDサーバデータバックアップは**同時実行可**。
※同時実行不可の場合は、先行処理が完了するまで待機ジョブとなります。

#HDDの設計
最後に、物理設計となります。

仮想テープ/メディアグループ/VTLの設計をしましたが、それらは最終的にバックアップストレージ内のHDDに書き込まれます。ですので、**どれだけHDDの容量が必要なのか？**が最終的に必要な設計要素となります。

ここまでの設計で必要なテープ数とテープ容量は算出されているかと思います。その容量がそのまま必要になることはほぼなく、ストレージの重複削除機能で圧縮され、より少ない容量で十分となります。

この重複削除率についても製品データシートに期待値の記載があるかと思いますが、おおよそ公表値は1/20、また実際のシステム運用では1/30～1/40となっていることが多いかと思います。

例として、VTL容量が200TB、重複削除率が1/20の場合は10TBが必要になります。
```200TB * 1/20 = 10TB```

ここでHDDが2TB/RAID6/SpareDisk付きとすると、8本が必要になります。
`必要容量 10TB / 2TB = 5本
RAID6   5本 + 2本 =　7本
Spare   7本 + 1本 = 8本
`

＃それとは別にバックアップストレージのシステム領域で別途要ったりもします。


#最後に
こんなこと考えないバックアップサービスがあればいいですよね。


#参考
始めよう、テープバックアップ！！
https://www.fujitsu.com/jp/products/computing/storage/tape/eternus-lt/feature/tape-backupbg/

磁気テープのバックアップをやめるこれだけの理由
https://ascii.jp/elem/000/000/658/658961/

仮想テープライブラリは忘れられた選択肢？ (1/3)
https://www.itmedia.co.jp/im/articles/0801/21/news116.html

LTO/オートローダー/仮想テープライブラリの基礎知識
https://www.slideshare.net/mktredwell/lto2

「バックアップ早わかり」講座[前編] バックアップとテープストレージの基礎
http://www.hitachi.co.jp/products/it/server/ha8500/column/no008_p01.html

「バックアップ早わかり」講座[中編]バックアップシステムの構築
http://www.hitachi.co.jp/products/it/server/ha8500/column/no009_p01.html

「バックアップ早わかり」講座[後編]アーカイブシステムとILM
http://www.hitachi.co.jp/products/it/server/ha8500/column/no010_p01.html

テープドライブ
https://ja.wikipedia.org/wiki/%E3%83%86%E3%83%BC%E3%83%97%E3%83%89%E3%83%A9%E3%82%A4%E3%83%96

テープライブラリ
https://ja.wikipedia.org/wiki/%E3%83%86%E3%83%BC%E3%83%97%E3%83%A9%E3%82%A4%E3%83%96%E3%83%A9%E3%83%AA

ディスク・バックアップ - 仮想テープ・ライブラリ(VTL / SVTL) 機能
https://www.quest.com/community/jp-ja/w/data-protection-wiki/646/--vtl-svtl

１からはじめるNetVault Backup 第14回 テープメディアの利用に関連したオプション
https://www.quest.com/community/jp-ja/b/blog/posts/1-netvault-backup-14

【今更聞けない】差分バックアップと増分バックアップの違いとメリット
https://www.backstore.jp/blog/2016/08/17/differential_and_increment_backup/