Az AI törölte az adatbázist: 7 perces helyreállítási terv

Az Ailoot használatával kapcsolatos gyakorlati információk a dokumentációban találhatók.

Teendők az első percben: ÁLLJON MEG, ne essen pánikba#

Ha ez történik Önnel, az első teendő az ügynök leállítása. Ne próbálja saját maga visszavonni a műveleteit, ne kérje tőle, hogy „állítson helyre mindent”, és ne futtasson új promptokat. Az ügynök minden további művelete felülírhatja azokat a lemezblokkokat, ahol az adatai még tárolódhatnak.

1. Zárja be az ügynök terminálját

   A veszélyes parancsot azonnal szakítsa meg Ctrl+C-vel; ne várja meg a törlés végét. Az ügynök leállása nem feltétlenül állítja le gyermekparancsait, távoli feladatait vagy adatbázis-lekérdezését. Azonosítsa a tényleges írót, és azt állítsa le vagy szakítsa meg; folytatódó adatrombolásnál fokozza a leállítást. A visszanyerhető fájlt nyitva tartó független folyamatokat hagyja életben.

2. NE indítsa újra a laptopját

   Törölt adat visszanyerhető maradhat, de ezt a tároló, adatbázis-működés, SSD discard/TRIM és későbbi írás határozza meg. Minimalizálja az érintett kötet írásait; ne feltételezze a bájtok megmaradását.

3. NE zárja be a nyitott folyamatokat

   Őrizze meg a törölt fájlt nyitva tartó független folyamatokat, mert fájlleíróikon át lehetséges lehet a visszanyerés. Ez a romboló íróra nem vonatkozik: azt előbb állítsa le. Nyitott fájlleíró kedvéért ne hagyjon tovább futni törlést.

4. Indítson képernyőfelvételt

   Rögzítse a pontos időt, érintett útvonalakat és látható parancskimenetet. Felvételt vagy másolt naplót külön ellenőrzött eszközre mentsen, ne a sérült kötetre. Helyreállítás előtt ott őrizze meg a fennmaradt követett, nem követett, kizárt fájlokat és Git-metaadatokat.

Ezután 6 perc áll rendelkezésére a helyreállításhoz. Lássunk hozzá.

2–3. perc: dokumentálja pontosan, mi történt#

Nyisson egy új terminálablakot. Ne azt, amelyikben az ügynök fut—egy másikat. Futtassa egymás után ezt a három parancsot.

1. Rögzítse pontosan, mi változott a git-tárolóban:

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

Törölt követett fájl még létezhet az indexben vagy commitban. Bármilyen restore előtt őrizze meg a jelenlegi munkafát, a nem követett és kizárt fájlokkal együtt; a helyben visszaállítás felülírhat megmaradt szerkesztéseket. Külön másolatban vizsgáljon és nyerjen vissza.

2. Ellenőrizze, mely ügynökfolyamatok futnak:

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

Azonosítsa a veszélyes írást ténylegesen végző folyamatot; névegyezés nem elég. Azt állítsa le, és igazolja a leállást. Hasznos nyitott fájlt tartó független folyamatot őrizzen meg; sikertelen kíméletes leállítás és folytatódó rombolás esetén kényszerített leállítás is szükséges lehet.

3. Mentse el az ügynök munkamenetnaplóját:

A Claude Code a JSONL-munkameneteket a ~/.claude/projects/ mappában tárolja. A Cursor a ~/.cursor/ mappában tárolja őket. Készítsen másolatot most azonnal:

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

A /external/incident-evidence/ helyett külön ellenőrzött, csatolt eszköz meglévő bizonyítékkönyvtárát adja meg. Ne az érintett kötetre mentsen, és ne írjon felül meglévő bizonyítékot. Ez a mappa az ügynökkel folytatott szó szerinti beszélgetést tartalmazza—milyen parancsokat futtatott, mit válaszolt és milyen sorrendben. Ez az incidens kivizsgálásának fő forrása, és a kontextus alapján a törölt fájlok helyreállításában is segíthet (lásd a 4. lépést).

4. perc: git reflog—a legjobb esélye#

A git reflog a helyi hivatkozásmozgásokat rögzíti, amíg a bejegyzések megmaradnak. A lejárat és törlés változó, az elérhetetlen objektumok eltávolíthatók; nem minden korábbi commit garantált archívuma. Az alábbi visszanyerést a külön eszközön őrzött tárolómásolatból futtassa.

1. lépés. Tekintse meg a naplót:

git reflog --all

Ehhez hasonló listát fog kapni:

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

