Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
入門 バックアップ
Search
ryuichi1208
October 04, 2024
Technology
22
10k
入門 バックアップ
ryuichi1208
October 04, 2024
Tweet
Share
More Decks by ryuichi1208
See All by ryuichi1208
AI前提のサービス運用について再考する
ryuichi1208
6
1.3k
A Shallow Dive into the World of TCP
ryuichi1208
1
580
入門リトライ
ryuichi1208
19
7.3k
超入門SRE 2025
ryuichi1208
4
1.4k
Goで作って学ぶWebSocket
ryuichi1208
5
3.8k
コード化されていない稼働中のサーバを移設_再構築する技術
ryuichi1208
20
14k
AI前提のサービス運用ってなんだろう?
ryuichi1208
9
1.9k
効果的なオンコール対応と障害対応
ryuichi1208
9
3.9k
コロナ禍とその後:地方エンジニアが学んだキャリア戦略の変遷
ryuichi1208
6
520
Other Decks in Technology
See All in Technology
Kubernetes における cgroup v2 でのOut-Of-Memory 問題の解決
pfn
PRO
0
470
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
3
470
2025年夏 コーディングエージェントを統べる者
nwiizo
0
110
今!ソフトウェアエンジニアがハードウェアに手を出すには
mackee
11
4.4k
[RSJ25] Feasible RAG: Hierarchical Multimodal Retrieval with Feasibility-Aware Embodied Memory for Mobile Manipulation
keio_smilab
PRO
0
120
AI駆動開発に向けた新しいエンジニアマインドセット
kazue
0
280
BPaaSにおける人と協働する前提のAIエージェント-AWS登壇資料
kentarofujii
0
120
Obsidian応用活用術
onikun94
1
420
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
3
490
Automating Web Accessibility Testing with AI Agents
maminami373
0
1.1k
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
2
150
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
2
150
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
800
Done Done
chrislema
185
16k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
31
2.2k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
Bash Introduction
62gerente
615
210k
GraphQLとの向き合い方2022年版
quramy
49
14k
KATA
mclloyd
32
14k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3k
A better future with KSS
kneath
239
17k
Why Our Code Smells
bkeepers
PRO
339
57k
Transcript
1 ⼊⾨ バックアップ ~ データ保護の基礎から実践まで ~ 渡部 ⿓⼀ YAPC::Hakodate 2024
前夜祭 2024/10/04
2 アジェンダ 1. 自己紹介 2. イントロダクション 3. バックアップの入門 4. バックアップの実践例
5. まとめ
3 ⾃⼰紹介
技術部プラットフォームグループ 2021年 中途入社 4 自己紹介 渡部 龍一 Watanabe Ryuichi •
ロール: SRE • 仙台から来ました。北海道は3ヶ月ぶり3回目 • SNS: @ryuichi_1208 • 好きなPerlモジュール: AnyEvent
5
6 イントロダクション
7 イントロダクション “バックアップやってますか?”
8 • スマホのバックアップ ◦ PC等に連絡先や写真データをバックアップ、アプリが⾃動でサーバに送信 • ⾃宅NASのバックアップ ◦ クラウドにデータのバックアップ •
ゲームデータのバックアップ ◦ クラウドセーブ機能 ⽇常⽣活でのバックアップ
9 “バックアップはなぜ必要なのか”
10 “バックアップがないと”
11 • 通常の業務では特に⽀障は出ない • バックアップがない機器‧システムで何かしらの障害が起きデータが使えなくなると バックアップがないと
12
13 • 仕事での影響 ◦ 顧客情報、取引記録という業務運営に不可⽋なデータの消失は、業務停⽌や経済的損失、 法的リスクを招く可能性 ◦ データベースやシステム設定の消失により、システムやサービスの再構築が必要になるこ とも •
個⼈レベルの影響 ◦ 写真や動画、連絡先かけがえのない思い出や重要な情報が消失... データロスト
14 https://www.publickey1.jp/blog/17/gitlabcom56.html
15 “バックアップを取ろう!”
16 バックアップ⼊⾨
17 • 定期的に全部のデータを1からどこかしらにコピーをすればバックアップは実現できる • 数MBとかなら短時間で終わるが数TBとか当たり前の時代 • ⾼速なストレージに⾼速なネットワークを⽤意してバックアップを取るとコストが嵩む • バックアップの⽅法にも複数の種類がありメリット‧デメリットがある •
バックアップ設計が⼤事 バックアップの実現
18 • バックアップの⽬的決め • サービスレベルの決定(RPO/RTO) • リカバリテストについて • 実装⽅法 •
セキュリティ バックアップ設計で考えること
19 • 災害復旧(DR) ◦ ⼤規模な災害が発⽣した場合に、事業を継続するために必要なデータを保護し、復旧 することを⽬的とする • 法規制への対応 ◦ 法律で定められたデータ保存期間や形式を守ることを⽬的とする
バックアップの⽬的決め
20 • RPO(Recovery Point Objective) ◦ ⽬標復旧時点 ◦ 例) 1時間前のデータまで復元できれば問題ない場合、RPOは1時間となる
▪ RPOを1秒としたら、障害発⽣の1秒前までのデータを復旧できることを意味する • RTO(Recovery Time Objective) ◦ ⽬標復旧時間 ◦ 例) 4時間以内にシステムを復旧させたい場合、RTOは4時間となる サービスレベルの決定(RPO/RTO)
21 サービスレベルの決定(RPO/RTO) 障害発生前のデータ RPO RTO 障害復旧
22 • リストアテストの重要性 ◦ バックアップデータが実際に使えるかどうかを確認するため、定期的な リストアテストが必要 ◦ テストを⾏わないと、バックアップが不完全だったり、リストア⼿順が誤っているこ とに気づかない可能性がある(あった) リストアテストの⽅針決め
23 • フルリカバリテスト ◦ 実際にバックアップから全てのシステムを復旧し、動作確認を⾏うテスト • シミュレーションテスト ◦ 実際のリストアを⾏わず、⼿順やツールの動作確認をシミュレーションします ◦
⼿順書の精査やスタッフのトレーニングに有効です リストアテスト
24 リストアテスト https://tech.pepabo.com/2023/06/09/db-restore-test/
25 • データの暗号化 ◦ バックアップデータを保存する際に、データの暗号化を⾏い、不正アクセスや情報漏 洩のリスクを低減 • アクセス制御 ◦ バックアップデータへのアクセス権限を厳密に管理し、特定のユーザーやシステム管
理者のみが操作できるように設定 • バックアップデータの保管ポリシー ◦ 保管期間やデータの廃棄⽅法を定めたポリシーを策定し、法的要件やセキュリティ基 準に従って適切に管理 セキュリティ
26 • 決まった時間に全てのデータをバックアップするだけなら単純 • 100TBとかになると毎回全部バックアップは時間がかかりすぎる • 他のバックアップ⼿法が必要となる ◦ フルバックアップ ◦
差分バックアップ ◦ 増分バックアップ • バックアップを取るサーバを⽌めて取るのか稼働させつつ取るのか ◦ ホットバックアップ ◦ コールドバックアップ 実装⽅法
27 実装⽅法: フルバックアップ 10/01 10/02 10/03 10/04 データ量 時間軸
28 実装⽅法: 増分バックアップ 10/01 10/02 10/03 10/04 データ量 時間軸
29 実装⽅法: 差分バックアップ 10/01 10/02 10/03 10/04 データ量 時間軸
30 メリット‧デメリット フルバックアップ 増分バックアップ 差分バックアップ バックアップ時間 ⻑い 普通 短い リストアにかかる時間
短い 普通 ⻑い バックアップサイズ ⼤きい 普通 ⼩さい
31 • コールドバックアップ(オフラインバックアップ) ◦ バックアップする対象のシステムを⽌めてからバックアップするやり⽅ ◦ 夜間に⽌めれるサービスとかだとこの⼿法が取れる • ホットバックアップ(オンラインバックアップ) ◦
バックアップする対象のシステムを動かしたままバックアップするやり⽅ ◦ 静⽌点を取らないとバックアップ中にユーザーがデータを書き換えたら不整合が起き 得てしまう コールドバックアップ‧ホットバックアップ
32 • 復旧時間を短くするには⾼性能なディスクやネットワークを⽤意しておく • それをするにはそれ相応のコストがかかる • コストとのトレードオフにはなるのでサービスレベルを決めて設計/運⽤していくのが⼤事 設計での⼤事な点
33 バックアップの実践例
34 • コンテンツサーバ(画像、動画データ、WordPress)とデータベースを取り上げます • クラウドサービスなんかだとファイルを置いた時点で複数DCにファイルが置かれる • オンプレミスでサービス運⽤をする上でのバックアップの話 バックアップの実践例
35 • ユーザーがHTTPを使ってサーバに対してコンテンツをアップロード コンテンツサーバ
36 • 別のサーバにデータをバックアップ • rsyncがよく使われる ◦ ⾼速で効率的かつ豊富な機能を使ったデータ転送 ▪ ブロック分割されたデータのハッシュ値の⽐較により差分検知 ▪
フルバックアップ/差分バックアップ/増分バックアップ ◦ SSHを通じたセキュアな通信 コンテンツサーバ
37 • rsyncだけでは静⽌点を取れない ◦ データコピー開始時のデータをユーザーが更新した場合は更新したデータのバック アップが取れる ▪ rsyncはブロック単位でコピーをする ▪ flock(1)を使ってロックを取ってコピーすることが必要
• 同⼀コンテンツの更新が⾛らないような特性なら無視できる ◦ 写真Aをアップロードしたら同⼀の名前で違うコンテンツを上げるケースが少ない コンテンツサーバ
38 • rsyncの実⾏でページキャッシュが汚れる ◦ ファイルI/Oを最適化するために、ファイルのページをキャッシュする仕組み ◦ rsyncでデータをコピーする際にファイルを読み取るとそれがページキャッシュに乗っ てしまう問題 ◦ 前段にCDNとかNginxとかいればそこでいい感じになるが
• Feh/nocache ◦ rsyncでデータをコピーする際にそのファイルをページキャッシュに乗せない ◦ ファイル操作のシステムコールをラップしてPOSIX_FADV_DONTNEEDを設定 コンテンツサーバ
39 “データベースの場合”
40 • データベースのRPOは重要 • フルバックアップの間隔 = RPOになるのが許容できるケースは少ない ◦ トランザクションを頻繁に⾏うシステムでは、データ損失を最⼩限に抑えるために RPOが短く設定されることが多い
◦ 任意の時間や特定のクエリの直前の状態に戻せるようにしたい • Point-in-time recovery(PITR) ◦ フルバックアップ -> トランザクションログを適⽤して任意の時間にロールフォワード データベース
41 データベース: PITR ② 障害発生前のデータでリストア ① 障害発 生 ③ トランザクションログの適用
42 • フルバックアップ ◦ コールドバックアップ‧ホットバックアップに対応 ◦ コールドバックアップ ▪ 特定ディレクトリ配下をコピーすることでバックアップ ◦
ホットバックアップ ▪ ディレクトリ配下をコピーするだけではリストアすることはできない • WAL、トランザクション管理、リカバリがありRDBでは難しいはず..?? • MyISAMなら書き込みがない状態ならホットバックアップ データベース: MySQL(InnoDB)の例
43 • PITR ◦ バイナリログをリストアしたDBに当てることでロールフォワードが可能 ▪ テーブル作成操作やテーブルデータへの変更などのデータベース変更を記述 データベース: MySQLの例
44 • 論理バックアップ ◦ データベースの内容をSQL形式でエクスポートする⽅法 ◦ mysqldumpやmysqlshellといったツールを使ってバックアップを取得 • 物理バックアップ ◦
データベースのデータファイルをそのままコピーする⽅法 ◦ ディスク上のMySQLデータファイルを直接バックアップするため、より⾼速にバック アップ‧リストアができる ▪ Percona XtraBackupのようなツールを使う データベース: MySQLの例
45 • 静⽌点 ◦ オンラインでフルバックアップはできないんじゃないの? ◦ mysqldumpでは静⽌点を取ってトランザクションのIsolationを活かして取得する ▪ 1. 読み取りロック
▪ 2. トランザクションの開始 ▪ 3. テーブルのデータをSELECTで取得 ▪ 4. トランザクションの終了 ◦ RRで実⾏することで最初のSELECT以降も同様のスナップショットを⾒るようになる データベース: MySQLの例
46 (コラム) MySQLのレプリカはバックアップになるのか • バックアップ代わりにレプリカを⽤意するみたいなことを聞いたことがある • バックアップ≠レプリカ ◦ プライマリで誤ったdropをしたらレプリカでも即drop ◦
リストアすることは難しい
47 データベース https://ryuichi1208.hateblo.jp/entry/2023/12/09/175134
48 まとめ
49 • バックアップ戦略は、企業の規模やシステムの重要度、データ特性などによって異なる • 適切なバックアップ戦略を策定し、定期的に⾒直すことで、データの安全性を確保し、事業継 続性を⾼めていくのが重要 • 「本当に必要なときにないのがバックアップ」とならないようにしていきましょう まとめ
50 よいバックアップライフを!
51 参考書籍など
52 • 運⽤設計の教科書 / 技術評論社 • インフラエンジニアの教科書 • 絵で⾒てわかるITインフラの仕組み •
インフラ設計のセオリー • 基礎から学ぶ新しいストレージ⼊⾨ • MySQL 運⽤‧管理 実践⼊⾨ 参考書籍など
53 (コラム) スナップショットはバックアップなのか? • スナップショット ◦ ストレージやファイルシステム、仮想マシン(VM)の特定時点の状態を記録する技術 • 短期的なデータ保護や変更前の状態に迅速に戻すために使⽤ •
スナップショットをバックアップ的に使うことはできる • スナップショット ≠ バックアップというのが個⼈的な意⾒