AI xóa cơ sở dữ liệu: kế hoạch khôi phục trong 7 phút

Thông tin thực tế về cách làm việc với Ailoot có trong tài liệu.

Cần làm gì trong phút đầu tiên: DỪNG LẠI, đừng hoảng loạn#

Khi điều này xảy ra với bạn, việc đầu tiên cần làm là dừng tác nhân. Đừng tự tìm cách hoàn tác những gì nó đã làm, đừng bảo nó “khôi phục mọi thứ” và đừng chạy prompt mới. Mỗi hành động tiếp theo của tác nhân đều có thể ghi đè các khối trên đĩa nơi dữ liệu của bạn có thể vẫn còn được lưu trữ.

1. Đóng terminal của tác nhân

   Ngắt lệnh nguy hiểm ngay bằng Ctrl+C, không chờ xóa xong. Dừng tác nhân chưa chắc dừng lệnh con, job từ xa hoặc truy vấn DB. Xác định writer thật và dừng/hủy thao tác; tăng mức chấm dứt nếu nó tiếp tục phá. Giữ tiến trình không liên quan có tệp mở có thể cứu.

2. KHÔNG khởi động lại máy tính xách tay

   Dữ liệu xóa có thể còn cứu được, tùy storage, DB, SSD discard/TRIM và ghi sau. Giảm ghi vào volume ảnh hưởng; không mặc định byte còn tồn tại.

3. KHÔNG đóng các tiến trình đang mở

   Giữ tiến trình không liên quan đang mở tệp xóa vì có thể cứu qua file descriptor. Điều này không áp writer phá: dừng writer trước. Không giữ việc xóa đang chạy chỉ để giữ handle mở.

4. Bắt đầu quay màn hình

   Ghi đúng giờ, đường ảnh hưởng và đầu ra lệnh nhìn thấy. Nếu ghi hình/chép log, lưu trên thiết bị riêng đã xác minh thay volume hỏng. Giữ tệp tracked, untracked, ignored còn lại và metadata Git tại đó trước cứu.

Tiếp theo là 6 phút để khôi phục. Bắt đầu thôi.

Phút 2–3: ghi lại chính xác điều gì đã xảy ra#

Mở một cửa sổ terminal mới. Không phải cửa sổ tác nhân đang chạy—hãy mở một cửa sổ khác. Chạy lần lượt ba lệnh sau.

1. Ghi lại chính xác những gì đã thay đổi trong kho git:

git status
git log --since="30 minutes ago" --all --oneline

Tệp tracked xóa có thể còn trong index hoặc commit. Giữ working tree hiện tại gồm untracked/ignored trước restore; phục hồi tại chỗ có thể đè sửa còn sống. Xem và cứu trong bản sao riêng.

2. Kiểm tra những tiến trình tác nhân nào đang chạy:

ps aux | grep -i claude
ps aux | grep -i cursor

Xác định tiến trình còn ghi nguy hiểm; chỉ khớp tên chưa đủ. Dừng writer và xác minh đã dừng. Giữ tiến trình không liên quan có tệp mở hữu ích; nếu dừng nhẹ thất bại và phá tiếp, có thể cần buộc dừng.

3. Lưu nhật ký phiên của tác nhân:

Claude Code lưu các phiên JSONL trong ~/.claude/projects/. Cursor lưu chúng trong ~/.cursor/. Hãy tạo bản sao ngay bây giờ:

cp -r ~/.claude/projects /external/incident-evidence/claude-projects

Thay /external/incident-evidence/ bằng thư mục bằng chứng có sẵn trên thiết bị gắn riêng đã xác minh. Không ghi backup vào volume ảnh hưởng hay đè bằng chứng. Thư mục này chứa nguyên văn cuộc trò chuyện với tác nhân—những lệnh nó đã chạy, câu trả lời của nó và thứ tự thực hiện. Đây là nguồn chính để điều tra sự cố và có thể khôi phục các tệp đã xóa từ ngữ cảnh tác nhân đã thấy (xem bước 4).

