1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 立即卸载分区，或把它改成只读挂载
sudo umount /dev/sda1

# 卸载不掉（有进程在用）时，先找出占用者
sudo lsof +f -- /home
# 然后改为只读挂载：注意 remount 后面跟的是"挂载点"，不是设备名
sudo mount -o remount,ro /home

# 根分区没法卸载（系统正在跑），正确做法是用 Live USB 启动，
# 从 U 盘里的系统去操作那块硬盘

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 安装
sudo apt install extundelete

# 查看已删除文件（模拟）
extundelete /dev/sda1 --inode 2

# 恢复特定文件
extundelete /dev/sda1 --restore-file path/to/deleted/file

# 恢复目录
extundelete /dev/sda1 --restore-directory path/to/deleted/dir

# 恢复所有删除文件
extundelete /dev/sda1 --restore-all

# 只恢复某个时间点之后删除的文件（--after 接的是"删除时间戳"）
extundelete /dev/sda1 --after 1704038400 --restore-all
# 时间用 Unix 时间戳，可用 date 换算：
#   date -d '2024-01-01' +%s

# 指定输出目录（务必放在另一块盘上）
extundelete /dev/sda1 --restore-all --output-dir /mnt/backup/RECOVERED

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 安装
sudo apt install testdisk

# 启动（交互式）
sudo testdisk

# testdisk 是交互式向导，典型流程：
# 选择磁盘 → 分区表类型（Intel/GPT）→ Analyse → Quick Search
#   → 没找到就 Deeper Search → 确认分区 → Write 写回分区表
# 写回前一定要先看清"将要写入的分区表"，这一步改错了会丢分区
sudo testdisk /dev/sda

1
2
3
4
5
6
7

# photorec 同样是交互式的，但可以直接指定磁盘开始
cd /mnt/backup        # 先切到"另一块盘"的目录，恢复结果会落在 recup_dir.N/
sudo photorec /dev/sdb

# 交互流程：选择磁盘 → 选择分区 → 选择文件系统类型 → File Opt（勾选要恢复的类型）
#          → Search → 选择恢复目录
# 默认会匹配 480 多种文件签名，不勾选类型的话会恢复出海量无用文件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 安装
sudo apt install ext4magic

# 恢复所有还能找到的文件到指定目录（目录要放在另一块盘上，且必须是空目录）
sudo mkdir -p /mnt/backup/recover
sudo ext4magic /dev/sda1 -r -d /mnt/backup/recover

# 只恢复某个文件（-f 后面跟原始路径）
sudo ext4magic /dev/sda1 -r -f /home/user/report.docx -d /mnt/backup/recover

# 只恢复某时间段内被删除的文件（时间格式：YYYYMMDDHHMMSS）
sudo ext4magic /dev/sda1 -r -a 20240115000000 -b 20240116000000 -d /mnt/backup/recover

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 安装（Debian/Ubuntu 的包名是 scalpel；RHEL 系在 EPEL 里）
sudo apt install scalpel

# 1. 复制一份默认配置再改，别直接动 /etc 下的原件
sudo cp /etc/scalpel/scalpel.conf /root/scalpel.conf
sudo nano /root/scalpel.conf

# 2. 默认配置里所有类型都被注释掉了，必须手动"取消注释"才会生效
#    格式：扩展名  区分大小写  最大长度  文件头  文件尾
# 示例（去掉行首的 #）：
jpg     y       20000000    \xff\xd8\xff\xe0    \xff\xd9
png     y       10000000    \x89\x50\x4e\x47    \x49\x45\x4e\x44
pdf     y       10000000    %PDF                %EOF

# 3. 输出目录必须"事先存在且为空"，否则报错
sudo mkdir -p /mnt/backup/scalpel-out
sudo scalpel /dev/sda1 -c /root/scalpel.conf -o /mnt/backup/scalpel-out

# 4. 结果按类型分目录，文件名是编号
ls -lh /mnt/backup/scalpel-out/jpg-*/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 安装
sudo apt install foremost

# 只看有哪些可用类型（-t 后面接类型列表，逗号分隔不要空格）
# 常用：jpg gif png bmp avi mov pdf doc zip rar htm exe
sudo foremost -t jpg,png,pdf,zip -i /dev/sda1 -o /mnt/backup/foremost-out

