「サイボウズが守ってくれている」は半分だけ正しい
kintoneを使い始めてしばらく経ったころ、「そういえばバックアップってどうなってるんだろう」と気になった経験はないでしょうか。クラウドサービスだから大丈夫、というイメージはあるけれど、具体的に何がどこまで保護されているかを確認した方は少ないと思います。
結論から言うと、サイボウズ側のインフラ保護と、利用者側が行うべきバックアップは別の話です。この区別を理解していないと、いざデータが消えたときに「守られていると思っていたのに」という事態になります。
kintoneのデータ保護は3層に分かれている
kintoneのデータ保護の仕組みを整理すると、以下の3層になります。
| 層 | 内容 | 誰が管理 |
|---|---|---|
| ① インフラ冗長化 | サーバー障害・停電時のデータ消失を防ぐ。複数データセンターへのレプリケーション。 | サイボウズ |
| ② ごみ箱機能 | 誤削除したレコードを60日以内なら復元できる。 | 利用者 |
| ③ リビジョン履歴 | レコードの変更履歴を参照できる(一部フィールドのみ)。 | 利用者 |
①のインフラ冗長化は確かに強固で、サイボウズのサービス障害によるデータ消失はほぼ起きません。しかし②と③は、利用者側の操作ミスや設定変更からは守ってくれません。
標準機能で「できないこと」——3つの盲点
BLIND SPOT 01
ごみ箱の期限は60日。それを過ぎると完全消失する
レコードを削除してもごみ箱に60日間保持されますが、それを過ぎると完全に消えます。「半年前に削除した顧客データをやっぱり戻したい」は、標準機能では対応できません。また、ごみ箱を空にする操作を誤って行った場合も即時消失します。
BLIND SPOT 02
アプリ設定の変更は巻き戻せない
フィールドの削除・変更はアプリ設定から行いますが、この操作は元に戻せません。「ドロップダウンの選択肢を整理したら、既存レコードの値が消えた」「フィールドを削除したらそこに入っていたデータが全部なくなった」——これはごみ箱にも残りません。
BLIND SPOT 03
アプリごと削除すると、レコードも復元できない
アプリを削除するとごみ箱には入らず、レコードも添付ファイルもすべて消えます。「古いアプリを整理しようとしたら、まだ必要なデータが入っていた」という事故は、開発環境と本番環境の混同や、担当者の引き継ぎ不足で起きやすいです。
実際に起きやすいデータ消失シナリオ
上記の盲点が組み合わさると、現場ではどんな事故が起きるでしょうか。よくあるシナリオを3つ挙げます。
- 大量レコードの誤削除:一括操作でレコードを削除し、60日後に気づいた。ごみ箱はすでに空。
- フィールド定義の変更による上書き:数値フィールドをテキストに変更したことで、既存の数値データが失われた。
- 退会・解約時のデータ消失:kintoneを解約する前にエクスポートを忘れ、すべてのデータへのアクセスを失った。
これらは「あり得ない話」ではなく、kintoneの運用に慣れていない組織ほど起きやすいものです。
中小企業が取れる現実的な対策
では、どう備えればいいでしょうか。主な選択肢を整理します。
| 対策 | メリット | デメリット |
|---|---|---|
| 手動CSV定期出力 | 追加コスト不要。すぐ始められる。 | 継続が難しい。添付ファイル非対応。アプリ設定は取得できない。 |
| 有料バックアップサービス | 自動・確実。サポートあり。 | 月額費用が発生する。 |
| 無償バックアッププラグイン | 自動化できる。無料。レコード・設定・添付ファイルをまとめて取得。 | 復元は取得したCSVをアプリ単位で手動インポートする運用。 |
手動CSV出力は「やろうと思えばできる」ものの、毎週・毎月の継続は現実的に難しく、添付ファイルやアプリ設定は取得できません。有料サービスは確実ですが、コストをかけられない中小企業には障壁になります。
そこで私たちが開発した無償のバックアッププラグインでは、レコード・アプリ設定・添付ファイルをまとめてGoogle Drive / OneDriveへ自動バックアップできます。バックエンドサービスも不要で、ブラウザだけで動作します。
現状、復元は取得したCSVをアプリ単位で手動インポートする運用になりますが、復元作業を補助するプラグインは近日公開予定です。まずはバックアップを取得する体制を整えることから始めてみてください。