AI vymazala databázu: 7-minútový plán obnovy

Praktické informácie o práci s Ailoot nájdete v dokumentácii.

Čo robiť počas prvej minúty: ZASTAVTE SA, nepanikárte#

Keď sa vám to stane, prvá vec, ktorú musíte urobiť, je zastaviť agenta. Nepokúšajte sa jeho kroky sami vrátiť späť, nehovorte mu „obnov všetko“ a nespúšťajte nové prompty. Každá ďalšia akcia agenta môže prepísať bloky disku, na ktorých môžu byť vaše údaje stále uložené.

1. Zatvorte terminál agenta

   Nebezpečný príkaz ihneď prerušte cez Ctrl+C; nečakajte na dokončenie mazania. Zastavenie agenta nemusí zastaviť jeho detské príkazy, vzdialené úlohy či databázové dotazy. Určte skutočného zapisovateľa a zastavte alebo zrušte operáciu; pri pokračujúcom ničení použite dôraznejšie ukončenie. Nesúvisiace procesy s obnoviteľnými otvorenými súbormi zachovajte.

2. NEREŠTARTUJTE notebook

   Vymazané dáta môžu zostať obnoviteľné, no závisí to od úložiska, databázy, SSD discard/TRIM a ďalších zápisov. Minimalizujte zápisy na dotknutý zväzok; nepredpokladajte zachovanie bajtov.

3. NEZATVÁRAJTE otvorené procesy

   Zachovajte nesúvisiace procesy držiace vymazané súbory otvorené; obnova cez ich deskriptory môže byť možná. To neplatí pre ničivého zapisovateľa: najprv ho zastavte. Nenechávajte mazanie bežať iba kvôli otvorenému súboru.

4. Spustite nahrávanie obrazovky

   Zaznamenajte presný čas, dotknuté cesty a viditeľný výstup príkazov. Záznam či logy ukladajte na samostatné overené zariadenie, nie poškodený zväzok. Pred obnovou tam uchovajte preživšie sledované, nesledované a ignorované súbory aj metadáta Gitu.

Potom máte 6 minút na obnovu. Poďme na to.

Minúty 2–3: presne zdokumentujte, čo sa pokazilo#

Otvorte nové okno terminálu. Nie to, v ktorom beží agent—iné. Spustite tieto tri príkazy za sebou.

1. Zaznamenajte, čo presne sa zmenilo v repozitári git:

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

Vymazaný sledovaný súbor môže zostať v indexe či commite. Pred obnovou uchovajte aktuálny pracovný strom vrátane nesledovaných a ignorovaných súborov; obnova na mieste môže prepísať preživšie úpravy. Skúmajte a obnovujte v samostatnej kópii.

2. Skontrolujte, ktoré procesy agenta sú spustené:

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

Určte proces stále vykonávajúci nebezpečné zápisy; samotná zhoda názvu nestačí. Zastavte ho a overte zastavenie. Nesúvisiace procesy s užitočnými otvorenými súbormi zachovajte; pri zlyhaní riadneho ukončenia a pokračujúcom ničení môže byť potrebné nútené ukončenie.

3. Uložte záznam relácie agenta:

Claude Code ukladá relácie JSONL do ~/.claude/projects/. Cursor ich ukladá do ~/.cursor/. Vytvorte ich kópiu hneď teraz:

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

/external/incident-evidence/ nahraďte existujúcim dôkazovým priečinkom na samostatnom overenom pripojenom zariadení. Zálohu nezapisujte na poškodený zväzok ani neprepisujte dôkazy. Tento priečinok obsahuje doslovnú konverzáciu s agentom—aké príkazy spustil, čo odpovedal a v akom poradí. Je vaším hlavným zdrojom na preskúmanie incidentu a potenciálnu obnovu vymazaných súborov z kontextu agenta (pozri krok 4).

Minúta 4: git reflog—vaša najlepšia šanca#

git reflog zaznamenáva lokálne pohyby referencií, kým sú záznamy uchované. Expirácia a odstraňovanie sa líšia a nedostupné objekty môžu zmiznúť; nie je zaručeným archívom každého commitu. Nasledujúce kroky spúšťajte z uchovanej kópie repozitára na samostatnom zariadení.

Krok 1. Zobrazte záznam:

git reflog --all