Phút 4: git reflog—cơ hội tốt nhất của bạn#

git reflog ghi chuyển động ref cục bộ khi mục còn được giữ. Hạn và prune khác nhau, object không thể tới có thể bị xóa; không là kho bảo đảm mọi commit cũ. Chạy bước cứu dưới từ bản kho đã giữ trên thiết bị riêng.

Bước 1. Xem nhật ký:

git reflog --all

Bạn sẽ nhận được danh sách như sau:

1a2b3c4 HEAD@{0}: reset: moving to HEAD~3
9z8y7x6 HEAD@{1}: commit: working version of the dashboard
5w4v3u2 HEAD@{2}: commit: added admin panel

Tìm điểm trước khi tác nhân gây ra thiệt hại. Mỗi mục là một “ảnh chụp nhanh” trạng thái kho tại thời điểm đó.

Bước 2. Cứu vào working tree riêng:

Sau chép kho và mọi việc còn sống sang thiết bị riêng, chạy từ bản kho đã giữ. Thay bằng đúng commit SHA đã kiểm trong reflog, chọn nhánh và đích chưa dùng:

RECOVERY_COMMIT='replace-with-verified-commit-sha'
git worktree add -b recovery-check ../recovery-check "$RECOVERY_COMMIT"

Xem tệp ở ../recovery-check, so với tệp chưa commit đã giữ trước chép ngược. Lệnh checkout commit riêng, không reset working tree hỏng. Worktree liên kết chung object store của kho đã chép, nên đây là workspace phục hồi, không backup độc lập. Xem git-worktree chính thức.

Nếu reflog cũng đã bị dọn (tác nhân đã chạy git gc):

git fsck --lost-found

Lệnh này tìm các commit và blob (đối tượng tệp) “thất lạc” không còn gắn với nhánh nào. Chúng sẽ xuất hiện trong .git/lost-found/commit/ và .git/lost-found/other/. Để khôi phục một tệp từ đó:

git cat-file -p <SHA1-blob> > recovered-file.ext

Trường hợp git reflog KHÔNG giúp được:

• Tệp chỉ nằm trong working tree, chưa có commit hoặc stash → reflog không thể tìm thấy
• Đã quá 90 ngày (giá trị gc.reflogExpire tiêu chuẩn) và git gc đã chạy
• Toàn bộ kho đã bị xóa (rm -rf .git)—khi đó bạn cần Time Machine hoặc một snapshot

Phút 5: khôi phục cơ sở dữ liệu từ bản sao lưu#

Cơ sở dữ liệu bị xóa bằng DROP DATABASE, DROP TABLE hoặc DELETE FROM ... WHERE ... (không có mệnh đề WHERE). Bạn nên làm gì?

Bước 1. Tìm hiểu xem nhà cung cấp của bạn có PITR hay không:

Bước 2. Khôi phục vào instance mới, không phải instance cũ:

Đừng bao giờ khôi phục đè lên cơ sở dữ liệu đang hoạt động. Tạo một instance mới từ bản sao lưu rồi chuyển ứng dụng sang đó. Nếu có vấn đề, bạn có thể chuyển DNS trở lại.

Bước 3. Nếu chưa bật PITR, hãy dùng snapshot mới nhất:

# AWS RDS, list snapshots:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Restore from a snapshot:
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier my-db-restored \
  --db-snapshot-identifier rds:my-db-2026-05-28-12-00

Lưu ý về Supabase, điều khiến nhiều người bất ngờ trong năm 2026: khi bật PITR, các bản sao lưu hằng ngày ngừng được tạo. Hành vi này trái với trực giác; bạn có thể không còn bản sao lưu nào. Kiểm tra Dashboard → Database → Backups để đảm bảo PITR đang hoạt động VÀ bạn có snapshot để khôi phục.

Phút 6: Time Machine, lsof và snapshot đĩa#

macOS—Time Machine:

# List snapshots:
tmutil listbackups

