カテゴリー: サーバ移設

【GCP】Booting from Hard Disk 0… から復旧させた話【P2V】

こんにちは。
先日に投稿した下記方法で GCP に P2V (RHEL6) を試みました。
…が、上手くVM が起動しなかったため、頑張って復旧させた際の備忘録です。

【V2V】dd コマンドでデータを丸ごと吸い出して GCP にサーバを移設してみる


シリアルコンソールから確認すると、出力が Booting from Hard Disk 0… にて止まっている模様。
仕方がないので、レスキュー用の VM を起動し、正常にブートするディスク (復旧ディスク) に対して、問題の (起動しない) ディスクデータを移行し VM の起動を目指します。

1. 復旧ディスクを用意

GCP では既に RHEL6 / CentOS6 のイメージを提供していません。
ついては、AWS にて CentOS6 のイメージを起動し、dd コマンドでディスクのイメージを取得してから GCP にて VM を作成します。
※ 詳細については こちら を参照ください。

※ 必要に応じてディスクを拡張しておきます。

sed -i -e "s/^mirrorlist=http:\/\/mirrorlist.centos.org/#mirrorlist=http:\/\/mirrorlist.centos.org/g" /etc/yum.repos.d/CentOS-Base.repo
sed -i -e "s/^#baseurl=http:\/\/mirror.centos.org/baseurl=http:\/\/vault.centos.org/g" /etc/yum.repos.d/CentOS-Base.repo
yum install epel-release
yum install cloud-utils-growpart
growpart /dev/sda 1
reboot
resize2fs /dev/sda1

2. データ移行

レスキュー用の VM を起動し、「1」にて作成したディスクと、問題の (起動しない) ディスクをアタッチし、それぞれ適当なディレクトリにマウントします。

※ /mnt/source01 → 問題の (起動しない) ディスク
※ /mnt/dest01 → 復旧ディスク

データ移行には rsync を使います。
※ 予め同期させないデータのリストファイルを作成してから実行します。

