AI menghapus database: rencana pemulihan 7 menit

Informasi praktis tentang bekerja dengan Ailoot tersedia di dokumentasi.

Yang harus dilakukan pada menit pertama: BERHENTI, jangan panik#

Saat hal ini terjadi pada Anda, hal pertama yang harus dilakukan adalah menghentikan agen. Jangan mencoba membatalkan tindakannya sendiri, jangan menyuruhnya “pulihkan semuanya”, dan jangan menjalankan prompt baru. Setiap tindakan agen berikutnya dapat menimpa blok disk tempat data Anda mungkin masih tersimpan.

1. Tutup terminal agen

   Interupsi perintah berbahaya segera dengan Ctrl+C; jangan tunggu penghapusan selesai. Menghentikan agen belum tentu menghentikan perintah anak, pekerjaan remote, atau kueri basis data. Identifikasi penulis sebenarnya dan hentikan atau batalkan operasi itu; tingkatkan penghentian jika terus menghancurkan data. Pertahankan proses tidak terkait yang mungkin membuka file yang dapat dipulihkan.

2. JANGAN reboot laptop Anda

   Data terhapus mungkin masih dapat dipulihkan, tetapi penyimpanan, perilaku basis data, discard/TRIM SSD, dan penulisan berikutnya menentukan hal itu. Minimalkan penulisan ke volume terdampak; jangan menganggap byte-nya masih ada.

3. JANGAN tutup proses yang masih terbuka

   Pertahankan proses tidak terkait yang membuka file terhapus, karena pemulihan mungkin dapat dilakukan melalui deskriptor file. Ini tidak berlaku bagi penulis destruktif: hentikan penulis itu terlebih dahulu. Jangan membiarkan penghapusan terus berjalan hanya demi mempertahankan handle terbuka.

4. Mulai perekaman layar

   Catat waktu tepat, jalur terdampak, serta keluaran perintah yang terlihat. Jika merekam atau menyalin log, simpan ke perangkat terpisah terverifikasi, bukan volume rusak. Simpan file terlacak, tidak terlacak, diabaikan yang bertahan beserta metadata Git di sana sebelum mencoba pemulihan.

Berikutnya, 6 menit untuk memulihkan data. Mari mulai.

Menit 2–3: dokumentasikan dengan tepat apa yang salah#

Buka jendela terminal baru. Bukan jendela tempat agen berjalan—jendela lain. Jalankan tiga perintah berikut secara berurutan.

1. Catat dengan tepat apa yang berubah di repositori git:

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

File terlacak yang terhapus mungkin masih ada dalam indeks atau commit. Simpan working tree saat ini, termasuk file tidak terlacak dan diabaikan, sebelum operasi pemulihan; memulihkan di tempat dapat menimpa edit yang bertahan. Periksa dan pulihkan pada salinan terpisah.

2. Periksa proses agen yang sedang berjalan:

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

Identifikasi proses mana yang masih melakukan penulisan berbahaya; kecocokan nama saja tidak cukup. Hentikan penulis itu dan verifikasi sudah berhenti. Pertahankan proses tidak terkait dengan file terbuka yang berguna; jika penghentian halus gagal dan kerusakan berlanjut, penghentian paksa mungkin diperlukan.

3. Simpan log sesi agen:

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

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

Ganti /external/incident-evidence/ dengan direktori bukti yang sudah ada pada perangkat terpasang terpisah yang terverifikasi. Jangan menulis cadangan pada volume terdampak atau menimpa bukti yang ada. Folder ini berisi percakapan lengkap dengan agen—perintah yang dijalankannya, balasannya, dan urutannya. Ini adalah sumber utama untuk menyelidiki insiden dan mungkin memulihkan file yang dihapus dari konteksnya (lihat langkah 4).

Menit 4: git reflog—peluang terbaik Anda#

git reflog mencatat perpindahan referensi lokal selama entri masih dipertahankan. Kedaluwarsa serta pruning bervariasi, dan objek tak terjangkau dapat dihapus; ini bukan arsip terjamin dari setiap commit terdahulu. Jalankan langkah pemulihan di bawah dari salinan repositori yang disimpan pada perangkat terpisah.