# 结果在 audited.txt（审计报告）和按类型分的子目录里
cat /mnt/backup/foremost-out/audited.txt
ls -lh /mnt/backup/foremost-out/jpg/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 安装
sudo apt install gddrescue

# ⚠️ 注意包名叫 gddrescue，但命令名是 ddrescue；别装成 dd_rescue（是另一个老工具）

# 第一遍：快速把好读的区域全部抓下来（-n 表示不反复刮擦坏区）
sudo ddrescue -n /dev/sda /mnt/backup/disk.img /mnt/backup/disk.log

# 第二遍：针对剩下的坏区做刮擦式重读（不加 -n，多花时间但尽量把数据抠出来）
sudo ddrescue -d -r3 /dev/sda /mnt/backup/disk.img /mnt/backup/disk.log

# 关键点：
#  - 镜像整个磁盘 /dev/sda（而不是 /dev/sda1），分区偏移才能对齐
#  - 日志文件（.log）就是"进度记录"，分次运行必须带上它才能接着上次继续
#  - 盘正在坏的时候可以加 -R（反向读），绕过响应越来越慢的区域

# 从镜像恢复文件
# 先在镜像上运行恢复工具
sudo extundelete /backup/disk.img --restore-all

# 或挂载镜像（必须加 ro，绝不能以可写方式挂载，否则会破坏证据/数据）
sudo mount -o ro,loop,offset=$((2048*512)) /mnt/backup/disk.img /mnt/recovery
# 偏移量从分区表里取，用 fdisk -l /dev/sda 或 parted 查看"起始扇区"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 1. 立即卸载分区（卸不掉就先改成只读挂载）
sudo umount /dev/sda1

# 2. 确认分区特性，决定用哪个工具
sudo dumpe2fs -h /dev/sda1 | grep features
#   出现 metadata_csum / 64bit → 用 ext4magic（extundelete 大概率失败）
sudo mkdir -p /mnt/backup/recover
sudo ext4magic /dev/sda1 -r -d /mnt/backup/recover
#   特性较老、或上面失败时再试：
#   sudo extundelete /dev/sda1 --restore-all --output-dir /mnt/backup/recover

# 3. 查看结果（extundelete 默认落在当前目录的 RECOVERED_FILES/）
ls -la /mnt/backup/recover/

1
2
3
4
5
6
7
8
9

# 1. 不要在格式化的分区写入任何数据！
#    也尽量别用同一台机器的系统盘当输出目标
# 2. 进入另一块盘的目录，再启动 photorec
cd /mnt/backup
sudo photorec /dev/sdb

# 3. 选择U盘分区 → File Opt → 选择要恢复的文件类型 → Search

# 4. 恢复的文件在 recup_dir.1 等目录（文件名是编号，需要自己按内容筛）

1
2
3
4
5
6
7
8

# 1. 先备份当前分区表（有备无患，出问题还能回到现状）
sudo sfdisk -d /dev/sda > /mnt/backup/parttable-before.txt

# 2. 使用 testdisk 分析
sudo testdisk /dev/sda
#    选择磁盘 → 分区表类型（Intel=Mbr/GPT）→ Analyse → Quick Search
#    → 找到分区后可以按 P 预览里面的文件（确认是不是要找的分区）
#    → 确认无误再 Write 写回分区表

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. 先创建镜像（整盘，不是单个分区），-n 表示第一遍快速抓取不刮擦
sudo ddrescue -n /dev/sda /mnt/backup/disk.img /mnt/backup/disk.log
#    再补一遍刮擦式重读
sudo ddrescue -d -r3 /dev/sda /mnt/backup/disk.img /mnt/backup/disk.log

# 2. 尝试挂载镜像（只读！偏移量从分区表里读）
sudo fdisk -l /mnt/backup/disk.img
sudo mount -o ro,loop,offset=$((2048*512)) /mnt/backup/disk.img /mnt/recovery

# 3. 或者在镜像上运行恢复工具
sudo ext4magic /mnt/backup/disk.img -r -d /mnt/backup/recover

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#!/bin/bash
# recover_deleted.sh
set -uo pipefail       # 恢复失败要允许继续尝试下一个工具，所以不加 -e

