作業目的

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

前提

  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を,6つのパーテションに切っています。ここでは,例として250GBを移行試験として示しました。)

これを3つパーティションに分割します。それぞれ,ラベル(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に保存されていた。この情報を元に,データを復元する。

② データを復元

1.で準備した新ハードディスクは,次のようにマウントする。なお,マウント先は,事前に,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に保存されるかも確認する。失敗する場合は,パーミッションの設定を再確認してみる。

以上で,作業完了です。