Keresse meg azt az állapotot, amely megelőzte az ügynök által okozott kárt. Minden bejegyzés a tároló akkori állapotának „pillanatképe”.

2. lépés. Visszanyerés külön munkafába:

A tároló és minden megmaradt munka külön eszközre másolása után ezt az őrzött tárolómásolatból futtassa. Az értéket a reflogban ellenőrzött pontos commit-SHA-ra cserélje, és még nem használt ágat és célhelyet válasszon:

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

Nézze át a ../recovery-check visszanyert fájljait, és bármi visszamásolása előtt vesse össze a megőrzött nem commitolt fájlokkal. A parancs külön választja ki a commitot, nem reseteli a sérült munkafát. A kapcsolt worktree-k a másolt tároló Git-objektumtárát használják közösen, ezért ez helyreállítási munkatér, nem független mentés. Lásd a hivatalos git-worktree dokumentációt.

Ha a reflogot is törölték (az ügynöknek sikerült futtatnia a git gc parancsot):

git fsck --lost-found

Ez a parancs megkeresi azokat az „elveszett” commitokat és blobokat (fájlobjektumokat), amelyek már egyetlen ághoz sem kapcsolódnak. Ezek a .git/lost-found/commit/ és .git/lost-found/other/ mappában jelennek meg. Fájl helyreállításához onnan:

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

Amikor a git reflog NEM segít:

• A fájl csak a working tree-ben volt, commit vagy stash nélkül → a reflog nem látja
• Több mint 90 nap telt el (a szabványos gc.reflogExpire érték), és lefutott a git gc
• A teljes tárolót törölték (rm -rf .git)—ekkor Time Machine-re vagy pillanatképre lesz szüksége

5. perc: állítsa vissza az adatbázist biztonsági másolatból#

Az adatbázist a DROP DATABASE, DROP TABLE vagy DELETE FROM ... WHERE ... paranccsal törölték (WHERE záradék nélkül). Mit tegyen?

1. lépés. Nézze meg, kínál-e a szolgáltatója PITR-t:

2. lépés. Új példányra állítsa vissza, ne a régire:

Soha ne állítson vissza élő adatbázisra. Hozzon létre új példányt a biztonsági másolatból, majd állítsa át rá az alkalmazást. Ha valami rosszul sül el, visszaállíthatja a DNS-t.

3. lépés. Ha a PITR nem volt engedélyezve, használja a legutóbbi pillanatképet:

# AWS RDS, pillanatképek listázása:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Visszaállítás pillanatképből:
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

Fontos tudnivaló a Supabase-ről, amely 2026-ban sokakat meglepett: ha a PITR engedélyezve van, a napi biztonsági másolatok készítése leáll. Ez ellentmond a várakozásoknak; előfordulhat, hogy egyáltalán nem marad biztonsági másolata. Ellenőrizze a Dashboard → Database → Backups részt, hogy a PITR aktív-e, ÉS van-e visszaállítható pillanatképe.

6. perc: Time Machine, lsof és lemezpillanatképek#

macOS—Time Machine:

# Pillanatképek listázása:
tmutil listbackups

# Fájl visszaállítása a legutóbbi biztonsági másolatból:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

A Time Machine óránként készít pillanatképeket, egy napig megőrzi az óránkéntieket, egy hétig a naponta készülőket, a hetieket pedig határozatlan ideig. Ha laptopja Time Capsule-hoz vagy külső meghajtóhoz csatlakozik, a projekt óránkénti részletességgel rendelkezésre áll.

Linux—a fájlt törölték, de egy folyamat még nyitva tartja:

# Az összes olyan „törölt” fájl megkeresése, amelyet még nyitva tart egy folyamat:
sudo lsof | grep deleted

# Ilyen sorokat fog látni:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# A fájl közvetlen másolása a /proc/PID/fd/N útvonalról:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Ha a folyamatot nem zárták be, a siker esélye ~95%. ext4, xfs és btrfs fájlrendszereken működik.

macOS—az lsof megfelelője:

lsof | grep deleted

A fájl másolása nehezebb (nincs /proc/), de az lldb segítségével megteheti:

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

A teljes lemez pillanatképe (Linux, végső megoldás):

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

Ez a teljes partíciót lemezképként menti el. Ezután állítsa helyre az adatokat az extundelete vagy a photorec segítségével. A helyreállítás esélye attól függ, mennyi adatot írtak a lemezre a törlés óta. Ha azóta semmit sem írtak rá, az esély 80–90%. Ha a rendszer már egy órája fut, az esély 20–30%.

7. perc: mi van, ha nincs biztonsági másolat#

1. lehetőség—a szolgáltató támogatása:

