タグ別アーカイブ: rsync

LVMのスナップショットの動作が怪しい

うちのサーバ機はxenを使って仮想化して運用している。
そして毎日定期バックアップをLVMのスナップショット機能を利用して行っているのだけども、どうも最近挙動がおかしいことに気づいた。
作成したスナップショットが高確率でファイルシステムにエラーを含んでいる。

# xm pause debian
# lvcreate -s -n snapdebian -L 200G /dev/ms09/debian
  Logical volume "snapdebian" created
# xm unpause debian

としてスナップショットを作成する。
ここまではいい。
が、ここでfsckを走らせるとエラーが出る。

# e2fsck -yfv /dev/ms09/snapdebian
e2fsck 1.41.12 (17-May-2010)
/dev/ms09/snapdebian: recovering journal
Clearing orphaned inode 15466504 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466503 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466502 (uid=109, gid=109, mode=0100600, size=0)
Clearing orphaned inode 15466501 (uid=109, gid=109, mode=0100600, size=20)
Clearing orphaned inode 15466500 (uid=109, gid=109, mode=0100600, size=0)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/ms09/snapdebian: ***** FILE SYSTEM WAS MODIFIED *****

  715619 inodes used (2.13%)
     738 non-contiguous files (0.1%)
     182 non-contiguous directories (0.0%)
         # of inodes with ind/dind/tind blocks: 0/0/0
         Extent depth histogram: 706955/133
23572155 blocks used (17.56%)
       0 bad blocks
       6 large files

  677160 regular files
   29784 directories
     126 character device files
      40 block device files
       2 fifos
      16 links
    8469 symbolic links (8324 fast symbolic links)
      29 sockets
--------
  715626 files

マウントしてrsyncでバックアップをとるとumountでえらい時間がかかる。
カーネルが文句いってる。

[  647.099517] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466504
[  647.099539] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466503
[  647.099548] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466502
[  647.099556] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466501
[  647.099591] EXT4-fs (dm-18): ext4_orphan_cleanup: deleting unreferenced inode 15466500
[  647.099599] EXT4-fs (dm-18): 5 orphan inodes deleted
[  647.099710] EXT4-fs (dm-18): recovery complete
[  647.433114] EXT4-fs (dm-18): mounted filesystem with ordered data mode
[ 1080.113046] INFO: task umount:4061 blocked for more than 120 seconds.
[ 1080.113114] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1080.113201] umount        D 0000000000000000     0  4061   2294 0x00000000
[ 1080.113331]  ffffffff8147b1f0 0000000000000282 0000000000000000 ffff8801e6971de8
[ 1080.113544]  0000000000000000 0000000000000000 000000000000f9e0 ffff8801e6971fd8
[ 1080.117004]  0000000000015780 0000000000015780 ffff8801c17654c0 ffff8801c17657b8
[ 1080.117004] Call Trace:
[ 1080.117004]  [<ffffffff8100e629>] ? xen_force_evtchn_callback+0x9/0xa
[ 1080.117004]  [<ffffffff8100ece2>] ? check_events+0x12/0x20
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff81109274>] ? bdi_sched_wait+0x9/0xe
[ 1080.117004]  [<ffffffff8130d19a>] ? _spin_unlock_irqrestore+0xd/0xe
[ 1080.117004]  [<ffffffff8130c3e7>] ? __wait_on_bit+0x41/0x70
[ 1080.117004]  [<ffffffff8100f0ac>] ? xen_smp_send_reschedule+0x0/0x7
[ 1080.117004]  [<ffffffff8110926b>] ? bdi_sched_wait+0x0/0xe
[ 1080.117004]  [<ffffffff8130c481>] ? out_of_line_wait_on_bit+0x6b/0x77
[ 1080.117004]  [<ffffffff81065f24>] ? wake_bit_function+0x0/0x23
[ 1080.117004]  [<ffffffff811092ec>] ? sync_inodes_sb+0x73/0x12a
[ 1080.117004]  [<ffffffff8110cea1>] ? __sync_filesystem+0x4b/0x70
[ 1080.117004]  [<ffffffff810f1aa2>] ? generic_shutdown_super+0x21/0xfa
[ 1080.117004]  [<ffffffff8100eccf>] ? xen_restore_fl_direct_end+0x0/0x1
[ 1080.117004]  [<ffffffff810f1b9d>] ? kill_block_super+0x22/0x3a
[ 1080.117004]  [<ffffffff810f226d>] ? deactivate_super+0x60/0x77
[ 1080.117004]  [<ffffffff81104bc0>] ? sys_umount+0x2dc/0x30b
[ 1080.117004]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b

