入門 バックアップ

Transcript

1. 1 ⼊⾨ バックアップ ~ データ保護の基礎から実践まで ~ 渡部 ⿓⼀ YAPC::Hakodate 2024 前夜祭 2024/10/04
2. 2 アジェンダ 1. 自己紹介 2. イントロダクション 3. バックアップの入門 4. バックアップの実践例 5. まとめ
3. 3 ⾃⼰紹介
4. 技術部プラットフォームグループ 2021年 中途入社 4 自己紹介 渡部 龍一 Watanabe Ryuichi • ロール: SRE • 仙台から来ました。北海道は3ヶ月ぶり3回目 • SNS: @ryuichi_1208 • 好きなPerlモジュール: AnyEvent
6. 6 イントロダクション
7. 7 イントロダクション “バックアップやってますか？”
8. 8 • スマホのバックアップ ◦ PC等に連絡先や写真データをバックアップ、アプリが⾃動でサーバに送信 • ⾃宅NASのバックアップ ◦ クラウドにデータのバックアップ • ゲームデータのバックアップ ◦ クラウドセーブ機能 ⽇常⽣活でのバックアップ
9. 9 “バックアップはなぜ必要なのか”
10. 10 “バックアップがないと”
11. 11 • 通常の業務では特に⽀障は出ない • バックアップがない機器‧システムで何かしらの障害が起きデータが使えなくなると バックアップがないと
13. 13 • 仕事での影響 ◦ 顧客情報、取引記録という業務運営に不可⽋なデータの消失は、業務停⽌や経済的損失、 法的リスクを招く可能性 ◦ データベースやシステム設定の消失により、システムやサービスの再構築が必要になるこ とも • 個⼈レベルの影響 ◦ 写真や動画、連絡先かけがえのない思い出や重要な情報が消失... データロスト
14. 14 https://www.publickey1.jp/blog/17/gitlabcom56.html
15. 15 “バックアップを取ろう！”
16. 16 バックアップ⼊⾨
17. 17 • 定期的に全部のデータを1からどこかしらにコピーをすればバックアップは実現できる • 数MBとかなら短時間で終わるが数TBとか当たり前の時代 • ⾼速なストレージに⾼速なネットワークを⽤意してバックアップを取るとコストが嵩む • バックアップの⽅法にも複数の種類がありメリット‧デメリットがある • バックアップ設計が⼤事 バックアップの実現
18. 18 • バックアップの⽬的決め • サービスレベルの決定(RPO/RTO) • リカバリテストについて • 実装⽅法 • セキュリティ バックアップ設計で考えること
19. 19 • 災害復旧（DR） ◦ ⼤規模な災害が発⽣した場合に、事業を継続するために必要なデータを保護し、復旧 することを⽬的とする • 法規制への対応 ◦ 法律で定められたデータ保存期間や形式を守ることを⽬的とする バックアップの⽬的決め
20. 20 • RPO（Recovery Point Objective） ◦ ⽬標復旧時点 ◦ 例) 1時間前のデータまで復元できれば問題ない場合、RPOは1時間となる ▪ RPOを1秒としたら、障害発⽣の1秒前までのデータを復旧できることを意味する • RTO（Recovery Time Objective） ◦ ⽬標復旧時間 ◦ 例) 4時間以内にシステムを復旧させたい場合、RTOは4時間となる サービスレベルの決定(RPO/RTO)
21. 21 サービスレベルの決定(RPO/RTO) 障害発生前のデータ RPO RTO 障害復旧
22. 22 • リストアテストの重要性 ◦ バックアップデータが実際に使えるかどうかを確認するため、定期的な リストアテストが必要 ◦ テストを⾏わないと、バックアップが不完全だったり、リストア⼿順が誤っているこ とに気づかない可能性がある(あった) リストアテストの⽅針決め
23. 23 • フルリカバリテスト ◦ 実際にバックアップから全てのシステムを復旧し、動作確認を⾏うテスト • シミュレーションテスト ◦ 実際のリストアを⾏わず、⼿順やツールの動作確認をシミュレーションします ◦ ⼿順書の精査やスタッフのトレーニングに有効です リストアテスト
24. 24 リストアテスト https://tech.pepabo.com/2023/06/09/db-restore-test/
25. 25 • データの暗号化 ◦ バックアップデータを保存する際に、データの暗号化を⾏い、不正アクセスや情報漏 洩のリスクを低減 • アクセス制御 ◦ バックアップデータへのアクセス権限を厳密に管理し、特定のユーザーやシステム管 理者のみが操作できるように設定 • バックアップデータの保管ポリシー ◦ 保管期間やデータの廃棄⽅法を定めたポリシーを策定し、法的要件やセキュリティ基 準に従って適切に管理 セキュリティ
26. 26 • 決まった時間に全てのデータをバックアップするだけなら単純 • 100TBとかになると毎回全部バックアップは時間がかかりすぎる • 他のバックアップ⼿法が必要となる ◦ フルバックアップ ◦ 差分バックアップ ◦ 増分バックアップ • バックアップを取るサーバを⽌めて取るのか稼働させつつ取るのか ◦ ホットバックアップ ◦ コールドバックアップ 実装⽅法
27. 27 実装⽅法: フルバックアップ 10/01 10/02 10/03 10/04 データ量 時間軸
28. 28 実装⽅法: 増分バックアップ 10/01 10/02 10/03 10/04 データ量 時間軸
29. 29 実装⽅法: 差分バックアップ 10/01 10/02 10/03 10/04 データ量 時間軸
30. 30 メリット‧デメリット フルバックアップ 増分バックアップ 差分バックアップ バックアップ時間 ⻑い 普通 短い リストアにかかる時間 短い 普通 ⻑い バックアップサイズ ⼤きい 普通 ⼩さい
31. 31 • コールドバックアップ(オフラインバックアップ) ◦ バックアップする対象のシステムを⽌めてからバックアップするやり⽅ ◦ 夜間に⽌めれるサービスとかだとこの⼿法が取れる • ホットバックアップ(オンラインバックアップ) ◦ バックアップする対象のシステムを動かしたままバックアップするやり⽅ ◦ 静⽌点を取らないとバックアップ中にユーザーがデータを書き換えたら不整合が起き 得てしまう コールドバックアップ‧ホットバックアップ
32. 32 • 復旧時間を短くするには⾼性能なディスクやネットワークを⽤意しておく • それをするにはそれ相応のコストがかかる • コストとのトレードオフにはなるのでサービスレベルを決めて設計/運⽤していくのが⼤事 設計での⼤事な点
33. 33 バックアップの実践例
34. 34 • コンテンツサーバ(画像、動画データ、WordPress)とデータベースを取り上げます • クラウドサービスなんかだとファイルを置いた時点で複数DCにファイルが置かれる • オンプレミスでサービス運⽤をする上でのバックアップの話 バックアップの実践例
35. 35 • ユーザーがHTTPを使ってサーバに対してコンテンツをアップロード コンテンツサーバ
36. 36 • 別のサーバにデータをバックアップ • rsyncがよく使われる ◦ ⾼速で効率的かつ豊富な機能を使ったデータ転送 ▪ ブロック分割されたデータのハッシュ値の⽐較により差分検知 ▪ フルバックアップ/差分バックアップ/増分バックアップ ◦ SSHを通じたセキュアな通信 コンテンツサーバ
37. 37 • rsyncだけでは静⽌点を取れない ◦ データコピー開始時のデータをユーザーが更新した場合は更新したデータのバック アップが取れる ▪ rsyncはブロック単位でコピーをする ▪ flock(1)を使ってロックを取ってコピーすることが必要 • 同⼀コンテンツの更新が⾛らないような特性なら無視できる ◦ 写真Aをアップロードしたら同⼀の名前で違うコンテンツを上げるケースが少ない コンテンツサーバ
38. 38 • rsyncの実⾏でページキャッシュが汚れる ◦ ファイルI/Oを最適化するために、ファイルのページをキャッシュする仕組み ◦ rsyncでデータをコピーする際にファイルを読み取るとそれがページキャッシュに乗っ てしまう問題 ◦ 前段にCDNとかNginxとかいればそこでいい感じになるが • Feh/nocache ◦ rsyncでデータをコピーする際にそのファイルをページキャッシュに乗せない ◦ ファイル操作のシステムコールをラップしてPOSIX_FADV_DONTNEEDを設定 コンテンツサーバ
39. 39 “データベースの場合”
40. 40 • データベースのRPOは重要 • フルバックアップの間隔 = RPOになるのが許容できるケースは少ない ◦ トランザクションを頻繁に⾏うシステムでは、データ損失を最⼩限に抑えるために RPOが短く設定されることが多い ◦ 任意の時間や特定のクエリの直前の状態に戻せるようにしたい • Point-in-time recovery(PITR) ◦ フルバックアップ -> トランザクションログを適⽤して任意の時間にロールフォワード データベース
41. 41 データベース: PITR ② 障害発生前のデータでリストア ① 障害発 生 ③ トランザクションログの適用
42. 42 • フルバックアップ ◦ コールドバックアップ‧ホットバックアップに対応 ◦ コールドバックアップ ▪ 特定ディレクトリ配下をコピーすることでバックアップ ◦ ホットバックアップ ▪ ディレクトリ配下をコピーするだけではリストアすることはできない • WAL、トランザクション管理、リカバリがありRDBでは難しいはず..?? • MyISAMなら書き込みがない状態ならホットバックアップ データベース: MySQL(InnoDB)の例
43. 43 • PITR ◦ バイナリログをリストアしたDBに当てることでロールフォワードが可能 ▪ テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述 データベース: MySQLの例
44. 44 • 論理バックアップ ◦ データベースの内容をSQL形式でエクスポートする⽅法 ◦ mysqldumpやmysqlshellといったツールを使ってバックアップを取得 • 物理バックアップ ◦ データベースのデータファイルをそのままコピーする⽅法 ◦ ディスク上のMySQLデータファイルを直接バックアップするため、より⾼速にバック アップ‧リストアができる ▪ Percona XtraBackupのようなツールを使う データベース: MySQLの例
45. 45 • 静⽌点 ◦ オンラインでフルバックアップはできないんじゃないの？ ◦ mysqldumpでは静⽌点を取ってトランザクションのIsolationを活かして取得する ▪ 1. 読み取りロック ▪ 2. トランザクションの開始 ▪ 3. テーブルのデータをSELECTで取得 ▪ 4. トランザクションの終了 ◦ RRで実⾏することで最初のSELECT以降も同様のスナップショットを⾒るようになる データベース: MySQLの例
46. 46 (コラム) MySQLのレプリカはバックアップになるのか • バックアップ代わりにレプリカを⽤意するみたいなことを聞いたことがある • バックアップ≠レプリカ ◦ プライマリで誤ったdropをしたらレプリカでも即drop ◦ リストアすることは難しい
47. 47 データベース https://ryuichi1208.hateblo.jp/entry/2023/12/09/175134
48. 48 まとめ
49. 49 • バックアップ戦略は、企業の規模やシステムの重要度、データ特性などによって異なる • 適切なバックアップ戦略を策定し、定期的に⾒直すことで、データの安全性を確保し、事業継 続性を⾼めていくのが重要 • 「本当に必要なときにないのがバックアップ」とならないようにしていきましょう まとめ
50. 50 よいバックアップライフを！
51. 51 参考書籍など
52. 52 • 運⽤設計の教科書 / 技術評論社 • インフラエンジニアの教科書 • 絵で⾒てわかるITインフラの仕組み • インフラ設計のセオリー • 基礎から学ぶ新しいストレージ⼊⾨ • MySQL 運⽤‧管理 実践⼊⾨ 参考書籍など
53. 53 (コラム) スナップショットはバックアップなのか？ • スナップショット ◦ ストレージやファイルシステム、仮想マシン（VM）の特定時点の状態を記録する技術 • 短期的なデータ保護や変更前の状態に迅速に戻すために使⽤ • スナップショットをバックアップ的に使うことはできる • スナップショット ≠ バックアップというのが個⼈的な意⾒