作業目的

旧ファイルサーバのバックアップデータを新ハードディスクにリストアし，新ファイルサーバへ移行(装着)し，旧ファイルサーバと同じ設定で運用を再開する。

前提

  1. クライアントPC:Ubuntu18.04LTSとWindows10Pro，どちらもアクティブディレクトリに参加。
  2. クライアントPC：Ubuntu18.04LTS上では，autofsを利用してファイルサーバと共有。
  3. 新ファイルサーバ：Ubuntu18.04LTSserver アクティブディレクトリに参加。
  4. ドメインコントローラ：CentOS6.10(Final)samba4にて運用。
  5. 旧ファイルサーバ(samba）のデータは，外付けHDDにバックアップ済み。

4.の旧ファイルサーバ(samba)は，CentOS5.10(Final)で運用していました。CentOS5は2017年3月31日にサポートが終了したので，新サーバ(2.のUubntu18.04)に移行することにしました。

旧ファイルサーバのデータは，1.のクライアントPCのUbuntu18.04LTSのバックアップアプリDeja Dupにより，外付けHDDにバックアップ済みです。

クライアントPCから旧ファイルサーバ，新ファイルサーバどちらにもKerberos認証によるsamba共有を実現しています。

クライアントPCのauto.smbは，次のように，マウント情報が記載されている。（一部抜粋）

kanri-a -fstype=cifs,rw,uid=10000,gid=10001,sec=krb5,vers=1.0,cruid=usr01 ://srv01.shigi.local/&

参考に，ファイルサーバのsmb.confの設定も（旧も新も同じもの）。（一部抜粋）

[kanri-a]
comment = management of work
path = /mnt/kanri-a
read only = No
browseable = Yes
valid users = SHIGI+usr01
force user = kanri-a

usr01,kanri-a,kanri-b,publicは，アクティブディレクトリのユーザである。sambaサーバには，登録していない。すべて，ドメインコントローラ（dc01.shigi.local）に登録してある。

krb5認証により，クライアントPCから，ファイルサーバにアクセスできるので，とても便利だ。

ザクッと移行の流れを，

バックアップデータを新しいハードディスク(1TB)に復元。復元が終わった新しいハードディスクを新ファイルサーバ機に増設。動作確認後，移行作業完了。

なお，新ファイルサーバのシステム部分(Ubuntu18.04LTSserver )は，すでに/dev/sdaにインストール，運用中。旧ファイルサーバのデータを復元した新しいハードディスクは，/dev/sdbとして，新ファイルサーバ機に増設します。

手順

  1. 新ハードディスクの準備。
  2. データの復元。
  3. 旧ファイルサーバの切り離し。
  4. 動作確認。

1.新ハードディスクの準備。

(1)　パーティション作成

パーティションテーブルをGPTとします。

データを復元する新ハードディスクの容量は，250GB。（実際には，1TBを，６つのパーテションに切っています。ここでは，例として250GBを移行試験として示しました。）

これを３つパーティションに分割します。それぞれ，ラベル(partlabel)と容量を次のようにする。

/dev/sdb1 パーティション名publick,約50GB，ファイルシステムxfs
/dev/sdb2 パーティション名kanri-a,約100GB，ファイルシステムxfs
/dev/sdb3 パーティション名kanri-b,約100GB，ファイルシステムxfs

パーティション名は，既に，旧ファイルサーバで使用していたものと同じものを使用する。この名前を変えると，ファイルサーバのsmb.confで設定している項目を変更する必要がある。さらに，クライアントPCでも，autofsの設定ファイルも変更する必要がある。可能な限り，過去の設定はそのままりようしたいので，パーティション名はそのまま利用する。もちろん，変更する場合は，前述の各設定もあわせて変更する。

パーテションを作成するツールには，Gpartedです。CUIベースのコマンドでは，gfdiskやpartedもありますが，GUIのGpartedの方が，視覚的に分かりやすいので，今回はGpartedを使いました。（実は，gdiskやpartedで初めはやってみたのですが，作成したパーティションがきちんと認識されていませんでした。なぜかは不明ですが，今回はGpartedでうまくいきました。）

新ハードディスクをUSB経由で，作業用PC（クライアンPC）に接続する。

次に，Gpatedを起動させます。（左上，アクティビティ＞検索ワードを入力＞Gpartedを入力＞アイコンが下に表示されるので，それをクリックする。）

Gparted

起動後，右上のディバイス名（/dev/sdaなど）が表示されているところ，クリックし，/dev/sdbを探しクリックする。

この後，パーティションを作成する。

2.データの復元。

バックアップデータが保存されたハードディスク（右上のHDD）をUSB経由で接続します。

バックアップデータは，Deja Dupで保存済み。全く同じ環境にすべてのデータを復元する場合は，このアプリで復元ボタンを押すだけで済みます。今回は，新ハードディスクは外付けで，作業用PCにマウントします。マウント先は，バックアップ元（旧ファイルサーバ）とはことなるので，Deja Dupの復元ボタンは使えません。

Duplicityコマンドで実行します。

(1)　バックアップデータを保存したハードディスクを作業用PCにマウント

バックアップ用のハードディスクは，Veracryptで，暗号化しているので，復号すると自動的にマウントされています。マウント先は，

/media/veracrypt11/

とします。バックアップデータの保存されているパスは，/media/veracrypt11/bkとします。

普通は，USB経由で接続すれば，自動認識されるので，おそらく次のようにマウントされると思います。

/media/ユーザ名/ハードディスクのUUID

もし，自動認識されないばあいは，手動でマウントします。まず，sudo fdisk -lで，ハードディスクのディバイス名を確認します。もし，/dev/sdc1となっていれば，次のようにntfs-3gでマウントします。マウント先は，/media/bkとします。

sudo mkdir /media/bk
sudo ntfs-3g /dev/sdc1 /media/bk

（マウントを解除する場合は，sudo umount /media/bk）

(2)　データの復元

①　復元するデータの保管場所（パス）を確認。

duplicityによってバックアップされたデータの場所（パス）の一覧をローカルのdup-list-bk.txtに保存。

sudo duplicity list-current-files file:///media/veracrypt11/shigismb-bk/ > dup-list-bk.txt
cat dup-list-bk.txt

保存されている場所がリストになって表示されます。

表示例：
Fri May 10 20:22:00 2019 mnt/public/MX-2310F_20190510_193218.pdf
Wed May 15 18:29:00 2019 mnt/public/MX-2310F_20190515_173811.pdf
Wed May 15 19:23:25 2019 mnt/public/MX-2310F_20190515_183332.pdf
Mon May 20 22:07:28 2019 mnt/public/MX-2310F_20190520_211722.pdf
Mon May 20 22:37:59 2019 mnt/public/MX-2310F_20190520_214732.pdf
Mon May 20 23:35:51 2019 mnt/public/MX-2310F_20190520_224546.pdf
Sun May 26 14:05:06 2019 mnt/public/MX-2310F_20190526_131444.pdf
Wed Jun 5 17:34:31 2019 mnt/public/MX-2310F_20190605_164349.pdf
Sat Jun 8 06:59:51 2019 mnt/public/MX-2310F_20190608_060858.pdf
Sat Jun 8 07:00:07 2019 mnt/public/MX-2310F_20190608_060918.pdf
Tue Jun 18 06:41:01 2019 mnt/public/MX-2310F_20190618_054948.pdf
Thu Jun 20 14:40:18 2019 mnt/public/MX-2310F_20190620_134608.pdf

これを見ると，publicは，/mnt/publicに保存されていることがわかる。kanri-aは，/mnt/kanri-aに，kanri-bはmnt/kanri-bに保存されていた。この情報を元に，データを復元する。

②　データを復元

１．で準備した新ハードディスクは，次のようにマウントする。なお，マウント先は，事前に，mkdirで作成しておく。

sudo mount -t xfs /dev/sdb1 /media/public
sudo mount -t xfs /dev/sdb2 /media/kanri-a
sudo mount -t xfs /dev/sdb3 /media/kanri-b

復元（リストア）は，duplicityのオプション–file-to-restoreを利用する。構文は，次のようになっています。

duplicity [復元元のデータが保存されているURL。(1)で示したパス。] [復元先のパス。(2)①で作成したパス。] –file-to-restore [復元したいデータが保存されているパス。(2)①で確認したパス。]

では，復元します。データ量にもよりますが，かなり時間がかかります。

sudo duplicity file:///media/veracrypt11/bk/ /media/public --file-to-restore /mnt/public
sudo duplicity file:///media/veracrypt11/bk/ /media/kanri-a --file-to-restore /mnt/kanri-a
sudo duplicity file:///media/veracrypt11/bk/ /media/kanri-b --file-to-restore /mnt/kanri-b

3.旧ファイルサーバの切り離し。

旧ファイルサーバ（svr01.shigi.local）をネットワークから切り離す。

新ファイルサーバのホスト名をsvr02からsvr01へ，IPアドレスを192.168.130.211を192.168.130.201へ変更する。

(1)　アクティブディレクトリから離脱。

旧ファイルサーバ上で実行。

sudo net ads leave -U Administrator

(2)　ネットワークから切り離す。

旧ファイルサーバをシャットダウンし，LANケーブルをL2スイッチから外す。

4.動作確認。

まだ，新ファイルダーバは起動していない。

(1)　データを復元した新ハードディスクを新ファイルサーバに装着する。

(2)　新ファイルサーバのfstabを編集

新ファイルサーバを起動する。

sudo vi /etc/fstab
PARTLABEL=kanri-a /mnt/kanri-a xfs defaults 1 2
PARTLABEL=kanri-b /mnt/kanri-b xfs defaults 1 2
PARTLABEL=public /mnt/public xfs defaults 1 2

マウントの確認

sudo mount -a
ls -la /mnt/

kanri-a,kanri-b,pulicが表示さていれば良し。念の為に，ls -la /mnt/kanri-aなどとして，データにアクセスできるか確認しておく。

重要！！！

マウント後に，各ディレクトリのユーザを適切に変更する。つまり，旧ファイルサーバと同じにする。

設定内容
/mnt/knari-aはユーザ名：グループ名がkanri-a:domain users
/mnt/kanri-bはユーザ名：グループ名がkanri-b:domain users
/mnt/publicはユーザ名：グループ名がpublic:domain users

sudo chmod -R 755 /mnt/kanri-a
sudo chmod -R 755 /mnt/kanri-b
sudo chmod -R 755 /mnt/public
sudo chwon -R kanri-a:'domain users' /mnt/kanri-a
sudo chwon -R kanri-a:'domain users' /mnt/kanri-b
sudo chwon -R kanri-a:'domain users' /mnt/public

(3)　ホスト名の変更

新ファイルサーバ上で実行。svr02をsvr01に変更。ネットワークを再起動する。

sudo vi /etc/hostname
srv01
sudo vi /etc/hosts
127.0.0.1 localhost
127.0.1.1 svr01.shigi.local svr01
sudo systemctl restart systemd-networkd

hostname -f
srv01.shigi.local

srv01.shigi.localに変更された。

(4)　IPアドレスの変更

192.168.xyz.211から192.168.xyz.201へ変更する。

sudo vi /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enp2s0:
#dhcp4: no
addresses:
- 192.168.xyz.201/24
gateway4: 192.168.xyz.1
nameservers:
search:
- shigi.local
addresses:
- 192.168.xyz.200
- 8.8.8.8
version: 2

ネットワークの再起動。

sudo systemctl restart systemd-networkd

IPアドレスが変更されたか確認。

ifconfig -a
enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.xyz.201 netmask 255.255.255.0 broadcast 192.168.xyz.255
ether 00:30:67:bb:ae:d8 txqueuelen 1000 (イーサネット)
RX packets 60683446 bytes 6021712067 (6.0 GB)
RX errors 0 dropped 18 overruns 0 frame 0
TX packets 210380705 bytes 309401076727 (309.4 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

192.168.xyz.201に変更されている。

(5)　アクティブディレクトリに参加

sudo net ads join -U Administrator
sudo net ads testjoin
Join is OK

アクティブディレクトリに参加した。

(6)　クライアントPCからアクセス。

クライアントPC上で，sudo service restart autofs を実行して，/mntにアクセスしてみる。

このあと，各ディレクトリ配下で，フルダやファイルの新規作成，ファイルへの書き込み・保存，削除の動作を確認する。複合機で，スキャンしてデータが/mnt/publicに保存されるかも確認する。失敗する場合は，パーミッションの設定を再確認してみる。

以上で，作業完了です。