# Restore a file from the latest backup:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine tạo snapshot mỗi giờ, giữ snapshot theo giờ trong một ngày, snapshot hằng ngày trong một tuần và snapshot hằng tuần vô thời hạn. Nếu máy tính xách tay của bạn kết nối với Time Capsule hoặc ổ đĩa ngoài, dự án sẽ có các bản lưu theo từng giờ.

Linux—tệp đã bị xóa nhưng tiến trình vẫn đang mở:

# Find all “deleted” files that a process still has open:
sudo lsof | grep deleted

# You'll get lines like:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Copy the file directly from /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Khả năng thành công là ~95% nếu tiến trình chưa bị đóng. Hoạt động trên ext4, xfs, btrfs.

macOS—cách tương đương bằng lsof:

lsof | grep deleted

Việc sao chép tệp khó hơn (không có /proc/), nhưng bạn có thể làm bằng lldb:

lldb -p 12345
(lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE

Snapshot toàn bộ đĩa (Linux, biện pháp cuối cùng):

sudo dd if=/dev/sda1 of=/external/disk-image.img bs=4M status=progress

Lệnh này lưu toàn bộ phân vùng dưới dạng ảnh đĩa. Sau đó khôi phục bằng extundelete hoặc photorec. Khả năng khôi phục phụ thuộc vào lượng dữ liệu đã được ghi lên đĩa kể từ khi xóa. Nếu chưa ghi gì, khả năng là 80–90%. Nếu đĩa đã hoạt động được một giờ, khả năng là 20–30%.

Phút 7: nếu không có bản sao lưu thì sao#

Lựa chọn 1—bộ phận hỗ trợ của nhà cung cấp:

AWS, Yandex Cloud, Google Cloud và DigitalOcean định kỳ khôi phục dữ liệu từ bộ nhớ nội bộ, ngay cả sau sự cố của khách hàng, đặc biệt với các gói trả phí. Mở phiếu hỗ trợ, cung cấp thời gian chính xác xảy ra sự cố và đính kèm ảnh chụp màn hình trạng thái. Cách này thường hiệu quả nhất với các nhà cung cấp lớn có giữ bản sao lưu tự động ở phía họ. Khả năng thành công là 40–60%; thời gian phản hồi là 24–72 giờ.

Lựa chọn 2—tạo phiên bản S3:

Nếu tệp nằm trong S3 (hoặc Yandex Object Storage) và tính năng tạo phiên bản đã được bật, mọi phiên bản vẫn còn trên đĩa; chúng chỉ được đánh dấu là “đã xóa”.

# AWS—list versions:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Restore a version:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Lưu ý quan trọng: Claude Code không giữ phiên mãi mãi—các tệp JSONL cũ sẽ tự động bị xóa sau vài tuần. Để đảm bảo bạn có một tháng lịch sử JSONL phòng khi xảy ra sự cố, hãy sao chép ~/.claude/projects/ sang ổ đĩa ngoài mỗi tuần một lần bằng một công việc cron đơn giản:

# In crontab, every Sunday at 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Miễn phí và sẽ cứu bạn khi “mọi thứ đã mất, không có bản sao lưu và reflog trống”.

7 quy tắc để ngăn chuyện này xảy ra lần nữa#

1. Dùng Plan Mode trước mọi thao tác phá hủy dữ liệu. Trong Claude Code:

claude --plan

Tác nhân lập kế hoạch trước khi hành động. Bạn đọc kế hoạch, thấy DROP TABLE users rồi hủy. Không có Plan Mode, tác nhân tự quyết định và thực thi trong vài mili giây. Tìm hiểu thêm trong hướng dẫn Plan Mode trong Claude Code.

2. Hook làm dây cảnh báo bổ sung. Dùng PreToolUse đã thử đọc JSON event từ stdin, thoát 2 khi phát hiện hành động nguy hiểm. Ví dụ đầy đủ dưới phủ Bash, Write, Edit; không là ranh giới bảo mật và có thể bỏ thao tác gián tiếp. Giữ quyền DB và sandbox hạn chế.

3. Dùng người dùng DB chỉ đọc cho tác nhân. Tạo một người dùng riêng cho tác nhân, người dùng này không có quyền DROP, TRUNCATE hoặc DELETE:

CREATE USER claude_readonly WITH PASSWORD 'xxx';
GRANT CONNECT ON DATABASE myapp TO claude_readonly;
GRANT USAGE ON SCHEMA public TO claude_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO claude_readonly;

Khi tác nhân thực sự cần ghi dữ liệu, hãy chuyển sang người dùng khác theo cách thủ công. Người dùng chỉ đọc là đủ cho các tác vụ thường ngày (phân tích dữ liệu, báo cáo, dashboard).

4. Lưu các thay đổi đã kiểm tra vào Git. Hook PostToolUse trong .claude/settings.json có thể hiển thị lời nhắc sau thao tác Write và Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Kiểm tra diff và chỉ commit thủ công những tệp đã thống nhất.' >&2"
          }
        ]
      }
    ]
  }
}