vim /var/tmp/exclude_list.txt 
=============================
# necessary-file exclude
- /boot/*
- /dev/*
- /sys/*
- /proc/*
- /etc/fstab
- /etc/passwd
- /etc/shadow
- /run/*

nohup rsync -av --exclude-from=/var/tmp/exclude_list.txt /mnt/source01/* /mnt/dest01/ &

※ OS ユーザはエントリの重複が発生しないように /etc/passwd 、/etc/shadow に手動で追記します。

データ同期が完了したら、ディスクをアンマウントし VM を起動します。

3. ネットワーク周り調整

VM 起動後はシリアルコンソールから接続します。
※ ログインプロンプトが表示されたら成功です。
P2V だとネットワーク周りの設定が競合して疎通ができない状態になっていると思うので適宜調整します。

※ たいていは network-scripts 配下のファイルを調整し、75-persistent-net-generator.rules を退避(削除)すれば良いかと。

調整後は VM を再起動して下さい。

vim /etc/sysconfig/network-scripts/ifcfg-eth0
=============================================
IPV6INIT="no"
DHCP_HOSTNAME="localhost"
BOOTPROTO="dhcp"
DEVICE="eth0"
ONBOOT="yes"
MTU=1460
PERSISTENT_DHCLIENT="y"
IPV6INIT=yes

mv /etc/udev/rules.d/75-persistent-net-generator.rules /var/tmp/

※ GATEWAY は VPC のゲートウェイですね。
vim /etc/sysconfig/network
==========================
NETWORKING=yes
HOSTNAME=hogehoge
NETWORKING_IPV6=no
NOZEROCONF=YES
GATEWAY=hogehoge

4. 終わりに

VM が起動しない時は手詰まりで泣きそうになりました…。
一か八かでデータの同期を試みたところ正常に起動したようで何よりです。
この案件、色々と勉強になりました…。

【V2V】dd コマンドでデータを丸ごと吸い出して GCP にサーバを移設してみる

こんにちは。
dd コマンドでディスクのデータを丸ごと吸い出して、GCP にサーバ移設を行う方法について検証してみたので備忘録を残しておきます。

前提として、AWS に構築した WEB / DB の仮想サーバ( EC2 )を、GCP に移設してみます。

1. 移設元

事前にデータを吸い出すディスクよりも大きなボリュームを EC2 にアタッチ / マウントしておきます。
あとは dd コマンドで吸い出すだけで OK です。
吸い出したデータは tar.gz で固めておきます。
※ デバイスファイル名は適宜変更してください。

fdisk /dev/xvdf
mkfs -t xfs /dev/xvdf1
mkdir -p /tmp/mnt
mount -t xfs /dev/xvdf1 /tmp/mnt
dd if=/dev/xvda of=/tmp/mnt/disk.raw bs=4M conv=sparse
cd /tmp/mnt
tar --format=oldgnu -Sczf /tmp/mnt/sanuki-source-wd01-compressed-image.tar.gz disk.raw

固めたデータは GCS ( Cloud Storage )にアップロードします。
方法はなんでも大丈夫ですが、gsutil を使うのが一番手っ取り早いかと考えます。
※ バケット名は適宜変更してください。

cd ~
curl https://sdk.cloud.google.com > install.sh
bash install.sh --disable-prompts
./google-cloud-sdk/bin/gcloud init
./google-cloud-sdk/bin/gsutil mb gs://sanuki-v2v-test-bucket01
./google-cloud-sdk/bin/gsutil ls
./google-cloud-sdk/bin/gsutil cp /tmp/mnt/sanuki-source-wd01-compressed-image.tar.gz gs://sanuki-v2v-test-bucket01/

2. 移設先

・Cloud Storage にアップロードしたファイルを元にイメージを作成しておきます。

イメージ > イメージを作成 > ソース : Cloud Storage ファイル > 作成

・作成したイメージから VM を起動します。
※ VM は sanuki-dest-wd01 という名称にしておきます。

VM インスタンス > インスタンスの作成 > ブートディスク : カスタムイメージ から 作成したイメージを選択 > 作成

…が、VM は正常に起動しません。

シリアルコンソールから VM に接続するとレスキューモードになっており、ログを漁ったところ、どうも File System が壊れているようです。

Feb 15 08:41:23 localhost kernel: XFS (sda1): Unmount and run xfs_repair
Feb 15 08:41:23 localhost kernel: XFS (sda1): First 64 bytes of corrupted metada
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe00: 58 41 47 46 00 00 00 01 00 0
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe10: 00 00 00 01 00 00 00 02 00 0
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe20: 00 00 00 01 00 00 00 00 00 0
Feb 15 08:41:23 localhost kernel: ffff96cdf565fe30: 00 00 00 04 00 07 bf 6b 00 0
Feb 15 08:41:23 localhost kernel: XFS (sda1): metadata I/O error: block 0x1bff20
Feb 15 08:41:23 localhost mount[343]: mount: mount /dev/sda1 on /sysroot failed:
Feb 15 08:41:23 localhost systemd[1]: sysroot.mount mount process exited, code=e
Feb 15 08:41:23 localhost systemd[1]: Failed to mount /sysroot.
Feb 15 08:41:23 localhost systemd[1]: Dependency failed for Initrd Root File Sys
Feb 15 08:41:23 localhost systemd[1]: Dependency failed for Reload Configuration
Feb 15 08:41:23 localhost systemd[1]: Job initrd-parse-etc.service/start failed 
Feb 15 08:41:23 localhost systemd[1]: Triggering OnFailure= dependencies of init
Feb 15 08:41:23 localhost systemd[1]: Job initrd-root-fs.target/start failed wit
Feb 15 08:41:23 localhost systemd[1]: Triggering OnFailure= dependencies of init
Feb 15 08:41:23 localhost systemd[1]: Unit sysroot.mount entered failed state

3. 復旧

復旧用 VM を用意して、壊れたブートディスクをセカンダリとしてアタッチしリペアを試みます。

・ディスクだけ残し VM を削除します。

VM インスタンス > sanuki-dest-wd01 > 編集 > ブートディスク : 削除ルール : ディスクを維持 > 保存 > 削除

・リカバリ用の VM を作成して、壊れたディスクをアタッチします。
※ VM は sanuki-recover01 という名称にしておきます。

VM インスタンス > インスタンスの作成 > ブートディスク : 公開イメージ : CentOS7 > 作成

VM インスタンス > sanuki-recover01 > 編集 > 追加ディスク : 既存のディスクを接続 > sanuki-dest-wd01 : 保存 > 保存

・リカバリ用の VM に接続し、File System のリペアを試みます。
先に復旧対象のデバイスファイルを確認しておきます。
今回は /dev/sdb1 が対象になります。

[root@sanuki-recover01 ~]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   20G  0 disk
tqsda1   8:1    0  200M  0 part /boot/efi
mqsda2   8:2    0 19.8G  0 part /
sdb      8:16   0   30G  0 disk
mqsdb1   8:17   0   30G  0 part
[root@sanuki-recover01 ~]# ls -l /dev/disk/by-id/ | grep "sanuki-dest-wd01"
lrwxrwxrwx. 1 root root  9 Feb 15 11:40 google-sanuki-dest-wd01 -> ../../sdb
lrwxrwxrwx. 1 root root 10 Feb 15 11:40 google-sanuki-dest-wd01-part1 -> ../../sdb1
lrwxrwxrwx. 1 root root  9 Feb 15 11:40 scsi-0Google_PersistentDisk_sanuki-dest-wd01 -> ../../sdb
lrwxrwxrwx. 1 root root 10 Feb 15 11:40 scsi-0Google_PersistentDisk_sanuki-dest-wd01-part1 -> ../../sdb1

いきなり xfs_repair を行うと怒られました。
一度 マウント / アンマウント する必要があるようです。

[root@sanuki-recover01 ~]# xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

適当にディレクトリを切ってから マウント → アンマウント → xfs_repair を行います。

mkdir /tmp/mnt
mount /dev/sdb1 /tmp/mnt
umount /dev/sdb1
xfs_repair /dev/sdb1

…正常にリペアできました。

[root@sanuki-recover01 ~]# xfs_repair /dev/sdb1
Phase 1 - find and verify superblock...
        - reporting progress in intervals of 15 minutes
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
agi unlinked bucket 29 is 23389 in ag 13 (inode=54549341)
        - 11:45:46: scanning filesystem freespace - 16 of 16 allocation groups done
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - 11:45:46: scanning agi unlinked lists - 16 of 16 allocation groups done
        - process known inodes and perform inode discovery...
        - agno = 15
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
data fork in ino 50509395 claims free block 6314488
data fork in ino 50509395 claims free block 6314489
        - agno = 13
data fork in ino 54549341 claims free block 6818903
data fork in ino 54549341 claims free block 6818904
data fork in ino 54549341 claims free block 6818937
data fork in ino 54549341 claims free block 6818938
        - agno = 14
        - 11:45:47: process known inodes and inode discovery - 103104 of 103104 inodes done
        - process newly discovered inodes...
        - 11:45:47: process newly discovered inodes - 16 of 16 allocation groups done
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - 11:45:47: setting up duplicate extent list - 16 of 16 allocation groups done
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - 11:45:47: check for inodes claiming duplicate blocks - 103104 of 103104 inodes done
Phase 5 - rebuild AG headers and trees...
        - 11:45:47: rebuild AG headers and trees - 16 of 16 allocation groups done
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
disconnected inode 54549341, moving to lost+found
Phase 7 - verify and correct link counts...
        - 11:45:47: verify and correct link counts - 16 of 16 allocation groups done
done

・リカバリ用 VM からディスクをデタッチします。

VM インスタンス > sanuki-recover01 > 編集 > 追加ディスク : 既存のディスク > sanuki-dest-wd01 : デタッチ > 保存

・リペアしたディスクからもう一度 VM を起動します。

VM インスタンス > インスタンスの作成 > ブートディスク : 既存のディスク : sanuki-dest-wd01 : 選択 > 作成

コンソールに接続します。
…接続できました。

serialport: Connected to fleet-acumen-286514.asia-northeast1-b.sanuki-dest-wd01 
port 1 (session ID: 99e0fefe92785865dd201bdc6865a89ae461aa77, active connections
: 1).
[   31.822303] APL|18307:18410:transport.c:1112:transport_device_release| INFO: 
detaching interceptors
[   31.838278] APL|18307:18410:tracepoints.c:99:tracepoints_detach| INFO: tracep
oints detached
[   31.847363] APL|18307:18410:syscall_common.c:149:detach_hooks| INFO: detachin
g syscall hooks...
[   31.856628] APL|18307:18410:syscall_common.c:186:detach_hooks| INFO: syscall 
hooks detached
[   31.865252] APL|18307:18410:syscall_common.c:213:syscall_hooks_detach| INFO: 
module_refcount()=1
[   31.874511] APL|18307:18410:transport.c:1117:transport_device_release| INFO: 
interceptors detached
[   32.305021] snapapi_init(modprobe,18440): Snapapi(v.0.8.8) init OK. Session s
ize 13784. Em size 990. Ctl major 245
[   32.351295] device-mapper: uevent: version 1.0.3
[   32.356843] device-mapper: ioctl: 4.37.1-ioctl (2018-04-03) initialised: dm-d
evel@redhat.com
[   32.390383] BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
CentOS Linux 7 (Core)
Kernel 3.10.0-1062.12.1.el7.x86_64 on an x86_64

sanuki-dest-wd01 login: root
Password: 
Last login: Tue Feb 15 07:57:24 on pts/0
[root@sanuki-dest-wd01 ~]#

4. 終わりに

色々と躓きましたが、サーバの移設自体は可能なようです。
移設元が稼働していてデータの差分等が発生するのであれば、適宜 rsync 等でデータを同期してあげればよいですね。
一から移設先のサーバを作ってデータを同期するよりもお手軽かもしれません。

【シェルスクリプト】だいたいのサーバ情報を取得する便利スクリプト【サーバ移設】

取り敢えずこのスクリプトを実行すれば、ある程度のサーバ情報を取得できるよ、ってだけのスクリプトです。

#!/bin/sh

# 情報取得関数
function addinfo(){

	# 情報を出力するファイル名を定義
	OUTPUT=serverinfo-`hostname`.txt
	# 情報内容を出力
	echo "####### $1 #########" >> $OUTPUT
	# コマンド結果を出力
	$2 >> $OUTPUT
	
	return 0
}

# ホストネーム
addinfo hostname "hostname"
# プロセス一覧
addinfo process-list "ps auxwwf"
# Listenポート一覧
addinfo listen-port "sudo netstat -lntp"
# ルートテーブル
addinfo route-table "sudo netstat -rn"
# rpmパッケージ
addinfo rpm-package "sudo rpm -qa | sort"
# 自動起動リスト
addinfo chkconfig "sudo chkconfig --list"
# OSバージョン
addinfo os-version "cat /etc/redhat-release"
# CPU
addinfo cpu-info "cat /proc/cpuinfo"
# メモリ
addinfo memory-info "free -m"
# ディスク
addinfo disk-info "df -hT"
# fstab
addinfo fstab "cat /etc/fstab"
# iptables
addinfo iptables "sudo service iptables status"
# ifconfig
addinfo ifconfig "ifconfig"

【proxy】踏み台経由でデータを同期する【rsync】

こんにちは。
踏み台を経由して rsync でデータ同期する方法を、自分用の備忘録として残しておきます。

↓ 前提として同期先、及び、踏み台に root ユーザで接続できる必要があります。

【AWS】EC2 に root ユーザで接続する【サーバ移設】


# SSH 接続設定
vi ~/.ssh/config
============================================================
# 踏み台サーバ
Host mng-bastion01
    # IP アドレス ( 踏み台サーバ )
    HostName      111.111.111.111
    # 接続ユーザ ( 踏み台サーバ )
    User          root
    # 秘密鍵 ( 踏み台サーバ )
    IdentityFile  ~/.ssh/root_secretkey

# ステージングサーバ
Host stg-web01
    ProxyCommand  ssh -W %h:%p mng-bastion01
    # IP アドレス ( ステージングサーバ )
    HostName      222.222.222.222
    # 接続ユーザ ( ステージングサーバ )
    User          root
    # 秘密鍵 ( ステージングサーバ )
    IdentityFile  ~/.ssh/root_secretkey

# 本番サーバ
Host prod-web01
    ProxyCommand  ssh -W %h:%p mng-bastion01
    # IP アドレス ( 本番サーバ )
    HostName      333.333.333.333
    # 接続ユーザ ( 本番サーバ )
    User          root
    # 秘密鍵 ( 本番サーバ )
    IdentityFile  ~/.ssh/root_secretkey
============================================================
    
# パーミッションを調整
chmod 600 ~/.ssh/config

# 接続確認
ssh mng-bastion01
ssh stg-web01
ssh prod-web01

# /path/to/sync_dir を同期先の /path/to/ 配下に同期 ( ドライラン )
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir stg-web01:/path/to/
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir prod-web01:/path/to/

# /path/to/sync_dir を同期先の /path/to/ 配下に同期
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir stg-web01:/path/to/
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' /path/to/sync_dir prod-web01:/path/to/


# 同期元の /path/to/sync_dir を /path/to/ 配下に同期 ( ドライラン )
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' stg-web01:/path/to/sync_dir /path/to/
rsync -avzn --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' prod-web01:/path/to/sync_dir /path/to/

# 同期元の /path/to/sync_dir を/path/to/ 配下に同期
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' stg-web01:/path/to/sync_dir /path/to/
rsync -avz --bwlimit=6400 -e 'ssh -i ~/.ssh/root_secretkey' prod-web01:/path/to/sync_dir /path/to/

【AWS】EC2 に root ユーザで接続する【サーバ移設】

こんにちは。
rsync でデータ同期を行う際、一般ユーザを用いてしまうと owner と group が適切に設定されないケースがあるようです。
AWS EC2 ( AmazonLinux ) のデフォルト設定では root ユーザでの接続ができないので、後述のように設定を調整します。

# 設定ファイルをバックアップ
cp -p /etc/ssh/sshd_config /etc/ssh/sshd_config.org
diff /etc/ssh/sshd_config /etc/ssh/sshd_config.org

# sshd 設定ファイルの調整
vi /etc/ssh/sshd_config
======================================
#PermitRootLogin forced-commands-only
PermitRootLogin without-password
======================================
# sshd 設定ファイルの syntax チェック
sshd -t

# sshd 再読み込み
/etc/init.d/sshd reload

# sshd の起動を確認
netstat -lntp | grep sshd

# root ユーザの公開鍵追記
vi /root/.ssh/authorized_keys
=======================================
ssh-rsa xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
=======================================

※ 秘密鍵、公開鍵のキーペアは下記コマンドで作成できます。
ssh-keygen -b 2048 -t rsa -f ./key_name

【サーバ移設】Linux の OS ユーザ移設【Tips】

こんにちは。
Linux サーバを移設する際に OS ユーザを移設先サーバにも作成する必要があるんですが、大量に OS ユーザが存在すると面倒くさいですよね。
そんなときは /etc/passwd 関連ファイルをコピーするといいらしいです。
※ 普通に実施すると権限がないので下記の手順が必要です。

# /etc/passwdを編集
vipw
=======================================
user1:x:515:515::/home/user1:/bin/bash
user2:x:504:504::/home/user2:/bin/bash
=======================================
:wq!

# /etc/shadowを編集
vipw -s
=======================================================================================================================
user1:$6$43wzBE4t$XVEOEQpipC9FRocISuPMZ47qPIPwG70sjm2S7ADy4scuwtuBBSlA70q/w0nduW1A2dHUkpVqEW8KW8Ro0:17387:0:99999:7:::
user2:$6$G8m9jYDT$X53N71JCVXbbJnDLrvBED67ZrrwtL.hfJa.9sosksjwnaUtlLF/K0F2l9KvmsgrULgFQ/KahH6C.:17220:0:99999:7:::
=======================================================================================================================
# 保存できないので無理やり保存する
:w !sudo tee %
:q!

# /etc/groupを編集
vigr
=============
user1:x:515:
user2:x:504:
=============

# /etc/gshadowの編集
vigr -s
===========
user1:!::
user2:!::
===========
# 保存できないので無理やり保存する
:w !sudo tee %
:q!

稼働中の MySQLサーバ から slaveサーバ を構築する備忘録

こんにちは。
MySQLサーバ の slaveサーバを構築する機会があったので備忘録を残しておきます。

確認事項

バイナリログが出力されていて、尚且つ server-id が設定されている必要があります。

vi /etc/my.cnf
=======================================
server-id=1001
log-bin = /var/lib/mysql/mysql-bin
=======================================

systemctl restart mysqld

レプリケーション用ユーザの作成

レプリケーション用のユーザを事前に作成しておきます。

create user 'repl'@'%' identified by 'xxxxxxxxxx';
grant replication slave on *.* to 'repl'@'%';

dumpファイルの取得

mysqldump で dumpデータを取得します。
ストレージエンジンが innodb であれば、–single-transaction オプションで DBをロックせずに取得が可能です。
また、–master-data=2 オプションでバイナリログの読み出し開始位置を出力しておきます。

mysqldump -u root -p --skip-lock-tables --quote-names --single-transaction --master-data=2 -A > /var/tmp/mysqldump.sql

dumpファイルのインポート

slaveサーバ に dumpファイルを転送して流し込みます。
単純に mysql コマンドとリダイレクトを組み合わせるだけで大丈夫です。

scp user@xxx.xxx.xxx.xxx:/var/tmp/mysqldump.sql /var/tmp/.
mysql -u root -p < /var/tmp/mysqldump.sql

テーブルチェック

mysql_upgrade コマンドを使ってテーブルのチェックを行います。

mysql_upgrade -u root -p
systemctl restart mysqld

バイナリログの開始位置を確認

–master-data=2 オプションでバイナリログの読み出し開始位置が出力されているので確認します。

grep "CHANGE MASTER" /var/tmp/mysqldump.sql

レプリケーション設定

mysql> change master to
    -> master_host='xxx.xxx.xxx.xxx',
    -> master_user='repl',
    -> master_password='xxxxxxxxxx',
    -> master_log_file='[バイナリログ]',
    -> master_log_pos=[ポジション];

mysql> start slave;
mysql> show slave status\G

【データ移行】/var を別の追加ディスクに移行【Tips】

こんにちは。
/var のディレクトリを別の追加ディスクに移行する手順を残しておきます。

[root@test-server /]# lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    253:0    0   30G  0 disk
mqvda1 253:1    0 29.3G  0 part /
vdb    253:16   0  100G  0 disk

/dev/vdb の領域に /var を移行してみます。

手順

・ファイルシステムの作成
/dev/vdb にパーティションを切ってからファイルシステムを作成します。

[root@test-server /]# fdisk /dev/vdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0xf4f00fe7.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-209584127, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-209584127, default 209584127): +100G
Value out of range.
Last sector, +sectors or +size{K,M,G} (2048-209584127, default 209584127): ^[[A^[[D^[[B^[[B^C
[root@sr-stg-ftp01 /]# fdisk /dev/vdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x71de9846.

Command (m for help): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   extended
Select (default p): p
Partition number (1-4, default 1): 1
First sector (2048-209584127, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-209584127, default 209584127):
Using default value 209584127
Partition 1 of type Linux and of size 100 GiB is set

Command (m for help): p

Disk /dev/vdb: 107.3 GB, 107307073536 bytes, 209584128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x71de9846

   Device Boot      Start         End      Blocks   Id  System
/dev/vdb1            2048   209584127   104791040   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

mkfs -t xfs /dev/vdb1

・シングルユーザモードへ
init 1

・追加ディスクをアタッチして/var を同期する
cd /
mkdir /new_var
mount -t xfs /dev/vdb1 /new_var
rsync -avzr /var/ /new_var/

・元の /var を別名保存し、/var へ vdb をマウント
umount /new_var
mv var var_old
mkdir var
mount -t xfs /dev/vdb1 /var

・fstab に追記
vi /etc/fstab
=================================
/dev/vdb1 /var xfs defaults 0 2

・マルチユーザモードへ
init 3

【サーバ移設】踏み台サーバを経由してrsyncする方法【rsync】

こんにちは。
先日にサーバ移設案件に携わる機会があって、踏み台サーバを経由して、目的のサーバにデータを同期する必要がありました。
その際に先輩に教えてもらった方法をメモレベルで残しておこうと思います。

rsync 用ユーザ作成

useradd rsync
su rsync
cd ~
mkdir .ssh
chmod 700 .ssh

SSH 設定

vi /home/rsync/.ssh/config
===============================================
Host step-new
    HostName      111.111.111.111
    User          step-new-user
    IdentityFile  ~/.ssh/id_rsa_step-new.pem
Host step-old
    ProxyCommand  ssh -W %h:%p step-new
    HostName      222.222.222.222
    User          step-old-user
    IdentityFile  ~/.ssh/id_rsa_step-old.pem
Host target-server
    ProxyCommand  ssh -W %h:%p step-old
    HostName      333.333.333.333
    User          target-server-user
    IdentityFile  ~/.ssh/id_rsa_target.pem
===============================================

vi ~/.ssh/id_rsa_step-new.pem
vi ~/.ssh/id_rsa_step-old.pem
vi ~/.ssh/id_rsa_target.pem

chmod 600 ~/.ssh/id_rsa_step-new.pem
chmod 600 ~/.ssh/id_rsa_step-old.pem
chmod 600 ~/.ssh/id_rsa_target.pem

データ同期

mkdir -p /var/tmp/rsync_results/test1
nohup time rsync -avzrn --rsync-path="sudo rsync" target-server:/home/target-server-user/ /home/purpose/ 1>/var/tmp/rsync_results/test1/result_$(date +"%Y%m%d").log 2>/var/tmp/rsync_results/test1/error_$(date +"%Y%m%d").log &
nohup time rsync -avzr --rsync-path="sudo rsync" target-server:/home/target-server-user/ /home/purpose/ 1>/var/tmp/rsync_results/test1/result_$(date +"%Y%m%d").log 2>/var/tmp/rsync_results/test1/error_$(date +"%Y%m%d").log &

補足

・.ssh/ 以下に config ファイルを作成することで、踏み台サーバを経由して接続が出来る。
・秘密鍵は事前に配置しておく必要がある。