場合によってはこのままumountできずにプロセスが残り続けて死ねる。
とりあえずディスクI/Oがロックされた状態になるんだろう。

この問題は稼働中のext4ファイルシステムのスナップショットを作成した際に起きるようだ。
おそらくジャーナルに書き出したデータが実データに反映されていないような状況でスナップショットを作成した場合に起きるんじゃないかと予測している。
のでext3でも同じ現象が起きるだろう。たぶん。
まあ、別にそれでも変更差分をきちんと吸収してくれているならかまわないんだけども、使い終わったスナップショットをアンマウントするのになんで何分もかかるのかがわからない。

その上、使用済みのスナップショットボリュームを削除しようとしても失敗することがある。

# lvremove -f /dev/ms09/snapdebian
  Unable to deactivate open ms09-debian-real (254:5)
  Failed to resume debian.

これに関してはバグレポートが見つかった
とりあえず4ヶ月経過しても治っていないらしい。

んーむ。
こうなるとバックアップ手法を見直す必要性が出てくる。
Dom0とDomUとで疑似遠隔rsyncでバックアップとなるのだろうか。
だけどそれだとrootでのリモートログインが必要となるから駄目だな。
ゲストはゲストでバックアップパーティションをディスクとしてアタッチして、各自でバックアップしてもらうような形ならいけるか。

あー、設定するのがめんどくさい。

まっすぃーんがやばいかも

このマシン、RAID0およびRAID5で構築してるんだけども、なんかIntel Matrix Storage Managerがディスク一本おかしいんだぜ、と警告だしてきやがっている。
まあ、たまにある脅しだろうと思っていたら、通常起動の途中でとまったり、セーフモードで起動しようとしたら勝手に再起動したりとかなり怪しい。
Linuxもルートファイルシステムが見つからないようで起動しない。
これはまずいということで、今たまたまWindowsが起動したので、この状態を維持して可能な限りバックアップをとることに。
以前作ったWindowsのrsync環境が役立ちまくり。

とりあえずrsyncするバッチファイル作ってたたいて、今日はとりあえず寝る。
明日はディスクチェックだな。。。

Windowsでrsync over sshでパスフレーズレス接続

前回、Windows版rsyncのcwrsyncを紹介したが、この際是非パスフレーズレスで使いたくなった。

sshでパスフレーズレス接続するには、ssh-keygenで公開鍵と秘密鍵のペアを作って、認証対象サーバの~/.ssh/authorized_keysに公開鍵をつっこんでおき、認証の際に秘密鍵を使ってログインインする。
超簡単にやり方を書いておこう。

サーバ上で鍵を生成。
~$ ssh-keygen -t RSA
公開鍵を登録。
~$ cat .ssh/id_rsa.pub >> .ssh/authorized_keys

フロッピーなどでid_rsa(秘密鍵の方)をクライアントマシンに転送。

認証している鍵は他の人に読めないように。
~$ chmod 600 .ssh/authorized_keys
鍵を削除
~$ rm .ssh/id_rsa.*

対象サーバじゃなくてクライアント側で鍵のペア作って、サーバに公開鍵をFTPかなんかで送る方が幸せかもしれない。
まあ、どっちでもいい。
あとはWindowsの場合は、teratermなんかsshで接続するときに、その鍵を使えばパスフレーズレスで接続できるようになる。
puttyの場合はputtygenで鍵の形式を変換してやらないと使えないけど、ppk形式に変換してやれば使える。
クライアントマシン側でsshコマンドでやる場合は、-iオプションで秘密鍵を指定してやればいい。