Zobrazí sa zoznam podobný tomuto:

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

Vyhľadajte stav predtým, ako agent spôsobil škodu. Každá položka je „snímka“ stavu repozitára v danom okamihu.

Krok 2. Obnovte do samostatného pracovného stromu:

Po skopírovaní repozitára a celej preživšej práce na samostatné zariadenie spustite toto z uchovanej kópie. Hodnotu nahraďte presným commit SHA overeným v reflog a vyberte nepoužitú vetvu a cieľ:

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

Obnovené súbory v ../recovery-check prezrite a pred kopírovaním späť porovnajte s uchovanými necommitnutými súbormi. Príkaz samostatne sprístupní vybraný commit; neresetuje poškodený pracovný strom. Prepojené worktrees zdieľajú Git objekty skopírovaného repozitára, preto je to pracovný priestor obnovy, nie nezávislá záloha. Pozrite oficiálnu dokumentáciu git-worktree.

Ak bolo vyčistené aj reflog (agent dokázal spustiť git gc):

git fsck --lost-found

Tento príkaz nájde „stratené“ commity a bloby (objekty súborov), ktoré už nie sú pripojené k žiadnej vetve. Zobrazia sa v .git/lost-found/commit/ a .git/lost-found/other/. Ak chcete odtiaľ obnoviť súbor:

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

Kedy git reflog nepomôže:

• Súbor bol iba v pracovnom strome, bez commitu alebo stash → reflog ho nevidí
• Uplynulo viac ako 90 dní (štandardné gc.reflogExpire) a spustilo sa git gc
• Bol vymazaný celý repozitár (rm -rf .git)—vtedy potrebujete Time Machine alebo snímku

Minúta 5: obnovte databázu zo zálohy#

Databáza bola vymazaná príkazom DROP DATABASE, DROP TABLE alebo DELETE FROM ... WHERE ... (bez klauzuly WHERE). Čo máte robiť?

Krok 1. Zistite, či váš poskytovateľ ponúka PITR:

Krok 2. Obnovte do novej inštancie, nie do starej:

Nikdy neobnovujte cez živú databázu. Vytvorte novú inštanciu zo zálohy a potom na ňu prepnite aplikáciu. Ak sa niečo pokazí, môžete prepnúť DNS späť.

Krok 3. Ak PITR nebolo zapnuté, použite najnovšiu snímku:

# AWS RDS, zoznam snímok:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Obnovenie zo snímky:
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

Upozornenie pre Supabase, ktoré v roku 2026 mnohých prekvapilo: keď je zapnuté PITR, denné zálohy sa prestávajú vytvárať. Je to neintuitívne správanie; môžete tak skončiť úplne bez záloh. Skontrolujte Dashboard → Database → Backups a uistite sa, že PITR je aktívne A zároveň máte snímku, z ktorej možno obnoviť.

Minúta 6: Time Machine, lsof a snímky disku#

macOS—Time Machine:

# Zoznam snímok:
tmutil listbackups

# Obnovenie súboru z najnovšej zálohy:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine vytvára snímky každú hodinu, uchováva hodinové snímky jeden deň, denné jeden týždeň a týždenné natrvalo. Ak je notebook pripojený k Time Capsule alebo externému disku, projekt tam nájdete s hodinovou presnosťou.

Linux—súbor bol vymazaný, ale proces ho stále drží otvorený:

# Nájdite všetky „vymazané“ súbory, ktoré má proces stále otvorené:
sudo lsof | grep deleted

# Zobrazia sa riadky podobné tomuto:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Skopírujte súbor priamo z /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Pravdepodobnosť úspechu je ~95 %, ak proces nebol zatvorený. Funguje na ext4, xfs, btrfs.

macOS—obdobné použitie lsof:

lsof | grep deleted

Kopírovanie súboru je náročnejšie (neexistuje /proc/), ale dá sa to pomocou lldb:

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

Snímka celého disku (Linux, posledná možnosť):

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

Tým sa celý oddiel uloží ako obraz. Potom obnovujte pomocou extundelete alebo photorec. Pravdepodobnosť obnovy závisí od toho, koľko údajov bolo na disk zapísaných od vymazania. Ak sa nič nezapísalo, je to 80–90 %. Ak už systém beží hodinu, je to 20–30 %.