TARGET_PARTITION="${1:?用法: $0 <设备，如 /dev/sda1>}"
RECOVERY_DIR="/mnt/backup/recovery-$(date +%Y%m%d_%H%M%S)"
LOG_FILE="/var/log/recovery.log"

mkdir -p "$RECOVERY_DIR/ext4magic" "$RECOVERY_DIR/extundelete"

echo "[$(date)] 开始恢复已删除文件" | tee -a "$LOG_FILE"
echo "目标分区: $TARGET_PARTITION" | tee -a "$LOG_FILE"
echo "输出目录: $RECOVERY_DIR（务必在另一块物理盘上）" | tee -a "$LOG_FILE"

# 1) 先看文件系统特性，决定主用工具
sudo dumpe2fs -h "$TARGET_PARTITION" 2>/dev/null | grep -i features | tee -a "$LOG_FILE"

# 2) ext4magic：读 journal，能还原文件名（推荐首选）
echo "尝试 ext4magic..." | tee -a "$LOG_FILE"
sudo ext4magic "$TARGET_PARTITION" -r -d "$RECOVERY_DIR/ext4magic" 2>&1 | tee -a "$LOG_FILE" || \
    echo "ext4magic 失败，继续尝试下一个工具" | tee -a "$LOG_FILE"

# 3) extundelete：老 ext4/ext3 上还有机会
echo "尝试 extundelete..." | tee -a "$LOG_FILE"
sudo extundelete "$TARGET_PARTITION" --restore-all \
    --output-dir "$RECOVERY_DIR/extundelete" 2>&1 | tee -a "$LOG_FILE" || \
    echo "extundelete 失败，继续尝试下一个工具" | tee -a "$LOG_FILE"

# 4) photorec 是交互式的，没法在这里自动跑完，给出提示
echo "如果上面都没找到，请手动执行：" | tee -a "$LOG_FILE"
echo "  cd $RECOVERY_DIR && sudo photorec $TARGET_PARTITION" | tee -a "$LOG_FILE"

echo "[$(date)] 本轮恢复结束，结果在 $RECOVERY_DIR" | tee -a "$LOG_FILE"
du -sh "$RECOVERY_DIR"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 基本恢复
mysql -u root -p database_name < backup.sql

# 恢复所有数据库
mysql -u root -p < all_databases.sql

# 解压并恢复
gunzip < backup.sql.gz | mysql -u root -p database_name

# 恢复特定表
mysql -u root -p database_name -e "DROP TABLE IF EXISTS users;"
mysql -u root -p database_name < users_table.sql

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 1. 恢复完整备份
mysql -u root -p < full_backup.sql

# 2. 取出备份时记录的 binlog 位置
#    备份命令里要带 --source-data=2 它才会写进备份文件
#    ⚠️ MySQL 8.0.26 起 --master-data 已更名，新版本用 --source-data，
#       老教程里的 --master-data=2 在新版本会直接报错
grep -A2 "CHANGE REPLICATION SOURCE TO" full_backup.sql
# 输出里形如 SOURCE_LOG_FILE='binlog.000003', SOURCE_LOG_POS=156

# 3. 应用 binlog 到"误操作之前"的那个时间点
mysqlbinlog \
    --start-position=156 \
    --stop-datetime="2024-01-15 14:30:00" \
    /var/lib/mysql/binlog.000003 /var/lib/mysql/binlog.000004 \
  | mysql -u root -p

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

#!/bin/bash
# point_in_time_recovery.sh
set -euo pipefail

DB_USER="root"
DB_NAME="myapp"
BACKUP_DIR="/backup/mysql"
MYSQL_CNF="$HOME/.my.cnf"        # 里面写 [client] user / password，权限 600

# ⚠️ 不要把密码写在变量里：会进 shell 历史，也会出现在 ps 输出中

# 恢复最近完整备份
echo "恢复完整备份..."
mysql --defaults-extra-file="$MYSQL_CNF" -u "$DB_USER" "$DB_NAME" < "$BACKUP_DIR/latest_full.sql"

# 取出备份时记录的 binlog 文件与起始位置
START_FILE=$(grep -oP "SOURCE_LOG_FILE='\K[^']+" "$BACKUP_DIR/latest_full.sql" | tail -1)
START_POS=$(grep -oP "SOURCE_LOG_POS=\K[0-9]+" "$BACKUP_DIR/latest_full.sql" | tail -1)
echo "从 $START_FILE:$START_POS 开始回放"

