AI memadam pangkalan data: pelan pemulihan 7 minit

Maklumat praktikal tentang cara bekerja dengan Ailoot tersedia dalam dokumentasi.

Perkara yang perlu dilakukan pada minit pertama: BERHENTI, jangan panik#

Apabila perkara ini berlaku kepada anda, perkara pertama yang perlu dilakukan ialah menghentikan ejen. Jangan cuba membatalkan tindakannya sendiri, jangan suruhnya “pulihkan semuanya”, dan jangan berikan arahan baharu. Setiap tindakan ejen yang seterusnya boleh menimpa blok cakera tempat data anda mungkin masih tersimpan.

1. Tutup terminal ejen

   Ganggu arahan berbahaya serta-merta dengan Ctrl+C; jangan tunggu pemadaman selesai. Menghentikan ejen tidak semestinya menghentikan arahan anak, tugas jauh atau pertanyaan pangkalan data. Kenal pasti penulis sebenar dan hentikan atau batalkan operasi itu; tingkatkan penamatan jika ia terus memusnahkan data. Kekalkan proses tidak berkaitan dengan fail terbuka yang mungkin boleh dipulihkan.

2. JANGAN but semula komputer riba

   Data dipadam mungkin masih boleh dipulihkan, tetapi storan, tingkah laku pangkalan data, discard/TRIM SSD dan tulisan berikutnya menentukannya. Minimumkan tulisan pada volum terjejas; jangan anggap bait masih wujud.

3. JANGAN tutup proses yang masih terbuka

   Kekalkan proses tidak berkaitan yang membuka fail dipadam kerana pemulihan mungkin boleh dilakukan melalui deskriptor failnya. Ini tidak terpakai pada penulis pemusnah: hentikannya dahulu. Jangan biarkan pemadaman berjalan hanya untuk mengekalkan pemegang terbuka.

4. Mula merakam skrin

   Rekod masa tepat, laluan terjejas dan output arahan kelihatan. Jika merakam atau menyalin log, simpan pada peranti berasingan disahkan, bukan volum rosak. Simpan fail dijejaki, tidak dijejaki, diabaikan serta metadata Git di situ sebelum mencuba pemulihan.

Seterusnya, 6 minit untuk pemulihan. Mari kita mulakan.

Minit 2–3: dokumentasikan perkara yang berlaku dengan tepat#

Buka tetingkap terminal baharu. Bukan tetingkap yang menjalankan ejen—tetingkap yang lain. Jalankan tiga arahan ini mengikut turutan.

1. Catat dengan tepat perubahan dalam repositori git:

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

Fail dijejaki yang dipadam mungkin masih wujud dalam indeks atau commit. Simpan pepohon kerja semasa, termasuk fail tidak dijejaki dan diabaikan, sebelum sebarang pemulihan; memulihkan pada tempat asal boleh menindih suntingan terselamat. Periksa dan pulihkan dalam salinan berasingan.

2. Semak proses ejen yang sedang berjalan:

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

Kenal pasti proses yang masih melakukan tulisan berbahaya; padanan nama sahaja tidak mencukupi. Hentikan penulis itu dan sahkan ia berhenti. Kekalkan proses tidak berkaitan dengan fail terbuka berguna; jika penamatan biasa gagal dan pemusnahan berterusan, penamatan paksa mungkin diperlukan.

3. Simpan log sesi ejen:

Claude Code menyimpan sesi JSONL dalam ~/.claude/projects/. Cursor menyimpannya dalam ~/.cursor/. Buat salinan sekarang juga:

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

Gantikan /external/incident-evidence/ dengan direktori bukti sedia ada pada peranti berasingan yang disahkan dipasang. Jangan tulis sandaran pada volum terjejas atau tindih bukti sedia ada. Folder ini mengandungi perbualan verbatim dengan ejen—arahan yang dijalankannya, jawapannya dan urutan tindakannya. Inilah sumber utama anda untuk menyiasat insiden dan mungkin memulihkan fail yang dipadam daripada konteks yang dilihat ejen (lihat langkah 4).

Minit 4: git reflog—peluang terbaik anda#

git reflog merekod pergerakan rujukan setempat selagi entri disimpan. Tempoh luput dan pemangkasan berbeza, serta objek tidak boleh dicapai boleh dibuang; ia bukan arkib dijamin setiap commit lalu. Jalankan langkah pemulihan di bawah daripada salinan repositori disimpan pada peranti berasingan.

Langkah 1. Lihat log:

git reflog --all

