総合演習 ― 全章の集大成

解説 ― SET 1 で何をしたか

1行目のmkdir -p ~/backupsは1-2で学んだコマンドで、バックアップファイルの保存先ディレクトリを先に作っています。2行目のls -d ~/backupsはディレクトリ自体の存在確認です(-dを付けると中身ではなくディレクトリそのものが1行表示されます)。3行目のls ~/scriptsで、6章から引き継いでいる練習スクリプトが今も残っていることを確認しておきます。4行目のid yumiは2-2でおなじみのコマンドで、バックアップ対象であるyumiが今もこのサーバーに存在していることを最終確認しています。

5行目のdate +%Fは、これから書くスクリプトの中で使う日付の書式(YYYY-MM-DD形式)を先に手元で確認しておく一言です。6行目のtouch ~/scripts/backup.shは1-2で学んだコマンドで、空のファイルを先に作っています。7行目のnano ~/scripts/backup.shで、6章で慣れ親しんだ~/scriptsの中に新しいスクリプトを作成します。8行目以降はcatでその中身を確認した出力例で、スクリプトの全文です(このページでは行数が多くなるため出力例を通常より多く表示しています)。1行目の#!/bin/bashは6-2で学んだシバン行、これから続く行をbashで実行するという宣言です。

TARGET_DIRとBACKUP_DIRは6-1で学んだ変数です。バックアップ元(yumiのホーム)と保存先を変数にしておくことで、あとから書き換えやすいスクリプトになります。TODAY=$(date +%F)は6-1で扱ったコマンド置換$()^※1で、date +%F(YYYY-MM-DD形式の今日の日付)の結果を変数に代入しています。BACKUP_FILEはこれらを組み合わせて、yumi-2026-07-03.tar.gzのような日付付きのファイル名を組み立てています。

1つ目のif [ ! -d "$TARGET_DIR" ]; then ... fiは6-3で学んだ条件分岐で、-dは「ディレクトリとして存在するか」を調べるテスト演算子^※2、!はその否定です。つまり「もしバックアップ元のディレクトリが存在しなかったら、エラーメッセージを出してexit 1(異常終了)する」という安全装置です。2つ目のifは、保存先~/backupsが万一なければその場で作る保険です。

最後のtar czf "$BACKUP_FILE" "$TARGET_DIR"は4-4で学んだアーカイブ作成で、c(作成)・z(gzip圧縮)・f(ファイル名指定)を組み合わせ、$TARGET_DIRを丸ごと$BACKUP_FILEという1つの圧縮ファイルにまとめます。最終行のechoは、いつ・どのファイルにバックアップが完了したかをログとして画面に出力する一言です。変数はすべてダブルクォートで囲んでいますが、これはパスの中にスペースが入っていても安全に扱えるようにする6章で学んだ書き方です。スクリプトを書き終えたら、9行目のwc -lで行数を確認しておきます(1-4で学んだ、テキストの行数を数えるコマンドでした)。

解説 ― SET 2 で何をしたか

1行目のchmod +xは6-2でおなじみ、スクリプトに実行権限を与える一言です。2行目のls -lで、出力例のように権限欄にxが加わっていることを確認します。3行目のbash -nは、スクリプトを実際には実行せず文法だけをチェックするオプションです。エラーがなければ何も表示されず、次のプロンプトに戻ります。いきなり本番実行する前に、こうした軽いチェックを挟む癖をつけておくと安心です。

4行目、あえてsudoを付けずに./scripts/backup.shを実行してみると、出力例のようにtar: /home/yumi: Cannot open: Permission deniedというエラーで止まります。バックアップ対象の/home/yumiは所有者がyumiのディレクトリで、一般ユーザーのubuntuには他人のホームディレクトリを丸ごと読み取る権限がないためです。5行目、改めてsudo ~/scripts/backup.shで実行します。tarコマンドが/home/yumiの中身を読み込むためには管理者権限が必要になるため、今度はスクリプト全体をsudoで実行しています。出力例のとおり、スクリプト内のechoの結果がそのまま画面に表示されます。

6行目のls -lh ~/backupsで、日付入りの.tar.gzファイルが実際に作られたことを確認します。sudoで実行したため、ファイルの所有者がrootになっている点にも注目してください。7行目のfileは1-4で学んだ、ファイルの種類を判定するコマンドで、出力例のようにgzip compressed dataと表示されれば圧縮ファイルとして正しく作られていることがわかります。8行目のtar tzfは4-4で学んだ、アーカイブを展開せずに中身の一覧だけを確認するオプション(t=list)です。出力例のようにhome/yumi/以下のファイルが並んでいれば、バックアップは正しく作られています。9行目のdu -shで、~/backupsディレクトリ全体のサイズを確認し、10行目のdf -h /で4-2のおさらいとしてサーバー全体のディスク使用状況も見ておきましょう。

解説 ― SET 3 で何をしたか

1行目でまずcrontab -lを確認すると、出力例のようにno crontab for ubuntuと表示されます。5-3で登録した練習用のcronは既に空に戻してあるため、一般ユーザーubuntuのcrontabには何も登録されていません。2行目でsudoを付けて確認しても、root用のcrontabもまだ空です。

3行目のsudo crontab -eで、5-3で学んだcronの設定を編集します。/home/yumiを読むにはroot権限が必要なので、ここでも一般ユーザーのcrontabではなくsudo crontab -e、つまりrootのcrontab^※3に登録します。開いたエディタの末尾に、出力例のような1行を追記して保存します。

5フィールドの読み方は5-3のおさらいです。0 3 * * *は「分=0、時=3、日=毎日、月=毎月、曜日=毎曜日」、つまり毎日午前3時ちょうどに実行するという意味です。人がほとんどサーバーを使っていない深夜の時間帯を選ぶのは、バックアップ処理がCPUやディスクに負荷をかけている間、他の作業を邪魔しないようにするための現場の定石です。そのあとにスクリプトのパスを絶対パスで書いている^※4点にも注意してください。cronは実行時に~を正しく展開してくれないことがあるため、/home/ubuntu/scripts/backup.shのようにフルパスで書くのが安全です。

4行目のsudo crontab -lは、登録した内容をその場ですぐに読み返す確認作業です。5-3でも触れたとおり、cron登録は「入れたつもり」で終わらせず、必ず-lで見直す習慣をつけましょう。5行目で試しにsudoを付けずにcrontab -lを実行すると、出力例のようにno crontab for ubuntuと表示されます。これは一般ユーザーubuntu用のcrontabと、root用のcrontabが別物として管理されているためです。今回の設定はroot側にあるので、確認するときも必ずsudoを付けます。

これで、毎日午前3時になると自動的にbackup.shが実行され、~/backupsに新しい日付のファイルが積み上がっていく仕組みが完成しました。6〜7行目は現在時刻の確認と、今日時点でのバックアップ一覧の確認です。8行目のtar tzf ... | head -n 3は4-4のtarと3-5で学んだheadの組み合わせで、アーカイブの中身の先頭数行だけをさっと覗く実務でもよく使うテクニックです。9行目のhistory | tail -n 5は1-6のhistoryと3-5のtailの組み合わせで、このページで直近に叩いたコマンドを振り返っています。10行目のcd ~でホームディレクトリに戻り、このページのドリルを締めくくります。