Minúta 7: čo ak nemáte žiadnu zálohu#

Možnosť 1—podpora poskytovateľa:

AWS, Yandex Cloud, Google Cloud a DigitalOcean pravidelne obnovujú údaje zo svojho interného úložiska, a to aj po katastrofe spôsobenej zákazníkom, najmä pri platených programoch. Otvorte tiket podpory, uveďte presný čas incidentu a priložte snímky obrazovky zachytávajúce stav. Najčastejšie to funguje u veľkých poskytovateľov, ktorí si na svojej strane uchovávajú automatické zálohy. Pravdepodobnosť úspechu je 40–60 %; reakcia trvá 24–72 hodín.

Možnosť 2—správa verzií S3:

Ak boli súbory v S3 (alebo Yandex Object Storage) a správa verzií bola zapnutá, všetky verzie fyzicky existujú; sú len označené ako „vymazané“.

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

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

Kritické upozornenie: Claude Code neuchováva relácie navždy—staré súbory JSONL sa po niekoľkých týždňoch automaticky odstraňujú. Ak chcete mať pre prípad katastrofy mesačnú históriu JSONL, raz týždenne skopírujte ~/.claude/projects/ na externý disk pomocou jednoduchej úlohy cron:

# V crontabe, každú nedeľu o 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

Je to zadarmo a zachráni vás, keď „je všetko preč, nemáte zálohu a reflog je prázdny“.

7 pravidiel, aby sa to už nikdy nestalo#

1. Plan Mode pred každou ničivou operáciou. V Claude Code:

claude --plan

Agent vytvorí plán predtým, ako začne konať. Prečítate si ho, uvidíte DROP TABLE users a zrušíte ho. Bez Plan Mode sa agent rozhodne sám a vykoná príkaz v priebehu milisekúnd. Viac sa dozviete v sprievodcovi Plan Mode v Claude Code.

2. Hooky ako dodatočná nástraha. Použite otestovaný PreToolUse hook čítajúci JSON udalosti zo stdin a vracajúci 2 pri rozpoznanej rizikovej akcii. Úplný príklad nižšie pokrýva Bash, Write a Edit; nie je bezpečnostnou hranicou a môže minúť nepriame operácie. Databázové oprávnenia a sandbox udržujte obmedzené.

3. Databázový používateľ agenta iba na čítanie. Vytvorte samostatného používateľa agenta, ktorý nemá oprávnenia DROP, TRUNCATE ani 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;

Keď agent skutočne potrebuje zapisovať, manuálne prepnite na iného používateľa. Používateľ iba na čítanie postačuje na každodenné úlohy (analýzu údajov, reporty, dashboardy).

4. Ukladajte do Gitu skontrolované zmeny. Hook PostToolUse v .claude/settings.json môže po operáciách Write a Edit vypísať pripomienku:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Skontrolujte diff a ručne vytvorte commit len z dohodnutých súborov.' >&2"
          }
        ]
      }
    ]
  }
}

Tento príklad iba vypíše pripomienku; nepridáva súbory do indexu ani nevytvára commit. Skontrolujte diff a ručne vytvorte commit len z dohodnutých súborov. Reflog neukladá zmeny, ktoré neboli zaznamenané v commite.

5. Projekt sandbox na experimenty. Nikdy nedovoľte agentovi pracovať v projekte, ktorý obsahuje skutočné údaje zákazníkov. Vytvorte samostatný priečinok ~/sandbox-projects/ s kópiou projektu a syntetickými údajmi. Používajte ho na skúšanie nového promptu, agenta alebo MCP servera. Ak sa niečo pokazí, nič sa nestane.

6. Snímky disku pomocou restic každú hodinu.

# Inštalácia:
brew install restic  # macOS
sudo apt install restic  # Linux

# Vytvorenie repozitára:
restic init --repo /external/backups

# Zálohovanie aktuálneho projektu:
restic --repo /external/backups backup ~/projects

# Naplánovanie cron úlohy každú hodinu:
crontab -e
# Pridajte:
0 * * * * restic --repo /external/backups backup ~/projects

Sedem dní hodinových záloh, štyri týždne denných záloh—a vždy sa môžete vrátiť do ktoréhokoľvek bodu v minulosti. Je to zadarmo a nastavenie trvá 10 minút.