Langkah 1. Lihat log:

git reflog --all

Anda akan mendapatkan daftar 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 agen menyebabkan kerusakan. Setiap entri adalah “snapshot” keadaan repositori pada saat itu.

Langkah 2. Pulihkan ke working tree terpisah:

Setelah menyalin repositori dan seluruh pekerjaan yang bertahan ke perangkat terpisah, jalankan dari salinan repositori yang disimpan tersebut. Ganti nilai dengan SHA commit tepat yang diperiksa di reflog, dan pilih cabang serta tujuan yang belum dipakai:

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

Periksa file yang dipulihkan dalam ../recovery-check dan bandingkan dengan file belum di-commit yang disimpan sebelum menyalin apa pun kembali. Perintah melakukan checkout commit terpilih secara terpisah; perintah tidak mereset working tree rusak. Worktree tertaut berbagi penyimpanan objek Git repositori salinan, jadi ini ruang kerja pemulihan, bukan cadangan independen. Lihat dokumentasi git-worktree resmi.

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

git fsck --lost-found

Perintah ini mencari commit dan blob (objek file) “hilang” yang tidak lagi terhubung ke cabang mana pun. Objek itu akan muncul di .git/lost-found/commit/ dan .git/lost-found/other/. Untuk memulihkan file darinya:

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

Kapan git reflog TIDAK membantu:

• File hanya ada di working tree, tanpa commit atau stash → reflog tidak dapat melihatnya
• Lebih dari 90 hari telah berlalu (standar gc.reflogExpire) dan git gc telah dijalankan
• Seluruh repositori dihapus (rm -rf .git)—saat itu Anda memerlukan Time Machine atau snapshot

Menit 5: pulihkan database dari cadangan#

Database dihapus dengan DROP DATABASE, DROP TABLE, atau DELETE FROM ... WHERE ... (tanpa klausa WHERE). Apa yang harus Anda lakukan?

Langkah 1. Cari tahu apakah penyedia Anda menawarkan PITR:

Langkah 2. Pulihkan ke instans baru, bukan ke instans lama:

Jangan pernah memulihkan dengan menimpa database aktif. Buat instans baru dari cadangan, lalu alihkan aplikasi ke sana. Jika terjadi masalah, Anda dapat mengembalikan DNS.

Langkah 3. Jika PITR belum diaktifkan, gunakan snapshot terbaru:

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

# Pulihkan dari 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

Catatan tentang Supabase, yang mengejutkan banyak orang pada 2026: saat PITR diaktifkan, pencadangan harian berhenti dibuat. Perilaku yang berlawanan dengan dugaan; Anda bisa berakhir tanpa cadangan sama sekali. Periksa Dashboard → Database → Backups untuk memastikan PITR aktif DAN Anda memiliki snapshot untuk dipulihkan.

Menit 6: Time Machine, lsof, dan snapshot disk#

macOS—Time Machine:

# Daftar snapshot:
tmutil listbackups

# Pulihkan file dari cadangan terbaru:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine membuat snapshot setiap jam, menyimpan snapshot per jam selama sehari dan snapshot harian selama seminggu, serta snapshot mingguan tanpa batas waktu. Jika laptop Anda terhubung ke Time Capsule atau drive eksternal, proyek Anda tersedia dengan perincian per jam.

Linux—file dihapus, tetapi masih terbuka oleh suatu proses:

# Temukan semua file “terhapus” yang masih terbuka oleh suatu proses:
sudo lsof | grep deleted

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

# Salin file langsung dari /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Peluang keberhasilannya ~95% jika prosesnya belum ditutup. Berfungsi di ext4, xfs, btrfs.

macOS—padanannya menggunakan lsof:

lsof | grep deleted

Menyalin file lebih sulit (tidak ada /proc/), tetapi Anda dapat melakukannya dengan lldb:

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

Snapshot seluruh disk (Linux, pilihan terakhir):

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

