isLandcenter 非番中

ブログトップ | ログイン

SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット

- はじめに -

久しぶりに SUSE 11 の仮想マシンを起動したら、見事にコケました、仕方がないので、 fsck して起動しましたが、あまりいいものじゃありません。


SUSE Linux Enterprise 12 から採用され、以降 SUSE Linux 15(SLE/openSUSE15) で openSUSE Leap で使われている BtrFS は、やれ「修復のため起動時の fsck の必要がない」とか、fsck しないので起動が速いとか、起動中にファイルシステムのチェックができるとか、いいことばかり書かれています。実際、この記事を書く時にたどり着いた情報は「BtrFS にクソハマった話」ばかりなのですが、それほど情報が少ないのはやはり安心して使えるファイルシステムだからでしょう。

現実には、論理障害よりも、物理障害もあるわけですから、

「困った!」

時のために、BtrFS の、修復だとかチェック、メンテナンス、スナップショットの設定の方法について、ちゃんと勉強しておくことにします。

- 参考にしたドキュメント -

SDB:BTRFS


- btrfs の修復 -

btrfs scrub start [mount_point]

パーティションの論理障害を修復します。

opesuse151:~ # btrfs scrub start /
scrub started on /, fsid 8466aee4-2738-4b0a-924a-79edad4b4676 (pid=23058)
opesuse151:~ #

- 前回 scrub した結果の確認 -

brtfs scrub status [mount_point]

scrub した結果を確認します。

opesuse151:~ # btrfs scrub status /
scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676
scrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50
total bytes scrubbed: 7.54GiB with 0 errors
opesuse151:~ #

-dR オプションを付けると詳細な情報が分かります。

opesuse151:~ # btrfs scrub status -dR /
scrub status for 8466aee4-2738-4b0a-924a-79edad4b4676
scrub device /dev/vda2 (id 1) history
scrub started at Wed Feb 26 14:05:43 2020 and finished after 00:01:50
data_extents_scrubbed: 247304
tree_extents_scrubbed: 31902
data_bytes_scrubbed: 7577907200
tree_bytes_scrubbed: 522682368
read_errors: 0
csum_errors: 0
verify_errors: 0
no_csum: 5030
csum_discards: 0
super_errors: 0
malloc_errors: 0
uncorrectable_errors: 0
unverified_errors: 0
corrected_errors: 0
last_physical: 11178868736
opesuse151:~ #

- btrfs のファイルシステムのチェック -

btrfs check [/dev/partition]

ファイルシステムのパーティションチェックです。

※ --force を付けるとマウント中のファイルシステムをチェックできる。

opesuse151:~ # btrfs check --force /dev/vda2
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/vda2
UUID: 8466aee4-2738-4b0a-924a-79edad4b4676
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 7839363072 bytes used, no error found
total csum bytes: 7380260
total tree bytes: 261373952
total fs tree bytes: 238518272
total extent tree bytes: 13942784
btree space waste bytes: 41699539
file data blocks allocated: 7779311616
referenced 7561506816
opesuse151:~ #

- btrfs での df (利用量)の確認 -

btrfs filesystem df [mount_point]

従来の df コマンドの代わりになるものです。

opesuse151:~ # btrfs filesystem df /
Data, single: total=8.01GiB, used=7.06GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.12GiB, used=249.25MiB
GlobalReserve, single: total=21.73MiB, used=0.00B
opesuse151:~ #

btrfs filesystem usage [mount_point]

