ほとんどの移行は、コピーの最中には失敗しません。失敗するのはDNS変更後の20分間です。インターネットの半分はまだ古いサーバーと話しており、残りの半分はすでに新しいサーバーに移っていて — しかも両方のマシンが書き込みを受け付けている状態です。ファイルは無傷で届き、サイトは表示されるにもかかわらず、注文は決して統合されることのない2つのデータベースにまたがって記録されていきます。これを避けるうえで転送速度はほとんど関係がなく、重要なのはほぼすべて順序です — 最初に何を変更するか、何を凍結するか、そして確信が持てるまで何を動かし続けるかです。
「ダウンタイムなし」が実際に意味すること
この言葉は正確に捉えておく価値があります。というのも、この表現は2つのまったく異なる約束を指しており、それぞれにかかる労力もまったく異なるからです。自分がどちらを求めているのかを決めることが、この移行における最初の本当の決断になります。
どちらか一方を犠牲にしなければならないなら、可用性を犠牲にしてください。4分間のメンテナンスページは説明のつくものです。食い違ったデータは修正できません。どちらのコピーが正しかったかを判定する権威がもはや存在しないからです。
始める前に、許容できる書き込み凍結時間の上限を書き出してください。4分か、30秒か、ゼロか。この1つの数字が、この先のすべてを決めます — ダンプと復元で十分なのか、レプリケーションが必要なのか、あるいは全体の前段にプロキシが必要なのかです。数字を決める前にツールを決めてしまうことが、移行に想定外の事態をもたらす原因になります。
コピーを取る前に、棚卸しをする
サーバーには、誰も記録してこなかったものが積み重なっています。インシデント対応中に追加されたcronジョブ、パートナーのアドレス用のファイアウォールルール、サービスファイルに貼り付けられたAPIキーなどです。コピーはこれらを引き継がず、その後の2週間かけて1つずつ発見していくことになります。今のうちに30分かけて棚卸しをしておけば、そのほとんどを取り除けます。
何がリッスンしているか
ss -tulpn を実行し、リッスンしているすべてのソケットを把握してください。それぞれが新しいマシンにも存在しなければならないサービスであり、説明のつかないポートはそれを複製する前に理解しておく価値があります — 移行は、2023年からずっと動き続けているものに気づくのにちょうどよい機会です。
何がタイマーで動いているか
rootを含むすべてのユーザーについて crontab -l を確認し、systemctl list-timers を実行し、アプリケーション自身に内蔵されたスケジューラーも確認してください。タイマーは、移行後に重複して生き残ってしまうものの中で最も多いものであり、重複は存在しないことよりも悪い結果を招きます。
ディスクの中にはないもの
DNSレコード、アドレスの逆引きDNS、ファイアウォールルール、第三者が保持しているAPIキー、webhookの送信先、そして現在のIPを名指ししている他所のallowlistです。これらはどれも、これからコピーしようとしているファイルシステムの中には存在しません。
アプリケーションが前提としていること
ハードコードされた絶対パス、設定ファイル内のホスト名、データベースソケットの場所、bindディレクティブ内のアドレス。これらは静かに壊れるものです — サービスは起動するものの、機能しません。
これはターミナルのスクロールバックにではなく、バージョン管理下に置くファイルに書き出してください。切り替え作業中にこれを3回読み返すことになり、そのうち1回は頭がうまく働いていない瞬間です。
後から変えられない要素で、移行先を選ぶ
スペックは後から調整できますが、一部の性質は調整できません。そしてそれらは、まだ自由に選べるうちに、意図的に決めておく価値があります。どうせ移行するのですから、これまで回避しながら付き合ってきた制約を直せる、これ以上安く済むタイミングは二度とありません。
- 所在地。ユーザーへのレイテンシも適用される法律も、これによって固定されるからです。/locations に各リージョンとその往復特性が一覧になっています — 今離れようとしている場所とは独立して障害が起きるリージョンを選んでください。
- 法的な立場。現在のプロバイダーが、パケットを転送するよりも早く苦情を転送してくるというのが移行の理由であるなら、これが重要になります。/offshore-hosting では、法域が実際に何を左右し、何を左右しないのかを解説しています。
- 支払い時の身元。支払いを受け付ける前に書類を要求するホストは、その仕組み上あなたに関するファイルを持っていることになります。/no-kyc-vps と /pay-with では、その代わりとなる方法 — 暗号資産でチャージした残高を使い、カードもなく、マシンに紐づく名前も残らない方法 — を解説しています。
- 余裕。2度移行する羽目になるのは、誰も望んでいない結末だからです。/vps に各プランを一覧にしてあり、現在のマシンを一度もきちんと計測したことがないなら /guides にサイジングの方法があります。
- IPv6と、汚れのないIPv4。使い回されたアドレスは、他人の評判を背負ったまま届くことがあります — メールの問題になる前に確認してください。
まずDNSのTTLを、数日前のうちに下げておく
これは、終盤になって急いでは済ませられない唯一の準備作業です。その効果が、自分ではコントロールできない時計によって制限されているからです。レコードのTTLは、リゾルバーに対して応答をどれだけの時間キャッシュしてよいかを伝えます。これが1日に設定されていれば、1時間前に問い合わせたリゾルバーは、その後どれだけ新しい情報を公開しようと、残り23時間はユーザーを古いサーバーへ送り続けます。
- 1
現在のTTLを確認する
dig +noall +answer yourdomain.com で、残りのキャッシュ時間を確認できます。dig @ns1.example.net yourdomain.com のように権威ネームサーバーへ直接問い合わせれば、設定されている値が確認できます。これを書き留めておいてください — 待機期間の長さを決めるものです。
- 2
300秒まで下げる
変更予定のあるすべてのレコード — A、AAAA、そしてそのホストを指すMXやCNAME — のTTLを下げてください。5分は切り替え作業を無理なく行えるほど短く、かつネームサーバーに過度な負荷をかけないほど長い時間です。
- 3
古いTTLの期間を待ち、さらにもう一度待つ
新しく短くしたTTLは、古い長いTTLが期限切れになった後でなければリゾルバーに届きません。短くなったTTLを信頼してよいと見なす前に、古いTTLの期間 — それが1日だったなら1日 — を丸々待ってください。これを早めに始めても費用はかからず、切り替え作業全体に余裕を生み出します。
リゾルバーの中には、設定したTTLを無視して独自の最小値でキャッシュするものもあり、一部のクライアントはプロセスが生きている間ずっとキャッシュを保持します。教科書通りに完璧な切り替えを行った後でも、何時間にもわたって古いアドレスへのトラフィックが尾を引くことを見込んでおいてください。だからといってTTLの作業を省いていい理由にはなりません — むしろ、その後も古いサーバーを生かしておかなければならない理由になります。
新しいサーバーは構築する。古いサーバーを複製しない
つい、現在のディスクをイメージ化してどこか別の場所に復元したくなるものです。しかしこれは誤った選択です。理由はバックアップからの復元の場合とまったく同じです — ブロックレベルの複製は、設定のずれ、放置されたパッケージ、誰かが中途半端に設定したまま放棄したサービス、そして過去の侵入者が残していった痕跡まで、忠実に再現してしまいます。しかも、古いディストリビューションのリリースに縛られたままになります。
新しいマシンは最新のベースイメージから構築し、サービスはスクリプトからインストールし、コピーするのはデータだけにしてください。本当の成果物はそのスクリプトです — 次回の移行を2週間ではなく午後だけで終わらせるのはこのスクリプトであり、インシデントの後に発掘作業なしで再構築できるようにするのもこのスクリプトです。
- 他の何かがそれに触れる前に、プロビジョニング、更新、そして堅牢化を済ませてください — 鍵認証のみのSSH、デフォルト拒否のファイアウォール、無人でのセキュリティ更新です。/guides に、このチェックリストの1時間版があります。
- ランタイムとデータベースは、本番環境と同じメジャーバージョンをインストールしてください。移行のついでにPostgreSQLを14から17にアップグレードするのは悪いタイミングです — 一度に1つずつ変更し、何か失敗したときの原因が必ず1つに絞れるようにしてください。
- ファイルをコピーする前に、同じ数値IDでユーザーとグループを再作成しておくか、後から手作業で所有者を修正してください。--numeric-idsを付けて転送すれば数値はそのまま保たれますが、それを正しい名前に対応づけ直すのは自分の仕事です。
- 現在古いアドレスを名指ししているすべてのallowlist — パートナーのAPI、マネージド型データベースのファイアウォール、決済ゲートウェイ、自分自身の監視システム — に、両方のアドレスがまだ有効なうちに新しいアドレスを追加しておいてください。
サービスをインストールしたら、停止させて無効化しておいてください。起動時に立ち上がり新しいアドレスで応答するWebサーバーは、スキャナーに発見され、間違ったホスト名でインデックスされ — さらに悪いことに — 早期に名前解決してしまった誰に対しても、中途半端にしか揃っていないサイトのコピーを喜んで返してしまいます。新しいマシン上の何ものも、自分がそう決めるまでは公に応答すべきではありません。
ファイルは2回に分けてコピーする
稼働中のファイルシステムを1回だけ転送しても、それは動いている的を捉えたスナップショットにすぎません。2回に分ければきれいに解決できます — 1回目は時間がかかり、稼働中のシステムに対して実行し、2回目は短く、凍結期間中に実行します。速さが求められるのは2回目だけです。
1回目は好きなタイミングで実行して構いません — 数日前でも問題ありません。これが大半を運びます。アップロードディレクトリ、メールスプール、コンテナボリューム、何年分も溜まったメディアファイルなどです。切り替えの時点では古くなっていますが、それこそがまさに2回目のパスの役目です。
- SSH経由で rsync -aAXH --numeric-ids --info=progress2 を使ってください。-a は通常の属性、-A はACL、-X は拡張属性、-H はハードリンク用で、マシン上に重複排除を行っているものがあるなら重要になります。
- 移動させるべきでないものは除外してください — /proc、/sys、/dev、/run、一時ディレクトリ群、不要なパッケージキャッシュやログです。カーネルのインターフェースをコピーしても、良くて時間の無駄、悪ければ転送がそのまま止まってしまいます。
- --deleteは2回目のパスにだけ付けてください。1回目に付けても害はありませんが、2回目に付けることで、それ以降にコピー元で削除されたファイルが取り除かれます。これはまさに、あなたが取り除こうとしているずれそのものです。
- システム設定は丸ごとではなく、選択的にコピーしてください。欲しいのはWebサーバーのvhost設定、サービスのunitファイル、アプリケーションの設定であって、古いマシンのファイルシステムテーブルやネットワーク設定、マシンIDではありません。
- 転送用に使い捨てのSSH鍵を生成し、移行先で認可し、移行が終わったら削除してください。2年間も残り続ける移行用の鍵は、誰も発行したことを覚えていない認証情報になってしまいます。
パスとパスの間では、推測せずに検証してください。2回目のパスを--dry-run付きで実行すれば、実際に変更される内容がそのまま表示されます。数百件程度の最近のファイルが並ぶなら健全ですが、4万件も並ぶなら、除外設定が間違っているか、何かが理由もなくタイムスタンプを書き換えています。
書き込みを失わずにデータベースを移行する
ここが、凍結時間の予算を使う場面です。正しい手法は、最初に書き出した数字によって完全に決まります。以下の3つの選択肢はいずれも正しく — ただし、それぞれ異なる数字に対して正しいのです。
どれを選ぶにせよ、新しいデータベースが書き込みを受け付け始める前に、古いデータベースは書き込みの受け付けを止めていなければなりません。少し後にではなく、その前にです。両方が書き込み可能な状態になる重複期間はスプリットブレイン状態であり、この記事全体を通じて唯一、きれいな回復方法が存在しない失敗です。2つに分岐した履歴を、行を手作業で読み比べることなく統合する方法はありません。
データセットが大きい場合は、スキーマとデータを分けてダンプしてください。先にスキーマを復元しておけば、新しいホスト上で構造、インデックス、権限を早い段階で検証でき、データの読み込みは、凍結期間中に安心して開始できる、単一の長い作業へと変わります。
TLS証明書は切り替えの後ではなく、前に発行する
新しいサーバー上の証明書は、最初のユーザーが到達した瞬間に有効でなければなりません。そうなっていないと気づいたときには、すべての訪問者がブラウザの警告画面に直面しており、HSTSヘッダーを送信している場合(送信すべきです)、彼らはそれをクリックで突破することすらできません。DNSがまだどこも新しい場所を指していない段階で、機能する証明書を手にしておく方法は2つあります。
- 既存の証明書をコピーする方法です。ACMEの状態ディレクトリをまるごとコピーするか、クライアントが保存している場所から証明書と鍵だけをコピーします。有効性はどのサーバーがそのファイルを保持しているかとは無関係なので、即座に有効になり、DNSが移行した後は更新も通常どおり再開されます。
- DNS-01チャレンジで新規に発行する方法です。現在のアドレスへのHTTPリクエストの代わりに、TXTレコードによってドメインの制御権を証明します。これは移行前でも、切り替え前でも機能し、HTTP-01ではまったく対応できないワイルドカード証明書にも使えます。
- 切り替え前に、新しいサーバー上でHTTP-01の検証を試みないでください。チャレンジはドメイン名のポート80経由で取得されますが、ドメインはまだ古いマシンを指しているため、検証は毎回失敗します。
DNSには触れずに、1つのコマンドだけホスト名を新しいアドレスに解決させることで検証できます — curl -sI --resolve yourdomain.com:443:198.51.100.10 https://yourdomain.com/ (実際のアドレスに置き換えてください)。この1行こそが、移行全体の中で最も価値の高い確認作業です。新しいマシン上の実際のvhost、実際の証明書、実際のアプリケーションスタックをそのまま動かすことになり、しかもまだ何のコストもかからないうちに設定ミスを発見できます。
サーバーがメールを送信するなら、もっと早く始める
メールは、移行の中でも数日後になって静かに失敗し、別の何かのせいにされてしまう部分です。新しいアドレスには送信元としての評判がまだなく、他人の評判を引き継いでいる可能性すらあります。そして公開する認証レコードはどれも、今まさに離れようとしているアドレスに結びついています。
- 新しいアドレスを本採用する前に、主要なブロックリストと照合してください。過去の履歴を持つ使い回しのIPは、無料で交換できるうちに交換しておく価値があります。
- 新しいアドレスの逆引きDNSレコードを、メールのホスト名に設定してください。受信側のサーバーは正引きと逆引きが一致しているかを確認しており、PTRが欠けているだけでもスパム判定を受けるのに十分です。
- 切り替え前にSPFへ新しいアドレスを追加し、その後で古いアドレスを削除してください — 重複期間中は両方を記載しておくことで、実際に送信したのがどちらのサーバーであってもメールが認証されます。
- DKIMの秘密鍵は新規に生成するのではなくコピーしてください。そうすることで、すでにDNSに公開されているセレクタがそのまま検証に通り続けます。再生成は再公開を意味し、再公開にはそれ自体の伝播遅延が伴います。
- ある程度の量を送信するなら、新しいアドレスは段階的にウォームアップしてください。存在してから一度も送信したことのないサーバーが、突然1万通のメッセージを送り始めれば、受信側からは侵害されたホストと見分けがつきません。
切り替え作業
ここまでのすべては、この部分を短く、秩序立てて、そして元に戻せるものにするための準備でした。験担ぎで午前3時に行うのではなく、実際のトラフィックが最も少ない時間帯に行ってください — 自分のアクセス解析を確認しましょう。ロールバック手順は始める前に書き出しておいてください。それが必要になる瞬間こそ、最もそれを書きたくない瞬間だからです。
- 1
古いサーバーの書き込みを凍結する
メンテナンスモード、読み取り専用のデータベースユーザー、あるいはリバースプロキシで書き込み経路にエラーを返す方法があります。この間ずっと読み取りは古いマシンから提供され続けます — これによって、データが移動している間もサイトは稼働し続けます。
- 2
古いサーバー上のすべてのタイマーを無効化する
crontabをコメントアウトし、タイマーを止め、キューワーカーを止めてください。この時点から、古いマシンは何も処理してはいけません。さもないとジョブが二重に実行されます — 請求書が2通、メールが2通、webhookの配信が2回です。
- 3
最終の差分を実行する
--deleteを付けた2回目のファイルパスを実行し、続いて最終的なデータベースダンプ、またはレプリカの追いつき処理を行います。1回目のパスですでに大部分を移動させてあるため、これは短時間、長くても数分で終わります。
- 4
新しいサーバーを、実際のホスト名で検証する
前述の --resolve を使ったテクニックで、データベースから読み取るページ、ログイン、そして1つの書き込み経路を実際に動かしてみてください。行数がコピー元と一致することを確認します。これらはすべて、ロールバックにまだ何のコストもかからない、DNS変更前の段階で行ってください。
- 5
DNSを切り替え、サービスを起動する
AレコードとAAAAレコードを新しいアドレスに更新し、続いて新しいサーバー上でアプリケーションとそのタイマーを有効化して起動してください。トラフィックはTTL1回分の時間内に届き始め、その後1時間ほどかけて移り変わっていきます。
- 6
古いサーバーには読み取りの提供を続けさせる
少なくとも24時間は、読み取り専用のまま稼働させ続けてください。キャッシュが古いままのクライアントは引き続きそこに到達しますが、読み取り専用の古いサーバーは接続拒否の代わりに多少古びたページを返します — これが、目に見えない移行と目に見える移行の違いです。
この重複期間には、最もきれいなテクニックも潜んでいます。DNSを一気に切り替える代わりに、ステップ5の最後で古いサーバーを新しいサーバーへのリバースプロキシとして再設定するのです。まだ古いアドレスに名前解決してしまう遅れたクライアントもすべて透過的に転送され、切り替え作業はDNSの伝播に一切依存しなくなり、そこへのトラフィックがゼロになった時点でプロキシを撤去すればよくなります。ログやレート制限が実際のクライアントアドレスを見られるよう、X-Forwarded-For を渡すようにしてください。
最初の48時間
サイトが表示されたからといって、移行が終わったわけではありません。終わったと言えるのは、もはや何も古いマシンに依存していない状態になったときです。そしてその依存関係を見つけ出す作業は、ただ待っているだけでは済まない、能動的な取り組みです。
- 古いサーバーのアクセスログを監視してください。そこにまだ届いているリクエストは1件残らず、移行し切れていない依存関係です — パートナー連携にハードコードされたアドレス、キャッシュが古いままのモバイルクライアント、誰の管理下にもない監視プローブなどです。ログこそがやるべきことのリストです。
- 新しいホスト上でタイマーが実際に実行されたことを確認してください。有効になっているというだけでなく、想定した時刻に、想定した出力とともに実行されたということをです。何もせず静かに終わるcronジョブは、正常に機能しているcronジョブとまったく見分けがつきません。
- 証明書の更新は、実際にドライランでテストしてください。60日後になって、ACMEクライアントがもはやチャレンジを受け取れなくなったサーバーに対して更新を試み続けていたと気づくのでは遅すぎます。
- アプリケーションが自動的に送信するものも含め、メールの流れを双方向でエンドツーエンドに確認してください。パスワードリセットは典型的な犠牲者です。ユーザーが実際に必要とするまで、誰もテストしないからです。
- 新しいサーバーのバックアップを取得し、どこかに復元してみてください。検証済みのバックアップを持たない新しいマシンは、あなたが去ってきた場所よりも悪い立場にあります。/guides にこの主張の詳しい説明があります。
- 確信が持てたら、DNSのTTLを通常の値に戻してください。300秒のまま永久に放置すると、もはや何の利益も残っていないのに、クエリ数とレイテンシの面でわずかながら恒久的なコストを払い続けることになります。
古いサーバーを廃止する
最後のこのステップこそが省かれがちであり、しかもプライバシー上の影響を持つ唯一のステップです。古いディスクには鍵、データベース、顧客データ、ログが残ったままであり、サービスを解約してもそれらは何も消去されません。ボリュームはプールに返却されるだけで、次のテナントは、プロバイダーの消去ポリシーが取りこぼしたものを何であれ受け取ることになります。
- 何かに手を付ける前に、古いアクセスログが静かになるのを待ってください。決済プロバイダーがまだ古いアドレスへwebhookを送り続けている最中に解約してしまうと、1週間後に移行がインシデントへと変わってしまいます。
- 単に削除するのではなく、ローテーションしてください — APIキー、データベースのパスワード、デプロイキー、一時的な移行用の鍵など、古いサーバーが保持していたすべての認証情報です。もはや自分の管理下にないマシン上に存在していたものは、いずれ侵害されるものだと見なしてください。実際、いずれそうなります。
- ボリュームを解放する前にデータを上書きしてください。機密性の高いディレクトリをシュレッダーにかけるか、空き容量を1つの大きなランダムファイルで埋めてから削除します。仮想化されたディスクでは完璧にはなりませんが、何もしないよりははるかにましです。
- 参考のために残しておきたいもの — ログ、設定、実際に行った作業を記録したシェル履歴など — の最終アーカイブを作成し、どちらのサーバーでもないどこかに暗号化して保管してください。
- サービスの解約は、新しいサーバーが1回分の請求サイクルと、バックアップと復元のテストを一通り無事に乗り越えてから行ってください。この重複する1か月分こそが、この工程全体の中で最も安い保険です。
そのまま使えるタイムライン
ここに挙げたことは、それぞれ単独では何も難しくありません。移行がうまくいかなくなるのは、TTLがまだ失効しておらず、証明書もテストされておらず、ロールバックも書かれていない状態のまま、すべての手順が一晩に圧縮されてしまうからです。1週間に分散させれば、1日あたり20分の作業で済みます。
移行が実際に失敗する理由
コピーそのものが原因になることはありません。原因になるのは、ディスクの中に一度も存在しなかったものと、二重に実行されてしまったものです。
- 両方のサーバーが同時に書き込みを行うこと — スプリットブレイン状態であり、ここに挙げた中で唯一きれいな修正方法がない失敗です。これを防ぐのはツールではなく順序です。古い方を止めてから、新しい方を起動してください。
- 両方のマシンでタイマーが動いてしまうこと。これが、顧客があらゆるものを2通ずつ受け取ってしまう原因です。古いタイマーは、最終同期の後ではなく前に無効化してください。
- 一度も下げられなかったTTL。これにより、5分で終わるはずだった切り替えが、誰も人員を配置する計画をしていなかった1日がかりの尾を引く作業に変わってしまいます。
- マシン間で数値IDが異なるためにファイルの所有者がずれてしまい、アプリケーションは起動するものの、自分自身のアップロードディレクトリに書き込めなくなること。
- 切り替え後に何とかするつもりだった証明書が、訪問者に先へ進む手段を一切残さないHSTSヘッダーと鉢合わせしてしまうこと。
- 自分の管理が及ばないどこかにハードコードされたアドレス — パートナー連携、ファイアウォールルール、存在すら忘れていたサブドメインのDNSレコードなどです。
- 移行当日に古いサーバーを解約してしまうこと。統計的に最もそれが必要になりやすいまさにその瞬間に、ロールバックの手段を失うことになります。
VPSの移行にはどのくらいの時間がかかりますか。
作業量としては、1週間に分散させた数時間が一般的で、ユーザーの目に見える部分は数分程度です。大部分の転送とTTLの短縮は、すべてが稼働したままの状態で数日前に済ませておきます。切り替え作業そのものは、最後の差分同期、DNS変更、そして検証作業です。数ギガバイトのデータとそこそこの規模のデータベースを持つサイトであれば、30分程度の切り替え作業で十分収まり、凍結時間は1桁分の分数に収まります。
ダウンタイムをまったくゼロにして移行することはできますか。
読み取りについては可能です — DNSが切り替わるまでは古いサーバーが応答を続け、その後リバースプロキシに切り替えれば、伝播の尾すら取り除けます。書き込みはより難しいケースです。何も失われないことを保証する最も簡単な方法は短い凍結時間を設けることであり、レプリケーションを使えばその凍結時間を数秒まで縮められます。書き込みを本当にゼロ凍結にするには、重複期間中にアプリケーションが両方のデータベースへ書き込む必要があり、これは実現可能ではあるものの、ほとんどのサイトには不要な失敗モードを追加することになります。
ディスクを複製すべきですか、それともサーバーを再構築すべきですか。
再構築してください。複製は、設定のずれ、放置されたパッケージ、そして過去の侵害が残していった痕跡まで運んでしまい、古いディストリビューションのリリースに縛られたままになります。スクリプトからインストールし、データだけをコピーすれば、クリーンなマシンと再現可能な手順の両方が手に入ります — これが、次回の再構築を速くするものでもあります。
IPアドレスと検索順位はどうなりますか。
アドレスは変わりますが、ドメインは変わりません。そしてリンクも、検索順位も、履歴もドメインに紐づいています。URLを同一に保ち、重複期間中はクローラーが接続エラーを目にすることのないよう古いサーバーに応答させ続ければ、この変更は検索エンジンから見て事実上見えないものになります。国をまたいだ移行はレイテンシに敏感な指標を多少動かすことがあるため、/locations で実際のユーザー層に近いリージョンを選んでください。
データを失わずにデータベースを移行するにはどうすればよいですか。
移行先で書き込みを始める前に、移行元の書き込みを止めてください — この順序こそが保証のすべてです。小規模なデータセットであれば、凍結し、pg_dump または mysqldump --single-transaction でダンプを取り、復元し、切り替えます。より大規模なデータセットであれば、事前にレプリケーションを組んでおき、切り替え時にレプリカを昇格させることで、追いつき処理を数秒で済ませます。トラフィックを送る前に、重要なテーブルの行数を比較して検証してください。
身元を明かすことなく、オフショアホストへ移行することはできますか。
できます。暗号資産残高から課金するホストには、マシンに紐づけるカードも請求先住所も存在しないため、サーバーの背後にあるアカウントにはあなたに関する情報が何も残りません。移行作業そのものは技術的にはまったく同じです — 同じファイルパス、同じダンプ、同じDNS切り替えです。/offshore-vps ではこの仕組みがどう機能するかを、/pay-with では支払い面を扱っています。
古いサーバーを解約しても安全なのはいつですか。
アクセスログが少なくとも1日静かな状態になり、保持していたすべての認証情報をローテーションし、新しいサーバーのバックアップを取得してどこかへの復元に成功した後です。小さなVPSをもう1か月分だけ余分に維持することは、この工程の中で最も安い保険です — それが、ロールバックで済むか、インシデントになるかの分かれ目です。