# 应用增量，停在误操作发生之前
# 注意：--stop-datetime 要和 MySQL 服务器同一时区，别混用 UTC 和本地时间
STOP_TIME="2024-01-15 14:30:00"
echo "应用 binlog..."
mysqlbinlog --start-position="$START_POS" \
    --stop-datetime="$STOP_TIME" \
    "/var/lib/mysql/$START_FILE" /var/lib/mysql/binlog.0000[0-9][0-9] \
  | mysql --defaults-extra-file="$MYSQL_CNF" -u "$DB_USER"

# 说明：起始 position 只对"第一个文件"有意义，
#       所以要把备份对应的那个文件排在第一位，后面按序跟上更新的文件

echo "完成。请立即核对关键表的数据是否已回到预期状态。"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 基本恢复
psql -U postgres database_name < backup.sql

# 恢复压缩文件
gunzip -c backup.sql.gz | psql -U postgres database_name

# 恢复自定义格式
pg_restore -U postgres -d database_name backup.dump

# 创建新数据库并恢复
createdb -U postgres new_database
pg_restore -U postgres -d new_database backup.dump

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

# ---------- 第一步：日常就要配好 WAL 归档（没配就没法 PITR） ----------
# postgresql.conf
# wal_level = replica
# archive_mode = on
# archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'
# ⚠️ 直接写 'cp %p /archive/%f' 有隐患：目标文件已存在时 cp 会静默覆盖，也不报错，
#    加 test ! -f 之后"已存在"会返回非 0，PostgreSQL 就知道该重试，而不是假装归档成功。
#    生产环境更推荐用 pgBackRest / WAL-G 之类的工具，而不是裸 cp。

# 改完需要重启（archive_mode 是 postgresql.conf 里少数必须重启才生效的参数）
sudo systemctl restart postgresql
psql -c "SELECT name, setting FROM pg_settings WHERE name IN ('wal_level','archive_mode','archive_command');"

# ---------- 第二步：出事之后，先停库、保现场 ----------
sudo systemctl stop postgresql
sudo mv "$PGDATA" "${PGDATA}.broken"     # 不要删！留着它可能还能救出部分数据

# ---------- 第三步：把"事前"的基础备份放回数据目录 ----------
# 基础备份是出事之前就该定期做的（用 pg_basebackup 生成），
# 这里只是把它复制/解包回来，而不是现在才去连数据库拉一份新的。
sudo install -d -o postgres -g postgres -m 700 "$PGDATA"
sudo rsync -a --delete /backup/base/ "$PGDATA"/
sudo chown -R postgres:postgres "$PGDATA"

# ---------- 第四步：写恢复配置 ----------
# ⚠️ PostgreSQL 12 起已经没有 recovery.conf 这个文件了！
#    现在是把恢复参数写进 postgresql.conf（或 postgresql.auto.conf），
#    另外在数据目录里放一个空的 recovery.signal 文件作为"我要做恢复"的开关。
sudo tee -a "$PGDATA/postgresql.auto.conf" > /dev/null << 'EOF'
restore_command = 'cp /archive/%f %p'
recovery_target_time = '2024-01-15 14:30:00+00'
recovery_target_action = 'promote'
EOF

sudo touch "$PGDATA/recovery.signal"
sudo chown postgres:postgres "$PGDATA/postgresql.auto.conf" "$PGDATA/recovery.signal"
sudo chmod 600 "$PGDATA/postgresql.auto.conf"

# ---------- 第五步：启动并观察恢复日志 ----------
sudo systemctl start postgresql
sudo -u postgres psql -c "SELECT pg_is_in_recovery();"
# 等到它变成 f（已提升为主库）就说明恢复完成

# ---------- 第六步：确认数据没问题后，把恢复配置清理掉 ----------
# recovery.signal 在恢复成功时会被自动删除；
# 但 postgresql.auto.conf 里的 restore_command / recovery_target_time 还留着，
# 下次重启会让人误以为还在恢复流程里。业务验证通过后把它清掉。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# 停止 Redis
sudo systemctl stop redis

