[ホーム](https://servhidden.com/ja) / [プライバシーホスティングガイド](https://servhidden.com/ja/guides) / サイトをオフショアホスティングへダウンタイムゼロで移行する方法 運用 # ダウンタイムゼロのオフショア移行 痛みを伴う移行のほとんどは、技術的な失敗ではなく順序の失敗だ——2日前ではなく当日の夜に下げたTTL、DNS変更の前ではなく後に発行した証明書、もう権威を持たないサーバー上に有効なまま残されたcronジョブ。ここにあるのは、ダウンタイムの窓を完全になくす手順であり、加えて一般的なガイドが省略する部分——移行があなたについて恒久的に記録してしまうものと、それでもなお自分にできることだ。 [ガイドを読む](#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「ダウンタイムゼロ」の本当の意味](#ダウンタイムゼロの本当の意味) [02DNSのTTLは、移行予定日の数日前に下げておく](#dnsのttlは移行予定日の数日前に下げておく) [03覚えているものではなく、実際に移行するものを洗い出す](#覚えているものではなく実際に移行するものを洗い出す) [04まず新しいサーバーを構築し、何かを載せる前に堅牢化する](#まず新しいサーバーを構築し何かを載せる前に堅牢化する) [05データは2回コピーする、遅い一回と速い一回](#データは2回コピーする遅い一回と速い一回) [06DNSがまだ知らないうちに、新しいサーバーをテストする](#dnsがまだ知らないうちに新しいサーバーをテストする) [07切り替えの手順](#切り替えの手順) [08移行が消せずに残すもの](#移行が消せずに残すもの) [09ドメインの問題、そのまま使うか、それとも一新するか](#ドメインの問題そのまま使うかそれとも一新するか) [10旧ホストを正しくデコミッションする](#旧ホストを正しくデコミッションする) [11この手順をまとめて1ページに](#この手順をまとめて1ページに) [FAQよくある質問](#guide-faq) [→推奨 pages](#guide-cta) 稼働中のサイトを娯楽で移行する者はいない。移行が起きるのは、今のホストが突然パスポートの写真を求めてきたときであり、24時間以内の期限付きで苦情を転送してきたときであり、あるいはデータセンターが所在する国が、データを預けるにふさわしい場所には見えなくなったときだ。何がきっかけであれ、危険なのは移行そのものだ——サイトが暗転しうる唯一の瞬間であり、不用意な一歩が新しいサーバーを、捨てようとしていたはずの身元に縫い付けてしまう唯一の瞬間でもある。 この二つのリスクには同じ処方箋が効く。しかもそれはツールではない。順序だ。正しい順序で行われた移行には、サイトが到達不能になる窓は存在しない。両方のサーバーが同時に生きていて、DNSが最後に動くものだからだ。誤った順序で行われた移行は、障害と痕跡を同時に生む。以下がその順序であり、主流プロバイダー間を行き来する場合ではなく、オフショアでKYC不要のホストへ移る人向けに書いている——仕組みそのものは同じだが、その後の後始末は同じではない。 ## 「ダウンタイムゼロ」の本当の意味 この言葉は緩く使われがちで、その緩さが人を痛い目に遭わせる。2台のマシンから同時にHTTPを配信するのは簡単だ。2台が同時に配信している間*状態*を一致させ続けることこそが難しい部分であり、データを失う原因になるのもそこだけだ。だから何かを計画する前に、自分が実際にどちらを運用しているのかを見極めておく必要がある。その答えが、その夜全体の形を決めるからだ。 | 移行対象 | 実際に効いてくる部分 | 取るべきプラン | | --- | --- | --- | | 静的サイト、パンフレットサイト、生成された出力 | 何もない。分割すべき状態が存在しない | コピーして検証し、切り替える。文字通りダウンタイムゼロ | | データベース付きCMS——WordPress、Ghost、フォーラムなど | コメント・ログイン・投稿が同時に2つのデータベースに書き込まれてしまうこと | 最も静かな時間帯に、**数分**単位の読み取り専用フリーズを | | ストアや、注文を受け付けるあらゆるもの | スプリットブレインが起きると、支払い済みの注文が静かに失われる | 短い作業時間帯を確保する。突き合わせ作業より安上がりだ | | cronジョブやバックグラウンドワーカーを持つあらゆるもの | 同じジョブが両方のサーバーで発火すること——メールも二重、課金も二重 | 新しい方を起動する*前に*、旧ホスト側のスケジュールを無効化する | | 同じドメイン上のメール | MXレコードはAレコードとは無関係に、独自のタイマーでキャッシュから失効する | メールは別の夜に移行し、旧MXを1週間受信可能なまま残しておく | 本当に無償なのは1行目だけだと気づいてほしい。それ以外のすべてにおいて、「ダウンタイムゼロ」が意味するのは「誰もチケットを立てないほど短い書き込みフリーズ」でしかない。04:00の2分間の読み取り専用は誤差の範囲だが、2つのデータベースにまたがる2時間の分裂書き込みは、週末をまるごと使う突き合わせ作業になる。フリーズの方を選ぼう。 両方のサーバーを同時に稼働させ、DNSは最後に動かす——正しい順序で行う切り替えに、窓がまったく存在しない理由はそこにある。 ## DNSのTTLは、移行予定日の数日前に下げておく リードタイムが必要な唯一のステップがこれであり、だからこそ最初に行うべきであり、だからこそ誰もが省略しがちなステップでもある。TTL——time to live、つまりレコードの生存時間——は、インターネット上のすべてのリゾルバに対して、次に問い合わせるまでどれだけの時間キャッシュしてよいかを伝える値だ。AレコードのTTLが86400なら、1時間前に問い合わせ済みのリゾルバは、レジストラ側で何を変更しようと、その後23時間は古いIPアドレスを配り続ける。 重要なのは、TTLを下げるという操作自体が、古いTTLの支配を受けるという点だ。リゾルバが新しい短い値を知るのは、キャッシュ済みの古いコピーが失効したときだけだ。だからTTLは300秒まで、**切り替えの少なくとも1回分の旧TTL期間前には**下げておく——1日単位のTTLなら、24〜48時間前ということになる。そうすれば、変更から5分以内に世界中がその新しいレコードに収束し、切り替えはもはやハラハラする出来事ではなくなる。 移行から数日後には、TTLを妥当な値に戻しておく。300秒のTTLは道具としては優秀だが、恒常設定としては質が悪い。問い合わせ量が跳ね上がり、DNSプロバイダーが単一障害点としての鋭さを一気に増してしまう。 ## 覚えているものではなく、実際に移行するものを洗い出す 失敗した移行の事後検証は、いつも同じ結論に行き着く。誰もリストに書かなかった何かが、コピーされていなかったのだ。Webルートとデータベースは誰もが覚えている二つだが、以下のリストはそれ以外のすべてであり、記憶に頼らず文字通り一つずつ確認していく価値がある。 - **スケジュール実行。**全ユーザー分のcrontab -lと、systemdタイマー。更新フックや夜間ジョブはここに隠れている。 - **サービス定義。**独自のsystemdユニット、Webサーバーのvhost、PHP-FPMのプール、supervisor系の設定。 - **シークレットと環境変数。**.envファイル、APIキー、データベースのパスワード、アプリケーションのソルト——これらは単にコピーするのではなく、ローテーションすべきものだと心に留めておく。 - **TLS関連。**証明書、そしてそれ以上に重要な、ACMEアカウントと更新設定。 - **メールの身元情報。**DKIM秘密鍵、SPFレコードとDMARCレコード。ここが食い違っても派手には壊れない——ただ静かにメールを迷惑メールへ送り込むだけだ。 - **アップロード済みメディア。**Webルートの外に置かれていることが多く、しばしば所有物の中で最も容量が大きい。 - **あなたのIPアドレスを信頼している外部のすべて。**決済ゲートウェイの許可リスト、Webhookの送信先、データベースのファイアウォール、IP制限付きのサードパーティAPI。03:00に「サイトは動くのに決済だけ壊れている」が起きる原因の第一位だ。 - **パッケージ一覧。**dpkg --get-selectionsあるいはそれに相当するもの。新しいマシンに、ほぼ同じではなく、まったく同じ拡張機能とライブラリを揃えるために。 コピーを始める前に、このリストを書き出しておこう。この洗い出しリストは後にそのままテスト計画にもなる——1行1行が、DNSがまだその存在を知らないうちに新しいサーバー上で確認すべき項目になる。 ## まず新しいサーバーを構築し、何かを載せる前に堅牢化する 移行先は早めに注文し、1〜2日は空のまま動かしておく。重複稼働にコストはほぼない——小さなオフショアVPSなら月に数ドルだ——一方で、フリーズさせたデータベースを待たせたまま時間に追われて構築するのを避けられる価値は大きい。 旧環境には意図的に合わせる。同じディストリビューションと同じメジャーバージョン、同じPHPかNodeかPythonのメジャーバージョン、同じデータベースのメジャーバージョンだ。ついでに近代化したくなる誘惑は強烈だが、完全に我慢すべきだ。切り替え後にサイトが壊れたなら、変化した変数はちょうど1つであってほしい。スタックのアップグレードは2週間ほど後、なんでもない午後に、ロールバックできる状態で行えばいい。 空のうちに堅牢化しておく。鍵認証のみのSSH、デフォルト拒否のファイアウォール、自動セキュリティアップデート——[最初の1時間の堅牢化チェックリスト](https://servhidden.com/ja/guides/first-hour-vps-hardening-checklist)はまさにこのリストであり、何も載っていないマシンに適用するほうがはるかに簡単だ。法域を移すほど機微なデータを扱っているなら、[保存データの暗号化](https://servhidden.com/ja/guides/full-disk-encryption-on-a-vps)を決めるのにもちょうどよいタイミングだ。後から組み込むとなると、また別の移行が発生してしまう。 ## データは2回コピーする、遅い一回と速い一回 メンテナンス時間中にすべてをコピーしたくなるのが人情だが、やるべきはその逆だ。旧サイトが何事もなくトラフィックを捌いている数日前に完全コピーを1回走らせ、切り替え時には変更分だけを移す2回目のパスを走らせる。1回目は6時間かかっても誰も気づかない。2回目は90秒で終わり、それがダウンタイム予算の全てになる。 ファイルにはrsync -aHAX --numeric-idsを使う。パーミッション、所有者、ハードリンク、拡張属性を保持できる。--numeric-idsフラグが重要なのは、新しく構築した2台のマシンの間ではUIDが一致することはまれだからだ。まず早い段階で1回実行し、切り替え直前に同じ引数でもう一度実行する——2回目は差分だけを転送する。 データベースにも同じ二段階の扱いが必要だが、道具は違う。mysqldump --single-transactionやpg_dumpを使えば、構築とテストの土台になる一貫性のある早期スナップショットが得られる。切り替え時には、短い書き込みフリーズの間に2回目のダンプを取るか——短いフリーズさえ痛手になるほど大きなデータベースなら——数日前から新しいサーバーを旧サーバーのレプリカとして立ち上げて追いつかせておき、それを昇格させる。レプリケーションを使えばフリーズは数秒で済む。だが2時間の移行を2日がかりのプロジェクトに変えてしまうので、規模が本当にそれを必要とするときだけ使うべきだ。 **プッシュではなくプルで行い、自宅の回線は絶対に経由しない。**コピーは新しいサーバー側から開始し、転送がホスト間でデータセンター速度のまま完結するようにする。自宅回線経由で数ギガバイトを流すのは遅いうえ、両方のマシンのアクセスログに自宅のIPアドレスを刻んでしまう——プライバシー目的の移行が何より避けたいはずの結びつきだ。旧ホストに新しいIPアドレスを知られること自体が許容できないなら、直接コピーは一切行わない。代わりに、自前の[オフサイト暗号化バックアップ](https://servhidden.com/ja/guides/vps-backup-strategy)から新しいサーバーを復元すれば、2台のマシンは一度も通信しない。 ## DNSがまだ知らないうちに、新しいサーバーをテストする 公開レコードを一切変更しないまま、新しいIPアドレスから本物のホスト名を配信することができるし、実際そうすべきだ——これこそが切り替えを平穏なものにする。ローカルの/etc/hostsにドメインを新しいIPアドレスへ向ける行を追加してもいいし、それを省いてcurlに1リクエストぶんだけ肩代わりさせてもいい。 curl -I --resolve example.com:443:203.0.113.10 https://example.com/ ここで洗い出しリストを一通りたどってみる。トップページと、奥にある3ページを読み込む。ログインする。フォームを送信する。ファイルをアップロードする。データベース接続が新しいローカルのものになっていて、インターネット越しに旧ホストを指したままになっていないかを確認する——これは旧サーバーを解約するまでは完璧に動いてしまうタイプのミスだ。cronジョブを手動で実行し、その出力を読む。リダイレクトを検証し、存在しないURLが200ではなくきちんと404を返すことも確かめる。 TLS証明書は、切り替えの後ではなく今、事前に発行しておく。DNS-01チャレンジを使えば、TXTレコードを通じてドメインの制御を証明できるので、Aレコードがまだ旧サーバーを指したままでも通用する。DNS変更後のHTTP-01検証を待ってしまうと、その間に訪れた初期の訪問者は全員証明書の警告を目にすることになる——守ろうとしていたはずのその窓の中で、自ら招いた障害だ。 ## 切り替えの手順 ここまで来れば、新しいサーバーは構築済み、堅牢化済み、データも投入済みで、本物のホスト名でテストも済ませ、有効な証明書も保持している。切り替えそのものは、もはや短くて退屈なリストにすぎない——それこそが目指すべき状態だ。 - サイトに依存する人が他にいるなら作業時間帯を告知し、旧サイトを読み取り専用またはメンテナンスモードにする。 - **旧ホスト側のcronとバックグラウンドワーカーを無効化する。**これは新しい方で起動する前に行う。後からでは絶対にいけない。 - 最後のrsync差分パスと、最後のデータベースダンプを実行し、それをインポートする。 - 新しいサーバーでアプリケーションを起動し、最終データに対して--resolve経由のスモークテストをもう一度実行する。 - AレコードとAAAAレコードを新しいIPアドレスに変更する。TTLが300秒なら、5分以内に世界中が追随する。 - 新しいホスト側でcronとワーカーを有効化する。 - 両方のアクセスログを並べて監視する。トラフィックは旧サーバーから流れ出し、新サーバー側に現れる。旧サーバーが静かになったら、切り替えは完了だ。 - 旧サーバーは1週間、稼働させたまま、配信させたまま、手を触れずに残しておく。それがロールバック手段になる。 8番目のステップは省略されがちだが、このリストの中で最も安い保険でもある。わずか数ドルの対価で、確信が持てるまでの間ずっと、DNSを元に戻す能力——5分で復旧できる能力——を保持できる。 ## 移行が消せずに残すもの ここからが、一般的な移行ガイドが省略する部分であり、価格ではなくプライバシーのために移行したのであれば最も重要な部分でもある。サイトを移行しても、その履歴は消えない。旧環境に関する公開または半公開のいくつもの記録が、移行後も永久に残り続ける。そのどれが残るのかを知っていることこそが、本当の決別と、決別したつもりでいるだけの状態との違いになる。 | 何が移行を記録するか | 誰が読めるか | 実際にできること | | --- | --- | --- | | パッシブDNS——過去のAレコード | 商用の履歴サービスを通じて誰でも | **何もできない。**旧IPアドレスはそのドメイン名と恒久的に結びついている。公開情報だと思って計画しよう。実際そうなのだから | | Certificate Transparencyのログ | 誰でも、永久に、ドメインで検索可能 | これまで発行されたすべての証明書が一覧化される——存在を忘れていた内部向けっぽいサブドメインも含めて。説明的な名前よりワイルドカードを選んでおく | | 旧ホストのアカウント記録 | 旧ホスト自身、そして彼らに開示を強制できる者 | カード情報、登録メールアドレス、ログイン時のIPアドレス。KYC不要の移行先が守るのは未来であって過去ではない | | WHOIS履歴 | 商用のWHOIS履歴アーカイブ | ドメインが一度でも実名情報で登録されていれば、そのスナップショットは残る。後からプライバシー保護を適用しても撤回はできない | | アナリティクスや広告の識別子 | 提供元、そしてページのソースを読む誰でも | 同じトラッキングIDを引き継ぐと、2つのサイトが決定的に結びついてしまう。新しいIDを発行するか、そもそも使わない | | 旧ディスクに残されたダンプやバックアップ | 次にそのストレージを割り当てられる者 | 解約前に削除し、上書きしておく。共有ストレージでは、削除は保証ではなくヒントに過ぎないと考える | | 送信済みメールのReceived:ヘッダー | すべての受信者に、永久に | 遡っての対処はできない。新しい経路が記録されるのは、移行後に送るメールだけだ | | コピー作業中の自分自身の接続 | 自分のISP、そして両ホストのアクセスログ | これだけは完全に自分でコントロールできる。自分だと特定できるIPアドレスからは、どちらのマシンにも決して触れないこと | 正直に要約すれば、移行は過去を書き換えることはできず、できるのはこれ以上積み増さないようにすることだけだ。それでも十分に価値はあるが、この事実が判断を左右する。もし脅威モデルとして、新サイトと旧サイトを誰にも結びつけられないことが必須条件なら、同じドメインを新しいホストへ移すだけではそれは達成できない。切り替え中にどれだけ注意を払っても、それは変わらない。その場合に必要なのは新しい名前とクリーンな出発であり、これは次の節で扱う。逆に、今日以降は身元を特定できる記録を新たに生まないようにし、法的な重心を自分で選んだ法域へ移すことが目的なら、この移行はまさにそれを果たしてくれる。その後の清潔さを保つ習慣については、当社の[サーバーOpSecガイド](https://servhidden.com/ja/guides/server-opsec-staying-anonymous)で扱っている。 ## ドメインの問題、そのまま使うか、それとも一新するか サイトとドメインは本来別々の判断であるにもかかわらず、両者を混同するのはよくあることだ。ホスティングは今日移行し、レジストラには一切触れないままにしておくこともできる。サーバー側の変更が、ドメインに手を付けることを要求する理由は何もない。*そうすべき*かどうかは、そのドメインがあなたについてすでに何を知っているかに完全に左右される。 - **ドメインは維持し、レジストラだけ変更する。**被リンク、検索順位、人が実際に入力してくれる名前など、ドメインに価値がある場合に理にかなう。WHOISレコードの未来は正せても過去は正せないが、順位シグナルはすべてそのまま保たれる。ほとんどの商用サイトにとって正解はこれだ。 - **ドメインは維持し、ホスト以外は何も変えない。**匿名性ではなく法域、稼働率、DMCA対応方針を理由に移行したのであれば、まったく合理的な選択だ。あり得る中で最もシンプルな移行で、SEOリスクはゼロ。 - **新しいドメインにして、旧ドメインからリダイレクトする。**検索順位は維持できるが、2つの名前を公開かつ恒久的に結びつけてしまう。継続性のために選ぶものであって、プライバシーのために選んではいけない——リダイレクトそのものが結びつきになる。 - **新しいドメインで、完全に決別する。**結びつきを本当の意味で断ち切れる唯一の選択肢だが、それまでの検索順位も被リンクもすべて失う。ドメインの匿名性は最初の登録の時点までしか遡れないので、最初から匿名で登録すること。正しく行う方法は[暗号資産による匿名ドメイン登録ガイド](https://servhidden.com/ja/guides/anonymous-domain-registration-with-crypto)で扱っている。 意図的に選び、しかも切り替えの最中ではなく、その前に選んでおく。DNSを移した後でドメインについて気が変わると、デリケートな作業を2回行う羽目になる。 ## 旧ホストを正しくデコミッションする 切り替えから1〜2週間が経ち、新サーバーのログが退屈なものになり、旧サーバーのログが空になったら、旧アカウントを閉じるタイミングだ。この順序で行うこと。魅力的に見える近道——いきなり解約ボタンを押すこと——こそが、自分のデータを他人のディスクに残してしまう原因だからだ。 - 旧IPアドレスを指すものが何も残っていないか確認する。サードパーティのWebhook、許可リスト、監視ツールにハードコードされたアドレス、そしてmailやcpanelのような書き忘れたDNSレコードがないかをチェックする。 - そのマシン上に存在したことのあるシークレットをすべてローテーションする——データベースのパスワード、APIキー、アプリケーションのソルト、DKIM鍵、SSH鍵。これらを新環境へそのまま引き継いではいけない。 - 旧サーバーからSSH公開鍵と、サポート用のアクセス権をすべて取り除く。 - アプリケーション、ダンプ、バックアップを削除し、空き領域を上書きする。再利用されたボリュームを軽く読み取っても何も出てこないようにするためだ。 - そこまで終えてはじめてサービスを解約し、旧アカウントに保存された支払い方法も削除する。 **もう自分の管理下にないハードウェアに存在していたものは、定義上すべて漏洩済みと考える。**旧ホストが悪意を持っているからではなく、そのディスクはやがてプールに戻され、消去処理の後に何が生き残ったのかを知る術は二度とないからだ。データベースのパスワードをローテーションするのは2分の作業だ。デコミッション済みのサーバー由来の鍵が何かを今も開けると数か月後に気づくのは、それよりずっと長い時間がかかる。 ## この手順をまとめて1ページに 理由づけを取り除いてしまえば、ホスト移行は9つのステップになり、そのうち緊急性があるのはたった2つだけだ。 - **2日前:**DNSのTTLを300秒まで下げる。 - **2日前:**移行先サーバーを注文し、旧スタックとバージョンを揃えて堅牢化する。 - **数日前:**洗い出しリストを書く——cron、シークレット、TLS、メール関連の鍵、メディア、IP許可リスト、パッケージ。 - **数日前:**ホスト間で1回目の完全データコピーを実行する。 - **作業時間帯の前:**DNS-01で証明書を発行し、--resolve経由ですべてをテストする。 - **作業時間帯（数分）:**書き込みをフリーズし、旧cronを無効化し、差分コピーと最終ダンプを実行し、新しいアプリを起動する。 - **作業時間帯（数秒）:**Aレコードを変更し、新ホスト側でcronを有効化する。 - **翌週:**旧サーバーはロールバック用に生かしたまま両方のログファイルを監視し、その後TTLを再び上げる。 - **その後:**シークレットをローテーションし、データを消去し、解約する——そして、この移行が消せなかったものを忘れないこと。 このリストの中に、難しいものは一つもない。痛手になるステップは、例外なく順序を間違えたステップだ——当日の夜に下げたTTL、DNS変更の後に発行した証明書、もう権威を持たなくなったマシン上に有効なまま残されたcronジョブ。順序さえ正しければ、移行の中で面白いのは移行作業そのものではなく、サーバーをどこに置くかを選ぶことになる。まだそこを決めていないなら、[法域選びのガイド](https://servhidden.com/ja/guides/choosing-an-offshore-jurisdiction)から始めるといい。 FAQ ## ホスト移行——よくある質問 ### 01 実際のところ、どれくらいのダウンタイムを見込むべきですか？ 静的サイトであれば、ダウンタイムはまったくのゼロです。2台のサーバーが同じ内容を同時に配信できるため、DNSの変更自体が誰にも見えません。データベースを伴うものであれば、ダウンタイムは書き込みフリーズの長さそのものになり、事前に完全データコピーを済ませておけば通常は2〜10分程度です。重要なのはDNSがどれだけ速く反映されるかではなく、その作業時間帯にどれだけの量をコピーするかです。ほぼすべてを数日前にコピーしておけば、作業時間帯は差分の大きさまで縮みます。 ### 02 DNSの伝播にはどれくらい時間がかかりますか？ 実は「伝播」というもの自体が存在しません。それは実際には起きていない現象を指す言葉です。リゾルバは単に、TTLが指定した時間だけレコードをキャッシュし、それが失効したら再度問い合わせているだけです。有効だったTTLが86400だった場合、一部のリゾルバはその後さらに24時間、古いIPアドレスを返し続けます。切り替えの少なくとも1回分の旧TTL期間前にTTLを300秒まで下げておけば、変更から5分以内にインターネット全体が追随します。 ### 03 ドメインも一緒に移行する必要がありますか？ いいえ。レジストラとホストは完全に独立しており、ドメインをそのままにしてサイトだけを移行しても何の問題もありません。移行すべきかどうかは、移行の理由次第です。理由が法域、価格、DMCA対応方針であれば、ドメインには触れないままで構いません。理由が匿名性であれば、ドメインには独自の履歴が別に存在することに注意してください——WHOISアーカイブは最初に登録されたときの情報を保持し続け、ホスティングの変更はそこには一切影響しません。 ### 04 旧ホストに移行先を知られずに移行することはできますか？ 2台のマシン間で直接コピーする場合はできません——どちらか一方がもう一方に接続する以上、双方のアクセスログにそれが記録されます。その結びつきが自分の脅威モデルにとって本当に重要なら、ホスト間で直接コピーすること自体をやめましょう。自前のオフサイト暗号化バックアップから新しいサーバーを復元すれば、2社のプロバイダーは一切パケットをやり取りしません。いずれの方法を取るにせよ、自分だと特定できる接続から転送を開始しないこと、そして旧プロバイダーに開くサポートチケットには移行先の情報を一切書かないことです。 ### 05 OSやスタックのアップグレードも同時に行うべきですか？ いいえ。これは移行における最も典型的な自滅パターンです。変えるものは1つに絞ってください。切り替え後にサイトの挙動がおかしくなったとき、新しいマシンなのか、新しいPHPバージョンなのか、新しいデータベースのメジャーバージョンなのか、候補が複数あるのは避けたいはずです。旧環境とバージョンをすべて揃えて移行を完了させ、1週間分のログがきれいであることを確認してから、ロールバックできる状態で別途アップグレードしてください。 ### 06 移行すると検索順位に悪影響はありますか？ ドメイン、URL、コンテンツがそのままであれば、実質的な悪影響はありません。GoogleがインデックスするのはURLであってIPアドレスではなく、ホストの変更それ自体は順位シグナルではないからです。URL構造を同一に保ち、同じステータスコードを返し、リデザインやURLスキームの変更を移行と同時に行わないようにしてください。新しいドメインへ移行する場合は、正しく301リダイレクトを設定していても一時的な順位の落ち込みは覚悟してください。また、そのリダイレクト自体が2つの名前を公に結びつけてしまうことも理解しておく必要があります。 ### 07 TLS証明書は再発行する必要がありますか？ はい。新しいサーバーには専用の証明書と秘密鍵が必要であり、旧サーバーの鍵をそのまま引き継ぐのは、技術的に動いてしまう場合であっても好ましくない習慣です。切り替えの前に、DNS-01チャレンジを使って発行してください。これはTXTレコードを通じて検証するため、Aレコードがまだ旧ホストを指したままでも成功します。DNS変更後のHTTP-01検証を待ってしまうと、まさに守ろうとしていたその作業時間帯に、証明書の警告が出続けることが確定してしまいます。 ### 08 旧サーバーを解約しても安全なのはいつですか？ 旧マシンのログが静かになり、新マシンのログがきれいな状態が1〜2週間続いてからです——この待機期間がロールバック手段であり、コストは数ドルで済みます。解約する前に、外部から旧IPアドレスを指しているものが残っていないか確認し、そのマシン上に存在したことのあるシークレットをすべてローテーションしたうえで、データを削除して空き領域を上書きしてください。解約は最後です。先に解約ボタンを押してしまうと、もう自分の管理が及ばないディスクの上に、データベースを残していくことになります。 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) [### VPSバックアップ完全ガイド：暗号化・オフサイト・復元検証 運用 ホスティング業者はバックアップを保持しません。サーバーを壊す本当の原因、restic対BorgBackupの選び方、忘れがちな鍵、復元テストの手順まで解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/vps-backup-strategy) [### Matrixサーバーのセルフホスト:Synapseと連合の実態 運用 Matrixホームサーバーで本当に変わることとは。Synapse・Conduitの違い、変更不可能なserver_name、肥大化するメディア保存、連合が明かす情報を解説します。 8の質問からなるFAQ](https://servhidden.com/ja/guides/self-host-a-matrix-server) [### 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つの法域のオフショアKVMサーバーは月額7.50ドルから。フルルート権限、NVMeストレージ、帯域無制限で、暗号資産決済の確認後5分足らずでデプロイされます。移行先を早めに立ち上げ、自分のペースでコピーし、準備が整ったところで切り替えましょう。 [VPSプランを見る](https://servhidden.com/ja/vps) [オフショアホスティング](https://servhidden.com/ja/offshore-hosting) [すべてのロケーション](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": "サイトをオフショアホスティングへダウンタイムゼロで移行する方法", "description": "ホスト移行を退屈な作業に変える順序をご紹介します。DNSのTTLを数日前に下げ、2台のサーバーを並行稼働させて書き込みフリーズを時間ではなく分に抑え、さらに移行が残すパッシブDNSやCertificate Transparency、WHOISの痕跡を消す方法まで解説します。", "image": "https://servhidden.com/assets/img/guides/migrate-website-to-offshore-hosting.webp?v=1787969426", "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-29T00:00:00+00:00", "dateModified": "2026-08-29T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/migrate-website-to-offshore-hosting", "inLanguage": "ja", "keywords": "サーバー移行 オフショア, ホスティング 乗り換え ダウンタイムなし, VPS 移行 手順, DNS TTL 切り替え, ウェブサイト 移行 チェックリスト, 無停止 サーバー移行, KYC不要 ホスティング 移行, rsync サーバー移行", "articleSection": "運用", "wordCount": 4014 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "実際のところ、どれくらいのダウンタイムを見込むべきですか？", "acceptedAnswer": { "@type": "Answer", "text": "静的サイトであれば、ダウンタイムはまったくのゼロです。2台のサーバーが同じ内容を同時に配信できるため、DNSの変更自体が誰にも見えません。データベースを伴うものであれば、ダウンタイムは書き込みフリーズの長さそのものになり、事前に完全データコピーを済ませておけば通常は2〜10分程度です。重要なのはDNSがどれだけ速く反映されるかではなく、その作業時間帯にどれだけの量をコピーするかです。ほぼすべてを数日前にコピーしておけば、作業時間帯は差分の大きさまで縮みます。" } }, { "@type": "Question", "name": "DNSの伝播にはどれくらい時間がかかりますか？", "acceptedAnswer": { "@type": "Answer", "text": "実は「伝播」というもの自体が存在しません。それは実際には起きていない現象を指す言葉です。リゾルバは単に、TTLが指定した時間だけレコードをキャッシュし、それが失効したら再度問い合わせているだけです。有効だったTTLが86400だった場合、一部のリゾルバはその後さらに24時間、古いIPアドレスを返し続けます。切り替えの少なくとも1回分の旧TTL期間前にTTLを300秒まで下げておけば、変更から5分以内にインターネット全体が追随します。" } }, { "@type": "Question", "name": "ドメインも一緒に移行する必要がありますか？", "acceptedAnswer": { "@type": "Answer", "text": "いいえ。レジストラとホストは完全に独立しており、ドメインをそのままにしてサイトだけを移行しても何の問題もありません。移行すべきかどうかは、移行の理由次第です。理由が法域、価格、DMCA対応方針であれば、ドメインには触れないままで構いません。理由が匿名性であれば、ドメインには独自の履歴が別に存在することに注意してください——WHOISアーカイブは最初に登録されたときの情報を保持し続け、ホスティングの変更はそこには一切影響しません。" } }, { "@type": "Question", "name": "旧ホストに移行先を知られずに移行することはできますか？", "acceptedAnswer": { "@type": "Answer", "text": "2台のマシン間で直接コピーする場合はできません——どちらか一方がもう一方に接続する以上、双方のアクセスログにそれが記録されます。その結びつきが自分の脅威モデルにとって本当に重要なら、ホスト間で直接コピーすること自体をやめましょう。自前のオフサイト暗号化バックアップから新しいサーバーを復元すれば、2社のプロバイダーは一切パケットをやり取りしません。いずれの方法を取るにせよ、自分だと特定できる接続から転送を開始しないこと、そして旧プロバイダーに開くサポートチケットには移行先の情報を一切書かないことです。" } }, { "@type": "Question", "name": "OSやスタックのアップグレードも同時に行うべきですか？", "acceptedAnswer": { "@type": "Answer", "text": "いいえ。これは移行における最も典型的な自滅パターンです。変えるものは1つに絞ってください。切り替え後にサイトの挙動がおかしくなったとき、新しいマシンなのか、新しいPHPバージョンなのか、新しいデータベースのメジャーバージョンなのか、候補が複数あるのは避けたいはずです。旧環境とバージョンをすべて揃えて移行を完了させ、1週間分のログがきれいであることを確認してから、ロールバックできる状態で別途アップグレードしてください。" } }, { "@type": "Question", "name": "移行すると検索順位に悪影響はありますか？", "acceptedAnswer": { "@type": "Answer", "text": "ドメイン、URL、コンテンツがそのままであれば、実質的な悪影響はありません。GoogleがインデックスするのはURLであってIPアドレスではなく、ホストの変更それ自体は順位シグナルではないからです。URL構造を同一に保ち、同じステータスコードを返し、リデザインやURLスキームの変更を移行と同時に行わないようにしてください。新しいドメインへ移行する場合は、正しく301リダイレクトを設定していても一時的な順位の落ち込みは覚悟してください。また、そのリダイレクト自体が2つの名前を公に結びつけてしまうことも理解しておく必要があります。" } }, { "@type": "Question", "name": "TLS証明書は再発行する必要がありますか？", "acceptedAnswer": { "@type": "Answer", "text": "はい。新しいサーバーには専用の証明書と秘密鍵が必要であり、旧サーバーの鍵をそのまま引き継ぐのは、技術的に動いてしまう場合であっても好ましくない習慣です。切り替えの前に、DNS-01チャレンジを使って発行してください。これはTXTレコードを通じて検証するため、Aレコードがまだ旧ホストを指したままでも成功します。DNS変更後のHTTP-01検証を待ってしまうと、まさに守ろうとしていたその作業時間帯に、証明書の警告が出続けることが確定してしまいます。" } }, { "@type": "Question", "name": "旧サーバーを解約しても安全なのはいつですか？", "acceptedAnswer": { "@type": "Answer", "text": "旧マシンのログが静かになり、新マシンのログがきれいな状態が1〜2週間続いてからです——この待機期間がロールバック手段であり、コストは数ドルで済みます。解約する前に、外部から旧IPアドレスを指しているものが残っていないか確認し、そのマシン上に存在したことのあるシークレットをすべてローテーションしたうえで、データを削除して空き領域を上書きしてください。解約は最後です。先に解約ボタンを押してしまうと、もう自分の管理が及ばないディスクの上に、データベースを残していくことになります。" } } ] } ``` ```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": "サイトをオフショアホスティングへダウンタイムゼロで移行する方法", "item": "https://servhidden.com/ja/guides/migrate-website-to-offshore-hosting" } ] } ```