Perintah ini menyimpan seluruh partisi sebagai citra. Lalu pulihkan dengan extundelete atau photorec. Peluang pemulihan bergantung pada banyaknya data yang telah ditulis ke disk sejak penghapusan. Jika belum ada data yang ditulis, peluangnya 80–90%. Jika perangkat sudah berjalan selama satu jam, peluangnya 20–30%.

Menit 7: bagaimana jika tidak ada cadangan#

Pilihan 1—dukungan penyedia:

AWS, Yandex Cloud, Google Cloud, dan DigitalOcean sesekali memulihkan data dari penyimpanan internal mereka, bahkan setelah bencana yang dialami pelanggan, terutama pada paket berbayar. Buat tiket dukungan, berikan waktu pasti insiden, dan sertakan tangkapan layar kondisinya. Cara ini paling sering berhasil pada penyedia besar yang menyimpan cadangan otomatis di sisi mereka. Peluangnya 40–60%; rentang waktu responsnya 24–72 jam.

Pilihan 2—versioning S3:

Jika file berada di S3 (atau Yandex Object Storage) dan versioning diaktifkan, semua versi ada secara fisik; versinya hanya ditandai sebagai “terhapus”.

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

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

Catatan kritis: Claude Code tidak menyimpan sesi selamanya—file JSONL lama dihapus secara otomatis setelah beberapa minggu. Agar Anda memiliki riwayat JSONL selama sebulan jika terjadi bencana, salin ~/.claude/projects/ ke drive eksternal seminggu sekali dengan cron job sederhana:

# Di crontab, setiap Minggu pukul 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Gratis dan akan menyelamatkan Anda ketika “semuanya hilang, tidak ada cadangan, dan reflog kosong.”

7 aturan untuk memastikan hal ini tidak terjadi lagi#

1. Plan Mode sebelum operasi destruktif apa pun. Di Claude Code:

claude --plan

Agen menyusun rencana sebelum bertindak. Anda membacanya, melihat DROP TABLE users, lalu membatalkan. Tanpa Plan Mode, agen memutuskan sendiri dan mengeksekusi dalam hitungan milidetik. Pelajari selengkapnya di panduan Plan Mode di Claude Code.

2. Hook sebagai pengaman tambahan. Gunakan hook PreToolUse teruji yang membaca JSON peristiwa dari stdin dan keluar dengan 2 untuk tindakan berisiko tinggi yang terdeteksi. Contoh lengkap di bawah mencakup Bash, Write, dan Edit; ini bukan batas keamanan dan dapat melewatkan operasi tidak langsung. Pertahankan hak basis data serta sandbox yang terbatas.

3. Pengguna DB hanya-baca untuk agen. Buat pengguna terpisah untuk agen yang tidak memiliki izin 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;

Saat agen benar-benar perlu menulis, beralihlah ke pengguna lain secara manual. Pengguna hanya-baca cukup untuk tugas sehari-hari (analisis data, laporan, dashboard).

4. Simpan perubahan yang sudah ditinjau di Git. Hook PostToolUse di .claude/settings.json dapat menampilkan pengingat setelah operasi Write dan Edit:

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

Contoh ini hanya menampilkan pengingat; tidak menambahkan file ke staging atau membuat commit. Tinjau diff dan buat commit secara manual hanya untuk file yang disepakati. Reflog tidak menyimpan perubahan yang belum di-commit.

5. Proyek sandbox untuk eksperimen. Jangan biarkan agen bekerja dalam proyek yang berisi data pelanggan sungguhan. Buat folder ~/sandbox-projects/ terpisah, dengan salinan proyek dan data sintetis. Gunakan untuk mencoba prompt, agen, atau server MCP baru. Jika terjadi kerusakan, tidak ada dampaknya.

6. Snapshot disk dengan restic setiap jam.

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

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

# Cadangkan proyek saat ini:
restic --repo /external/backups backup ~/projects

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

Cadangan per jam selama tujuh hari, cadangan harian selama empat minggu—dan Anda selalu dapat kembali ke titik mana pun di masa lalu. Gratis dan hanya membutuhkan 10 menit untuk disiapkan.

7. Arsipkan sesi JSONL Claude Code. Sudah disebutkan di atas, tetapi diulangi sebagai aturan terpisah: jadwalkan rsync mingguan dari ~/.claude/projects/ ke drive eksternal. Gratis dan cukup satu baris di crontab.

