之前個人認為可能的主機災難有兩種：
- 區域性的問題。可能是地震電纜斷了、機房失火 (hinet)、廠商被 hacker 攻擊 (directspace 一週沒辦法用)，或者主機商說要重開機(像aws ec2)。總之就是東京機房沒辦法使用的時候，那就要在美國重架個VPS。
- 系統毀損。可能是系統更新之後就掛了，或是系統不明原因就掛掉(這應該都蠻常見的)。
我「那時」的解決方案就是把大量的圖檔放在 aws s3 上面。反正放在雲端，如果真有什麼意外的話，aws s3 放著不會跑掉，用 vps 安裝系統15分鐘，資料庫也有辦法用 15 分鐘傳完(以我家超慢ADSL來上傳的話)，一切都很美好...
用了 s3 之後，安裝系統都很順利，要換主機只要把幾百MB的資料庫帶著走就好。不過後來心理總覺得毛毛的，假如我 aws s3 的帳號被駭了怎麼辦？ 把檔案傳到 s3 需要花24小時，整個砍掉只需要三分鐘。備份非常的困難，如果單純用 s3cmd 的 sync 指令，檢查有沒有新的檔案，卻需要 1.5 小時。
因為 linode 的頻寬變超大，於是就決定自己架設一個s3 liked 的服務：
- 自己架設一台機器 (或放在其它機器中也是可以的)，只安裝 nginx ，單純做 webservice ，然後把 /_.* 給擋掉，來放置不公開的檔案。
- 新刪修都用 ssh 的指令，主機之間設定 authorized_keys2，就不需要密碼了。
- 設定公開 domain ，如果要換主機就換 ip 吧
其實程式一整個比aws 的 sdk 精簡多了，以下就是我在用的程式：
--
--
比較麻煩就是在安裝的部份，主機之間的 .ssh/id_rsa 和 .sshauthorized_keys2 要互通，權限記得設 600，也別忘了小心保管那組 key 。再來是安裝時我通常也會習慣在 .ssh/config 中設
Host *.example.com
StrictHostKeyChecking no
並且把 .ssh/know_hosts 給砍了。
這樣換主機或是在第一次連線時，不會跳出來yes/no的選項
我習慣是會寫一個安裝的script來做這些事情。
好處很多，像是 rsync 備份超容易，檢查新檔案用 s3 需要 1.5hr，rsync只要 15 秒鐘。可以使用 shell 來操作，做什麼都容易。
