IBM Cloud: VSI for VPC のシステム・バックアップ取得・リストア方法 (代替策) 〜RHEL版〜

# 1. はじめに
IBM CloudのVirtual Server for VPCにおいては、現在システムバックアップを取得する機能がありません。

そこで、本記事では、IBM CloudのVPCのVSI(Virtual Server)のシステム・バックアップ方法について、Virtual Server for Classicとの違いを元に、Virtual Server for VPCの機能を利用したシステムバックアップの代替策を記載します。

後半では、いくつかのパラメータの変化を確認しました。
Image Templateを取得しているためデータや設定は基本的に変更されていないはずですが、Image templateという複数のサーバーを生成する仕組みの上で、元のサーバーと変わってしまっていないかという箇所を重点的に選択して確認してみました。

### Virtual Private Cloud (VPC)のシステムバックアップ、及び、代替策
しかしながら、IBM CloudのVPC上のVSIにはClassicのような、イメージからブートする・ロードするといった機能に相当する機能がなく、VPCのVSIでOSのリカバリが必要となった場合、新たにVSIを作成する方法しかございません。この場合、通常のオペレーションでは、IPアドレスなどが変更されてしまい、システムバックアップとしては利用できないこととなります。

そこでシステムバックアップの代替策として、VSIのimage template機能を利用した手順をご案内いたします。この手順に則れば、OSの構成やソフトウェアの導入・構成など、起動ディスクに関する構成情報をリストアすることが可能となり、システムバックアップと同等の効果を得ることができます。（あくまで代替案ですので、ご理解ください...）

バックアップ手順：
　　1. boot volumeのイメージを作成

リストア手順：
　　1. リストア対象のVSIを削除
　　2. イメージリストア用のAPIコマンドの作成（そこで、IPアドレスを指定）
　　3. APIコマンドの実行

システムリストアで、元のVSIと同じIPアドレスを付与する場合、IPアドレスがかぶらないように、新規VSI作成前に古いVSIを削除しておく必要があります。

# 2. VPC上のVSIのバックアップ作成 ＆ リストアストア手順について

以下の流れに沿って、手順についてご紹介いたします。
　　1. 今回利用したバックアップ対象環境概要
　　2. イメージを利用したバックアップ手順
　　3. リストア手順
　　4. リストア後の確認（パラメータなどの変更点の確認）

### 2-1. 今回利用したバックアップ対象環境概要
今回利用したVSIの概要について説明いたします。イメージ作成するVSIのOSは以下の通りです。
a) OS: Red Hat Enterprise Linux 8.4 (Ootpa)
b) Data Volume: 50GBをattach


### 2-2 バックアップの取得（boot volumeイメージの作成）
VSIの詳細画面からアクションメニュー → インスタンスの停止を選択し、対象のVSIを停止します。
**※ boot volumeイメージの作成する場合は、システム停止が必須となります。**
1. VSIの詳細画面から`アクションメニュー` → `インスタンスの停止`を選択し、対象のVSIを停止します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/9cc2ac0e-a42f-de47-1ac7-bc31495348ad.png" width=50%>
2. 同様に、VSIの詳細画面から`アクションメニュー` → `イメージの作成`を実行します。
<img src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/f364fa0c-9295-05fc-6f54-a9f3eef0b486.png" width=50%>
3. イメージが作成されました。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/86b7de20-a94d-2440-a4e9-f6ba6a3fe14f.png width=50%>

※Data Volumeはsnapshot機能を用いてバックアップを取得しました。

# 3. システム・リストア方法
### 3-0.　削除前の注意
サーバーを削除する前に、以下をご確認ください。

- 可能であれば一度同じVPC or 異なるVPCで、Image templateを使ってサーバーが正しくプロビジョニングできることを確認する。
    - 異なるVPCであれば同じIPアドレスが使用可能です。
-  Boot volumeも自動削除を無効にしておき、万が一消去された設定があったときにリストアできるように備えておく。新環境の十分な確認を以って削除する。

<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/da8b05e4-c2ab-278c-4bdf-e4e5ccd36748.png width=80%>

### 3-1. リストア対象のVSIを削除

VSIの詳細画面から`アクションメニュー` → `インスタンスの削除`を選択し、対象のVSIを停止します。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/3b7e14ab-fe42-d944-4f05-6b06bdc86424.png width=50%>

### 3-2. イメージリストア用のAPIコマンドの作成（そこで、IPアドレスを指定）

1.インスタンス作成画面にて、`オペレーティング・システム` → `カスタム・イメージ`からリストア対象VSIのイメージを選択し、`サンプルAPI呼び出しの取得`をクリックします。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/0ba0ab59-1d27-22cd-951d-7175204e51b2.png width=80%>