Hooks siap pakai untuk memblokir perintah berbahaya#

Gabungkan entri ini ke .claude/settings.json tanpa mengganti hook yang ada:

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

Buat .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 terdokumentasi dari stdin, memeriksa tool_input.command atau tool_input.file_path, dan keluar dengan 2 ketika cocok. Hook memeriksa Write dan Edit. Uji contoh aman yang diizinkan serta contoh diblokir sebelum mengandalkannya, dan pastikan Python serta skrip yang dikonfigurasi benar-benar dimulai.

Ini pengaman leksikal: urutan flag berbeda, skrip, alias, perintah yang dikaburkan, alat lain, dan penulisan tidak langsung dapat terlewat; contoh kutipan yang aman juga dapat ditolak. Hook tidak memberi atau menghapus izin OS/basis data. Jauhkan kredensial produksi dari lingkungan agen, gunakan peran basis data hanya-baca serta sandbox yang ditegakkan, dan lindungi konfigurasi hook dari perubahan. Lihat referensi resmi masukan hook dan kode keluar.

Untuk operasi pengecualian yang disengaja, tinjau dan jalankan di luar agen dengan akun terbatas yang sesuai. Variabel lingkungan shell bukan antarmuka penonaktifan hook yang terdokumentasi, dan hook tidak mengatur perintah terminal biasa.

Kapan memberi AI izin (dan kapan tidak)#

Anthropic mendokumentasikan flag --dangerously-skip-permissions (juga dikenal sebagai mode YOLO) sebagai pilihan untuk “lingkungan tepercaya”. Dalam kenyataan tahun 2026, ini adalah jalan langsung menuju bencana. Ketika agen tidak perlu meminta izin, ia:

• Menjalankan perintah Bash apa pun tanpa konfirmasi
• Menulis file tanpa bertanya
• Dapat memanggil subagen, yang mewarisi YOLO tanpa cara untuk membatalkannya

Poin ketiga paling berbahaya. Jika Anda memulai agen utama dengan YOLO, subagennya juga menggunakan YOLO, dan Anda tidak dapat menimpanya. Satu prompt—dan rangkaian 10 agen paralel dapat melakukan apa pun pada sistem Anda.

Aturan:

Alternatif—izin presisi. Di .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/*)"
    ]
  }
}

Agen melihat apa yang diizinkan dan tidak diizinkan. Anda tidak perlu mengeklik “ya” atau “tidak” setiap kali—agen dapat bekerja cepat, dan Anda mengendalikan batasannya.

Berikutnya: daftar periksa 7 menit untuk disimpan#

Daftar periksa: “AI menghapusnya—apa yang harus saya lakukan?”

1. Hentikan penulis destruktif sebenarnya segera; pastikan operasi anak atau remote sudah berhenti
2. Jangan reboot; pertahankan proses tidak terkait yang membuka file terhapus
3. Catat waktu insiden dan bukti perintah pada perangkat terpisah terverifikasi
4. Salin file yang bertahan, metadata Git, dan log sesi relevan ke perangkat terpisah tersebut
5. Pada salinan repositori yang disimpan, periksa git reflog --all dan pulihkan commit terverifikasi ke worktree terpisah
6. Jika git tidak membantu—git fsck --lost-found
7. Database: PITR (AWS/Yandex/Supabase) atau snapshot terbaru
8. File: Time Machine di Mac, lsof di Linux
9. Pilihan terakhir: dukungan penyedia + versioning S3
10. Setelah pemulihan, konfigurasi 7 aturan pencegahan dalam panduan ini

Berikutnya—perlindungan sistematis:

• Plan Mode di Claude Code—agar agen membuat rencana sebelum operasi destruktif
• Hooks di Claude Code—templat siap pakai untuk memblokir perintah berbahaya
• Cara membatalkan perubahan di Claude Code—panduan terperinci tentang /rewind, git, dan 5 metode pembatalan standar
• Tinjauan keamanan di Claude Code—pemeriksaan keamanan kode secara berkala

Kunjungi Ailoot.