逆バックアップ

通常のバックアップは、最初にフルバックアップ、次に差分バックアップを6日、またフルバックアップ、というような運用が多かったと思う。このときの問題とは、例えば4日目にリストアしたくなったとき、1日目のフルバックアップをまず戻して、次に二日目と3日目の差分バックアップを重ねてやる必要があるところだ。要は手間と時間が掛かる。

これに対し、常に最新のバックアップを用意しておけば、それを戻せば済む。この際、常にフルバックアップを取るのではなく、差分バックアップを送っておいて、バックアップ側で常に最新の状態にしておく。これが逆バックアップの考え方だ。つまり、

1. 最初にフルバックアップをとる。
2. 翌日は差分を送る。差分自体は差分として取っておき、フルバックアップから最新のバックアップを生成する。フルバックアップ自体はまだ取っておく。
3. 次に差分を送る。差分は差分として取っておき、同じく最新のバックアップを生成する。この時点で、①最初のフルバックアップ、②二つの差分バックアップ、③最新の状態、が存在している。
4. 1週間経って再びフルバックアップを取るわけだが、まず、昨日からの差分と、差分を除いた最新の両方を作る。合成すればフルバックアップ相当になるのだが、まずは昨日からの差分だけ送る。
   1. これを受け取ったバックアップ側は、同様に最新の状態を生成する。そしてその状態のハッシュをとる。
   2. システム側は差分を除いた最新のハッシュを送る。これをバックアップ側で受け取り、ハッシュが一致すれば残りは送らなくてよい、と通知する。もし一致しなければ送ってもらう。
5. もし最新でない状態に復元したいときは、バックアップ側で最新の状態から差分を順に引き、指定のバックアップを生成してリストアに送る。

このアルゴリズムでバックアップを行えば、二つのメリットが生まれる。まず、最新の状態へのリストアが高速に行える。次に、フルバックアップを定期的に行う必要がなくなる(確率的に)。一方でデメリットは、バックアップ側にもCPUパワーが必要、また若干追加で記憶領域が必要、となる。