カテゴリー: バッチ処理

わたしの経験では、バックアップの定期復元テストは有用だった。本記事で経験した内容を紹介する。

背景

とあるウェブサービスで、データベースを吹っ飛ばし、6重のバックアップが全滅していた話を聞いてぞっとしたから。

問題とその対策

ファイルサーバーへのバックアップが、一部ダウンロードされていなかった

バッチファイルの待機時間が長くて、別のタスクで実施された再起動で中断していた。待機時間を短く変更

ファイルサーバーで、古いファイルが自動削除されていなかった

バッチファイルを修正

設定に追加したサイトのバックアップが、ファイルサーバーにダウンロードされていなかった

サーバー側のバックアップファイル作成時間がバッチファイル実行時間より遅かった。順序を一致させた

ローカルでバッチ処理するパソコン乗り換えで、一部処理されないサイトが発生

ダウンロード管理表を使って、タスクを正しい時間に実行されるよう修正

復元作業手順書に書かれていない処理が分からず復元失敗

手順書を現状に即した内容で修正

復元先を間違えて、復元失敗

手順の中で、復元先を間違わないよう、日本語でディレクトリが分かるようにツールを変更

波及効果

• 管理者がだれでも短時間で復元できるようになった
• 手順書の強化に寄与できた

2サイト以上の小規模なサイト運用をしている管理者にとって、バックアップは重要だが手間のかかる作業だ。ここを自動化した。詳細は別途、記事にする。

前提
Cron が使えるレンタルサーバー
本記事では、さくらインターネットのレンタルサーバーを例にする

概要

DBバックアップ：さくらのレンタルサーバーでシェルを使う、実行はCron を1時間ごとに実行
ファイルのダウンロード：Windows のバッチ処理でFTP 接続を使ってダウンロード、バッチはタスクスケジューラーを使って毎週実行
バックアップは1サイトのディレクトリとDBを圧縮している
サーバー丸ごとバックアップしないのは、負荷分散と、復元が1サイトごとになると想定しているため

必要な手動作業

• バックアップ動作を監視する
• 復元テストを定期的に実行する(1回/月、月初に)
• 社内Wiki などに、復元作業手順書、復元テスト履歴を記載する
• 自動化に必要なシェル、バッチファイル、スケジュール計画表を管理

動作

Cron でシェルスクリプトを実行。コンテンツとDBをサーバー内に圧縮保存(毎日0時～、1時間おきに1サイトをバックアップ)
タスクスケジューラーで毎週土曜日12:00～、1時間おきにバッチファイルを実行する
バッチ処理で作業場内のファイルサーバーにデータをダウンロード

管理用ツール

Podesora

Podesora  はターミナル。
さくらのレンタルサーバーでシェルスクリプトを手動で動かす
シェルスクリプトの文字エンコーディング：SJIS(管理者用メールで文字化けしないため)
SSH接続例)

例) /home/mysite/backup/backup_website1.sh と入力、バックアップのシェルスクリプトを実行

7-Zip File Manager 圧縮、解凍ソフト

7-zip は、.sql.bz .tar.gz2 を解凍する

データベースを解凍するときは、文字エンコーディングを”UTF-8″にする。(SJIS だと文字化けする)