Az AWS, a Yandex Cloud, a Google Cloud és a DigitalOcean időnként visszaállít adatokat a belső tárhelyéről, ügyféloldali katasztrófa után is, különösen a fizetős csomagoknál. Nyisson támogatási jegyet, adja meg az incidens pontos időpontját, és mellékeljen képernyőképeket az állapotról. Ez leggyakrabban azoknál a nagy szolgáltatóknál működik, amelyek a saját oldalukon automatikus biztonsági másolatokat őriznek. Az esély 40–60%; a válaszra 24–72 órát kell várni.

2. lehetőség—S3-verziókezelés:

Ha a fájlok az S3-ban (vagy a Yandex Object Storage-ban) voltak, és a verziókezelés engedélyezve volt, minden verzió fizikailag létezik; csupán „töröltként” van megjelölve.

# AWS—verziók listázása:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Egy verzió visszaállítása:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Kritikus tudnivaló: a Claude Code nem őrzi meg örökké a munkameneteket—a régi JSONL-fájlok néhány hét után automatikusan törlődnek. Ha katasztrófa esetére egy hónapnyi JSONL-előzményt szeretne megőrizni, hetente egyszer másolja a ~/.claude/projects/ mappát egy külső meghajtóra egy egyszerű cronfeladattal:

# A crontabban, minden vasárnap 03:00-kor:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Ingyenes, és megmenti, amikor „minden elveszett, nincs biztonsági másolat, és a reflog is üres”.

7 szabály, hogy ez soha többé ne történjen meg#

1. Plan Mode minden destruktív művelet előtt. A Claude Code-ban:

claude --plan

Az ügynök mielőtt cselekedne, tervet készít. Elolvassa, meglátja benne a DROP TABLE users parancsot, és megszakítja. Plan Mode nélkül az ügynök maga dönt, és milliszekundumok alatt végrehajtja a műveletet. További információ a Plan Mode a Claude Code-ban útmutatóban.

2. Hookok kiegészítő jelzőként. Tesztelt PreToolUse hookot használjon, amely stdinről olvassa az esemény JSON-ját, és észlelt kockázatos műveletnél 2-vel lép ki. Az alábbi teljes példa Bash, Write és Edit eszközöket fed; nem biztonsági határ, és közvetett műveleteket kihagyhat. Az adatbázisjogok és sandbox maradjanak korlátozottak.

3. Csak olvasási jogosultságú DB-felhasználó az ügynöknek. Hozzon létre külön felhasználót az ügynök számára, akinek nincs DROP, TRUNCATE vagy DELETE jogosultsága:

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;

Ha az ügynöknek valóban írnia kell, manuálisan váltson egy másik felhasználóra. A csak olvasási jogosultságú felhasználó elegendő a mindennapi feladatokhoz (adatelemzés, jelentések, irányítópultok).

4. Az ellenőrzött változtatásokat mentse Gitbe. A .claude/settings.json fájlban egy PostToolUse hook emlékeztetőt írhat ki a Write és Edit műveletek után:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Ellenőrizze a diffet, és kézzel csak a megbeszélt fájlokat commitolja.' >&2"
          }
        ]
      }
    ]
  }
}

Ez a példa csak emlékeztetőt ír ki; nem ad fájlokat az indexhez, és nem készít commitot. Ellenőrizze a diffet, és kézzel csak a megbeszélt fájlokat commitolja. A reflog nem menti a commitba nem került változtatásokat.

5. Sandboxprojekt a kísérletekhez. Ne engedje, hogy az ügynök olyan projektben dolgozzon, amely valódi ügyféladatokat tartalmaz. Hozzon létre külön ~/sandbox-projects/ mappát a projekt másolatával és szintetikus adatokkal. Itt próbáljon ki új promptot, ügynököt vagy MCP-szervert. Ha valami elromlik, nem történik baj.

6. Lemez-pillanatképek a restic segítségével óránként.

# Telepítés:
brew install restic  # macOS
sudo apt install restic  # Linux

# Tároló létrehozása:
restic init --repo /external/backups

# Az aktuális projekt biztonsági mentése:
restic --repo /external/backups backup ~/projects

# Óránkénti cronfeladat ütemezése:
crontab -e
# Adja hozzá:
0 * * * * restic --repo /external/backups backup ~/projects

Hét napnyi óránkénti és négy hétig napi biztonsági másolat—így bármikor visszaállhat egy korábbi állapotra. Ingyenes, és 10 perc alatt beállítható.

7. Archiválja a Claude Code JSONL-munkameneteket. Már említettük fent, de külön szabályként is megismételjük: ütemezze a ~/.claude/projects/ mappa heti rsync-másolását egy külső meghajtóra. Ingyenes, és egyetlen crontab-sorra van szükség.