opesuse151:~ # btrfs filesystem usage /
Overall:
Device size: 14.00GiB
Device allocated: 10.32GiB
Device unallocated: 3.68GiB
Device missing: 0.00B
Used: 7.54GiB
Free (estimated): 4.63GiB (min: 2.79GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 21.73MiB (used: 0.00B)

Data,single: Size:8.01GiB, Used:7.06GiB
/dev/vda2 8.01GiB

Metadata,DUP: Size:1.12GiB, Used:249.25MiB
/dev/vda2 2.25GiB

System,DUP: Size:32.00MiB, Used:16.00KiB
/dev/vda2 64.00MiB

Unallocated:
/dev/vda2 3.68GiB
opesuse151:~ #

- デフォルトのメンテナンスは一週間ごと -

sysconfig の File systems の中に、自動メンテナンスの間隔を設定します。

"BTRFS_BALANCE_PERIOD" のキーに設定されます。デフォルトは weekly となっています。

SDB:Disable btrfsmaintenance

weekly から none にすると、無効となります。

SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット_a0056607_13465207.png

- snappper の初期設定 -

snapper は初期設定では無効です。snapper コマンドでスナップショットを初期化します。

snapper -c create [YourSnapSotName] create-config [PathToYouNeedSpapShot]

ここではルートパーティション全体を取っていますが、例えば DB ファイルがあるところとか、 /srv/www/htdocs などを指定します。設定ファイルは /etc/snapper/configs/ の下に作られます。

opesuse151:~ # snapper -c mysnapconfig create-config /
opesuse151:~ #
opesuse151:~ # ls /etc/snapper/configs -l
total 4
-rw-r----- 1 root root 1169 Feb 27 10:37 mysnapconfig
opesuse151:~ #
opesuse151:~ # cat /etc/snapper/configs/mysnapconfig


# subvolume to snapshot
SUBVOLUME="/"

# filesystem type
FSTYPE="btrfs"


# btrfs qgroup for space aware cleanup algorithms
QGROUP=""


# fraction of the filesystems space the snapshots may use
SPACE_LIMIT="0.5"

# fraction of the filesystems space that should be free
FREE_LIMIT="0.2"


# users and groups allowed to work with config
ALLOW_USERS=""
ALLOW_GROUPS=""

# sync users and groups from ALLOW_USERS and ALLOW_GROUPS to .snapshots
# directory
SYNC_ACL="no"


# start comparing pre- and post-snapshot in background after creating
# post-snapshot
BACKGROUND_COMPARISON="yes"


# run daily number cleanup
NUMBER_CLEANUP="yes"

# limit for number cleanup
NUMBER_MIN_AGE="1800"
NUMBER_LIMIT="50"
NUMBER_LIMIT_IMPORTANT="10"


# create hourly snapshots
TIMELINE_CREATE="yes"

# cleanup hourly snapshots after some time
TIMELINE_CLEANUP="yes"

# limits for timeline cleanup
TIMELINE_MIN_AGE="1800"
TIMELINE_LIMIT_HOURLY="10"
TIMELINE_LIMIT_DAILY="10"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="10"
TIMELINE_LIMIT_YEARLY="10"


# cleanup empty pre-post-pairs
EMPTY_PRE_POST_CLEANUP="yes"

# limits for empty pre-post-pair cleanup
EMPTY_PRE_POST_MIN_AGE="1800"

詳細はこちらをご参考下さい。

4 Snapperによるスナップショットとロールバック

SLES12 の Snapper のチューニング

- snapper のスナップショットの設定 -

snapper を起動したら、YaST2 snapper で、スナップショットの設定をします。

opesuse151:~ # yast2 &

SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット_a0056607_13430414.png

定義したパーティションルートに .snapshot ディレクトリが創られます。ここは snapshot の保管場所です。

opesuse151:~ # ls /.snapshots/1/snapshot/
.snapshots boot etc lib mnt proc run selinux sys usr
bin dev home lib64 opt root sbin srv tmp var
opesuse151:~ #


SUSE Linux 15 BtrFS のファイルシステム自動修復、チェック、スナップショット_a0056607_13480760.png

実際のスナップショットの取り方、ロールバックの方法はこちらの過去記事をご参考にしてください。

SLES12が採用した btrfs, snapper を使った Snap Shot
なるほど、SUSE Linux 12, 15 でルートパーティションは標準の BtrFS は COW (Copy On Write) なので、ファイルの論理障害には強いんだ、という事です。しかし物理障害には無力な事には変わりません。やっぱり必要なのはバックアップです。

一通りやってみて、Windows の起動直後の chkdisk や EXT3 の場合の fsck の待ち時間を考えると実に楽になったなと実感しています。








by islandcenter | 2020-02-27 14:20 | SUSE | Comments(0)