Backup plan (hysk)

バックアップの基本方針

本ページでは，研究で使用する Linux PC の個人用ファイルのバックアップを主な対象とする．システム領域などのバックアップは，管理コマンドのメモ内の /etc や /var のバックアップを参照．

参考: 管理コマンドのメモ
参考: 個人的設定のメモ

これを読まれる方々へ

以下の記述はあくまでも「私(早崎)の使いかたの場合のバックアップ方法」であり，必ずしも一般的な方法ではない事に留意していただきたい．

バックアップ対象

特に重要なのは，/home (ないしユーザの $HOME) 以下である．ただし，自分の home ($HOME)以下に研究用のデータなども全て置いている人の場合，容量が莫大すぎて $HOME 全体のバックアップが事実上不可能な場合がある．

そのような使い方をする人の場合，ディレクトリ構成・ファイルの置き方に関する方針を，根本から変更することをお薦めする．もし変更がイヤならば，私の基本運用方針と全く異なるタイプなので，以後の記述を読む必要は無い．各自の使い方に最も適切な・便利なバックアップ方針は，自分で決めるのが鉄則．

更新インストール時

パーティション設定方針(version: 2011-06-21)

基本的考えは，個人的設定のメモにも記載．記載内容は重複するが，本ページでも再掲:

デフォルト設定 (/ と /boot だけ)に比べ，かなり細分化する(理由は後述)
実使用量は，私がデータ解析で使用しているデスクトップ機からの抜粋．サーバ用途ではない．したがって，これを見た人が自分の計算機の使用目的も考えずに下記のサイズを参考にすると，痛い目にあう(かもしれない)．もし自分で使用目的を決められないなら，素直にデフォルト設定に従うべき
研究で使う計算機(と周辺機器)の発展次第で，下記のパーティション設定を変更する．実際，これまでにも何度も変更をしてきた．カギになるのは，HDD容量とバックアップメディア容量．

パーティション名	目安サイズ	実使用量の目安	メモ
/	8 - 10 GB	せいぜい 1 GB 強	ルート．操作ミス等で filesystem full になる事態は避けたいので，大きめに設定．ディスクに余裕がある場合は，/tmp も分割(数GB - 10GB程度)．そうすれば，ルートファイルシステムが溢れる可能性はかなり低下する．
/boot	150 - 200 MB	20 - 60 MB	カーネルイメージ5つ置いても60 MB程度． HDD単体で数TBが使える現代では，ほぼ誤差範囲．
/usr	10 - 15 GB	5 - 6 GB	Desktop & Sever & Development Tools 入れると、6 GB 近くになる
/usr/local/	15 - 30 GB	10 - 15 GB	個人的に追加したプログラム・ライブラリ類 (GMT, NetCDF, HDF, ...)の置き場所． /usr と一緒にしても良いが，昔からの習慣 & 個人的趣味の問題で分離．システムクラッシュなどが原因で同一バージョンを再インストールする場合，フォーマットせずに残せば，かなり素早く復旧できる．なお，アップデートインストールの際には，まっさらフォーマットすべき(これも個人的趣味・習慣の問題)．
/var	10 GB	1 - 2GB	ログ置き場 & RPMパッケージ置き場． CentOS デフォルトでは，www も /var 以下だが，個人的にはそこは好きじゃない．外部非公開の自分用メモしか置いてないし，バックアップの容易さも勘案して置き場所を /home/ 以下に移動．だから，本来なら /var にこんなデカいスペース不要だが，計算ジョブのログを大量に吐くこともあるので念のため．
/home	40 - 45 GB	30 - 25 GB	最重要パーティション．自分の $HOME が6 - 7 GB，自分PCのローカルWeb (外部非公開なので /home/ 以下に置いている)が max. 10 GBくらい．合計容量が BluRay (2層; 正味45GB程度)で1枚に収まるサイズを目安．
/data	使えるだけ全部	--	データ領域はいくらあっても不足．使用者(研究スタイル)により，必要量は数オーダー異なるので，「万人に受け入れられる目安容量」など，設定するのは不可能．ただし，オリジナルデータと自分が解析して得た二次処理データ置き場は絶対に分離する(物理的に異なるHDDに置く)方が良い．