Ví dụ này chỉ hiển thị lời nhắc; không đưa tệp vào staging hoặc tạo commit. Kiểm tra diff và chỉ commit thủ công những tệp đã thống nhất. Reflog không lưu các thay đổi chưa được commit.

5. Dùng dự án sandbox để thử nghiệm. Đừng bao giờ để tác nhân làm việc trong một dự án có dữ liệu khách hàng thật. Tạo một thư mục ~/sandbox-projects/ riêng, chứa bản sao dự án và dữ liệu tổng hợp. Dùng thư mục này để thử prompt, tác nhân hoặc máy chủ MCP mới. Nếu có sự cố, sẽ không gây hại gì.

6. Tạo snapshot đĩa bằng restic mỗi giờ.

# Install:
brew install restic  # macOS
sudo apt install restic  # Linux

# Create repository:
restic init --repo /external/backups

# Back up the current project:
restic --repo /external/backups backup ~/projects

# Schedule cron every hour:
crontab -e
# Add:
0 * * * * restic --repo /external/backups backup ~/projects

Bạn sẽ có bảy ngày bản sao lưu theo giờ, bốn tuần bản sao lưu hằng ngày—và luôn có thể quay lại bất kỳ thời điểm nào trong quá khứ. Miễn phí và chỉ mất 10 phút để thiết lập.

7. Lưu trữ các phiên JSONL của Claude Code. Đã nhắc đến ở trên, nhưng hãy coi đây là một quy tắc riêng: lên lịch chạy rsync hằng tuần để sao chép ~/.claude/projects/ sang ổ đĩa ngoài. Miễn phí và chỉ cần một dòng trong crontab.

Hooks có sẵn để chặn các lệnh nguy hiểm#

Gộp mục sau vào .claude/settings.json, không thay hook hiện có:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-risk.py\""
          }
        ]
      }
    ]
  }
}

Tạo .claude/hooks/check-risk.py với Python 3 sau:

import json
import re
import sys
from pathlib import Path

try:
    event = json.load(sys.stdin)
    tool = event["tool_name"]
    data = event["tool_input"]
    blocked = False
    if tool == "Bash":
        command = data["command"]
        blocked = bool(re.search(
            r"drop\s+(database|table)|truncate\s+table|"
            r"delete\s+from.*where\s+1|rm\s+-rf|"
            r"git\s+reset\s+--hard|git\s+push.*(--force|-f)|"
            r"chmod\s+-R\s+777",
            command, re.IGNORECASE | re.DOTALL))
    elif tool in ("Write", "Edit"):
        path = Path(data["file_path"]).resolve()
        blocked = (".git" in path.parts or path.name.startswith(
            (".env", "credentials", "secrets")))
except (ValueError, KeyError, TypeError, OSError):
    print("BLOCKED: invalid hook input", file=sys.stderr)
    sys.exit(2)