7. Archivujte relácie Claude Code JSONL. Už sme to spomenuli, no opakujeme to ako samostatné pravidlo: naplánujte týždenný rsync priečinka ~/.claude/projects/ na externý disk. Je to zadarmo a v crontabe stačí jeden riadok.

Pripravené hooky na blokovanie nebezpečných príkazov#

Túto položku zlúčte do .claude/settings.json bez nahradenia existujúcich hookov:

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

Vytvorte .claude/hooks/check-risk.py s týmto skriptom Python 3:

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 číta zdokumentovanú udalosť JSON zo stdin, kontroluje tool_input.command alebo tool_input.file_path a pri zhode končí kódom 2. Kontroluje Write aj Edit. Pred spoliehaním sa vyskúšajte neškodný povolený a blokovaný vstup a overte skutočný štart Pythonu a skriptu.

Je to lexikálna nástraha: môže minúť iné poradie príznakov, skripty, aliasy, maskované príkazy, iné nástroje či nepriame zápisy a odmietnuť neškodné citované príklady. Neudeľuje ani neodoberá práva OS/databázy. Produkčné prihlásenie držte mimo agenta, použite databázovú rolu iba na čítanie a vynucovaný sandbox a konfiguráciu hooku chráňte pred zmenou. Pozrite oficiálny vstup a návratové kódy hookov.

Zámernú výnimočnú operáciu posúďte a vykonajte mimo agenta s príslušným obmedzeným účtom. Premenná shellu nie je zdokumentované rozhranie vypnutia hookov a hooky neriadia bežné terminálové príkazy.

Kedy udeliť AI oprávnenia (a kedy nie)#

Anthropic dokumentuje príznak --dangerously-skip-permissions (známy aj ako režim YOLO) ako možnosť pre „dôveryhodné prostredia“. V realite roku 2026 je to priama cesta ku katastrofe. Keď sa agent nemusí pýtať, môže:

• Spúšťať ľubovoľné príkazy Bash bez potvrdenia
• Zapisovať súbory bez opýtania
• Vyvolať podagenta, ktorý zdedí režim YOLO a nemožno ho z neho vyňať

Tretí bod je najzákernejší. Ak spustíte hlavného agenta v režime YOLO, aj jeho podagenti budú v režime YOLO a nemôžete to zmeniť. Jeden prompt—a kaskáda 10 paralelných agentov môže so systémom urobiť čokoľvek.

Pravidlo:

Alternatíva—presné oprávnenia. V .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/*)"
    ]
  }
}

Agent vidí, čo môže a čo nemôže robiť. Nemusíte zakaždým klikať na „áno“ alebo „nie“—agent pracuje rýchlo a vy kontrolujete hranice jeho oprávnení.

Ďalej: 7-minútový kontrolný zoznam, ktorý si môžete uložiť#

Kontrolný zoznam: „AI to vymazala—čo mám robiť?“

1. Ihneď zastavte skutočného ničivého zapisovateľa; overte zastavenie detských a vzdialených operácií
2. Nereštartujte; zachovajte nesúvisiace procesy držiace vymazané súbory otvorené
3. Čas incidentu a dôkazy príkazov zaznamenajte na samostatné overené zariadenie
4. Na toto samostatné zariadenie skopírujte preživšie súbory, metadáta Gitu a príslušné logy relácií
5. V uchovanej kópii repozitára prezrite git reflog --all a overený commit obnovte do samostatného worktree
6. Ak git nepomohol—git fsck --lost-found
7. Databáza: PITR (AWS/Yandex/Supabase) alebo najnovšia snímka
8. Súbory: Time Machine na Macu, lsof v Linuxe
9. Posledná možnosť: podpora poskytovateľa + správa verzií S3
10. Po obnove nakonfigurujte 7 preventívnych pravidiel uvedených v tomto sprievodcovi

Ďalej—systematická ochrana:

• Plan Mode v Claude Code—agent tak vytvorí plán pred ničivou operáciou
• Hooky v Claude Code—pripravené šablóny na blokovanie nebezpečných príkazov
• Ako vrátiť zmeny v Claude Code—podrobný sprievodca príkazom /rewind, gitom a 5 štandardnými metódami vrátenia zmien
• Bezpečnostná kontrola v Claude Code—pravidelné kontroly bezpečnosti kódu

Otvorte Ailoot.