バックアップと復元

アプリの名前は「Ticket System Backup & Restore」です。チケットシステムの隣にあり、デスクトップに専用のショートカットができます。

Windows 版と Linux 版があります。同じアプリを、それぞれの OS 向けに作ったものです。

タブは6つです。「Restore」は手元のバックアップを並べ、「Create Backup」は新しく作り、「Schedule」は時刻を扱い、「Encryption」はリカバリーキーを示し、「Settings」は保存先を示し、「Log」は記録を示します。

設定は、すでに埋まっています。初回の起動時に、アプリがチケットシステムの場所を自分で調べます。

バックアップの保存先は「Backup directory」にあります。別のドライブなどに変更できます。

Windows では、アプリは起動するときに管理者の権限を求めます。その設定は、そのコンピューターのすべての管理者に適用され、「%ProgramData%\SMITEY\backup-app」に保存されます。

導入時に、毎日のバックアップが自動で設定されます。チケットシステムのタイムゾーンで23時に動きます。

予定は OS の中にあります。Windows ならタスクスケジューラ、Linux なら cron です。そのため、バックアップのためだけに動くサービスはありません。

バックアップに、誰かがサインインしている必要はありません。誰もサインインしないサーバーでも動きます。

ボタンの下の行が、そのタスクが本当に OS に存在するかを伝えます。チェックが入っているだけでは、何が保存されたかが分かるにすぎません。

バックアップは5つの段階で保持されます。14日、4週、12か月、4四半期、5年です。ある段階で、その期間の中で最も新しいものである限り、そのバックアップは残ります。

数えるのはファイルではなく、暦の日です。1日に2件のバックアップがあっても、1日です。

手で作ったバックアップが、自動で削除されることはありません。「Keep manual」の 0 は、その意味です。

予定を変更した場合、その変更は更新をはさんでも残ります。導入の処理が予定を設定するのは、一度も予定を設定したことがない場合だけです。バックアップをオフにしていれば、オフのままです。「Remove all scheduled tasks」も持続します。そのあとの更新で、予定がもう一度作られることはありません。

バックアップには、システムの状態を作るものがすべて入ります。データベース、添付ファイル、アーカイブ、そして鍵です。入らないのは、SMITEY の外にあるデータベースだけです。

鍵は、見落としやすい部分です。保存された認証情報、たとえばメールアカウントのものを復号します。鍵がなければ、復元しても認証情報は使えないままです。

新しいバックアップは、「.smbk」で終わる暗号化された1つのファイルです。中に、ボリュームごとのファイル、内容の一覧、含まれている場合はテキストファイルとしてのデータベースが入ります。

その間も、システムは動き続けます。エージェントがバックアップに気づくことはありません。

「Estimate size」が、データベースの大きさを先に伝えます。添付ファイルのボリュームは、それに加わります。バックアップは圧縮されません。

上書きされるものはありません。バックアップはどれも独立したファイルで、古いものを消すのは片づけの処理だけです。

バックアップを読めるのは管理者だけです。インストールフォルダーにある設定ファイルと、最初のサインイン情報のファイルも同じです。インストーラーと各更新が、これらの権限を自動で設定します。

データベースが SMITEY のコンテナではなく、専用のサーバーで動いている場合、アプリはそれをバックアップできません。その場合は、ご自身のツールでバックアップしてください。このときバックアップに入るのは、添付ファイル、アーカイブ、鍵だけで、いつもどおり暗号化されます。更新はそのようなデータベースを自分で見つけ、アプリを切り替えます。それまでは、そのような環境で毎日のバックアップは失敗します。先に手で切り替えた場合は別です。コマンドラインでは、「config --database external」で手で切り替えることもできます。「config --database bundled」で元に戻せます。

新しいバックアップはすべて暗号化されます。予定によるバックアップも、手で作ったバックアップも、更新の前のバックアップも同じです。何も有効にする必要はありません。

バックアップは AES-256 で暗号化されます。キーはインストール時に自動で作られます。既存の環境では、暗号化を備えたバージョンへの最初の更新で作られます。キーはサーバー上に保護された状態で保存されます。読み取れるのは管理者だけです。

これで、サーバーの外にあるコピーが守られます。ネットワークドライブ、USB メモリ、オンラインストレージでバックアップを見つけた人も、キーがなければ読めません。サーバーそのものを掌握している人は、キーも手にしています。

リカバリーキーは、書き留められる形にした同じキーです。「SMBK-」で始まります。「Encryption」タブと、インストールフォルダーのファイル「SMITEY-credentials.txt」にあります。そのファイルを削除した場合でも、キーは「Encryption」タブで確認できます。

「Copy」はキーをクリップボードに入れます。「Save to file...」は、キー ID と日付を付けてテキストファイルに保存します。たとえばパスワードマネージャーや、金庫に入れた紙に保管してください。