$ eval `ssh-agent`
$ ssh-add 鍵

とかやってクライアントマシン側でssh-agentを起動して、秘密鍵を喰わせておけば指定の必要もない。(その場合は作業が終わったらeval `ssh-agent -k`をして殺しておかないと泣くことになる)
あとは~/.ssh/configをかくかんじか。

で、本題はこれじゃなくて、それをcwrsyncを使って窓マシンからlinuxサーバにrsyncするときに、パスフレーズレスにすることだ。
cwrsyncのbinフォルダをのぞくと、ssh-keygenなんかはあるけどssh-agentはない。
そこで、~/.ssh/configは使えないかと考える。

Windowsのインストールドライブ:Documents and Settingsユーザ名.ssh

をのぞいてみたらknown_hostsがある。
試しにココにconfigファイル作ってみる。

Host waterblue.net
User ユーザ名
IdentityFile 鍵ファイルのパス(C:keyid_rsaなら/cygdrive/c/key/id_rsa)
Protocol 2

で、コマンドラインからssh waterblue.netとしたら。

H:>ssh waterblue.net
Linux debian 2.6.29-1-amd64 #1 SMP Fri Apr 17 10:12:36 UTC 2009 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have mail.
Last login: Thu Apr 30 22:59:06 2009 from xxx.xxx.xxx.xxx
~$

キタ━━━━━━(゚∀゚)━━━━━━ !!!!!

ここでrsyncをドライランでたたいてみる。

H:>rsync -a –progress -v -n /cygdrive/f/test waterblue.net:/home/ユーザ名/rsync
sending incremental file list
test/
test/test.txt

sent 85 bytes  received 19 bytes  69.33 bytes/sec
total size is 6  speedup is 0.06 (DRY RUN)

ユーザ名もパスワードもきかれないでいけたよママン!

これで窓でも快適なrsyncライフを送ることができる!

rsyncのWindows版

rsyncについてこの間書いたが、Windows版も無いものかと思って探してみた。
あった
cwrsyncというやつ。
早速ダウンロードしてインストールしてみた。

インストール先のフォルダにbinフォルダがあり、そこの中はこんな感じ。

cwrsync

どうやらcygwinから必要なものを引っこ抜いてパッケージングしたもののようだ。

とりあえず、環境変数のPATHに「インストール先のフォルダbin」を追加する。
コマンドラインからrsync -hをたたいてみたらrsyncのヘルプがでてきた。
ssh.exeが見えたので、ためしにsshでLinuxサーバに接続してみたところ、できた。
これは、使える!

とりあえず、testフォルダとtest.txtを作成して動作実験してみる。
リモートのサーバでrsyncで同期をとるための~/rsyncディレクトリを作成、Windows側でF:testtest.txtを作成。
コマンドラインから動作テストをしてみる。

H:>rsync -a –progress -v -n /cygdrive/f/test USER@waterblue.net:/home/USER/rsync
Password:
sending incremental file list
test/
test/test.txt

sent 85 bytes  received 19 bytes  12.24 bytes/sec
total size is 6  speedup is 0.06 (DRY RUN)

いけた!
Windows側のパスの扱いは予想通りcygwinと同じ、/cygdrive/Windowsドライブ名/で参照できるようだ。

スタートメニューからcwrsyncを選択して、1. Batch exampleを選択すると、rsyncを使ってのバックアップをするためのひな形ファイルがでてくる。
ダブルクリックで一発でいけるようにしたいなら、このファイルを編集して設定をしておくといいだろう。

さて、とするとパスフレーズレスで接続できるようにしたい。
それについては次のエントリーで。

rsyncによるバックアップ

Linuxサーバのバックアップにはよくdumpが使われたりするけれども、それよりもrsyncの方が幸せになれると思う。
ネットワーク経由やssh経由でバックアップできるのがすばらしい。
もちろんローカルのメディアにバックアップすることも可能。
更に差分バックアップなので、時間が食われるのは最初だけ。
Heartbeatなんかを使ってレプリケーションするのも手だが、レプリケーションは個人ユースではまあ不要だろう。

続きを読む rsyncによるバックアップ