7.バックアップ
7.1 バックアップ
7.1.1 バックアップの必要性
現在のコンピュータでは、一般的なデータをハードディスクに記録していますが、故障発生や人的ミスなどにより、データが失われてしまう可能性もあります。しかし、定期的にバックアップをとっていれば、データが消失してしまってもデータを復元させることができます。
重要なデータを消失させないためにも、定期的にバックアップをとることが必要です。
※サーバー機不調の時はたまにお世話になってます。
7.1.2 バックアップ用のメディア
現在利用されているバックアップ用のメディアとしては・・・・
ＤＤＳ－ＤＡＴ、通常運用しているものとは別なハードディスク、ＣＤ－ＲやＤＶＤなどがあります。
私の場合は、ＦｒｅｅＢＳＤのサーバー機にバックアップ用のメディア装置を増設できないので次のような方法をとっています。
バックアップ元 → FreeBSD の Webコンテンツ領域 (Samba共有） → クライアント機の共有ドライブに設定
バックアップ先 → Win NT の ＭＯドライブ(Windows共有) → クライアント機の共有ドライブに設定
バックアップ起動 → クライアントＰＣに設定の MediaKeeper により差分バックアップ実行です。
ですので、これから紹介する tar は使っていません。
7.2 ファイル、ディレクトリ単位のバックアップ
7.2.1 tar コマンドによるバックアップ
tar コマンドは、複数のファイルを一つのファイルにまとめたアーカイブファイルを作成するためのコマンドです。
Linux(Unix)では、ファイルとしてデバイスを指定することができますので、複数のファイルをバックアップメディアに記録することによりバックアップを実現します。
【tar】・・・・・・・・ものによって微妙な違いは man などで調べてください。
機能 アーカイブの作成、展開 書式 tar cvf archive file . . .
tar tvf archive
tar xvf archiveオプション ｃ アーカイブの作成
ｔ アーカイブの内容確認
ｘ アーカイブの展開
ｖ 処理したファイルの詳細情報を表示する
ｆ ａｒｃｈｉｖｅ アーカイブの指定z アーカイブを gzip 形式にフィルターする j アーカイブを bzip2 形式にフィルターする
バックアップするファイル名はディレクトリでもよいです。その場合、指定したディレクトリ以下のファイルをすべてバックアップします。また、複数のファイルをバックアップする場合は、空白で区切ってファイルを指定します。
参考にした資料では比較的大きなファイルをバックアップし、リストアしてましたが、非力なマシンなのでちっちゃいサイズで試してみます。まずはバックアップしてみましょう。
次にリストアしてみましょう。
↑
確かにリストアされています。
次にFDにバックアップしリストアしてみましょう。FDは事前にフォーマットしておきましょう。
↑
おお、バックアップされたみたい。では、リストアを!
↑
OKですね!
7.2.2 圧縮バックアップ
tar コマンドは、gzip / bzip 形式で圧縮したアーカイブを作成することができます。
gzip 形式は z , bzip 形式は j オプションを指定します。圧縮されたアーカイブの内容を確認、展開するには、圧縮時に指定されたオプションを指定する必要があります。
↑
なるほど、出来ていますね。
※圧縮率は bzip2 の方が高いですが、圧縮速度は gzip の方が速いとのことです。
7.3 ファイルシステム単位のバックアップ
7.3.1 dumpコマンドによるバックアップ
tar コマンドを利用してもバックアップをとることは可能ですが、より本格的にバックアップを行う場合は、dump コマンドを利用します。
dump コマンドはファイルシステム単位(パーティション単位)でバックアップを行います。さらに差分(インクリメンタル)バックアップを利用して、前回バックアップを行った後に変更されたファイルのバックアップのみをバックアップすることができます。
【dump】
機能 ファイルシステムのバックアップ 書式 dump -[0-9]uaf backup device
device は該当パーティションのデバイスファイル名、またはマウントポイントオプション -[0-9] バックアップレベルの指定。 0 がフルバックアップ 1-9 がインクレメンタルバックアップ
-u /etc/dumpdates の更新 インクリメンタルバックアップを実現させるために必要
-a サイズ自動調整
-f バックアップファイルの指定
・dump コマンドのレベル
0 : フルバックアップ(指定したファイルシステムを全てバックアップ)
1 ～ 9 : 差分バックアップ
差分バックアップは、指定されたレベルより小さいレベルでバックアップをとった日以降に変更があったファイルのみをバックアップします。例えば、次のような感じです。
それでは、/home をバックアップしてみましょう。その前に現在の状況を見ておきましょう。
では、実行です。
↑
どうやらできた? では確認してみましょう。
↑
できました。 /var の使用率も増えていますね。
では、/home に takaq.txt というファイルを作ってレベル3でインクリメンタルバックアップをしてみましょう。
↑
これもOKです。では、確認してみましょう。
↑
いいようです。
雑記
後からパーティションを追加した /data (/dev/hda6) をダンプしたかったのですが、dump したら「これは fstab に dump の記述にないからだめですよぉー」みたいなメッセージが出てダンプできませんでした。
LABEL=/data /data ext3 defaults 1 0
となってんですけど・・・・最後のパラメータが「0」だから? でもここ「1」にすると fsck エラーに!!!
これも Plamo Linux(98)のせい?
バックアップを行った日付やパーティションの情報は /etc/dumpdates ファイルに出力され、この情報をもとに差分バックアップが行われています。
↑
こんな感じですね。
7.3.2 計画によるバックアップ
dump コマンドを利用してバックアップを行う例を以下に示します。
●月単位のバックアップ
毎月一回、１日にフルバックアップを行う。
●週単位のバックアップ
・毎週金曜日に、１日以降に変更されたファイル全てを差分バックアップする。
・直前の金曜日か１日の近い方の日以降に変更されたファイル全てを差分バックアップする。
ただし、１日と金曜日は行わない。
●dump レベルスケジュール
日付 1 2 3 4 5 6 7 8 9 曜日 日 月 火 水 木 金 土 日 月 レベル 0 2 2 2 2 1 2 2 2
・1日にフルバックアップ
・2日～5日は1日からの変更分をバックアップ
・6日は1日以降に変更された分をまとめてバックアップ
また、dump することを忘れないために、 /etc/fstab にはダンプを行う間隔を記述するフィールドがあります。
このフィールドを適切に設定しておきますと、dump -w コマンドでダンプを行うべきファイルシステムを表示することができます。
/etc/fstab の hda3(/home)の記述 → /dev/hda3 /home ext3 defaults 2 1
前回の dump が Sun May 8 22:40:28 2005 なので・・・・
では、２日(48時間)経過したら・・・・下のようになりました。
この報告の仕方も、参考にした資料のRed Hat系のものとは少し違っています。
7.3.3 dump で作成されたバックアップのリストア
dump コマンドを使って作成したバックアップをリストアするには、文字通り restore コマンドを利用します。
【restore】
機能 dump で作成されたバックアップの復元 書式 restore -rf backup
restore -if backupオプション -r バックアップの内容を全て復元する。
-i 対話的に復元を行う。
-f バックアップファイルを指定する。
-t バックアップファイルの内容を確認する。
では、先に作ったバックアップ dump0 dump3 を復元してみましょう。復元する時はレベルの小さい方から復元します。
まずはリストア先のディレクトリを作成して、カレントディレクトリを移動しましょう。
そして、dump0 を復元しましょう。
次は dump3 を復元します。これの後で ls で見ると takaq.txt が存在しているはずです。
↑
どうやら復元しました。でも、restoremytable ってなんでしょう。
↑
割と大きなファイルですね。cat で中見てみましょう。こんな感じです。
どうやら、そこにあったファイルやディレクトリ情報のようです。
【ちょっと実践的に】
/home がこわれた時の復元を想定してみましょう。
①リストア用のパーティションを作成します。( /dev/sda2 と仮定します。→ファイルシステムを作成します)
② /dev/sda2 を /home にマウントします。
③ /home にバックアップをリストアとます。
④自動マウントを設定します。
ラベルを設定します。(e2label /dev/sda2 /home → /etc/fstab を書き換えなくてもよいので!)
もしくは /etc/fstab を編集します。( /dev/sda2 /home default 1 2 )
だいぶ端折りましたけど、こんな感じでしょうか。
7.3.4 restore コマンドによるバックアップの復元
●dump レベルスケジュール
日付 1 2 3 4 5 6 7 8 9 曜日 日 月 火 水 木 金 土 日 月 レベル 0 2 2 2 2 1 2 2 2
・1日にフルバックアップ
・2日～5日は1日からの変更分をバックアップ
・6日は1日以降に変更された分をまとめてバックアップ
上記のようなスケジュールで運用していたところ /home に「9日」に故障が発生した場合のリストア手順を以下に記載します。
①リストア用のパーティションを作成します。( /dev/sda2 と仮定します。→ファイルシステムを作成します)
②/dev/sda2 を /home2 にマウントします。
mount -t ext3 /dev/sda2 /home2
③カレントディレクトリをマウントした場所に移動します。
cd /home2
④まず、フルバックアップである「1日」の分( dump0 と仮定)をリストアします。
restore -rf /var/backup/dump0
⑤次に「1日」からの差分バックアップをとった「6日」の分( dump6 と仮定)をリストアします。
restore -rf /var/backup/dump6
⑥そして「6日」からの差分バックアップをとった「8日」の分( dump8 と仮定)をリストアします。
restore -rf /var/backup/dump8
⑦/home2 のマウントを外し、新たに /home へマウントします。
umount /home2
mount -t ext3 /dev/sda2 /home
⑧ /etc/fstab を編集し自動マウントを設定します。
上記により、/home が「8日」の時点まで復元されます。
7.3.5 対話的なバックアップの復元
restore に -if オプションを指定することにより、対話的にバックアップからファイルを復元することができます。
通常この方法は必要ないですが、誤って削除してしまったファイルを復元する時に使用します。
対話的なバックアップの復元においては、バックアップデータをファイルシステムのように取り扱うことができます。
ls コマンドや cd コマンドを使って、復元したいファイルに対して add コマンドを実行します。
実際の展開は extract コマンドで行われます。
では、見てみましょう。
リストア用に /restore1 ディレクトリを作成してカレントディレクトリを移して作業してみます。
では、Mail ディレクトリを復元してみましょう。
↑
Mail に選択した * マークがつきましたね。
どれ、どんな風に復元したでしょう。
↑
おおー、すばらしい!ちゃんとディレクトリ構造も復元してますね。
7.4 定期的作業のスケジューリング
7.4.1 スケジューリングタスク
バックアップは、定期的に実行するものです。Linux(UNIX)には定期的にコマンドを実行するサービス : cron があるのでバックアップを自動的に実行させることが可能です。
スケジューリングタスクを行うサービスは crond でクロックデーモンと呼ばれます。
7.4.2 crontab ファイル
cron の設定は /etc/crontab ファイルで行います。・・・・と参考にした資料にはあったし、FreeBSDもこれを編集しましたが、Plamo にはこのファイルがありません。
あれ、どうすんの・・・・で調べたら crontab というコマンドを使うらしいです。
man crontab をしてみました。
CRONTAB(1) CRONTAB(1)
NAME
crontab - manipulate per-user crontabs (Dillon's Cron)
SYNOPSIS
crontab file [-u user] - replace crontab from file
crontab - [-u user] - replace crontab from stdin
crontab -l [user] - list crontab for user
crontab -e [user] - edit crontab for user
crontab -d [user] - delete crontab for user
crontab -c dir - specify crontab directory
DESCRIPTION
crontab manipulates the crontab for a particular user.
Only the superuser may specify a different user and/or
crontab directory. Generally the -e option is used to
edit your crontab. crontab will use /usr/bin/vi or the
editor specified by your VISUAL environment variable to
edit the crontab.
Unlike other crond/crontabs, this crontab does not try to
do everything under the sun. Frankly, a shell script is
much more able to manipulate the environment then cron and
I see no particular reason to use the user's shell (from
his password entry) to run cron commands when this
requires special casing of non-user crontabs, such as
those for UUCP. When a crontab command is run, this
crontab runs it with /bin/sh and sets up only three envi-
ronment variables: USER, HOME, and SHELL.
crond automatically detects changes in the time. Reverse-
indexed time changes less then an hour old will NOT re-run
crontab commands already issued in the recovered period.
Forward-indexed changes less then an hour into the future
will issue missed commands exactly once. Changes greater
then an hour into the past or future cause crond to resyn-
chronize and not issue missed commands. No attempt will
be made to issue commands lost due to a reboot, and com-
mands are not reissued if the previously issued command is
still running. For example, if you have a crontab command
'sleep 70' that you wish to run once a minute, cron will
only be able to issue the command once every two minutes.
If you do not like this feature, you can run your commands
in the background with an '&'.
The crontab format is roughly similar to that used by vix-
iecron, but without complex features. Individual fields
may contain a time, a time range, a time range with a skip
factor, a symbolic range for the day of week and month in
year, and additional subranges delimited with commas.
1 May 1994 1
CRONTAB(1) CRONTAB(1)
Blank lines in the crontab or lines that begin with a hash
(#) are ignored. If you specify both a day in the month
and a day of week, the result is effectively ORd... the
crontab entry will be run on the specified day of week and
on the specified day in the month.
# MIN HOUR DAY MONTH DAYOFWEEK COMMAND
# at 6:10 a.m. every day
10 6 * * * date
# every two hours at the top of the hour
0 */2 * * * date
# every two hours from 11p.m. to 7a.m., and at 8a.m.
0 23-7/2,8 * * * date
# at 11:00 a.m. on the 4th and on every mon, tue, wed
0 11 4 * mon-wed date
# 4:00 a.m. on january 1st
0 4 1 jan * date
# once an hour, all output appended to log file
0 4 1 jan * date >>/var/log/messages 2>&1
The command portion of the line is run with /bin/sh -c
<command> and may therefore contain any valid bourne shell
command. A common practice is to run your command with
exec to keep the process table uncluttered. It is also
common to redirect output to a log file. If you do not,
and the command generates output on stdout or stderr, the
result will be mailed to the user in question. If you use
this mechanism for special users, such as UUCP, you may
want to create an alias for the user to direct the mail to
someone else, such as root or postmaster.
Internally, this cron uses a quick indexing system to
reduce CPU overhead when looking for commands to execute.
Several hundred crontabs with several thousand entries can
be handled without using noticable CPU resources.
BUGS
Ought to be able to have several crontab files for any
given user, as an organizational tool.
AUTHOR
Matthew Dillon (dillon@apollo.west.oic.com)
1 May 1994 2
ちなみに、crontab -l としてみると。
↑
現在の内容がこのように表示されます。んー・・・・で、また調べました。
どうやら次のような感じです。
【まとめ】
cronのデフォルトの設定ファイルは/etc/crontabです。(このサーバーにはありませんでした)
したがいまして、次のような自動実行は無いようです。→自分で書かないとだめなのかも!
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly/etc/cron.うんたらというディレクトリもありません!
自分で新たにタスクを登録するには、/etc/crontabに書いてもいいのですが、それだとrootでしか登録ができません（/etc/crontabの所有者がrootなので）。
ですので実際には別のファイルにタスクを書きます（/etc/crontabに直接書いてしまっても構いません）。
タスクを記述するファイルはこのサーバーの場合、「/var/spool/cron/crontabs/ユーザー名」です。rootの場合、「/var/spool/cron/crontabs/root」になります。
vi等のエディタでファイルを新規作成しても構いませんが、専用のコマンド「crontab」を使いましょう。
いずれも、ログインしたユーザーで該当のディレクトリに作成・編集されます。
●現在の設定を表示
crontab -l
●設定の編集
crontab -e
●設定の削除
crontab -r
●ファイルの書式
内容 意 味 ディフォルト／ユーザー SHELL /etc/passwordの記述に関係なく、強制的にここで定義されたシェルを使います。 ディフォルト(crontab) PATH パスの設定 ディフォルト(crontab) MAILTO
- cronの実行結果をここで指定されたユーザー宛にメールで送ります。ユーザー名を空にするとメールを送信しません。ただし、MAILTOの記述自体をしないと、crontabファイルの所有者にメールを送ります（デフォルトではroot）。
- FreeBSDでは実行文がエラーの時だけメール来ました。
ディフォルト(crontab) HOME cronを実行する際のホームディレクトリの設定です。 ディフォルト(crontab) 実行文（タスク） 分 時 日 月 曜日 (ユーザー) コマンド
分 ： 0-59
時 ： 0-23
日 ： 1-31
月 ： 1-12
曜日： 0-6 0：日曜日 1：月曜日 ・・・・・・ 6：土曜日
（ユーザー） 実行ユーザー（省略可）
コマンド cronが実行するコマンドです。
----------
日付、時間の部分は範囲指定が可能です。例えば1時、2時、3時なら、時間のフィールドに「1,2,3」と書く代わりに「1-3」と書けます。また、何分おき（あるいは何時間おき）という場合は「*/」の後に書きます。2時間おきなら「*/2」です。「1,4,7,10」は「1-10/3」と書くこともできます。共通
7.4.4 定期的なバックアップ
上記のようにcronを利用して自動バックアップする方法を検討してみましょう。
例えば、次のような計画を立ててみました。
【/homeの月単位のバックアップ】
毎月１日にフルバックアップを実行する。
【／ｈｏｍｅの週単位のバックアップ】
・毎週金曜日に、１日以降変更されたファイルすべてを差分バックアップする。
・直前の金曜日か１日の近い方の日以降変更されたファイルすべてを差分バックアップする。
（ただし、１日と金曜日は実行しない）
次の記述を /etc/crontab に追加するとよいでしょう。
# Backup Task /home
30 4 1 * * root dump -0uaf /var/backup/dump0 /home
40 4 2-31 * 5 root dump -1uaf /var/backup/dump1 /home
50 4 2-31 * 0-4,6 root dump -2uaf /var/backup/dump2 /home
| Prev | Top | Next |
| ユーザ管理 | 目次 | ログ管理 |