キーを保管したことを確認するまで、アプリは上部に黄色のバーを表示します。確認するには、「I stored the key outside this server」をクリックし、質問に「Yes」と答えます。バーはそこで消えます。タブには、確認した日時が表示されます。

キー ID は、バックアップがどのサーバーのものかを示します。バックアップがこのサーバーのものでない場合、アプリはそのキー ID を示します。続いて、対応するリカバリーキーを求めます。

アプリがキーを読み取れない場合、バックアップを作りません。暗号化なしのバックアップも作りません。その場合、「Encryption」タブに、キーを読み取れないと表示されます。キーのファイルがまったくない場合、次のバックアップで新しいキーが作られます。新しいキーも保管する必要があるため、黄色のバーが再び表示されます。古いバックアップは、これまでどおり古いリカバリーキーでしか開けません。

ZIP 形式の古いバックアップは暗号化されていません。復元は引き続きできます。タブに、その件数が表示されます。クリーンアップは、ほかのバックアップと同じ規則でそれらを削除します。

デスクトップのないサーバーでは、「key --show」がコマンドラインで同じ内容を表示します。

「Restore」のタブで、戻したいバックアップを選びます。そのあと「Restore」をクリックします。

アプリは、まず確認します。何が起きるかを伝えます。今の状態が上書きされること、そしてアプリがコンテナを再起動することです。今の状態に匿名化された人がいる場合は、2つ目の質問が続きます。その人数を示し、復元の後にもう一度匿名化するかどうかを尋ねます。「Yes」があらかじめ選ばれています。「No」を選ぶと、この手順なしでバックアップが復元されます。代わりにウィンドウを閉じると、何も復元されません。

「Wipe target volumes before restore」にチェックを入れると、先にボリュームを空にします。これで、バックアップの時点になかったファイルが残ることはありません。

手順は「Log」のタブに表示されます。そこで、アプリが何をしたかを順に確認できます。2つ目の質問に「Yes」と答えた場合は、チケットシステムが次の夜間の実行でもう一度適用する匿名化の数が、終わりのほうの行に表示されます。引き継げなかった場合は、代わりにログに警告が表示されます。警告があった場合は、ウィンドウ下部のステータス行にその数が表示されます。

バックアップにデータベースが入っている場合、状態がそのまま戻ります。チケット、コメント、履歴、添付ファイル、記録した時間、ナレッジベースが、バックアップの時点のとおりに戻ります。

そのあと、システムはまた使えるようになります。小さな環境なら、1分もかかりません。

バックアップにデータベースが入っている場合、データベースは、すべて戻るか、まったく戻らないかのどちらかです。ボリュームは、そのあとに続きます。ボリュームで失敗した場合、データベースはすでに戻っていますが、ファイルが欠けていることがあります。どの段階で失敗したかは、「Log」タブに表示されます。復元に失敗した場合でも、アプリはそのあと必ずコンテナを再び起動します。

古いバージョンのバックアップは、新しいバージョンに復元できます。次に起動するとき、システムがデータベースを自分のバージョンに合わせます。

満足度調査の同意と配信停止は、確認なしで引き継がれます。2つ目の質問に「No」と答えた場合も同じです。アプリは、復元の前に、稼働中の環境からそれらを読み取ります。そのあと「Log」タブの1行に、件数が表示されます。たとえば「12 consent and unsubscribe record(s) were carried over.」です。チケットシステムは、最初の起動でそれらを取り込みます。そのため、バックアップのあとに行われた同意や配信停止も有効のままです。引き継ぎに失敗すると、ログに警告が表示されます。それでも、復元は成功として扱われます。

アプリはまず、暗号化されたバックアップ全体を調べます。その間、ステータス行に「Checking the encrypted backup before anything is changed...」と表示されます。調べ終えてから、コンテナを止めます。ファイルが壊れている、または改ざんされている場合は、そこで止まり、「The backup file is damaged. Nothing was changed.」と表示します。

バックアップが別のサーバーのものである場合、アプリはそのサーバーのリカバリーキーを求めます。これは質問のあとに行われます。ウィンドウ「Recovery key needed」に、バックアップのキー ID が示されます。このサーバーのキーがない場合も、同じウィンドウが表示されます。

入力ミスは、何かが変わる前に気づきます。ステータス行には「The recovery key has a typing error. Check each character.」と表示されます。そのあと、ウィンドウがもう一度たずねます。キーが別のバックアップのものである場合、ステータス行には「This recovery key does not belong to this backup.」と表示されます。「Cancel」を押すと、アプリは止まり、「Restore cancelled. Nothing was changed.」と表示します。

アプリは、入力されたキーを引き継ぎません。自分のキーを使い続けます。新しいバックアップは、これまでどおりこのサーバーのキーで作られます。新しいサーバーで復元した場合は、そのサーバーのリカバリーキーも保管してください。

