[ホーム](https://servhidden.com/ja) / [プライバシーホスティングガイド](https://servhidden.com/ja/guides) / VPSバックアップ完全ガイド：暗号化・オフサイト・復元検証 運用 # 確実に復元できるVPSバックアップ 本人確認不要のホスティングは、書類と一緒に安全網も取り除く。バックアップは一切保持されず、解約から24時間以内にデータは破棄され、復元されたコピーへとたどり着くサポート窓口も存在しない。ここにあるのは実践的な計画だ——何をコピーし、どこに置き、攻撃者にそれを消させない方法、そして復元できることを証明する方法。 [ガイドを読む](#guide-body) [FAQ](#guide-faq) ## このページの内容 - [ガイド](#guide-body) - [FAQ](#guide-faq) - [Related ガイドs](#guide-related) - [推奨 pages](#guide-cta) KYC不要 暗号資産決済のみ ログなし DMCA無視 フルroot NVMe SSD 21 min 読み込み Aug 2026更新 このページの内容 [01サーバーを実際に壊すもの](#サーバーを実際に壊すもの) [02スナップショットはバックアップではなく、ホストもバックアップ係ではない](#スナップショットはバックアップではなくホストもバックアップ係ではない) [033-2-1ルールを、身分証を見せたことがない人向けに書き換える](#3-2-1ルールを身分証を見せたことがない人向けに書き換える) [04プッシュ型・プル型、そして一晩の事故で両方のコピーを失う間違い](#プッシュ型プル型そして一晩の事故で両方のコピーを失う間違い) [05まず送信元で暗号化し、それから鍵を誰が持つかを決める](#まず送信元で暗号化しそれから鍵を誰が持つかを決める) [06ツール選び、一枚の表で](#ツール選び一枚の表で) [07動いているものはファイルではない](#動いているものはファイルではない) [08何をバックアップすべきか、そして誰もが忘れる部分](#何をバックアップすべきかそして誰もが忘れる部分) [09試したことのない復元は、噂話にすぎない](#試したことのない復元は噂話にすぎない) [10ずっと動き続けるように自動化する](#ずっと動き続けるように自動化する) [11要約](#要約) [FAQよくある質問](#guide-faq) [→推奨 pages](#guide-cta) バックアップ戦略が試されるのは、サーバーが死んだその夜ではない。実際に試されるのはその数週間前、誰も書き留めない3つの静かな決断の中でだ。コピーをどこに置くか、それを削除できるのは誰か、そして誰かが実際にそれを読み戻したことがあるか。 本人確認を一切求めないホスティングは、その引き換えに何かを手放している。それを正直に言うべき場所がここだ。電話をかけられるアカウント担当者はいないし、消去済みボリュームを復活させるチケットも存在しない。[当社の保持ポリシー](https://servhidden.com/ja/privacy)はその理由をはっきり述べている。サーバーデータは解約から24時間以内に破棄され、ディスクはフォーマットではなく暗号学的に消去され、**バックアップは一切保持されない**。これは、このプラットフォームを購入する価値がある性質と、裏表の関係にある。悪い夜のあとに取り戻したいものは、すでにどこか別の場所にあるべきで、そこに置くのはあなた自身だ。 ## サーバーを実際に壊すもの 想像しているような形でサーバーを失う人はほとんどいない。壊滅的なハードウェア障害は実在するが稀であり、優れたホストならすでに対策済みのケースだ。実際に起きる損失はもっと地味で、それぞれが異なる種類のコピーを無力化する。だからこそ「バックアップはあります」は、そのどれに耐えるかを言うまでは答えになっていない。 | 何が起きるか | 通常どう起きるか | 何があれば戻れるか | | --- | --- | --- | | **自分自身の手** | シェル変数が空だったときのrm -rf、本番を向いてしまったマイグレーション、間違ったテーブルを削除したデプロイ | ミスより*前*のオフボックスコピー。つまり保持期間は、気づくまでにかかる時間より長く遡れる必要がある | | **静かな破損** | 死にかけのNVMe、再起動中の書き込み途中断、1週間ダメージのある行を書き続けていたデータベース | 既知の正常な時点まで遡れる十分な深さのバージョン管理コピー。単一のミラーコピーはダメージも忠実にミラーする | | **侵害** | 盗まれた鍵、パッチ未適用のアプリケーション、汚染された依存関係——そして意図的に狙われるバックアップ | 侵害されたマシンには削除する権限がなかったコピー。ここではそれ以外は数に入らない | | **プロバイダーや国の事変** | ハードウェアの喪失、データセンターへの法的措置、もう手が届かなくなったアカウントやトークン | そのプロバイダーになく、その法域の下にもないコピー | | **鍵の喪失** | 忘れたパスフレーズ、保護対象のサーバーと一緒に消えたキーファイル、誰もエクスポートしなかったLUKSヘッダー | **何もない。**これだけが復旧手段のない唯一の行であり、ハードウェア障害よりもよくある | この表は不安のリストではなく、チェックリストとして読んでほしい。同じマシン内の2台目のディスクへの毎晩のコピーは、1行目にしか答えない。同じパネル内のスナップショットは1行目と2行目に答える。サーバーが手を出せない場所に置かれ、なお手元にある鍵で守られたコピーだけが、5行すべてに答える。 バックアップ先に必要なのはコア数ではなく、ディスクとアドレスだ。別の法域にある最も安価な2台目のマシンでも十分な保存先になり、しかも最初のプロバイダーで何かが起きたときに生き残る唯一のコピーになる。 ## スナップショットはバックアップではなく、ホストもバックアップ係ではない スナップショットは得意なことに関しては優秀だ。失敗したアップグレードを、転送なしで数秒でロールバックできる。できないのは、サーバーそのものを奪った出来事を生き延びることだ。同じプロバイダー、同じアカウント、同じ請求トークン、同じ国、しばしば同じストレージクラスタと、あらゆる障害ドメインを共有しているからだ。スナップショットが守ってくれるのは*自分自身*からであり、バックアップが守ってくれるのはそれ以外のすべてからだ。 この区別は、一般的なホストよりもここでは重要になる。通常のセーフティネットが意図的に取り除かれているからだ。顧客のサーバーに誰もログインしないので、あなたのバックアップジョブが3月から失敗し続けていても誰も気づかない。アカウントに紐づく本人確認情報がないので、「本人であることを証明すれば復元します」という人力の道も存在しない。そして解約は文字通り終わりを意味する。残高切れはデータ消失イベントであって、単なる請求イベントではない。 **24時間条項がすべてを物語っている。**このプラットフォームでは、解約されたサーバーのデータは1日以内に破棄され、ディスクはフォーマットではなく暗号学的に消去される。取り消しはなく、静かなコールドストレージ階層もなく、「古いコピーが見つかりました」で終わるサポート対応もない。それを保持することは、削除してほしいと頼まれたデータを持ち続けることを意味するからだ。セーフティネットとプライバシーは、一度限りの同じ取引なのだ。 ## 3-2-1ルールを、身分証を見せたことがない人向けに書き換える 古典的なルールは、2種類のメディアに3つのコピーを持ち、そのうち1つはオフサイトに置けと言う。これはテープと回転式ディスクの時代に書かれたもので、「メディアの種類」という条項はいつの間にか意味を失っている。本番のディスクもNVMe、バックアップ先のディスクもNVMeで、それを「2種類のメディア」と呼ぶのは自分に言い聞かせているだけの話だ。残す価値がある条項は距離についてのものであり、オフショアインフラにとって距離はキロメートルでは測れない。 これを**3つのコピー、2つのプロバイダー、2つの法域**と書き換えよう。両方のコピーを同時に奪う障害は、物理的なものであることはほとんどない。アクセスを失ったアカウント、調子の悪い週を過ごしたプロバイダー、ある国には及ぶが別の国には及ばない法的手段、といったものだ。同じラックの2台のサーバーは、余計な手間がかかる1つのコピーにすぎず、同じ法制度下の2台のサーバーもほとんど変わらない。[法域選びのガイド](https://servhidden.com/ja/guides/choosing-an-offshore-jurisdiction)では、最初の法域と同じリスクを単純に映さない2つ目の選び方を扱っている。 実際には、これは安上がりだ。バックアップ先にコア数は要らず、ネットワークすらほとんど要らない。必要なのはディスクとアドレスだけだ。最小の[VPSプラン](https://servhidden.com/ja/vps)でも、[7つのロケーション](https://servhidden.com/ja/locations)のうち本番とは別の場所で使えば、resticやBorgの保存先として十分な性能になる。テラバイト単位のアーカイブなら、実ドライブを積んだ[専有サーバー](https://servhidden.com/ja/dedicated)のほうが、どのオブジェクトストレージよりもテラバイト単価が安い。データが本当に大きく、めったに読み出されない場合、経済性は大差でベアメタルに軍配が上がる。 本番環境では正しくできているのに、バックアップ先では間違えがちなことが一つある。同じ方法で支払うことだ。自分の名前のカードで買った2台目のサーバーは、1台目から苦労して切り離した身元情報を静かに再び結びつけてしまい、しかもそこには全データの完全なコピーが置かれる。本番機の支払いを[Moneroで](https://servhidden.com/ja/guides/how-to-pay-for-hosting-with-monero)行っているなら、バックアップ機にも同じ扱いがふさわしい。 3つ目のコピーは、ほとんどの人が省略してしまうものであり、しかも遠隔障害をすべて同時にかわせる唯一のコピーだ。物理的に手元に持ち、たまに更新し、オフラインで保管するディスクである。月に1回で十分な人がほとんどだろう。コーヒー1杯分の手間で済み、他の2つが共有してしまうシナリオを生き延びるコピーになる。 ## プッシュ型・プル型、そして一晩の事故で両方のコピーを失う間違い ほぼ誰もが最初に組む構成はこうだ。本番サーバー上のジョブが毎晩動き、バックアップ先の鍵やトークンを保持し、接続してプッシュする。これは機能するしシンプルだが、サーバーの人生で最悪の日にだけ姿を現す性質を持っている。**本番機を制御できる者は、バックアップも制御できる。** これは仮定の話ではない。名乗り出る前に被害者のバックアップを削除または暗号化するのは、これを商売にしている者にとって標準的な手口だ。認証情報はcronジョブや環境ファイルの中に置かれていて、見つけるのに1分もかからない。攻撃者が削除できるコピーは、2つ目のコピーとは呼べない。それは遅延付きの1つ目のミラーにすぎない。 すっきりした解決策が2つあり、どちらもすでに済ませているはずの[基本的な堅牢化](https://servhidden.com/ja/guides/first-hour-vps-hardening-checklist)とよく組み合う。 - **追記専用の保存先にする。**主要な2つのツールはどちらも、クライアントがデータを追加できるが削除はできないモードを備えている。Borgは保存先のSSH鍵をborg serve --append-onlyに固定することで、resticは--append-only付きで起動したRESTサーバーでこれを実現する。本番サーバーは毎晩書き込むだけで、構造的に履歴を破壊できない。古いスナップショットの削除はその後、本番機が開始できないセッションの中で保存先側が行う。 - **プッシュではなくプルにする。**方向を逆転させる。バックアップ側のホストが本番に接続し、読み取り、保存する。本番側は保存先の認証情報を一切持たないので、盗む対象が存在しない。本番側で使う鍵はrestrictと強制的なcommand=で制限し、盗まれたバックアップ用の鍵がシェルに化けないようにする。 プル型はより強固なモデルだが運用の手間はやや増える。追記専用は、すでにBorgかresticを使っているならほぼ無料で実現できる。どちらの方法でも、「攻撃者にバックアップを消された」は結果ではなく未遂に変わる。このガイドから一つだけ持ち帰るなら、この節にしてほしい。 ## まず送信元で暗号化し、それから鍵を誰が持つかを決める 本格的なツールはどちらも、何かがネットワークを渡る前に、バックアップ対象のマシン上で暗号化する。保存先には解読できないブロブが保存される——これこそがプロバイダーをまたいだコピーを安全にしている理由だ。2台目のホストは信頼できる必要も、友好的である必要すらなく、到達可能でディスクさえあればいい。この一つの性質だけで、「まったく知らない国にあるサーバー」がリスクからインフラへと変わる。 これはサーバー自身のディスクを暗号化するのとは異なる仕組みで、答える問いも違う。当社の[VPSでのフルディスク暗号化](https://servhidden.com/ja/guides/full-disk-encryption-on-a-vps)ガイドでは、マシンが稼働している間にディスク暗号化が何を守り何を守らないかを扱っている。バックアップの暗号化のほうが簡単で価値も高い。脅威モデルが素直だからだ。データは静止状態にあり、自分が制御していないハードウェア上にあり、鍵はそこには決して渡らない。 その結果、リスクはすべて鍵の管理に集約される。パスフレーズは今や唯一の完全喪失ポイントであり、それは人が思う以上にたちの悪い単一障害点だ。失うことが静かに起きるからだ——何も壊れず、バックアップは動き続け、まさに必要になった瞬間にそれと気づく。これを直す習慣は3つある。 - パスフレーズはサーバー上ではrootだけが読めるファイルとしてのみ保持し、--password-fileで参照する。プロセス一覧やシェル履歴に決して現れないようにするためだ。 - 人が読める形のコピーを、関係するすべてのマシンの外に保管する。引き出しの中の紙は、自分もアクセスを失うかもしれないアカウントに同期するパスワードマネージャーより、実際に優れている。 - リポジトリに2つ目の鍵を追加する——restic key add、あるいはエクスポートしたBorgの鍵など。これにより、パスフレーズを一つ忘れても不便で済み、アーカイブの終わりにはならない。 この3つすべての土台にあるルールはこうだ。**鍵の唯一のコピーが、そのバックアップが置き換えるはずのマシン上にしかないなら、それはバックアップではない。**それはただの暗号化されたブロックの山であり、それについての物語にすぎない。 ## ツール選び、一枚の表で ツールの選択は、接続の方向や鍵の状態ほど重要ではない。だからこそこの節は1番目ではなく6番目に置いている。とはいえ違いは確かに存在し、用途に合わない形を選ぶと後で余計な作業が発生する。 | ツール | 送出前に暗号化するか | 重複排除 | 追記専用の保存先 | 向いている用途 | | --- | --- | --- | --- | --- | | **restic** | する、リポジトリ全体を | する | する、RESTサーバー経由で | デフォルトの選択肢。SFTP、オブジェクトストレージ、独自サーバーを話せるので、保存先はほぼ何でもよい | | **BorgBackup** | する、リポジトリ全体を | する、この中で最も強力 | する、SSH上でネイティブに | SSHで到達する単一のLinux保存先向け。データが大きく反復的な場合は無敵 | | **rsyncとローテーション** | しない——保存先はすべてを見える | 部分的、ハードリンク経由 | しない | 完全に自分の管理下にあるマシンへのミラーリング。プライバシーより即時の部分リストアが重要な場合 | | **rclone** | rclone cryptを使う場合のみ | しない | ストレージプロバイダー次第 | すでに存在するアーカイブをオブジェクトストレージへ、あるいはプロバイダー間で移動する | | **ZFSレプリケーション** | 暗号化データセットの場合のみ | する、ブロック単位 | スナップショット権限経由 | 2台のZFSマシン間でのレプリケーション。非常に高速だが、両端の構成にとても厳格 | | **tarとageまたはGPG** | する、アーカイブを暗号化すれば | しない | 該当なし | 小規模で、たまにしか行わず、永久保存するアーカイブ向け。効率よりシンプルさを優先する場合 | 単一サーバーなら、2台目のVPSへのresticが正解への最短ルートだ。シードボックスやメディアアーカイブ、似たような大きなファイルが多い用途では、Borgの重複排除がディスクの空き具合を大きく左右する——その種のワークロードのストレージ面については[シードボックス構築ガイド](https://servhidden.com/ja/guides/seedbox-setup-guide)で詳しく扱っている。 ## 動いているものはファイルではない 世界で最もよくある壊れたバックアップは、稼働中のデータベースをそのままファイルコピーしたものだ。エラーもなく完了し、サイズも妥当で、それなのに復元するとエンジンが開こうとしないテーブルになる。コピーが通過した瞬間、データベースは書き込みの途中だった。保存されたのは、ページがめくられている最中の写真にすぎない。 抜け出す方法は3つあり、手間の順に並べるとこうなる。ダンプする——mysqldump --single-transactionは書き込みをロックせずに一貫性のあるInnoDBダンプを得られ、pg_dumpはPostgreSQLで同じことをする。スナップショットを取る——ファイルシステムを凍結するか、LVMやZFSのスナップショットを取り、そのスナップショットからコピーして解放する。これは、毎晩ダンプするには大きすぎるデータセットの扱い方だ。あるいは止める——小規模なサービスなら、04:00の2分間のダウンタイムは十分に立派な一貫性戦略であり、しかも例外ケースが一切ない唯一の方法だ。 同じ論理はデータベースの先にも及ぶ。コンテナの書き込み可能レイヤーは使い捨てだが、そのボリュームはそうではなく、隣にあるdocker composeファイルと環境変数も同様だ。データは復元できても定義が復元できないバックアップは、記憶を頼りにスタックを再構築する羽目になる。メッセージキュー、永続化を有効にしたRedis、MTAが書き込み中のメールスプールも、すべて同じ扱いに値する。静止させるか、スナップショットを取るか、ダンプするか。決して、そのままコピーして無事を祈ってはいけない。 ## 何をバックアップすべきか、そして誰もが忘れる部分 ほとんどの人は明らかなペイロード——データベースとアプリケーションディレクトリ——だけをバックアップし、残りは緊急事態の中で手作業で再構築する。時間を食うのはその再構築だ。正しいデータの山ではなく、動くシステムに戻してくれるバックアップには、地味な層が含まれている。 - /etc一式に加え、自分で書いたsystemdのユニットとタイマー、そしてその外にあるすべてのcrontab。 - TLS証明書とその秘密鍵、少なくともACMEアカウント鍵。これがあれば証明書はゼロからではなく更新で済む。 - ファイアウォールルールとパッケージ一覧。この2つを合わせると、記憶に頼るよりも速くマシンの形を再現できる。 - アプリケーションのシークレットと環境ファイル——意図的にコードリポジトリから除外されているため、他のどこにも存在しないもの。 - テキストとしてエクスポートしたDNSレコード。逆引きDNSやPTRエントリも含め、これらはサーバー上ではなくプロバイダー側にある。 **鍵の中にはデータではなく、身元そのものであるものがある。**Torのオニオンサービスの秘密鍵はアドレス*そのもの*だ。それを失えば、他に何を復元してもその[.onionアドレス](https://servhidden.com/ja/guides/how-to-host-a-tor-hidden-service)で同じサイトを復活させることはできない。WireGuardのサーバー鍵を失えば、これまで配布したすべてのクライアント設定を再発行する羽目になる。メールサーバーのDKIM鍵を失えば、新しいセレクタと[到達率](https://servhidden.com/ja/guides/offshore-mail-server-setup)のゼロからのやり直しを意味する。Lightningノードのシードとチャネル状態は、ファイルではなく資金そのものを意味しうる——[ノードホスティングガイド](https://servhidden.com/ja/guides/crypto-node-hosting-guide)はその点を明言している。これらは別に分けてコピーし、オフラインで保管し、それが守っているデータよりも価値のあるものとして扱ってほしい。 ## 試したことのない復元は、噂話にすぎない バックアップソフトウェアは自分自身について報告するが、正直に報告しているのは違うことについてだ。「スナップショット完了」が意味するのは、リポジトリにデータが書き込まれたということだけだ。そのリポジトリが、これとは別のマシンで、11か月前に何を設定したか覚えていない人間によって読み出せるかどうかについては、何も語っていない。 まずは安価な整合性チェックから始めよう——定期的なrestic check --read-data-subset=5%やborg check --verify-dataだ。ただし、これらが検証するのはアーカイブであって、あなたがそれを使いこなせるかではない、と理解しておくこと。本当の訓練は違うもので、一度だけ午後をまるごと使う。普段使わないロケーションで、時間課金の新品サーバーを注文する。リポジトリのアドレスとパスフレーズ、そして自分のメモだけを頼りにそこへ復元する。サービスを立ち上げる。全体の所要時間を計る。それからマシンを破棄する。総費用は数ドル、そしてこれだけが信頼できる数字を生む唯一の演習だ。 この訓練が確実にあぶり出すのは、データそのものではない。誰も書き留めなかった不足パッケージ、バックアップ対象のパス外にあった設定、置き換えようとしているサーバーのシェル履歴にしか存在しなかったパスフレーズ、そしてリポジトリの形式を読めるツールのバージョン。そのどれもが、事前なら直すのは簡単で、障害中に発見するのは悲惨だ。 この訓練が与えてくれる2つの数字を書き留めておこう。復元にかかった時間と、そのスケジュールで失いうる作業量だ。それがバックアップポリシーそのものであり、それ以外はすべて、その2つに奉仕する実装の細部にすぎない。 ## ずっと動き続けるように自動化する ジョブはcronではなくsystemdタイマーから実行しよう。ログが一箇所にまとまり、最後の実行についての本物の記録が残り、再起動を生き延びるスケジュールが手に入る——これらはどれもcronが余計な作業なしには与えてくれないものだ。パスフレーズはユニットファイル自体には置かないこと。シェルアクセスさえあれば誰でもsystemctl catでそのまま読めてしまう。 次に、実際に人を苦しめる失敗モードを解決しよう。それはエラーではなく、沈黙だ。6週間前に止まったバックアップは、完璧に動いているバックアップとまったく同じに見える。どちらも出力を何も生まないからだ。**失敗ではなく、不在にアラートを出す。**ジョブには成功時に監視サービスへpingを送らせ、そのpingが届かないときに監視サービス側が文句を言うようにする。そしてその監視サービスは、見張っている対象のサーバー以外のどこかに置く。落ちているマシンは、自分が落ちていることを報告できないからだ。 保持期間はデフォルト任せではなく意図的に設定しよう。--keep-daily 7 --keep-weekly 4 --keep-monthly 6のようなものなら、今夜気づくミスも春になって気づく破損も、永遠に肥大化することなくカバーできる。追記専用にしているなら、削除は保存先側で行う。それこそが追記専用にした意味だ。当社のネットワークでは転送量が制約になることはめったにない——帯域は全プランで無制限だ——のでクォータではなく一貫性を基準にスケジュールを組み、その時刻を自分の静かな時間帯と照らし合わせよう。この周辺のより広い習慣については[サーバーOpSecガイド](https://servhidden.com/ja/guides/server-opsec-staying-anonymous)で扱っている。 ## 要約 このページから何か一つだけ実行するなら、だいたいこの順番で次の6つをやってほしい。 - 1つのコピーを、2つ目のプロバイダー、2つ目の法域に置き、1台目と同じくらいプライベートな方法で支払う。 - そのコピーを追記専用にするか、保存先側からプルする形にし、侵害されたサーバーがそれを破壊できないようにする。 - ツールに送信元で暗号化させ、鍵は関係する両方のマシンの外に保管する。 - データベースはダンプし、動いているものは止めるかスナップショットを取る。稼働中の状態を決してそのままコピーしない。 - 身元に関わる鍵は別に分けてバックアップする——オニオン、WireGuard、DKIM、ノードのシードなど。これらは再生成できない。 - 使い捨てのサーバーへ一度復元してみて、時間を計り、何が足りなかったかを書き留める。 これらのどれも特別なものではなく、週末をまるごと使うようなものでもない。プロジェクトを終わらせてしまう類の損失に対して、必要なのは設定に半日と訓練を一度だけだ。あなたについて意図的に何も残さないプラットフォームでは、自分自身が作ったコピーだけが唯一存在するものになる——それがこの仕組みの代償であり、公平な代償でもある。最初の法域とは違う場所で[2台目のサーバーを立ち上げ](https://servhidden.com/ja/vps)、今夜のバックアップに行き先を用意しよう。 FAQ ## VPSバックアップ——よくある質問 ### 01 ServHiddenはVPSをバックアップしてくれますか？ いいえ、それは見落としではなく意図的な方針です。当社の保持ポリシーでは、バックアップは一切保持されないこと、サーバーデータは解約から24時間以内に破棄されること、ディスクはフォーマットではなく暗号学的に消去されることが明記されています。削除を依頼された後もデータのコピーを保持し続けることは、このプラットフォームが存在する理由そのものと矛盾します。サーバーを生き延びさせたいものはすべて、あなた自身がそこからコピーして持ち出す必要があります。できれば別の法域にある別のプロバイダーへ。 ### 02 スナップショットはバックアップと同じですか？ いいえ。スナップショットは、それが由来するサーバーとあらゆる障害ドメインを共有しています——同じプロバイダー、同じアカウント、同じ国、しばしば同じストレージです。失敗したアップグレードを取り消すには優秀ですが、アカウントやプロバイダーやマシンそのものの喪失には無力です。スナップショットは取り消しボタン、バックアップは保険だと考えてください。それぞれ違う問題を解決するので、両方とも必要です。 ### 03 resticとBorgBackup、どちらを使うべきですか？ 保存先がオブジェクトストレージやSFTP、あるいはまだ決めていない何かになる可能性があるならresticです。最も多くのバックエンドを話せるからです。保存先がSSHで到達する1台のLinuxマシンで、データが大きく反復的ならBorgBackupです。このグループの中で重複排除が最も強力だからです。どちらも、何かがマシンを離れる前に送信元で暗号化し、どちらも追記専用の保存先をサポートします。これはツール選び自体よりもずっと重要な点です。 ### 04 攻撃者にバックアップを削除されないようにするには？ 動機ではなく能力を奪ってください。保存先を追記専用にして、本番サーバー上の認証情報がデータを追加できても削除はできないようにするか、あるいは接続の向きを逆にして、バックアップ側のホストが本番から取りに行く形にし、本番サーバーには認証情報を一切持たせないようにします。名乗り出る前にバックアップを削除するのは、これを商売にしている者にとって標準的な手口であり、攻撃者が削除できるコピーは2つ目のコピーとは呼べません。 ### 05 2つ目のコピーはどこに置くべきですか？ 本番サーバーとは別のプロバイダーの、別の法域に、本番サーバーと同じくらいプライベートな方法で支払って置いてください。両方のコピーを同時に奪う出来事はめったに物理的なものではなく、アクセスを失ったアカウント、調子の悪い週を過ごしたプロバイダー、ある国には及ぶが別の国には及ばない法的手段であることがほとんどです。同じラックの2台のサーバーは、余計な手間がかかる1つのコピーにすぎません。ツールが送信元で暗号化するため、2台目のホストを信頼する必要はありません。 ### 06 バックアップの頻度はどれくらいが適切ですか？ どれだけの作業をやり直してもよいかから逆算してください。ブログなら1日分を失っても誰も気づきませんが、ストアなら1時間分の注文も失えません。ほとんどの単一サーバー構成では毎晩が適切な既定値で、書き込みに価値があるならデータベースのダンプはもっと頻繁に行います。頻度以上に重要なのは保持期間の深さです。破損は数週間遅れて気づかれることが多いので、それが始まる前の時点まで戻れるだけの履歴を保持してください。 ### 07 自分の管理下にないサーバー上の暗号化バックアップは安全ですか？ 内容については安全です。resticとBorgはデータが送信元を離れる前に暗号化するので、保存先は読めないブロブを保存するだけで、鍵は決してそこへ移動しません。保存先が知ることになるのはメタデータです。おおよそのデータ量、その変化のしかた、ジョブがいつ動くか、といったものです。通常はこれで問題ありません。もし問題があるなら、スケジュールを変化させ、所有者が本番機と結びつかないマシンにリポジトリを置いてください。 ### 08 バックアップのパスフレーズを紛失したらどうなりますか？ アーカイブは永久に失われ、誰にも救済手段はありません。これはこの分野全体で最もよくある完全喪失であり、復旧手段がまったくない唯一の失敗です。パスフレーズは関係するすべてのマシンの外のどこかに保管し、自分もアクセスを失うかもしれないアカウントよりも紙を優先し、リポジトリに2つ目の鍵を追加してください。そうすれば、パスフレーズを一つ忘れても不便で済み、アーカイブの終わりにはなりません。 Related ガイドs ## 続けて読む [### 2026年にオフショアホスティング法域を選ぶ方法 購入 オフショア法域を選ぶための実践的な意思決定フレームワーク: データ保持法、MLATの露出、DMCA対応姿勢、裁判所のスピード、実際の執行状況を国ごとに解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/choosing-an-offshore-jurisdiction) [### プライバシーが重要なワークロード向けのVPS vs 専用サーバー 購入 VPSで十分な場合、共有テナンシーが弱点になる場合、そしてベアメタルだけが誠実な答えになる場合を解説します。ハードウェア分離、ハイパーバイザーのリスク、コストと脅威モデルの比較について。 6の質問からなるFAQ](https://servhidden.com/ja/guides/vps-vs-dedicated-for-privacy) [### No-KYC VPS上のセルフホストVPN: WireGuard vs OpenVPN 運用 セルフホストVPNが商用プロバイダーより優れている理由、そして2026年時点でWireGuardとOpenVPNがプライバシー、性能、運用リスクの面で実際にどう比較されるかを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/self-hosted-vpn-wireguard-vs-openvpn) [### AI推論向けRTX 4090 vs H100 SXM5比較（RTX 5090はどこに位置するか） 購入 購入ガイド：2026年、セルフホストのLLM、画像、動画、音声、ファインチューニングのワークロードにはどのNVIDIA GPUを選ぶべきか。RTX 4090 vs RTX 5090 vs H100 SXM5 vs デュアルH100——VRAM、スループット、$/トークン、それぞれが優位になる場面を比較します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/rtx-4090-vs-h100-for-ai-inference) [### MT4 / MT5 / cTrader Forexトレード向けのオフショアWindows RDP 運用 完全ガイド：Forex取引にWindows RDPを使う理由、低遅延なオフショア法域の選び方、MT4 / MT5 / cTrader / Expert Advisorのセットアップ方法、ブローカーサーバーへの遅延、そしてKYC不要の決済フローまで解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/offshore-windows-rdp-for-forex-trading) [### DMCA無視ホスティング解説：2026年における本当の意味 購入 「DMCA無視」ホスティングが実際に何をもたらすのか、どの法域が本当に支持しているのか、それを必要とするワークロードとは何か、そしてその言葉がカバーしない著作権の落とし穴とは何か。 6の質問からなるFAQ](https://servhidden.com/ja/guides/dmca-ignored-hosting-explained) [### 暗号通貨による匿名ドメイン登録：2026年のWHOISプライバシー プライバシー 身元を明かさずにドメインを登録するための2026年実践ガイド：TLD別WHOISの仕組み、レジストラの選択、暗号支払いオプション、そしてそれでも身元が漏れる運用上のミス。 6の質問からなるFAQ](https://servhidden.com/ja/guides/anonymous-domain-registration-with-crypto) [### 暗号資産決済向けホスティング: Monero vs Bitcoin vs USDT プライバシー 支払いに使うコインによって、ホストに知られる情報がどう変わるかを解説します。XMR、BTC、USDTそれぞれのプライバシー、手数料、ファイナリティ、チェーン分析への露出を比較し、明確な結論を提示します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### オフショアホスティングは本当に匿名なのか?正直な答え プライバシー オフショアのKYC不要ホスティングは、通常のホスティング業者が収集する身元情報を排除します——しかし「匿名」かどうかは、支払い方法、業者側のログ、そしてあなた自身のOPSEC次第です。実際に何が追跡可能なのかを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/is-offshore-hosting-truly-anonymous) [### VPSハードニングの最初の1時間:チェックリスト 運用 新しいVPSを1時間以内に守るための、具体的で順序立ったチェックリスト。SSHキー、ファイアウォール、fail2ban、自動アップデート、そして無差別攻撃の大半を食い止める攻撃対象領域の削減。 6の質問からなるFAQ](https://servhidden.com/ja/guides/first-hour-vps-hardening-checklist) [### No-KYCホスティングとは？定義・合法性・仕組みを解説 プライバシー No-KYCホスティングは、氏名・メールアドレス・身分証明書など一切の本人確認なしでサーバーを借りられるサービスです。その意味、技術的な仕組み、合法性、そして本物のプロバイダーの見分け方を詳しく解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/what-is-no-kyc-hosting) [### オフショアホスティングは合法か？2026年版・正直な回答 購入 オフショアホスティングは合法です――利用者にとっても、プロバイダーにとっても。この記事では、その用語の本当の意味、法的境界線の実態、払拭すべき誤解、そして責任ある活用方法を解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/is-offshore-hosting-legal) [### Monero（XMR）でホスティングを支払う方法 — ステップバイステップ プライバシー Monero（XMR）でVPSや専用サーバーの料金を支払うためのステップバイステップガイド：XMRがプライバシー保護の観点から最も優れた選択肢である理由、入手方法、そしてチェックアウトから数分でサーバーが稼働するまでの流れを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-pay-for-hosting-with-monero) [### ウェブサイトを匿名でホスティングする方法 — 2026年版実践ガイド プライバシー アカウント、支払い、ドメイン、管轄地域、接続、コンテンツ — 身元を一切残さずウェブサイトをホスティングするための、層ごとに解説した実践的ガイド。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-host-a-website-anonymously) [### VPSにWireGuard VPNを構築する — ステップバイステップガイド 運用 WireGuardを使ってVPS上に自分専用のプライベートVPNを構築する方法：セルフホスト型VPNが商用VPNより優れている理由から、インストールからクライアント接続まで完全なセットアップ手順、そして堅牢化の方法まで解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### GPUサーバーでLLMをセルフホストする方法 — 2026年版ガイド 運用 レンタルGPUサーバーで独自の大規模言語モデルを稼働させる：APIより自己ホスティングが優れている理由、GPUとモデルの選び方、OllamaまたはvLLMを使ったセットアップ、そしてコストについて。 6の質問からなるFAQ](https://servhidden.com/ja/guides/self-host-an-llm-on-a-gpu-server) [### バレットプルーフホスティングとオフショアホスティング — その違いとは？ 購入 バレットプルーフホスティングとオフショアホスティングは混同されがちですが、まったく別物です。両者の本質的な違い、その重要性、そして実際にどちらを選ぶべきかを解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/bulletproof-vs-offshore-hosting) [### BitcoinでVPSを購入する方法――ステップバイステップ完全ガイド（2026年版） 購入 BitcoinでVPSを購入するための初心者向けガイド。BTCの入手方法、プランの選び方、請求書の支払い方、そして手に入るものが何か――カードも氏名も不要なサーバーを手順を追って解説します。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-buy-a-vps-with-bitcoin) [### DMCAを無視できるホスティングに最適な国（2026年版） 購入 米国式の削除申請が届かないサーバーをどこに置くか——機能する法域、「DMCA無視」が本当に意味すること、そして選び方。 6の質問からなるFAQ](https://servhidden.com/ja/guides/best-countries-for-dmca-ignored-hosting) [### Torの隠しサービス（.onionサイト）のホスティング方法 — 2026年版ガイド 運用 VPS上にTor onionサービスを構築する：隠しサービスとは何か、それが最も強力な匿名ホスティング形態である理由、完全な設定手順、そして真の匿名性を維持する方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/how-to-host-a-tor-hidden-service) [### オフショアメールサーバーの構築 — 2026年版・プライベートメールを自己ホスト 運用 オフショアVPS上でプライベートメールサーバーを自己ホストする方法：なぜ自己ホストするのか、何が必要か、オールインワンメールスタックによる現実的な構築手順、そして配信可能性を正しく確保する方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/offshore-mail-server-setup) [### 暗号ノードホスティングガイド — VPS でブロックチェーンノードを運用する 運用 ブロックチェーンノードをサーバー上でホストする方法：自前のノードを運用する理由、Bitcoin・Ethereum・Monero などに適したサーバー構成、セットアップ手順、そしてプライバシーを守りながら運用する方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/crypto-node-hosting-guide) [### Stable Diffusion 向け GPU ホスティング — 自分だけの画像生成サーバーを運用する 運用 GPU サーバーで Stable Diffusion を自己ホストする方法：セルフホスティングの理由、最適な GPU の選び方、Web UI のセットアップ、そしてホスト型サービスとのコスト比較。 6の質問からなるFAQ](https://servhidden.com/ja/guides/gpu-hosting-for-stable-diffusion) [### サーバーOpSec — サーバー運用時に匿名性を維持する方法 プライバシー 匿名サーバーを運用するすべての人のための運用セキュリティ：身元が特定されてしまう失敗のパターン、それを防ぐ習慣、そして真に独立したアイデンティティを保ち続ける方法。 6の質問からなるFAQ](https://servhidden.com/ja/guides/server-opsec-staying-anonymous) [### シードボックス設定ガイド — 2026年版プライベートシードボックスの自己構築 運用 サーバー上に自分だけのシードボックスを構築する方法：シードボックスとは何か、サイジングの考え方、WebUI付きトレントクライアントのインストール、そしてプライベートかつ安全に保つための手順。 6の質問からなるFAQ](https://servhidden.com/ja/guides/seedbox-setup-guide) [### 自前のVPSでDPI検閲を回避する方法(2026年版ガイド) プライバシー VPNが突然つながらなくなった?自前のVPSでDPI検閲を回避する方法を解説する。ディープパケットインスペクション(DPI)が実際に何を検知しているのか、2026年時点で有効な5つのプロトコルがそれぞれどのブロック手法に強いのか、そしてVLESS+REALITYの導入手順をひと通り示す。 6の質問からなるFAQ](https://servhidden.com/ja/guides/bypass-dpi-censorship-with-your-own-vps) [### VPSのフルディスク暗号化：LUKS導入と本当に守れるもの 運用 VPSをLUKSで暗号化する方法を解説します。暗号化データボリューム、dropbearによるSSH経由リモートロック解除を伴うフルルート暗号化、インストール時に暗号化するベアメタルという3つの構成、小規模サーバーで本当に重要になる設定、そしてディスク暗号化が実際に何を防ぎ、何を防がないのかを正直に説明します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/full-disk-encryption-on-a-vps) [### オリジンサーバーIPを隠す：CDN・リバースプロキシと漏れる経路 プライバシー オフショアサーバーの前にCDNやリバースプロキシを置くべきかどうかを解説します。CDNが実際に何を隠してくれるのか、その代わりに背負うことになる苦情処理の窓口、そして設定を誤るとオリジンサーバーのIPアドレスが漏れてしまう6つの経路と、自分のIPアドレスを10分で監査する具体的な手順までを正直に述べます。 8の質問からなるFAQ](https://servhidden.com/ja/guides/hiding-your-origin-server-ip) [### Matrixサーバーのセルフホスト:Synapseと連合の実態 運用 Matrixホームサーバーで本当に変わることとは。Synapse・Conduitの違い、変更不可能なserver_name、肥大化するメディア保存、連合が明かす情報を解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/self-host-a-matrix-server) [### サイトをオフショアホスティングへダウンタイムゼロで移行する方法 運用 ホスト移行を退屈な作業に変える順序をご紹介します。DNSのTTLを数日前に下げ、2台のサーバーを並行稼働させて書き込みフリーズを時間ではなく分に抑え、さらに移行が残すパッシブDNSやCertificate Transparency、WHOISの痕跡を消す方法まで解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server 運用 Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8の質問からなるFAQ](https://servhidden.com/ja/guides/self-host-a-crypto-payment-gateway) ## 今夜のバックアップに、行き先を用意する 7つの法域、全プランで帯域無制限、月額7.50ドルからのサーバーはresticやBorgの保存先として十分な性能です。KYC不要、メール不要、暗号資産決済のみ——それは本番環境だけでなく、バックアップ先にも言えることです。 [VPSプランを見る](https://servhidden.com/ja/vps) [専用サーバー](https://servhidden.com/ja/dedicated) [すべてのロケーション](https://servhidden.com/ja/locations) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "7つのオフショア法域で提供するVPSと専用サーバー。KYC不要、ログなし、暗号資産決済のみ。設計段階からプライバシーを重視しています。", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPSバックアップ完全ガイド：暗号化・オフサイト・復元検証", "description": "ホスティング業者はバックアップを保持しません。サーバーを壊す本当の原因、restic対BorgBackupの選び方、忘れがちな鍵、復元テストの手順まで解説します。", "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-20T00:00:00+00:00", "dateModified": "2026-08-20T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy", "inLanguage": "ja", "keywords": "VPS バックアップ, VPS バックアップ 暗号化, restic BorgBackup 比較, オフサイト バックアップ VPS, 3-2-1 バックアップ ルール, 追記専用バックアップ, KYC不要 VPS バックアップ, バックアップ 復元 テスト", "articleSection": "運用", "wordCount": 4188 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "ServHiddenはVPSをバックアップしてくれますか？", "acceptedAnswer": { "@type": "Answer", "text": "いいえ、それは見落としではなく意図的な方針です。当社の保持ポリシーでは、バックアップは一切保持されないこと、サーバーデータは解約から24時間以内に破棄されること、ディスクはフォーマットではなく暗号学的に消去されることが明記されています。削除を依頼された後もデータのコピーを保持し続けることは、このプラットフォームが存在する理由そのものと矛盾します。サーバーを生き延びさせたいものはすべて、あなた自身がそこからコピーして持ち出す必要があります。できれば別の法域にある別のプロバイダーへ。" } }, { "@type": "Question", "name": "スナップショットはバックアップと同じですか？", "acceptedAnswer": { "@type": "Answer", "text": "いいえ。スナップショットは、それが由来するサーバーとあらゆる障害ドメインを共有しています——同じプロバイダー、同じアカウント、同じ国、しばしば同じストレージです。失敗したアップグレードを取り消すには優秀ですが、アカウントやプロバイダーやマシンそのものの喪失には無力です。スナップショットは取り消しボタン、バックアップは保険だと考えてください。それぞれ違う問題を解決するので、両方とも必要です。" } }, { "@type": "Question", "name": "resticとBorgBackup、どちらを使うべきですか？", "acceptedAnswer": { "@type": "Answer", "text": "保存先がオブジェクトストレージやSFTP、あるいはまだ決めていない何かになる可能性があるならresticです。最も多くのバックエンドを話せるからです。保存先がSSHで到達する1台のLinuxマシンで、データが大きく反復的ならBorgBackupです。このグループの中で重複排除が最も強力だからです。どちらも、何かがマシンを離れる前に送信元で暗号化し、どちらも追記専用の保存先をサポートします。これはツール選び自体よりもずっと重要な点です。" } }, { "@type": "Question", "name": "攻撃者にバックアップを削除されないようにするには？", "acceptedAnswer": { "@type": "Answer", "text": "動機ではなく能力を奪ってください。保存先を追記専用にして、本番サーバー上の認証情報がデータを追加できても削除はできないようにするか、あるいは接続の向きを逆にして、バックアップ側のホストが本番から取りに行く形にし、本番サーバーには認証情報を一切持たせないようにします。名乗り出る前にバックアップを削除するのは、これを商売にしている者にとって標準的な手口であり、攻撃者が削除できるコピーは2つ目のコピーとは呼べません。" } }, { "@type": "Question", "name": "2つ目のコピーはどこに置くべきですか？", "acceptedAnswer": { "@type": "Answer", "text": "本番サーバーとは別のプロバイダーの、別の法域に、本番サーバーと同じくらいプライベートな方法で支払って置いてください。両方のコピーを同時に奪う出来事はめったに物理的なものではなく、アクセスを失ったアカウント、調子の悪い週を過ごしたプロバイダー、ある国には及ぶが別の国には及ばない法的手段であることがほとんどです。同じラックの2台のサーバーは、余計な手間がかかる1つのコピーにすぎません。ツールが送信元で暗号化するため、2台目のホストを信頼する必要はありません。" } }, { "@type": "Question", "name": "バックアップの頻度はどれくらいが適切ですか？", "acceptedAnswer": { "@type": "Answer", "text": "どれだけの作業をやり直してもよいかから逆算してください。ブログなら1日分を失っても誰も気づきませんが、ストアなら1時間分の注文も失えません。ほとんどの単一サーバー構成では毎晩が適切な既定値で、書き込みに価値があるならデータベースのダンプはもっと頻繁に行います。頻度以上に重要なのは保持期間の深さです。破損は数週間遅れて気づかれることが多いので、それが始まる前の時点まで戻れるだけの履歴を保持してください。" } }, { "@type": "Question", "name": "自分の管理下にないサーバー上の暗号化バックアップは安全ですか？", "acceptedAnswer": { "@type": "Answer", "text": "内容については安全です。resticとBorgはデータが送信元を離れる前に暗号化するので、保存先は読めないブロブを保存するだけで、鍵は決してそこへ移動しません。保存先が知ることになるのはメタデータです。おおよそのデータ量、その変化のしかた、ジョブがいつ動くか、といったものです。通常はこれで問題ありません。もし問題があるなら、スケジュールを変化させ、所有者が本番機と結びつかないマシンにリポジトリを置いてください。" } }, { "@type": "Question", "name": "バックアップのパスフレーズを紛失したらどうなりますか？", "acceptedAnswer": { "@type": "Answer", "text": "アーカイブは永久に失われ、誰にも救済手段はありません。これはこの分野全体で最もよくある完全喪失であり、復旧手段がまったくない唯一の失敗です。パスフレーズは関係するすべてのマシンの外のどこかに保管し、自分もアクセスを失うかもしれないアカウントよりも紙を優先し、リポジトリに2つ目の鍵を追加してください。そうすれば、パスフレーズを一つ忘れても不便で済み、アーカイブの終わりにはなりません。" } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "ホーム", "item": "https://servhidden.com/ja/" }, { "@type": "ListItem", "position": 2, "name": "プライバシーホスティングガイド", "item": "https://servhidden.com/ja/guides" }, { "@type": "ListItem", "position": 3, "name": "VPSバックアップ完全ガイド：暗号化・オフサイト・復元検証", "item": "https://servhidden.com/ja/guides/vps-backup-strategy" } ] } ```