2.以下のような画面が表示されるので赤枠部分をクリックしてコピーし、シェルスクリプトとして保存します。
（create_vsi.shファイルを作成し、コピーしたものを中にペースト）
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/74c0e5c7-e9b1-7d9d-4a98-0450dca2b299.png width=65%>

3.IPアドレスの指定がないので、`primary_netowork_interface`内に `primary_ipv4_address`フィールドを追加します。

```
（省略）
  "primary_network_interface": {
    "name": "eth0",
    "primary_ipv4_address": "10.0.1.5",　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　# <- この行を追加
    "allow_ip_spoofing": false,
    "subnet": {
      "id": "02e7-ff96ff2a-fa27-4d88-b855-98fb85112636"
    },
    "security_groups": [
      {
        "id": "r022-1a2bb9f2-7647-4332-8a1b-eb925fb6e160"
      }
    ]
  },
（省略）
```

### 3-3. リストアのAPIコマンドの実行
1.IAMトークンの取得 コピーしたAPIを実行する際に$iam_tokenを使用するので、以下のコマンドでIAMトークンを取得します。
アクセストークン取得に関しての詳細は[こちら](https://cloud.ibm.com/docs/key-protect?topic=key-protect-retrieve-access-token&locale=ja)。

```
# export iam_token=`ibmcloud iam oauth-tokens | awk '{printf $4}'`
```

2.シェルスクリプトを実行すると、VSIが作成されます。

```
# sh create_vsi.sh
{"bandwidth":4000,"boot_volume_attachment":......
(省略)
```

3.VSI作成されたことを確認
これで無事にリストアすることができました。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/dae7cb68-05c3-202b-2335-422960432e2d.png width=70%>
IPアドレスもリストア対象のVSIと同じものが割り当てられています。
<img src=https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2199676/f940259b-4c2a-ecfa-6426-89546e57a1d7.png width=70%>

Data Volumeについては、Snapshotから復元してattachしました。

# 4. リストア後の確認（パラメータなどの変更点の確認）
リストア前後の変更点を、以下のパラメータで確認してみます。
　　1. IPアドレス・MACアドレス
　　2. uuid
　　3. machine id
　　4. ip routeコマンド
　　5. /etc/ssh/sshd_config ファイル
　　6. ~/.ssh/配下



### 4-1. IPアドレス、MACアドレス
MACアドレスは変更されています。


```:リストア前VSI
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:00:08:0e:74:a5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.5/26 brd 10.0.1.63 scope global dynamic noprefixroute eth0
       valid_lft 327sec preferred_lft 327sec
    inet6 fe80::8ff:fe0e:74a5/64 scope link
       valid_lft forever preferred_lft forever
```


```:リストア後VSI
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 02:00:02:0e:74:a5 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.5/26 brd 10.0.1.63 scope global dynamic noprefixroute eth0
       valid_lft 200sec preferred_lft 200sec
    inet6 fe80::2ff:fe0e:74a5/64 scope link
       valid_lft forever preferred_lft forever
```



### 4-2. uuid
2つのコマンドで確認し、uuidは異なるidが付与されていました。

```:リストア前VSI
# cat /sys/devices/virtual/dmi/id/product_uuid
61a3ca85-7c12-41ff-bc25-8f7a0f6a6559
# dmidecode -s system-uuid
61a3ca85-7c12-41ff-bc25-8f7a0f6a6559
```

```:リストア後VSI
# cat /sys/devices/virtual/dmi/id/product_uuid
9e3c5e58-7772-435a-82a7-867c534b9847
# dmidecode -s system-uuid
9e3c5e58-7772-435a-82a7-867c534b9847
```

また、Volumeのuuidは、vda配下に変化はありませんでした。

```:リストア前VSI
# lsblk -pf
NAME        FSTYPE  LABEL      UUID                                 MOUNTPOINT
/dev/vda
├─/dev/vda1
├─/dev/vda2 vfat               7B77-95E7                            /boot/efi
└─/dev/vda3 xfs     root       d47ead13-ec24-428e-9175-46aefa764b26 /
/dev/vdb
/dev/vdc    iso9660 cidata     2021-11-03-06-01-14-00
/dev/vdd    swap    SWAP-xvdb1 32456c80-7060-4ba9-8e38-7da59c08facc
#
```

```:リストア後VSI
# lsblk -pf
NAME        FSTYPE  LABEL      UUID                                 MOUNTPOINT
/dev/vda
├─/dev/vda1
├─/dev/vda2 vfat               7B77-95E7                            /boot/efi
└─/dev/vda3 xfs     root       d47ead13-ec24-428e-9175-46aefa764b26 /
/dev/vdb
/dev/vdc    iso9660 cidata     2021-11-04-06-17-43-00
/dev/vdd    swap    SWAP-xvdb1 e4385e9f-3bc2-4786-aef3-b981c944ea55
```

### 4-3. machine id
machine idに変化はありませんでした。

```:リストア前VSI
# hostnamectl
   Static hostname: vsi-backup
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 7fa98b608ea40d90149abb93ba5df113
           Boot ID: 91fa86323ca541be8d203a8ebded0e2c
    Virtualization: kvm
  Operating System: Red Hat Enterprise Linux 8.4 (Ootpa)
       CPE OS Name: cpe:/o:redhat:enterprise_linux:8.4:GA
            Kernel: Linux 4.18.0-305.7.1.el8_4.x86_64
      Architecture: x86-64
```

```:リストア後VSI
# hostnamectl
   Static hostname: vsi-backup
         Icon name: computer-vm
           Chassis: vm
        Machine ID: 7fa98b608ea40d90149abb93ba5df113
           Boot ID: 69c197fa5c9242a0af97be846ffa975f
    Virtualization: kvm
  Operating System: Red Hat Enterprise Linux 8.4 (Ootpa)
       CPE OS Name: cpe:/o:redhat:enterprise_linux:8.4:GA
            Kernel: Linux 4.18.0-305.7.1.el8_4.x86_64
      Architecture: x86-64
```

### 4-4. ip routeコマンド
リストア前に以下を追加しました。
`192.168.0.0/24 via 10.0.1.1 dev eth0 proto static metric 100`

結果、ルーティングテーブルは変更を加えた箇所は、リストア後に反映されていませんでした。

```:リストア前VSI
# ip r
default via 10.0.1.1 dev eth0
default via 10.0.1.1 dev eth0 proto dhcp metric 100
192.168.0.0/24 via 10.0.1.1 dev eth0 proto static metric 100
10.0.1.0/26 dev eth0 proto kernel scope link src 10.0.1.5 metric 100
```

```:リストア後VSI
# ip r
default via 10.0.1.1 dev eth0
default via 10.0.1.1 dev eth0 proto dhcp metric 100
10.0.1.0/26 dev eth0 proto kernel scope link src 10.0.1.5 metric 100
```

### 4-5. /etc/ssh/sshd_config ファイル
ファイルの編集部分に変化はありませんでした。

```:リストア前VSI
(中略)
#ClientAliveInterval 0
#ClientAliveCountMax 3
ClientAliveInterval 30
ClientAliveCountMax 3
```


```:リストア後VSI
(中略)
#ClientAliveInterval 0
#ClientAliveCountMax 3
ClientAliveInterval 30
ClientAliveCountMax 3
```

### 4-6. ~/.ssh/配下
sshする際に使用する公開鍵を、リストア前は鍵を1つ、リストア後は鍵を2つ、IBM Cloudポータルにて指定しました。
また、リストア前に`backup-test.txt`ファイルを別で作成しました。
authorized_keysファイルのみ中身が変化していました。

```:リストア前VSI
# cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC...
(中略)
== [追加したkey元PC①]
# 
# cat backup-test.txt
backup test
```


```:リストア後VSI
# cat ~/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC...
(中略)
...OcZ8oHCQ== [追加したkey元PC①]
ssh-rsa AAAAB3NzaC...
(中略)
...OZc4fxQ== [追加したkey元PC②]
# 
# cat backup-test.txt
backup test
```


# 5. リカバリの際にも元のVSIを残しておく運用方法を取りたいと言う場合
最初からCLIかAPIを使ってsecondary Interfaceを定義して利用するIP addressを明示的に指定してください。リカバリの際には、一旦異なるprimary IP addressで新たなVSIを作成し、元のVSIからsecondary IP addressを削除して、新たなVSIにsecondary interfaceとそのIP addressを明示的に指定して追加することで、secondary IP addressを旧VSIから新VSIに移動してください。

# 注意
Imageの作成の際には、VSIを停止する必要があるので、日常的なシステムバックアップとして使うことは難しいと思います。OSのupgradeなど、停止を伴う作業の際に、Imageの作成をし直すなどの工夫が必要でしょう。

## 参考
IPアドレス指定のプロビジョニングに関して、こちらを参考にさせていただきました。
[IBM Cloud: VPCのVSIをIPアドレス指定でプロビジョニングする方法](https://qiita.com/testnin2/items/337bc02892024fb684a3)