データベースの入っていないバックアップが戻すのは、添付ファイル、アーカイブ、鍵だけです。既存の鍵はそのまま残ります。データベースは変わりません。アプリは復元の前にそれを伝え、たずねます。「No」を選ぶと何も変わりません。

インストールが独自のデータベースを使う設定になっている場合、バックアップにデータベースが入っていても、アプリはデータベースの部分を飛ばします。たとえば古いバックアップがこれに当たります。アプリは事前にたずねます。「No」を選ぶと何も変わりません。

サーバーには、デスクトップがないことがよくあります。そのため、同じアプリはコマンドとしても使えます。

日々の運用で必要なコマンドは5つです。「backup」が保存し、「list」が手元のバックアップを並べ、「restore」が1件を戻し、「schedule」が時刻を決め、「config」が設定を示します。キーのために、さらに「key」と「decrypt」があります。

その裏にあるのは、画面と同じアプリです。別のことをする2つ目の経路は、ありません。

アプリは「/opt/smitey/Backup」にあります。「sudo」を付けて呼び出し、コマンドを続けます。コンテナは「root」で動くため、バックアップにも同じ権限が必要です。

下の6つの枠は、そのままコピーできます。日々の運用で本当に必要なものが入っています。

復元は、ここでも確認します。「--yes」を付けたときにだけ実行されます。そのとき、今の状態の匿名化も引き継がれます。ウィンドウで「Yes」を選んだときと同じです。「--no-reapply」を付けると、この手順なしで実行されます。

これらを読み直すためのファイルが、サーバーにあります。名前は「BACKUP-RESTORE.txt」で、「/opt/smitey」にあります。予定、すべてのコマンド、戻し方を、自分のペースでもう一度たどれます。ファイルにはドイツ語版と英語版があります。導入のときにドイツ語を選んだ場合はドイツ語版、それ以外の場合は英語版が入ります。どちらの版も「/opt/smitey/docs」にもあります。

「key --show」は、リカバリーキー、キー ID、暗号化されていないバックアップの件数を示します。キーをサーバーの外に保管したら、「key --confirm-stored」でそれを確認します。

別のサーバーのバックアップは、「--key-file」で復元します。指定したファイルに、リカバリーキーが入っています。「Save to file...」で作ったファイルも使えます。ファイルの代わりに、環境変数「SMITEY_BACKUP_KEY」を使うこともできます。「sudo」を使う場合は、プログラムの直前に置きます。つまり「sudo SMITEY_BACKUP_KEY=<キー> /opt/smitey/Backup/TicketSystemBackup restore …」です。この場合、キーはシェルの履歴に残ります。キーが合わない場合、何も変わりません。

「decrypt」は、バックアップの内容を暗号化なしのファイルとして、空のフォルダーに書き出します。このファイルは暗号化されていません。パスワードと個人データが入っています。作業が終わったら、すぐに削除してください。

バックアップは、設定したフォルダーの中のファイルです。そのフォルダーは、チケットシステムと同じ機械の上にあります。

よくある場面には、これで十分です。誤って削除したデータ、失敗した更新、データの誤りは、どれも対応できます。

ディスクが壊れた場合には、役に立ちません。ディスクがなくなれば、バックアップも一緒になくなります。

そのため、ファイルを別の場所に複製してください。ネットワークドライブ、2台目のサーバー、ネットワーク上の保管先で足ります。

複製したファイルは、どのサーバーでも読み戻せます。別のサーバーでは、そのためにリカバリーキーが必要です。「Import backup file…」で、ファイルを一覧に戻せます。

コピーは暗号化されています。リカバリーキーがなければ、誰も読めません。ですから、キーをコピーの隣に置かないでください。「.zip」で終わる古いバックアップは暗号化されていません。

更新は、その前に独自のバックアップを取ります。これは予定とは関係なく行われ、チェックを入れる必要もありません。

保存するものは、いつもと同じです。データベース、添付ファイル、アーカイブ、鍵です。データベースが SMITEY の外で動いている場合、更新が保存するのは添付ファイル、アーカイブ、鍵だけです。

このバックアップは、アプリ「Ticket System Backup & Restore」が取ります。ほかのバックアップと同じように暗号化され、同じフォルダーに置かれます。一覧では、種類が「Update」です。この種類のバックアップは、新しい3件が残ります。古いものは、アプリが自分で削除します。

更新の前の案内が、その旨を伝えます。自分で先に保存することを、覚えておく必要はありません。

このバックアップに失敗した場合、更新は何かが置き換えられる前に止まります。SMITEY の外にあるデータベースは、更新を止めません。更新はそのとき、毎日のバックアップもそのデータベースを除くように、アプリを切り替えます。そのデータベースは、ご自身のツールでバックアップしてください。