--- tags: - security - l1 - flashcard-deck - backup-restore --- [Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [Backup & Restore](../../../../library/portal/topics.md) | **Domain:** Security id category difficulty tags question answer source_path backup-restore/a1c2d3e4f5b6 backup-restore easy backup-restore, strategy, basics What does the 3-2-1 backup rule require, and what does the modern 3-2-1-1-0 variant add? 3 copies of data, 2 different media types, 1 offsite copy. The modern 3-2-1-1-0 variant adds 1 immutable or air-gapped copy and 0 errors in restore testing.\n\nRemember: 3-2-1 rule: 3 copies of data, 2 different media types, 1 offsite. Protects against hardware failure, site disaster, and ransomware.\n\nExample: production database + local snapshot + S3 cross-region replication = 3 copies, 2 media, 1 offsite. training/library/topics/backup-restore/primer.md backup-restore/b2d3e4f5a6c7 backup-restore easy backup-restore, concepts What is the difference between RPO and RTO? RPO (Recovery Point Objective) is the maximum acceptable data loss measured in time. RTO (Recovery Time Objective) is the maximum acceptable downtime. RPO drives backup frequency; RTO drives restore speed and automation.\n\nRemember: RPO = how much data can you lose? RPO 1h = you can lose up to 1 hour of data. Lower RPO = more frequent backups = higher cost.\n\nExample: RPO=0 (no data loss) requires synchronous replication. RPO=24h means daily backups suffice. training/library/topics/backup-restore/primer.md backup-restore/c3e4f5a6b7d8 backup-restore easy backup-restore, types What are the three main backup types and how do they differ? Full captures everything (slow, large). Incremental captures changes since last backup of any type (fast, small). Differential captures changes since the last full backup (medium speed and size). training/library/topics/backup-restore/primer.md backup-restore/d4f5a6b7c8e9 backup-restore medium backup-restore, tools, borg What makes Borg Backup well-suited for server backups? Borg provides block-level deduplication (only stores unique data chunks), compression (lz4/zstd), authenticated encryption, and efficient pruning of old archives. It significantly reduces storage requirements for incremental backups. training/library/topics/backup-restore/primer.md backup-restore/e5a6b7c8d9f0 backup-restore medium backup-restore, tools, restic How does restic differ from Borg in backend support? Restic has native support for cloud backends including S3, GCS, Azure Blob, and SFTP, making it well-suited for cloud-native backup strategies. Borg primarily targets local and SSH-based repositories. training/library/topics/backup-restore/primer.md backup-restore/f6b7c8d9e0a1 backup-restore medium backup-restore, kubernetes, velero How do you create a scheduled Kubernetes backup with Velero? velero schedule create daily-backup --schedule="0 2 \n* * *" --include-namespaces production --ttl 720h. This backs up the production namespace daily at 2 AM with a 30-day retention. training/library/topics/backup-restore/primer.md backup-restore/a7c8d9e0f1b2 backup-restore medium backup-restore, database Why are filesystem-level copies insufficient for database backups? Databases have data in memory buffers, write-ahead logs, and complex file relationships. A raw file copy may capture an inconsistent state. Use application-consistent tools like pg_dump, mysqldump, or snapshot with fsfreeze. training/library/topics/backup-restore/primer.md backup-restore/b8d9e0f1a2c3 backup-restore hard backup-restore, testing Why is restore testing the most important backup practice? A backup that cannot be restored is worthless. Silent corruption, missing files, incompatible versions, or changed schemas can make backups useless. Monthly automated restore tests with validation checks are the only way to confirm recoverability.\n\nRemember: 'An untested backup is not a backup.' Schedule regular restore drills. Verify data integrity after restore. Automate restoration testing.\n\nGotcha: the #1 backup failure mode is discovering your backups are corrupt or incomplete during an actual emergency. training/library/topics/backup-restore/primer.md backup-restore/c9e0f1a2b3d4 backup-restore hard backup-restore, snapshots Why are cloud snapshots alone not a complete backup strategy? Snapshots reside in the same provider and often the same region. A provider outage or account compromise can take both primary data and snapshots. Snapshots must be combined with cross-region or cross-provider copies to meet the offsite requirement.\n\nRemember: snapshots are point-in-time copies, usually copy-on-write. Fast to create but not a replacement for offsite backups. training/library/topics/backup-restore/primer.md backup-restore/d0f1a2b3c4e5 backup-restore hard backup-restore, monitoring What are the consequences of not monitoring backup jobs? Backup jobs fail silently — network issues, full disks, expired credentials, or permission changes can cause failures with no alert. Without monitoring, you discover the failure only when you need to restore, which is the worst possible time. training/library/topics/backup-restore/primer.md backup-restore/e1a2b3c4d5f6 backup-restore medium backup-restore, encryption, keys What are the key management risks when encrypting backups, and how do you mitigate them? If you lose the encryption key, the backup is unrecoverable — encryption without key management is worse than no encryption. Mitigate: store keys separately from backups (never in the same bucket), use a KMS or key escrow service, document key rotation procedures, and test decryption as part of restore drills. backup-restore/f2b3c4d5e6a7 backup-restore hard backup-restore, ransomware, immutable How do immutable backups protect against ransomware, and how do you implement them? Immutable backups cannot be modified or deleted for a set retention period, even by admins. Ransomware that compromises admin credentials cannot encrypt or destroy them. Implement with: S3 Object Lock (Compliance mode), Azure immutable blob storage, or air-gapped tape/offline media. Test that immutability cannot be bypassed by your own admin accounts.\n\nRemember: immutable backups (WORM / Object Lock) prevent deletion or modification. Essential defense against ransomware that encrypts backups. backup-restore/a3c4d5e6f7b8 backup-restore hard backup-restore, database, pitr What is Point-in-Time Recovery (PITR) for databases, and what does it require? PITR lets you restore a database to any specific moment (e.g., 1 second before a bad DELETE). It requires: a base backup (full snapshot) plus continuous archiving of write-ahead logs (WAL in PostgreSQL, binlogs in MySQL). The base backup is replayed, then WAL is applied up to the target timestamp. WAL archiving must be configured before the incident. backup-restore/b4d5e6f7a8c9 backup-restore medium backup-restore, rto, estimation How do you estimate restore time before a disaster actually happens? Measure: backup size / network bandwidth to get transfer time, add decompression and decryption overhead (benchmark with a sample restore), add application startup and validation time. For databases, factor in WAL replay time. Document the result as tested RTO and compare against the business RTO requirement. Re-test quarterly as data grows. backup-restore/c5e6f7a8b9d0 backup-restore medium backup-restore, verification, checksums How do you verify backup integrity using checksums, and when should you check them? Tools like restic and Borg automatically store and verify content hashes (SHA-256) for each chunk. Run periodic integrity checks: restic check or borg check weekly. For raw file backups, generate SHA-256 manifests at backup time and verify after transfer. Check on both write (detect corruption during backup) and read (detect bit-rot in storage).\n\nRemember: 'An untested backup is not a backup.' Schedule regular restore drills. Verify data integrity after restore. Automate restoration testing.\n\nGotcha: the #1 backup failure mode is discovering your backups are corrupt or incomplete during an actual emergency. backup-restore/d6f7a8b9c0e1 backup-restore easy backup-restore, automation, scheduling What are the risks of manually triggered backups versus automated scheduled backups? Manual backups are forgotten, inconsistently timed, and create unpredictable RPO gaps. Automated backups (cron, Velero schedules, managed service policies) run reliably and can be monitored for failures. Always automate, and alert when a scheduled backup does not complete within its expected window. backup-restore/d02c7eb476a2 backup-restore medium backup;rpo What is RPO and how does it influence backup strategy? Recovery Point Objective (RPO) is the maximum acceptable data loss measured in time. A 1-hour RPO requires backups at least hourly. Lower RPO = more frequent backups or continuous replication.\n\nRemember: RPO = how much data can you lose? RPO 1h = you can lose up to 1 hour of data. Lower RPO = more frequent backups = higher cost.\n\nExample: RPO=0 (no data loss) requires synchronous replication. RPO=24h means daily backups suffice. backup-restore/c2b7433b6ea7 backup-restore hard backup;testing Why must backup restores be tested regularly, and what is one common failure mode? Untested backups may be corrupt, incomplete, or incompatible with the current environment. Common failure: backup succeeds but restore fails due to changed schema, missing dependencies, or permission drift.\n\nRemember: 'An untested backup is not a backup.' Schedule regular restore drills. Verify data integrity after restore. Automate restoration testing.\n\nGotcha: the #1 backup failure mode is discovering your backups are corrupt or incomplete during an actual emergency. backup-restore/7d4f561dd702 backup-restore medium backup;strategy Describe the 3-2-1 backup rule. Keep 3 copies of data, on 2 different media types, with 1 copy offsite. This protects against hardware failure, site disaster, and media-specific corruption.\n\nRemember: 3-2-1 rule: 3 copies of data, 2 different media types, 1 offsite. Protects against hardware failure, site disaster, and ransomware.\n\nExample: production database + local snapshot + S3 cross-region replication = 3 copies, 2 media, 1 offsite. backup-restore/701a2fd23b8f backup-restore medium backup;incremental What is the difference between incremental and differential backups? Incremental backs up only changes since the last backup (any type). Differential backs up all changes since the last full backup. Incremental is faster to create but slower to restore.\n\nRemember: Full = everything. Differential = changes since last full. Incremental = changes since last backup (any type). Incremental is smallest but slowest to restore.\n\nRemember: restore speed: Full > Differential > Incremental. Backup speed/size: Incremental > Differential > Full. Trade-off! --- ## Wiki Navigation ### Related Content - [Backup Restore](../../../../library/topics/backup-restore/index.md) (Topic Pack, L1) — Backup & Restore - [Disaster Recovery & Backup Engineering](../../../../library/topics/disaster-recovery/index.md) (Topic Pack, L2) — Backup & Restore