Anda akan mendapat senarai seperti ini:

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

Cari titik sebelum ejen menyebabkan kerosakan. Setiap entri ialah “syot kilat” keadaan repositori pada waktu itu.

Langkah 2. Pulihkan ke pepohon kerja berasingan:

Selepas menyalin repositori dan semua kerja terselamat ke peranti berasingan, jalankan ini daripada salinan repositori disimpan. Gantikan nilai dengan SHA commit tepat yang diperiksa dalam reflog, dan pilih cabang serta destinasi belum digunakan:

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

Periksa fail dipulihkan dalam ../recovery-check dan bandingkan dengan fail belum dikomit yang disimpan sebelum menyalin kembali apa-apa. Arahan checkout commit dipilih secara berasingan; ia tidak mereset pepohon kerja rosak. Worktree berpaut berkongsi stor objek Git repositori disalin, jadi ini ruang kerja pemulihan, bukan sandaran bebas. Lihat dokumentasi git-worktree rasmi.

Jika reflog juga sudah dibersihkan (ejen sempat menjalankan git gc):

git fsck --lost-found

Arahan ini mencari commit dan blob (objek fail) “hilang” yang tidak lagi dikaitkan dengan mana-mana cabang. Objek tersebut akan muncul dalam .git/lost-found/commit/ dan .git/lost-found/other/. Untuk memulihkan fail daripadanya:

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

Keadaan apabila git reflog TIDAK membantu:

• Fail itu hanya berada dalam pepohon kerja, tanpa commit atau stash → reflog tidak dapat mengesannya
• Lebih 90 hari telah berlalu (nilai gc.reflogExpire standard) dan git gc telah dijalankan
• Seluruh repositori telah dipadam (rm -rf .git)—dalam keadaan itu, anda perlukan Time Machine atau syot kilat

Minit 5: pulihkan pangkalan data daripada sandaran#

Pangkalan data dipadam menggunakan DROP DATABASE, DROP TABLE atau DELETE FROM ... WHERE ... (tanpa klausa WHERE). Apakah yang patut anda lakukan?

Langkah 1. Ketahui sama ada penyedia anda menawarkan PITR:

Langkah 2. Pulihkan ke tika baharu, bukan tika lama:

Jangan sekali-kali memulihkan dengan menindih pangkalan data yang sedang digunakan. Cipta tika baharu daripada sandaran, kemudian tukar aplikasi untuk menggunakannya. Jika berlaku masalah, anda boleh menukar DNS kembali.

Langkah 3. Jika PITR tidak diaktifkan, gunakan syot kilat terkini:

# AWS RDS, senaraikan syot kilat:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Pulihkan daripada syot kilat:
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

Perhatian tentang Supabase, yang mengejutkan ramai orang pada 2026: apabila PITR diaktifkan, sandaran harian berhenti dicipta. Tingkah laku yang berlawanan dengan jangkaan ini boleh menyebabkan anda langsung tiada sandaran. Semak Dashboard → Database → Backups untuk memastikan PITR aktif DAN anda mempunyai syot kilat untuk dipulihkan.

Minit 6: Time Machine, lsof dan syot kilat cakera#

macOS—Time Machine:

# Senaraikan syot kilat:
tmutil listbackups

# Pulihkan fail daripada sandaran terkini:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine membuat syot kilat setiap jam, menyimpan syot kilat setiap jam selama sehari, syot kilat harian selama seminggu dan syot kilat mingguan selama-lamanya. Jika komputer riba anda disambungkan kepada Time Capsule atau pemacu luaran, projek anda tersedia di situ dengan butiran setiap jam.

Linux—fail telah dipadam, tetapi proses masih membukanya:

# Cari semua fail “dipadam” yang masih dibuka oleh proses:
sudo lsof | grep deleted

# Anda akan mendapat baris seperti ini:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Salin fail terus daripada /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Peluang berjaya ialah ~95% jika proses itu belum ditutup. Berfungsi pada ext4, xfs dan btrfs.

macOS—cara yang setara menggunakan lsof:

lsof | grep deleted

Menyalin fail lebih sukar (tiada /proc/), tetapi anda boleh melakukannya dengan lldb:

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

Syot kilat seluruh cakera (Linux, pilihan terakhir):

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

Arahan ini menyimpan seluruh sekatan sebagai imej. Kemudian pulihkan dengan extundelete atau photorec. Peluang pemulihan bergantung pada jumlah data yang telah ditulis ke cakera sejak pemadaman. Jika tiada apa-apa ditulis, peluangnya 80–90%. Jika sistem sudah berjalan selama sejam, peluangnya 20–30%.