# 先确认数据目录和文件名（不一定是默认值）
redis-cli CONFIG GET dir dbfilename appendonly
# dir        → 数据目录，例如 /var/lib/redis
# dbfilename → RDB 文件名，默认 dump.rdb
# appendonly → 是否开启 AOF，yes/no

# ---- 情况一：用 RDB 恢复 ----
sudo install -o redis -g redis -m 640 /backup/dump.rdb /var/lib/redis/dump.rdb
# 恢复前先校验 RDB 文件能不能读
sudo -u redis redis-check-rdb /var/lib/redis/dump.rdb

# ---- 情况二：用 AOF 恢复 ----
# ⚠️ Redis 7 起 AOF 不再是一个 appendonly.aof 文件，
#    而是 /var/lib/redis/appendonlydir/ 目录下的一组文件：
#      appendonly.aof.1.base.rdb   （基础快照）
#      appendonly.aof.1.incr.aof   （增量部分）
#      appendonly.aof.manifest     （清单，记录用了哪些文件）
#    所以恢复时要整目录一起放回去，只覆盖单个 .aof 文件是不完整的。
sudo systemctl stop redis
sudo rm -rf /var/lib/redis/appendonlydir
sudo cp -r /backup/appendonlydir /var/lib/redis/appendonlydir
sudo chown -R redis:redis /var/lib/redis/appendonlydir

# AOF 可能因为崩溃而写到一半，先校验并修复
sudo -u redis redis-check-aof --fix /var/lib/redis/appendonlydir/appendonly.aof.manifest

# 启动 Redis
sudo systemctl start redis

# 验证
redis-cli PING
redis-cli DBSIZE
redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|aof_last_write_status'

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# 恢复整个备份
mongorestore --db database_name /backup/mongo/database_name/

# 恢复压缩备份
mongorestore --gzip --archive=/backup/mongo.gz

# 恢复特定集合
mongorestore --db database_name --collection users /backup/users.bson

# 恢复并覆盖（⚠️ --drop 会先删掉目标库里的同名集合，确认后再用）
mongorestore --db database_name --drop /backup/database_name/

# 恢复时带上 oplog，才能把备份期间的增量也补上（备份时要 --oplog）
mongorestore --oplogReplay /backup/mongo/

# 验证恢复（MongoDB 6 起自带的 shell 是 mongosh，老的 mongo 命令已移除）
mongosh "mongodb://localhost:27017/database_name" --eval "db.stats()"
mongosh "mongodb://localhost:27017/database_name" --eval "db.getCollectionNames()"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 1. 使用 Live USB 启动
# 2. 挂载原系统分区
sudo mount /dev/sda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

# 3. chroot 到原系统
sudo chroot /mnt

# 4. 重新安装 GRUB —— BIOS 传统引导
grub-install /dev/sda
update-grub          # Debian/Ubuntu 写法
# RHEL / Rocky / Alma 系请用：
# grub2-mkconfig -o /boot/grub2/grub.cfg

# 5. 退出并重启
exit
sudo umount -R /mnt
sudo reboot

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 1. 使用 Live USB 启动
# 2. 挂载并 chroot（见上）

# 3. 重新安装损坏的包
apt install --reinstall dpkg coreutils bash libc6

# 4. 如果系统文件大面积损坏，重新安装"必要的系统包"
#    ⚠️ 千万别无条件重装全部包（apt install --reinstall $(dpkg -l | ...)），
#       那会把几百个包一起重装，耗时极长，还可能因为某个包下载失败而中断在半路。
#       只重装 essential/required 级别的系统包就够了：
apt install --reinstall $(dpkg-query -W -f '${Package} ${Priority}\n' \
    | awk '$2=="required"{print $1}')

# 5. 修复依赖
apt --fix-broken install

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# MBR 的 512 字节里有三段：0-445 引导代码、446-509 分区表、最后 2 字节签名

# 备份 MBR（含分区表）
sudo dd if=/dev/sda of=/mnt/backup/mbr.img bs=512 count=1

# 恢复整个 MBR
sudo dd if=/backup/mbr.img of=/dev/sda bs=512 count=1

# 仅恢复引导代码（446 字节），保住当前分区表
sudo dd if=/backup/mbr.img of=/dev/sda bs=446 count=1

# 重建 GRUB
sudo grub-install /dev/sda

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