個人設定ファイル

最初に結論．自分のアカウントの $HOME 以下，ドットファイル(ドットで始まるディレクトリ以下のファイルも含む) を忘れずに保存しておく．

特に私が忘れやすいものを以下に記す:

要バックアップ

bash 関連 (.bashrc , .bash_profile, .bash_logout): bash 使いなら，カスタマイズしてるはず． ssh-agent を動かしていたら，logout 時の終了処理部分も忘れずに．

Firefox の bookmarks.html: ~/.mozilla/firefox/*.default/ 以下．私の場合，bookmark は非常に大事．昔，たぶん2年ちょい使ったLinuxの入れ替え時に， bookmarks.html を吹っ飛ばしたことがある (2009年頃か?)．研究生活に必要な web アドレス情報を復旧するのに，それなりに時間がかかった．なお，~/.mozilla/firefox/*.default/ 以下は，個人情報も大量に含まれる．取扱いにはくれぐれも注意．

~/.vimrc: vim の設定．私は個人的にカスタマイズしてるので，これがないと後で非常に困る．以前の私は emacs 系エディタも併用していたので，当時は ~/.emacs も重要なドットファイルの一つだった．しかし，おそらく2005年頃以降では vi 系しか使ってない．

~/.gmtdefaults4: GMT の個人設定パラメータファイル． default からの修正は多くないので，もし無くなっても大きな損失ではないが，過去の環境との整合性を守るために保存

~/.gv: GV の設定パラメータファイル．カスタマイズしてる箇所は多くないので，後日再作成してもそれほど大きな手間ではない．実際に，2ー3回前まで(2008年頃まで?)のOS更新時には無視していた．しかし，OS更新直後に更新前環境に戻すために手作業で修正するのがストレスになり始めたため，最近ようやくバックアップ対象となった

~/.ncftp/: ncftp コマンドの設定やログなど．ログは不要だが，anonymous 接続用のデフォルトパスワード(自分のメールアドレス) などの情報がある(~/.ncftp/prefs.v3)ので，保存．異動時には，前の職場のメールアドレスから新アドレスへの変更を忘れずに．

旧環境をまるごと移設すべきでないもの

なお，バックアップを新規環境に移行する時には，必ずしも過去の設定全てを認識できるとは限らない事に注意．自分の経験で，バックアップを丸ごとコピーしたがゆえに困った事例を以下に挙げる:

~/.gnome 関連．CentOS でも，バージョンアップのたびに何度かトラブルを経験．記憶にあるのは，アイコン画像がなくなった(ディレクトリ名・ファイル名が変更された)，のような，些細なトラブル．ただ，それを経験するたびに小さなストレスを感じたので，旧環境を新環境にコピーすることをしなくなった．丸ごとコピーは行わないが，参照はする．
~/.ssh/ 関連．セキュリティに関わることなので，丸ごとコピーするのは少々気分がよくない
~/.scim/ 関連．コピーしたら変な挙動示したことがある．新環境で存在しなければ自動作成されるものなので，コピーしない方がよい．もし個人的にカスタマイズしてるなら話は別だが，私は何もカスタマイズしてないので移行に気をつかう必要が無い

旧環境の保存: HDD 外してしばらく保管

私の個人ルールでは，保存媒体 (私の場合， HDDそのもの)は，最低でも3ヶ月程度は保管し，他の用途への転用などを行わない．具体的には，保存媒体をオフライン化 (PC ケースから外に出す，電源を入れずケース内に放置，など)して保管．参照の必要が生じたら，USB や IEEE，eSATA 端子経由で外部記憶装置として接続，アクセスする．

「OSバージョンアップに伴うアップグレードインストールなどをする前に，必ず重要ファイルのバックアップをとっておく」

... というのは，どんなマニュアルでも・誰しもが書くこと．それでも，アップグレード後になって「あのファイルが上書きされた! どうしよう!!」なんて事態は必ず生じる．人間，誰しも間違う & 忘れっぽいのだから，間違いが起きることを前提とした行動をとるべき．

私見だが，一番確実かつコスト安な方法は「現状維持のまま凍結保存」である．これまで使っていた作業環境を丸ごと，一定期間保存するのが簡単である．

これだと，古い HDD の使いまわしが(少なくとも一定期間は)出来ないので，余分な出費が増える．しかし，もし本当に大事な情報の場合，または情報の復元にかける労力 (金銭・時間両方の合計)が多大な場合，リスク回避の必要経費として HDD 一つの値段など，大した出費とは思えない．

バックアップスクリプト

Under construction!

同期をとる

rsync コマンドを使用．元ファイル・ディレクトリの全てのメタ情報，例えば owner/group ID やパーミッション，更新時刻情報など全てにわたってバックアップするなら，rsync コマンドが楽だろう．

Case 0. 一般ユーザでの自動実行

$HOME のバックアップを，対象PC内で一般ユーザが使用可能な，かつ $HOME とは物理的に異なる別HDDに取る方法．物理的に異なる HDD が同時に損傷する可能性は少ないだろうから，自分の $HOME が完全に吹きとぶリスクはかなり低くなる．

これだけなら，下記のようなシェルスクリプトを作り， cron 実行を設定すれば良い．極めて原始的かつ単純な方法だが，とにかく自動バックアップを始めたいなら，この程度でも十分．バックアップ取り忘れの可能性が無くなるのは大きな利点．

差分バックアップや，最新版だけでなく複数時期のバックアップを残したいなどの場合は，もっと複雑な条件設定に関する記述の必要あり．その手順は少々面倒なので，ここでは書かない．

#!/bin/sh

source_dir=$HOME
output_dir=/work/user01/home_backup

if [ ! -d ${output_dir} ] ; then
  mkdir -p ${output_dir}
fi

rsync -au ${source_dir}/* ${output_dir}/.

exit

なお，必要ならバックアップ先ディレクトリに適切なパーミッション設定を入れること．上記の例では何も指定していないので，システム標準のパーミッション(CentOS なら umask 022 に従う)でディレクトリが作成されている．このため，現状では他のユーザからも $HOME 以下が閲覧可能になる可能性がある．他者に見られて困るものが $HOME にあるなら，この方法をおこなうべきでない．

Case 1. root での手動実行

# mount /dev/sdc1 /mnt/usb01
# rsync -a /home/user01/* /mnt/usb01/backup/.

これは欠点が2つ．(1) マウントは手動である(マウント先も事前設定)， (2) 管理者でのログインが必要である．これでは使い勝手が悪いし，何よりユーザ全員に管理者権限を付与するわけにはいかない．個人PCで自分個人だけが使うならこの程度で良いが，大学研究室の計算機のような複数人利用環境では問題あり．

Case 2. 一般ユーザでの半自動実行

上記を改善するため， (1) autofs により自動マウント．ただし，他ユーザからのアクセス(read & write の両方)は不許可． (2) sudo を利用，mount/umount コマンドだけは指定ユーザにのみ使用許可


(実行コマンドは後日記載．ひとまず pending)

Case 3. 一般ユーザでの半自動実行，バックアップ先も限定

autofs 使用．マウント先は，"/mnt/ユーザアカウント名/デバイス識別用の名前/" とする．ユーザアカウント以下は，本人のみしかアクセスできないように設定．
バックアップ先(ユーザ個人所有のUSBメモリなど)は，ユーザアカウントごとに個別指定．なお，UUID を利用してマウント先とバックアップ装置との関連付けするため，初回のみ root 権限による autofs 関連設定ファイルの修正が必要

(初回のみ)
[バックアップ装置のデバイスレターを sdc ，ext3 にてフォーマット]
# fdisk /dev/sdc
# mkfs.ext3 /dev/sdc1

(UUID 付与，情報を確認)
# /sbin/tune2fs -U random /dev/sdc1
# /sbin/tune2fs -l /dev/sdc1 | grep UUID

(マウント先を作成，所有権限を user01 にのみ限定)
# mkdir /mnt/user01/hoge01
# chown user01: /mnt/user01/hoge01

(sudo にて mount/umount 実行を許可．autofs の設定も追記)
# visudo
# vi /etc/auto.mnt

(以後，一般ユーザでの実際の利用)
$user01: cd /mnt/user01/hoge01       <= autofs により自動マウント
  (必要なコマンドを実行)

ひとまずこの手順で利用開始してみたが... どうにも設定が面倒．これだと，人数やデバイス数に比例して設定を追記する必要がある．もっと単純な手順にしないと，すぐに破綻してしまうのが明らか．とりあえず今後の課題とする．

Web関連 (HTML, PHP, CSSファイルなど)バックアップ

対象ディレクトリ以下にある特定の拡張子をもつファイルだけをリストアップ，バックアップする方法．この例では，拡張子 html, php, css などだけを選択して tar archive する．

Web 用ディレクトリに多い画像ファイルなど，ファイルサイズが巨大になりがちなものを排除してバックアップしたい... という用途に向いているだろう．

#!/bin/sh
source $HOME/bin/function/chk_dir_file

tmp00="tmp00_$$.txt"
  tmp_list=" ${workdir}/$tmp00 "

chk_file ${workdir}/$tmp00

tar_output=/hoge/backup/web_PHP_HTML.tgz

### Tar option: tar+gz (*.tgz) & preserve mode/owner information.
# Use --preserve-permission & --same-owner options.
tar_opt=" --preserve-permission  --create --gzip   --file --same-owner "

target_dir_list=" /work/ftp/pub /var/www/html "
for target_dir in ${target_dir_list} ; do
  find ${target_dir} -type f -iname "*htm*" -print >> ${workdir}/$tmp00
  find ${target_dir} -type f -iname "*php"  -print >> ${workdir}/$tmp00
  find ${target_dir} -type f -iname "*css"  -print >> ${workdir}/$tmp00
done  # target_dir

tar ${tar_opt} ${tar_output} --files-from ${workdir}/$tmp00

cleanup_workfile  ${tmp_list}

上記では，shell script 内で私がよく使う関数 (上記スクリプトでは chk_file, cleanup_workfile) を記述したファイル chk_dir_file を最初に読み込んでいる (see also 自分専用コマンド・関数)
tar コマンドのオプションは，使用者の好みで変更を．私の場合，自宅PCやノートPCのVMware上でも同一環境を構築している．ファイル・ディレクトリパーミッションや所有者名義の保存は，異なる計算機への移植時に重要となる事がある．特に，wiki 関連を移行先でも正常動作させるために owner や permission 情報を保存せねばならない．
tar のオプションと選択するファイルを正規表現を使って表現すれば，同様の事をもっと短く記述するのは可能だと思う(未検証)．ただ，自分にとってはこちらの方がわかりやすい(正規表現は単純なものしか覚えてない)
anonymous FTP ディレクトリ以下および httpd の DocumentRoot 以下の web 関連の主要テキストファイルを対象とする．私にとって web 関連ディレクトリ以下で最重要なのは，テキストファイル．画像ファイルは，拡張子だけで重要・非重要を区分できないし，私のwebページの場合，画像ファイルが多すぎて (現時点で数百ギガバイト程度．そろそろテラバイトに達するか...?)，バックアップ不可能．

応用として，

シェルスクリプトやプログラムのソースだけ(拡張子 *.sh や *.c, *.f90 など)をバックアップ
README や設定ファイルだけ (*readme* とか，*.conf のような指定) をバックアップ

なども有効な使用法だろう．

システム領域 (/etc, /var など)バックアップ

/etc や /var のバックアップ (管理コマンドのメモ内)を参照．

バックアップ(個人用ファイル)