Minit 7: bagaimana jika tiada sandaran#

Pilihan 1—sokongan penyedia:

AWS, Yandex Cloud, Google Cloud dan DigitalOcean memulihkan data daripada storan dalaman mereka secara berkala, walaupun selepas bencana yang menimpa pelanggan, khususnya pada pelan berbayar. Buka tiket sokongan, berikan masa tepat insiden dan sertakan tangkapan skrin keadaan tersebut. Kaedah ini paling kerap berjaya dengan penyedia utama yang menyimpan sandaran automatik di pihak mereka. Peluangnya 40–60%; tempoh respons ialah 24–72 jam.

Pilihan 2—pemversian S3:

Jika fail berada dalam S3 (atau Yandex Object Storage) dan pemversian diaktifkan, semua versi wujud secara fizikal; versi tersebut hanya ditandakan sebagai “dipadam”.

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

# Pulihkan satu versi:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Perhatian penting: Claude Code tidak menyimpan sesi selama-lamanya—fail JSONL lama dipadam secara automatik selepas beberapa minggu. Untuk memastikan anda mempunyai sejarah JSONL selama sebulan sekiranya berlaku bencana, salin ~/.claude/projects/ ke pemacu luaran sekali seminggu menggunakan tugas cron ringkas:

# Dalam crontab, setiap Ahad pada 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Percuma dan menyelamatkan anda apabila “semuanya sudah hilang, tiada sandaran dan reflog kosong”.

7 peraturan untuk mengelakkan kejadian ini berulang#

1. Plan Mode sebelum sebarang operasi yang memusnahkan data. Dalam Claude Code:

claude --plan

Ejen membina pelan sebelum bertindak. Anda membacanya, melihat DROP TABLE users lalu membatalkannya. Tanpa Plan Mode, ejen membuat keputusan sendiri dan melaksanakannya dalam milisaat. Ketahui lebih lanjut dalam panduan Plan Mode dalam Claude Code.

2. Hook sebagai pengesan tambahan. Gunakan hook PreToolUse diuji yang membaca JSON peristiwa daripada stdin dan keluar 2 bagi tindakan berisiko tinggi dikesan. Contoh lengkap di bawah meliputi Bash, Write dan Edit; ia bukan sempadan keselamatan dan boleh terlepas operasi tidak langsung. Kekalkan keistimewaan pangkalan data serta sandbox terhad.

3. Pengguna DB baca sahaja untuk ejen. Cipta pengguna berasingan untuk ejen yang tidak mempunyai kebenaran DROP, TRUNCATE atau 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;

Apabila ejen benar-benar perlu menulis, tukar secara manual kepada pengguna lain. Pengguna baca sahaja mencukupi untuk tugasan harian (analisis data, laporan, papan pemuka).

4. Simpan perubahan yang telah disemak dalam Git. Hook PostToolUse dalam .claude/settings.json boleh memaparkan peringatan selepas operasi Write dan Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Semak diff dan buat commit secara manual untuk fail yang dipersetujui sahaja.' >&2"
          }
        ]
      }
    ]
  }
}

Contoh ini hanya memaparkan peringatan; ia tidak menambah fail ke staging atau membuat commit. Semak diff dan buat commit secara manual untuk fail yang dipersetujui sahaja. Reflog tidak menyimpan perubahan yang belum di-commit.

5. Projek sandbox untuk eksperimen. Jangan biarkan ejen bekerja dalam projek yang mengandungi data pelanggan sebenar. Cipta folder ~/sandbox-projects/ yang berasingan, dengan salinan projek dan data sintetik. Gunakannya untuk mencuba arahan, ejen atau pelayan MCP baharu. Jika sesuatu rosak, tiada mudarat berlaku.

6. Syot kilat cakera dengan restic setiap jam.

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

# Cipta repositori:
restic init --repo /external/backups

# Sandarkan projek semasa:
restic --repo /external/backups backup ~/projects

# Jadualkan cron setiap jam:
crontab -e
# Tambah:
0 * * * * restic --repo /external/backups backup ~/projects

Tujuh hari sandaran setiap jam, empat minggu sandaran harian—dan anda sentiasa boleh kembali ke mana-mana titik pada masa lalu. Percuma dan mengambil masa 10 minit untuk disediakan.