#!/bin/bash
# system_backup.sh

TARGET="/dev/sda"
BACKUP_FILE="/mnt/backup/system_$(date +%Y%m%d).img.gz"

# ⚠️ dd 是"整盘按字节复制"，没有任何"排除目录"的能力。
#    整个盘有多大就产出多大的数据（压缩后依然是几十 GB 起）。
sudo dd if="$TARGET" bs=4M status=progress conv=fsync | gzip -1 > "$BACKUP_FILE"

# 恢复（⚠️ 会整盘覆盖，目标盘上的所有数据都会被抹掉）
gunzip -c "$BACKUP_FILE" | sudo dd of="$TARGET" bs=4M status=progress conv=fsync
sudo sync

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 安装
sudo apt install timeshift

# 创建快照
sudo timeshift --create --comments "Before upgrade"

# 查看快照
sudo timeshift --list

# 恢复快照（交互式，会让你选快照和目标设备，执行前务必看清）
sudo timeshift --restore

# 定时快照：编辑 /etc/timeshift/timeshift.json（配置界面里也能改）
# 例如 schedule_monthly=1、schedule_weekly=1 之类，然后重启 timeshift 的定时任务
sudo systemctl restart cron

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

#!/bin/bash
# rsync_system_backup.sh

SOURCE="/"
DEST="/external/backup/system"
EXCLUDES="/root/backup_excludes.txt"

# 创建排除列表
cat > "$EXCLUDES" << EOF
/dev/*
/proc/*
/sys/*
/tmp/*
/run/*
/mnt/*
/media/*
/lost+found
/var/cache/*
/home/*/.cache
EOF

# 执行备份
rsync -aAXHv --numeric-ids \
    --exclude-from="$EXCLUDES" \
    --delete \
    "$SOURCE" "$DEST"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# AWS EC2 备份（快照）
# 1. 创建 EBS 快照
aws ec2 create-snapshot \
    --volume-id vol-1234567890abcdef0 \
    --description "System backup $(date)" \
    --tag-specifications 'ResourceType=snapshot,Tags=[{Key=Name,Value=SystemBackup}]'

# 2. 从快照创建新卷
aws ec2 create-volume \
    --snapshot-id snap-1234567890abcdef0 \
    --availability-zone us-east-1a

# 3. 附加到实例
aws ec2 attach-volume \
    --volume-id vol-0987654321fedcba0 \
    --instance-id i-1234567890abcdef0 \
    --device /dev/sdf

# Google Cloud 备份
gcloud compute disks snapshot DISK_NAME --snapshot-names=SNAPSHOT_NAME
gcloud compute disks create NEW_DISK --source-snapshot=SNAPSHOT_NAME

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

#!/bin/bash
# recovery_check.sh - 恢复后必做检查
set -uo pipefail

echo "========== 恢复后检查清单 =========="

echo "1. 检查磁盘空间"
df -hT

echo "2. 检查关键文件"
for file in /etc/passwd /etc/shadow /etc/group /etc/fstab; do
    if [ -f "$file" ]; then
        echo "  ✓ $file 存在"
    else
        echo "  ✗ $file 缺失！"
    fi
done

echo "2b. 检查关键文件的权限（恢复后权限错乱是常见问题）"
stat -c '%a %U:%G %n' /etc/shadow /etc/passwd /etc/ssh/sshd_config 2>/dev/null

echo "3. 检查服务状态"
for svc in sshd nginx mysql postgresql redis; do
    if systemctl is-active --quiet "$svc" 2>/dev/null; then
        echo "  ✓ $svc 运行正常"
    else
        echo "  ⚠ $svc 未运行或不存在"
    fi
done

echo "4. 检查启动项"
systemctl list-unit-files --state=enabled | grep -v "listed"

echo "5. 检查挂载点与 fstab 是否一致（不一致会导致重启后进不去系统）"
findmnt --verify --fstab 2>/dev/null || echo "  ⚠ fstab 校验未通过，请人工确认"

echo "6. 检查网络"
ip addr
ping -c 3 8.8.8.8

echo "7. 检查日志中的错误"
journalctl -p err --since "1 hour ago" | tail -10