Kész hookok veszélyes parancsok blokkolására#

E bejegyzést a meglévő hookok cseréje nélkül illessze a .claude/settings.json fájlba:

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

Hozza létre a .claude/hooks/check-risk.py fájlt e Python 3-szkripttel:

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)

A hook a dokumentált JSON-eseményt stdinről olvassa, a tool_input.command vagy tool_input.file_path mezőt vizsgálja, egyezésnél 2-vel lép ki. Write és Edit esetén is ellenőriz. Támaszkodás előtt ártalmatlan engedett és blokkolt mintát teszteljen, és igazolja a Python és beállított szkript tényleges indulását.

Ez lexikai jelző: átrendezett kapcsolókat, szkripteket, aliasokat, elrejtett parancsokat, más eszközöket és közvetett írásokat kihagyhat; ártalmatlan idézett példát is elutasíthat. Operációsrendszer- vagy adatbázisjogot nem ad és nem vesz el. Az éles hitelesítő adatokat tartsa az ügynök környezetén kívül, használjon csak olvasó adatbázisszerepet és kikényszerített sandboxot, és védje a hook konfigurációját a módosítástól. Lásd a hivatalos hookbemeneti és kilépésikód-referenciát.

Szándékos kivételes műveletet nézzen át, és az ügynökön kívül, megfelelően korlátozott fiókkal futtassa. A shell-környezeti változó nem dokumentált hookkikapcsolási felület, a hookok pedig nem szabályozzák a szokásos terminálparancsokat.

Mikor adjon jogosultságokat az AI-nak (és mikor ne)#

Az Anthropic a --dangerously-skip-permissions jelzőt (más néven YOLO módot) „megbízható környezetekhez” használható lehetőségként dokumentálja. A 2026-os valóságban ez egyenes út a katasztrófához. Ha az ügynöknek nem kell engedélyt kérnie, akkor:

• Bármilyen Bash-parancsot megerősítés nélkül lefuttat
• Kérdezés nélkül ír fájlokat
• Elindíthat egy alügynököt, amely örökli a YOLO módot, és ezt nem lehet visszavonni

A harmadik pont a legveszélyesebb. Ha a fő ügynököt YOLO módban indítja, az alügynökei is YOLO módban lesznek, és ezt nem írhatja felül. Egy prompt—és 10 párhuzamos ügynökből álló láncolat bármit megtehet a rendszerén.

Szabály:

Alternatíva—pontos jogosultságok. A .claude/settings.json fájlban:

{
  "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/*)"
    ]
  }
}

Az ügynök látja, mi engedélyezett és mi nem. Nem kell minden alkalommal az „igen” vagy a „nem” gombra kattintania—az ügynök gyorsan dolgozhat, Ön pedig szabályozza a határokat.

Következő lépés: egy 7 perces ellenőrzőlista könyvjelzőbe mentéshez#

Ellenőrzőlista: „Az AI törölte—mit tegyek?”

1. Azonnal állítsa le a tényleges romboló írót; igazolja a gyermek- vagy távoli műveletek leállását
2. Ne indítsa újra; őrizze meg a törölt fájlt nyitva tartó független folyamatokat
3. Külön ellenőrzött eszközön rögzítse az incidens idejét és parancsbizonyítékát
4. A fennmaradt fájlokat, Git-metaadatokat és releváns munkamenetnaplókat másolja ugyanarra a külön eszközre
5. Az őrzött tárolómásolatban nézze meg a git reflog --all eredményét, és igazolt commitot nyerjen vissza külön worktree-be
6. Ha a git nem segített—git fsck --lost-found
7. Adatbázis: PITR (AWS/Yandex/Supabase) vagy a legutóbbi pillanatkép
8. Fájlok: Time Machine Macen, lsof Linuxon
9. Végső lehetőség: szolgáltatói támogatás + S3-verziókezelés
10. A helyreállítás után állítsa be az útmutató 7 megelőző szabályát

Következő lépés—szisztematikus védelem:

• Plan Mode a Claude Code-ban—hogy az ügynök mielőtt destruktív műveletet végezne, tervet készítsen
• Hooks a Claude Code-ban—kész sablonok veszélyes parancsok blokkolására
• Változtatások visszavonása a Claude Code-ban—részletes útmutató a /rewind, a git és 5 szokásos visszaállítási módszer használatához
• Biztonsági felülvizsgálat a Claude Code-ban—rendszeres kód-biztonsági ellenőrzések

Ailoot megnyitása.