7. Arkibkan sesi JSONL Claude Code. Perkara ini sudah disebut di atas, tetapi diulangi sebagai peraturan berasingan: jadualkan rsync mingguan bagi ~/.claude/projects/ ke pemacu luaran. Percuma dan hanya memerlukan satu baris dalam crontab.

Hooks sedia guna untuk menyekat arahan berbahaya#

Gabungkan entri ini ke .claude/settings.json tanpa menggantikan hook sedia ada:

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

Cipta .claude/hooks/check-risk.py dengan skrip Python 3 berikut:

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 membaca peristiwa JSON didokumenkan daripada stdin, memeriksa tool_input.command atau tool_input.file_path dan keluar 2 apabila sepadan. Ia memeriksa Write dan Edit. Uji contoh tidak berbahaya dibenarkan serta contoh disekat sebelum bergantung padanya, dan sahkan Python serta skrip dikonfigurasikan benar-benar bermula.

Ini pengesan leksikal: ia boleh terlepas bendera disusun semula, skrip, alias, arahan dikaburkan, alat lain dan tulisan tidak langsung; ia juga boleh menolak contoh berpetik yang tidak berbahaya. Ia tidak memberikan atau membuang kebenaran OS/pangkalan data. Simpan kelayakan produksi di luar persekitaran ejen, gunakan peranan pangkalan data baca sahaja serta sandbox dikuatkuasakan, dan lindungi konfigurasi hook daripada perubahan. Lihat rujukan rasmi input hook dan kod keluar.

Untuk operasi pengecualian disengajakan, semak dan jalankan di luar ejen dengan akaun terhad sesuai. Pemboleh ubah persekitaran shell bukan antara muka penyahaktifan hook didokumenkan, dan hook tidak mengawal arahan terminal biasa.

Bila perlu memberikan kebenaran kepada AI (dan bila tidak)#

Anthropic mendokumenkan bendera --dangerously-skip-permissions (juga dikenali sebagai mod YOLO) sebagai pilihan untuk “persekitaran yang dipercayai”. Dalam realiti 2026, ini ialah jalan terus menuju bencana. Apabila ejen tidak perlu meminta kebenaran, ejen akan:

• Menjalankan sebarang arahan Bash tanpa pengesahan
• Menulis fail tanpa bertanya
• Memanggil subejen yang mewarisi YOLO dan tiada cara untuk membatalkannya

Perkara ketiga paling berbahaya. Jika anda memulakan ejen utama dengan YOLO, subejennya juga menggunakan YOLO dan anda tidak boleh mengatasinya. Satu arahan—dan rangkaian 10 ejen selari boleh melakukan apa-apa sahaja pada sistem anda.

Peraturan:

Alternatif—kebenaran tepat. Dalam .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/*)"
    ]
  }
}

Ejen dapat melihat perkara yang dibenarkan dan dilarang. Anda tidak perlu mengklik “ya” atau “tidak” setiap kali—ejen bekerja dengan pantas dan anda mengawal sempadannya.

Seterusnya: senarai semak 7 minit untuk disimpan dalam penanda buku#

Senarai semak: “AI memadamnya—apa yang perlu saya buat?”

1. Hentikan penulis pemusnah sebenar serta-merta; sahkan operasi anak atau jauh berhenti
2. Jangan but semula; kekalkan proses tidak berkaitan yang membuka fail dipadam
3. Rekod masa insiden dan bukti arahan pada peranti berasingan disahkan
4. Salin fail terselamat, metadata Git dan log sesi relevan ke peranti berasingan itu
5. Dalam salinan repositori disimpan, periksa git reflog --all dan pulihkan commit disahkan ke worktree berasingan
6. Jika git tidak membantu—git fsck --lost-found
7. Pangkalan data: PITR (AWS/Yandex/Supabase) atau syot kilat terkini
8. Fail: Time Machine pada Mac, lsof pada Linux
9. Pilihan terakhir: sokongan penyedia + pemversian S3
10. Selepas pemulihan, konfigurasikan 7 peraturan pencegahan dalam panduan ini

Seterusnya—perlindungan sistematik:

• Plan Mode dalam Claude Code—supaya ejen menyediakan pelan sebelum operasi yang memusnahkan data
• Hooks dalam Claude Code—templat sedia guna untuk menyekat arahan berbahaya
• Cara mengundurkan perubahan dalam Claude Code—panduan terperinci tentang /rewind, git dan 5 kaedah undur semula standard
• Semakan keselamatan dalam Claude Code—semakan keselamatan kod secara berkala

Buka Ailoot.