echo "8. 注意事项（需要人工确认）"
echo "  - 恢复出来的数据是否为最新版本？（对比备份时间与业务最后成功时间）"
echo "  - 数据库是否完成了崩溃恢复？（看 mysqld / postgresql 启动日志）"
echo "  - 定时任务、证书、密钥是否都已恢复？"
echo "  - 是否需要通知下游系统？（消息队列积压、缓存里的旧数据要清）"

echo "========== 检查完成 =========="

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

# ---------- 第一步：先判断"是哪些表坏了" ----------
# 注意：mysqlcheck 需要 MySQL 服务在运行（它连上去发 CHECK TABLE）
mysqlcheck -u root -p database_name

# 也可以用 SQL 直接看（InnoDB 建议用 CHECK TABLE，MyISAM 才能 REPAIR）
# CHECK TABLE users, orders;

# ---------- 第二步：能修的先修 ----------
# MyISAM / Aria 表可以直接修：
mysqlcheck -u root -p --auto-repair --optimize database_name

# 也可以离线修单个 MyISAM 表（要先停 MySQL，否则会损坏）
sudo systemctl stop mysql
sudo myisamchk -r /var/lib/mysql/database_name/users.MYI
sudo systemctl start mysql

# ⚠️ InnoDB 表不要用 myisamchk！它是 MyISAM 专用工具，
#    对着 InnoDB 的 .ibd 文件跑会直接损坏数据。

# ---------- 第三步：InnoDB 损坏时用"强制恢复模式"抢救数据 ----------
# 在 my.cnf 的 [mysqld] 段加入：
#   innodb_force_recovery = 1
# 数值可以 1→6 逐级加大（越大越能启动，但对数据的写入限制越严）：
#   1~3：能读能写部分数据；4 以上基本只读；6 连 redo 回滚都跳过
# 启动后【只做导出，不要写业务】：
#   mysqldump --single-transaction --routines --triggers myapp > /mnt/backup/rescue.sql
#
# 导出完成后立刻做两件事：
#   1. 把 innodb_force_recovery 从配置里删掉（否则数据库永远处于不完全可用状态）
#   2. 在一台全新的实例上导入这份 dump，用新实例替换旧实例
#      —— 不要在"强行启动起来的库"上继续跑业务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

# 如果开启了 binlog，可以从 binlog 恢复
# 1. 把 binlog 转成可读的 SQL（ROW 格式必须加 -v --base64-output=DECODE-ROWS）
mysqlbinlog --database=myapp -v --base64-output=DECODE-ROWS \
    /var/lib/mysql/binlog.000001 > /tmp/binlog.sql

# 2. 找到那条误操作（DROP TABLE / DELETE）所在的位置
grep -n "DROP TABLE" /tmp/binlog.sql
#    在这条语句上方找 "# at 12345" 这样的注释，那个数字就是 position

# 3. 只回放到"误操作之前"
mysqlbinlog --database=myapp --stop-position=12345 \
    /var/lib/mysql/binlog.000001 | mysql --defaults-extra-file=~/.my.cnf

# 4. 如果误操作已经发生了，也可以"反向"补回来：
#    从 binlog 里想办法拿到被删数据（ROW 格式的 binlog 里往往能看到原始行数据），
#    整理成 INSERT 语句再导入。
#    用 binlog2sql / my2sql 这类工具可以自动把 binlog 解析成"反向 SQL"，
#    比手工翻省事得多。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 异地恢复步骤
# 1. 确认主站点不可恢复
# 2. 激活异地灾备站点
# 3. 更新 DNS 指向新 IP
# 4. 验证应用连接
# 5. 通知用户

# DNS 切换策略
# 方案一：修改域名解析（最简单，但生效时间取决于 TTL）
# 在 DNS 提供商处把 A 记录指向新的 IP
# 关键前置动作：平时就把 TTL 调小（如 60 秒），否则切换要等几小时
#   ——但 TTL 调小意味着解析请求变多，也是成本

# 方案二：使用 CDN 回源
# 通过 CDN 回源到新的站点（CDN 的这一层切换通常比改 DNS 快）

# 方案三：使用负载均衡健康检查
# 异地站点健康检查通过后自动切换
# 比如 Route53 的故障转移路由、云解析的"主备地址池"，可以做到分钟级甚至秒级

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

#!/bin/bash
# database_recovery_drill.sh - 定期进行数据库恢复演练

