こんにちは。フリーエンジニアの木下です。
ファイルサーバーのバックアップ、どうされていますか？ファイルサーバーの運用管理業務のうち、労力を要する業務の一つにデータバックアップがあります。
システム管理者にとっては費用と労力に見合わない業務の代表格がこのバックアップ管理業務です。
バックアップ管理の中で一番手間暇が掛かってしまうのが『ファイルサーバーのバックアップ』と表現できます。
- 連載『ファイルサーバーの導入運用を学ぼう』のほかの記事はこちら
第1回：うちのファイルサーバー遅すぎ・・・！？導入時に考慮すべき２つのスペック - 第2回：ファイルサーバーをより便利に。二つの共有フォルダ
- 第3回：ファイルサーバーの重要業務はディスク容量のキャパシティ管理
- 第4回：この記事
- 第5回：社外とのデータやり取りに共有フォルダを使いたい
- 第6回：悩んでる？3つのポイントからファイルサーバーとオンラインストレージの選び方を考える
- 第7回：ファイルサーバーとオンラインストレージの認証管理
第8回：ファイルサーバーとオンラインストレージの障害対処の差
①ファイル数が多い＝バックアップに要する時間が多い
20GBの単一ファイルをバックアップするよりも20GB分のファイル（例えば20KBのファイルを1,000,000個）バックアップを取得する方がタスクの実行時間を要します。
これはコンピュータ（記憶装置）の仕様上の話です。小さい細切れのファイルを大量にバックアップするよりも、大きな連続した単一ファイルのバックアップのほうが、読み書きに掛かる時間が少なく済む、という動きをします。
よって、個人で利用されているPCであれば極力ZIP圧縮してバックアップに掛かる時間を削減することができるのですが、ファイルサーバーにおいては、共有フォルダ内のファイルに手を加えてユーザーの利便性を阻害してしまうような方法でバックアップ時間を短縮するといった負荷軽減策は実行できません。
それなりの規模で運用されているファイルサーバーであれば、ファイルサーバーの仕様容量が数TBに到達する容量をバックアップしなければならないことが多いと思われますが、バックアップ取得という視点だけで見ると一番効率の悪いファイルコピー方法でバックアップデータを収集しなければならないのが、ファイルサーバーのバックアップである、と言えます。
バックアップはユーザーが利用していない夜間にまとめて取得することが多い処理ですが、バックアップに要する時間が想定外に増えてしまうことで、バックアップ処理が一晩で完了せず、業務開始時間を過ぎてもバックアップタスクが動作し続ける、ということも発生しうることになります。
バックアップ処理が業務開始時間に食い込む影響として、ファイルサーバーの処理に必要なCPUやメモリやストレージのI/Oといったサーバーリソースが、想定外に消費されることになってしまい動作に支障をきたすことや、ファイルが使用される（ロックされる）ことによってバックアップの取得漏れなどが発生することで肝心のファイルリストア時に復元したいファイルが存在しないという弊害も想定されます。
②バックアップ先の容量監視
ファイルサーバーのバックアップ必要容量は他のサーバーに比較して桁違いに多くなるという点は運用設計時に考慮しておく必要があります。
社内システムで利用中のDBサーバーやメールサーバーなど、バックアップを収集されているサーバーは他にも多くあるかと思いますが、ファイルサーバーのバックアップに要するストレージ容量は飛び抜けて多くなるのではないでしょうか？
何しろ、社内イントラネットユーザーの中で、ファイルサーバーのアクセス権が付与されないユーザー、というのはほとんど居ないことが一番の理由です。全ユーザーが何かしらの共有フォルダへのアクセス権を有しており、アクセス権があるフォルダに対して自由に自身のデータを格納することができます。
自由にデータを格納できることと、ファイルサーバーの容量管理はシステム部門が実施しているので、ユーザーにとってはファイルサーバーの残り容量などはあまり気になりません。自宅のPCの外付けハードディスクであれば残り容量に注意するようなユーザーでもファイルサーバーの残り容量を気にして利用する社内ユーザーはほとんどいないと言えます。
このようなユーザーが束になってデータを格納するサーバーがファイルサーバーです。
これによってファイルサーバー本体に容量が必要になるのはもちろんですが、世代管理をしなければならないバックアップという観点から言えばファイルサーバーの数倍の容量をバックアップ先のストレージに要求されることになってしまいます。
つまり単純にファイルサーバーの容量と同容量のストレージに対してバックアップを（上書きして）保管するだけではなく、バックアップを取得した時点でのデータをそのまま保管した状態で新たにバックアップを取得することが一般的です。同一名称のファイルでも1日前と2日前の2種類の（内容が相違した）データをバックアップして、ユーザーが要望する時点にデータを復旧させる必要があるからです。これを世代管理と言います。
世代管理であれば、全体をバックアップするフルバックアップを複数持つことが要件となりますので、必然的にバックアップを保管するストレージ容量はファイルサーバーの2倍3倍の容量が要求されることになります。
③バックアップログは毎日確認
ひとたびバックアップが失敗してしまえば、その阻害する要因を取り除かない限りバックアップの失敗は継続してしまいます。このバックアップの失敗を知るための方法として、毎日バックアップタスクの実行結果をメールなどで受信しているシステム管理者の方は多いと思います。
ですが、製品によっては、バックアップに失敗したファイルを見つけ出すために大量のログファイルから失敗したファイルを見つけ出したり、原因となるエラーコードをログファイルの大量のエントリから見つけ出したりとかなりの根気が要求される作業もあります。
ログを日々チェックするのはシステム管理者の業務の一環とはいえ、日々大量のログファイルから問題があるバックアップタスクとバックアップファイルを見つけ出すのはそれだけで労力がかなりかかるものです。
④いちばん重要な「リストアは成功するか」
一番に重要なのは、バックアップの成否ではなくリストアの成否です。問題・障害の解決方法が「バックアップデータからのリストアしかない」という局面が運用管理の現場ではよくある話であり、バックアップが成功・失敗していたかということより、復元したいデータのリストアが成功するかどうか、ということが一番のプライオリティだといえます。
バックアップやデータリストアのことまで考慮してファイルサーバーを導入する、というのは少数派だという感覚が個人的にはあります。ファイルサーバーを運用するうえでバックアップの運用管理は避けて通れない業務の一つにもかかわらずファイルサーバーの導入時にはバックアップ・リストアはそれほど要件定義の話に挙げられません。
ですが、視点を変えてファイルサーバーを導入する前の計画段階からバックアップ・リストア計画も導入スコープに含めてファイルサーバーの検討を実施することをお勧めしたいです。
ユーザー側からは、単に「上書き・削除してしまったデータをサッと復元してくれる」程度の認識しかないかもしれませんが、ファイルサーバーのバックアップはこのようにシステム管理者の苦労の結晶として、ユーザーの誤操作によるデータ損失からの保護が実現されることによって、復元（リストア）を達成しているといえます。
