山本様
こんにちは、kintoneユーザーの西村と申します。私自身kintoneの調査検討段階含めまだ1年程度ですのでアドバイスというほどのものはないですが、同じような悩みを抱えましたので返信します。

個人的見解ですが、外部バックアップツールという意味では、トヨクモさんのkBackupはおすすめと思います。

テスト運用開始時点でバックアップの必要性については検討したのですが、テスト時はバックアップを導入せず運用開始。すると早々にユーザーから「入れたはずのデータが消えた」との連絡。「え？早速？！」「というか最初だからよけいに色々あるのかな。」と私自身kintoneの扱いに不慣れな中でログ確認するも、「あれ？データ作成のログってそもそもない？」「削除ログはあるけど削除したデータが何かわからないから、問い合わせデータの誤削除かどうかはわからない？！」「削除実行ユーザーに『間違って消した？』って聞いても絶対消してないっていうしな^^;。」で、私の知識ではわからずじまい。恐らく質問ユーザーがデータ入力後[保存]を押さなった可能性が高いけど、別ユーザーが消したという可能性もゼロではないので、結局、「テスト中なのでバックアップがなく復旧できません。ごめんなさい。」とあやまる方法で解決しました。

で、早速トヨクモさんの「kBackup」をお試しで設定。ざっとテストしたところ、定期バックアップに加えレコード操作のタイミングで１レコードづつオンラインバックアップでき１レコードずつリストア可能とわかりました。「これって副次的にレコード追加更新削除のログが取得できるって事？！」「よし今日からお試し期間中は、同じ質問がきても大丈夫！バチ来い！！」思ってましたがその後ユーザーも慣れたのか超安定稼働で、実運用でリストアすることなく本日お試し期間終了日です。^^;

それでも、おかげ様でお試し期間中は「バックアップしている安心感」という恩恵にあやかりつつテストできました。早く社内で正式購入されてほしいです。

他R3さんのgusuku Deploit（デプロイット）もバックアップ機能はあるようですが、私自身は実際にテストはしていないのでコメントは控えさせていただきます。

なにぶんまだ知識不足ですので、私の思い違いや、もっとよい方法もあるかもしれませんが、ご参考になれば幸いです。

こんにちは。お客さん環境でkBackup（トヨクモ）を使ったり、kintoneコマンドラインツール（Cli-kintone）で定期的にバックアップを作ったりという運用をサポートしています。

バックアップを取る方法はそれぞれの現場によってニーズも違いますので色々試してお好みでいいんじゃないかなと思います。

どんな外部連携や拡張機能でバックアップを実現できたとしてもひとつだけやっておいた方が良いのは「バックアップからkintoneへのデータ戻し」のリハーサルです。

kintoneの特性上、アプリ項目などが都度追加されていくこともありますので定期的にバックアップからの戻しが行えるかを確認する機会があるとさらに良いかと！

私が関わっている案件では「データ避難訓練」と呼んでおります＾＾；

ご参考になれば。

山本さん、こんにちは。プロジェクト・アスノートの松田です。
人的ミスによるデータ削除というのは、誤ってレコードを削除してしまうということですかね。
連携サービスでバックアップができるものとしては、トヨクモのkBackupや、アールスリーインスティテュートのgusuku Deproitがあります。
ただし、削除してしまったレコードを元のアプリに復元する、という使い方を想定する場合は注意が必要です。
両サービスともに、バックアップやリストア（復元）には制限やクセがありますので、検討するのであればトライアルをして検証するべきかと思います。

私が実際にアプリを運用する際に気をつけているのは、アプリ／レコードの削除権限は管理者を含めて通常誰にもつけないようにしています。
削除が必要なレコードに関しては、チェックボックスやドロップダウン等で「削除のマーク」をつけるようにして、通常使う一覧から見えないようにする等の工夫をします。
また、レコード削除については管理者がチェックのうえ、必要な時だけ削除権限をつけて実施するか、またはレコードのアクセス権等を工夫して、レコードデータは残しておいたままにしておき、利用者からは削除マークがついたレコードは見えなくする等、運用で工夫しています。

各種連携サービスも有効かと思いますが、まず現実的な対応としては、与えるアクセス権を適切に管理して、そもそも間違いが起こらないようにする、という対応を考えることも有りかと思います。
参考になりますでしょうか。