DB_NAME="myapp"
DRILL_DIR="/mnt/backup/drill"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
MYSQL_CNF="$HOME/.my.cnf"      # [client] user / password，权限 600
DRILL_DB="${DB_NAME}_drill_${TIMESTAMP}"

# 恢复演练的正确姿势：最好恢复到"另一台实例"，退而求其次也要用独立库名。
# 用 -e 逐个传 -p 密码会让脚本每次都要交互，所以统一走配置文件。
MY="mysql --defaults-extra-file=$MYSQL_CNF"

echo "========== 数据库恢复演练 =========="
echo "时间: $TIMESTAMP"
echo "数据库: $DB_NAME"

# 创建测试环境
echo "1. 创建测试数据库..."
$MY -e "CREATE DATABASE IF NOT EXISTS \`${DRILL_DB}\`;"

# 恢复备份到测试库
echo "2. 恢复备份到测试库..."
zcat /backup/mysql/${DB_NAME}_latest.sql.gz | \
    $MY "${DRILL_DB}"

# 验证数据完整性
echo "3. 验证数据..."
TABLE_COUNT=$($MY -N -e \
    "SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='${DRILL_DB}';")
echo "   恢复表数量: $TABLE_COUNT"

# ⚠️ information_schema.table_rows 对 InnoDB 只是"统计估算值"，会有偏差，
#    不能当作准确的记录数对比依据。要精确核对，请对关键表做 COUNT(*)。
echo "   关键表精确记录数："
for table in users orders products; do
    cnt=$($MY -N -e "SELECT COUNT(*) FROM \`${DRILL_DB}\`.\`${table}\`;" 2>/dev/null || echo "N/A")
    echo "     ${table}: ${cnt}"
done

# 检查关键表
echo "4. 检查关键表..."
for table in users orders products; do
    if $MY -e "SELECT 1 FROM \`${DRILL_DB}\`.\`${table}\` LIMIT 1;" >/dev/null 2>&1; then
        echo "   ✓ $table 存在"
    else
        echo "   ✗ $table 缺失！"
    fi
done

# 记录演练结果，便于对比"每次恢复出来的数据是否一致"
REPORT="${DRILL_DIR}/drill_${TIMESTAMP}.txt"
mkdir -p "$DRILL_DIR"
{ echo "时间: $TIMESTAMP"; echo "表数量: $TABLE_COUNT"; \
  echo "关键表: $(for t in users orders products; do \
      printf '%s=%s ' "$t" "$($MY -N -e "SELECT COUNT(*) FROM \`${DRILL_DB}\`.\`${t}\`;" 2>/dev/null || echo NA)"; done)"; \
} | tee "$REPORT"

# 清理测试数据库
echo "5. 清理测试数据库..."
$MY -e "DROP DATABASE IF EXISTS \`${DRILL_DB}\`;"

echo "========== 演练完成 =========="
echo "结果已记录到 $REPORT"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

#!/bin/bash
# backup_health_check.sh —— 每天跑一次，确认"备份"这件事真的在发生
set -uo pipefail

BACKUP_DIR=/mnt/backup/mysql
MAX_AGE_HOURS=26      # 超过 26 小时没新备份就告警

# 1. 最新备份是不是太老了？
latest=$(ls -t "$BACKUP_DIR"/*.sql.gz 2>/dev/null | head -1)
if [ -z "$latest" ]; then
    echo "❌ 没有找到任何备份文件"; exit 1
fi
age_h=$(( ( $(date +%s) - $(stat -c %Y "$latest") ) / 3600 ))
echo "最新备份: $latest（$age_h 小时前）"
[ "$age_h" -le "$MAX_AGE_HOURS" ] || echo "❌ 备份过旧，请检查备份任务"

# 2. 备份文件完不完整？（gzip 能解压通过才算）
gzip -t "$latest" && echo "✅ 压缩包完整" || echo "❌ 压缩包损坏"

# 3. 备份文件大小是否异常（比平时小很多说明导出中途失败）
size=$(stat -c %s "$latest")
echo "大小: $(( size / 1024 / 1024 )) MB"

# 4. 磁盘空间是否还够（备份盘写满会导致后续备份静默失败）
df -h "$BACKUP_DIR" | tail -1