if blocked:
    print("BLOCKED: high-risk command or sensitive path", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Hook đọc JSON event có tài liệu từ stdin, kiểm tool_input.command hoặc tool_input.file_path, thoát 2 khi khớp, phủ cả Write và Edit. Thử fixture vô hại được phép và fixture bị chặn, xác minh Python/script thực khởi chạy.

Đây là cảnh báo theo chữ: có thể bỏ cờ đảo, script, alias, lệnh che, công cụ khác và ghi gián tiếp; cũng có thể chặn ví dụ trích vô hại. Không cấp/thu quyền OS hoặc DB. Giữ credential production ngoài môi trường tác nhân, role DB chỉ đọc, sandbox cưỡng chế; bảo vệ cấu hình hook khỏi sửa. Xem tham chiếu input/mã thoát chính thức.

Với thao tác ngoại lệ có chủ ý, xem lại rồi chạy ngoài tác nhân bằng tài khoản hạn chế phù hợp. Biến môi trường shell không phải giao diện tắt hook có tài liệu; hook không quản lệnh terminal thông thường.

Khi nào nên cấp quyền cho AI (và khi nào không)#

Anthropic mô tả cờ --dangerously-skip-permissions (còn gọi là chế độ YOLO) như một tùy chọn dành cho “môi trường đáng tin cậy”. Trong thực tế năm 2026, đây là con đường trực tiếp dẫn đến thảm họa. Khi không phải xin phép, tác nhân sẽ:

• Chạy mọi lệnh Bash mà không cần xác nhận
• Ghi tệp mà không hỏi
• Có thể gọi một tác nhân con, tác nhân này kế thừa YOLO và không có cách nào tắt chế độ đó

Điểm thứ ba nguy hiểm nhất. Nếu khởi chạy tác nhân chính với YOLO, các tác nhân con của nó cũng sẽ dùng YOLO và bạn không thể ghi đè. Chỉ một prompt—và một chuỗi gồm 10 tác nhân chạy song song có thể làm bất cứ điều gì trên hệ thống của bạn.

Quy tắc:

Giải pháp thay thế—phân quyền chính xác. Trong .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(npm run build:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(git push:*)",
      "Edit(.env)",
      "Edit(prisma/migrations/*)"
    ]
  }
}

Tác nhân biết điều gì được phép và điều gì không. Bạn không phải nhấp “có” hoặc “không” mỗi lần—tác nhân làm việc nhanh chóng, còn bạn kiểm soát ranh giới.

Tiếp theo: danh sách kiểm tra 7 phút để lưu lại#

Danh sách kiểm tra: “AI đã xóa dữ liệu—tôi phải làm gì?”

1. Dừng writer phá thật ngay; xác minh thao tác con hoặc remote đã dừng
2. Không reboot; giữ tiến trình không liên quan đang mở tệp đã xóa
3. Ghi giờ sự cố và bằng chứng lệnh trên thiết bị riêng đã xác minh
4. Chép tệp còn, metadata Git và log phiên liên quan sang thiết bị riêng đó
5. Trong bản kho đã giữ, xem git reflog --all, cứu commit xác minh vào worktree riêng
6. Nếu git không giúp được—git fsck --lost-found
7. Cơ sở dữ liệu: PITR (AWS/Yandex/Supabase) hoặc snapshot mới nhất
8. Tệp: Time Machine trên Mac, lsof trên Linux
9. Biện pháp cuối cùng: bộ phận hỗ trợ nhà cung cấp + tạo phiên bản S3
10. Sau khi khôi phục, thiết lập 7 quy tắc phòng ngừa trong hướng dẫn này

Tiếp theo—bảo vệ có hệ thống:

• Plan Mode trong Claude Code—để tác nhân lập kế hoạch trước thao tác phá hủy dữ liệu
• Hooks trong Claude Code—các mẫu có sẵn để chặn lệnh nguy hiểm
• Cách hoàn tác thay đổi trong Claude Code—hướng dẫn chi tiết về /rewind, git và 5 phương pháp hoàn tác tiêu chuẩn
• Đánh giá bảo mật trong Claude Code—kiểm tra bảo mật mã thường xuyên

Truy cập Ailoot.