データベースには通常バックアップ機能が備えられている。DBMSによって若干異なるが、コマンドラインで行うもの、対話的にできるツールがあるもの、など。

SQL Server ではバックアップの方式や対象が異なる3種類のバックアップがある。バックアップは、テーブル単位ではなくデータベース単位で行われる。

完全バックアップ
データベースの状態をそのまますべて確保するバックアップである。フルバックアップともいう。以下に挙げる2つのバックアップ方式を実行する場合であってもこのバックアップが一度は実施されていることが前提となる。つまりは、データベースが壊れたとき、これがないことには復旧できない、ということになる。

差分バックアップ
直前の完全バックアップ時点からの差分のみを確保するバックアップである。差分のみなので全てを確保するより実行時間が短くて済む。
完全バックアップ後に差分バックアップを複数回実行したときはどうなるか?前述の通り「直前の完全バックアップ時点からの差分のみ」を確保するので、最新の状態を確保しておくためには完全バックアップと、最新の差分バックアップがあればよい、ということになる。

トランザクションバックアップ
データベースのデータではなく、そのログファイルを確保するバックアップである。ログファイルとは「実行された更新系のSQL文が確保されているもの」である。直前の完全バックアップまたはトランザクションバックアップ時点からの差分のみを確保する。差分のみではあるが、更新量が多いデータベースの場合はかなり時間が掛かるケースがある。


さて、使い方である。これは「どのくらいの履歴まで再現が必要か」「どのくらいの重要度があるのか」に依存する。
どの時点まで戻す、というようなこともなく、日中は稼働させるが夜間はほぼ動かすことがないような場合
 ・週に一度 or 月に一度 完全バックアップ
 ・上記以外の毎日     差分バックアップ
くらいで十分だろう。更新されるテーブルを含むデータベースであれば最低限このくらいの対応はしたいものだ。これ以外ばケースバイケースである。


参考まで。ごく当たり前の話として「バックアップを確保する先は、バックアップ元と同じ物理ドライブには置かない」ということを理解しておく必要がある。
データが壊れる最大の要因はHDDなどのメディアの故障である。おなじドライブ上に入れていては「バックアップもろとも消滅」となる。
USB接続のHDD等でもよいから、バックアップは必ず別の物理メディアに格納しよう。

なお、ワークグループではなくドメインを構築している場合、LAN上のドライブに直接バックアップを確保するのは少々知識や設定が要るので注意が必要だ。
簡単に言えば
・SQL Server を実行しているIDがワークグループ上で、該当するLANのドライブに読み書き権限があること。
だそうだ。サーバーであれば「そのサーバー独自の管理」とし、ドメイン参加させないケースも多いと聞く。このあたりはハマるポイントらしい。