AI smazala databázi: plán obnovy za 7 minut

Praktické informace o práci s Ailootem najdete v dokumentaci.

Co udělat jako první, když AI smaže databázi?#

Když se vám to stane, první věc, kterou musíte udělat, je zastavit agenta. Nepokoušejte se jeho kroky sami vrátit zpět, neříkejte mu „všechno obnov“ a nezadávejte mu nové pokyny. Každá další akce agenta může přepsat bloky disku, na kterých mohou být vaše data stále uložená.

1. Zavřete terminál agenta

   Nebezpečný příkaz přerušte okamžitě pomocí Ctrl+C; nečekejte na dokončení mazání. Zastavení agenta nemusí ukončit děti, vzdálené úlohy ani dotazy DB. Určete skutečného zapisovatele a zastavte či zrušte operaci; pokračuje-li ničení dat, ukončení zesilte. Nesouvisející procesy s užitečnými otevřenými soubory zachovejte.

2. Notebook NERESTARTUJTE

   Smazaná data mohou být obnovitelná, rozhoduje ale úložiště, databáze, SSD discard/TRIM a další zápisy. Minimalizujte zápisy na postižený svazek; nepředpokládejte zachování bajtů.

3. NEZAVÍREJTE otevřené procesy

   Zachovejte nesouvisející procesy držící smazané soubory, protože obnova přes deskriptory může být možná. To neplatí pro destruktivního zapisovatele: nejprve jej zastavte. Mazání nenechávejte běžet kvůli otevřenému souboru.

4. Spusťte nahrávání obrazovky

   Zaznamenejte přesný čas, postižené cesty a viditelný výstup příkazu. Nahrávky a logy ukládejte na samostatné ověřené zařízení místo poškozeného svazku. Před obnovou tam zachovejte přeživší sledované, nesledované i ignorované soubory a metadata Git.

Teď máte 6 minut na obnovu. Jdeme na to.

Minuty 2–3: přesně zdokumentujte, co se pokazilo#

Otevřete nové okno terminálu. Ne to, ve kterém běží agent – jiné. Spusťte postupně tyto tři příkazy.

1. Zaznamenejte přesně, co se změnilo v repozitáři git:

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

Smazaný sledovaný soubor může stále existovat v indexu či commitu. Před obnovou zachovejte současný pracovní strom včetně nesledovaných a ignorovaných souborů; obnova na místě může přepsat přeživší úpravy. Zkoumejte a obnovujte v oddělené kopii.

2. Zkontrolujte, které procesy agentů běží:

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

Určete proces provádějící nebezpečné zápisy; samotná shoda názvu nestačí. Zapisovatele zastavte a ověřte ukončení. Nesouvisející procesy s užitečnými otevřenými soubory zachovejte; selže-li šetrné ukončení a ničení pokračuje, může být nutné vynucené ukončení.

3. Uložte záznam relace agenta:

Claude Code ukládá relace JSONL do ~/.claude/projects/. Cursor je ukládá do ~/.cursor/. Hned je zkopírujte:

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

/external/incident-evidence/ nahraďte existujícím adresářem důkazů na samostatném ověřeném připojeném zařízení. Kopii nezapisujte na postižený svazek ani přes existující důkazy. Tato složka obsahuje doslovný přepis konverzace s agentem – jaké příkazy spustil, co odpověděl a v jakém pořadí. Je vaším hlavním zdrojem pro vyšetření incidentu a případnou obnovu smazaných souborů z jeho kontextu (viz krok 4).

Minuta 4: git reflog – vaše nejlepší šance#

git reflog zaznamenává místní pohyby referencí, dokud jsou položky uchovány. Expirace a prořezávání se liší a nedostupné objekty mohou zmizet; nejde o zaručený archiv všech commitů. Následující obnovu provádějte ze zachované kopie repozitáře na odděleném zařízení.

Krok 1. Zobrazte záznam:

git reflog --all

Zobrazí se seznam 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

Najděte stav předtím, než agent způsobil škodu. Každá položka je „snímek“ stavu repozitáře v daném okamžiku.

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

Po kopii repozitáře a přeživší práce na oddělené zařízení spusťte z této kopie následující. Dosaďte přesné SHA ověřené v reflogu a nepoužitou větev i cíl:

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

V ../recovery-check prohlédněte soubory a porovnejte je se zachovanými necommitnutými změnami před kopírováním zpět. Příkaz vybere commit odděleně, neresetuje poškozený strom. Propojené worktree sdílejí objekty Git kopie repozitáře, jde tedy o pracovní prostor obnovy, nikoli nezávislou zálohu. Viz oficiální dokumentace git-worktree.

Pokud byl vyčištěn i reflog (agent stihl spustit git gc):

git fsck --lost-found

Tento příkaz vyhledá „ztracené“ commity a bloby (objekty souborů), které už nejsou připojené k žádné větvi. Objeví se v .git/lost-found/commit/ a .git/lost-found/other/. Soubor z nich obnovíte takto:

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

Kdy vám git reflog nepomůže:

• Soubor byl pouze v pracovním stromu, bez commitu nebo stashu → reflog ho nevidí
• Uplynulo více než 90 dní (standardní gc.reflogExpire) a byl spuštěn git gc
• Byl smazán celý repozitář (rm -rf .git) – v takovém případě potřebujete Time Machine nebo snímek disku

Minuta 5: obnovte databázi ze zálohy#

Databáze byla smazána pomocí DROP DATABASE, DROP TABLE nebo DELETE FROM ... WHERE ... (bez klauzule WHERE). Co máte dělat?

Krok 1. Zjistěte, zda váš poskytovatel nabízí PITR:

Krok 2. Obnovte do nové instance, ne do té původní:

Nikdy neobnovujte přes živou databázi. Vytvořte novou instanci ze zálohy a potom na ni přepněte aplikaci. Pokud se něco pokazí, můžete DNS přepnout zpět.

Krok 3. Pokud PITR nebylo povoleno, použijte nejnovější snapshot:

# 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

Upozornění k Supabase, které v roce 2026 zaskočilo mnoho lidí: když je povoleno PITR, denní zálohy se přestanou vytvářet. Je to neintuitivní; mohli byste skončit zcela bez záloh. V Dashboard → Database → Backups ověřte, že je PITR aktivní A ŽE máte snapshot, ze kterého lze obnovit.

Minuta 6: Time Machine, lsof a snapshoty disku#

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 vytváří snapshoty každou hodinu, hodinové snapshoty uchovává jeden den, denní snapshoty jeden týden a týdenní snapshoty neomezeně dlouho. Pokud je notebook připojený k Time Capsule nebo externímu disku, najdete tam svůj projekt se zálohami po hodinách.

Linux – soubor byl smazán, ale proces ho stále má otevřený:

# 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

Šance na úspěch je ~95 %, pokud proces nebyl zavřen. Funguje v ext4, xfs a btrfs.

macOS – obdoba pomocí lsof:

lsof | grep deleted

Zkopírovat soubor je obtížnější (neexistuje /proc/), ale lze to udělat pomocí lldb:

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

Snapshot celého disku (Linux, poslední možnost):

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

Tím se uloží celý oddíl jako obraz. Poté obnovujte pomocí extundelete nebo photorec. Šance na obnovu závisí na tom, kolik dat bylo od smazání na disk zapsáno. Pokud na něj nebylo zapsáno nic, činí 80–90 %. Pokud běžel už hodinu, je to 20–30 %.

Minuta 7: co když není k dispozici žádná záloha#

Možnost 1 – podpora poskytovatele:

AWS, Yandex Cloud, Google Cloud a DigitalOcean někdy obnovují data ze svého interního úložiště i po katastrofě na straně zákazníka, zejména u placených tarifů. Otevřete žádost na podpoře, uveďte přesný čas incidentu a přiložte snímky obrazovky zachycující stav. Nejčastěji to funguje u velkých poskytovatelů, kteří si uchovávají automatické zálohy. Šance je 40–60 %; doba odezvy činí 24–72 hodin.

Možnost 2 – verzování S3:

Pokud byly soubory v S3 (nebo Yandex Object Storage) a verzování bylo povoleno, všechny verze fyzicky existují; jsou pouze označené jako „smazané“.

# 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

Zásadní upozornění: Claude Code neuchovává relace navždy – staré soubory JSONL se po několika týdnech automaticky mažou. Chcete-li mít v případě katastrofy měsíční historii JSONL, kopírujte složku ~/.claude/projects/ jednou týdně na externí disk pomocí jednoduché úlohy cron:

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

Je to zdarma a zachrání vás, když „je všechno pryč, záloha není a reflog je prázdný“.

7 pravidel, která tomu zabrání#

1. Plan Mode před každou destruktivní operací. V Claude Code:

claude --plan

Agent před akcí sestaví plán. Než začne jednat, přečtete si ho, uvidíte DROP TABLE users a operaci zrušíte. Bez Plan Mode agent rozhoduje sám a provede akci během milisekund. Více se dozvíte v návodu k Plan Mode v Claude Code.

2. Hooky jako dodatečná pojistka. Použijte otestovaný PreToolUse čtoucí událost JSON ze stdin a vracející 2 pro zjištěnou rizikovou akci. Úplný příklad níže pokrývá Bash, Write a Edit; není bezpečnostní hranicí a může přehlédnout nepřímé operace. Databázová oprávnění a sandbox ponechte omezené. Další podrobnosti jsou v průvodci hooky.

3. Databázový uživatel agenta pouze pro čtení. Vytvořte pro agenta samostatného uživatele, který nemá oprávnění 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;

Když agent opravdu potřebuje zapisovat, ručně přepněte na jiného uživatele. Uživatel pouze pro čtení stačí na běžné úkoly (analýzu dat, reporty, dashboardy).

4. Ukládejte do Gitu zkontrolované změny. Hook PostToolUse v .claude/settings.json může po operacích Write a Edit vypsat připomenutí:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Zkontrolujte diff a ručně vytvořte commit pouze z dohodnutých souborů.' >&2"
          }
        ]
      }
    ]
  }
}

Tento příklad pouze vypíše připomenutí; nepřidává soubory do indexu ani nevytváří commit. Zkontrolujte diff a ručně vytvořte commit pouze z dohodnutých souborů. Reflog neukládá změny, které nebyly zaznamenány v commitu.

5. Sandboxový projekt pro experimenty. Nikdy nenechte agenta pracovat v projektu, který obsahuje skutečná zákaznická data. Vytvořte samostatnou složku ~/sandbox-projects/ s kopií projektu a syntetickými daty. Zkoušejte v ní nové zadání, agenta nebo MCP server. Když něco rozbije, nic se nestane.

6. Hodinové snapshoty disku pomocí restic.

# 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

Sedm dní hodinových záloh, čtyři týdny denních záloh – a vždy se můžete vrátit k libovolnému okamžiku v minulosti. Je to zdarma a nastavení zabere 10 minut.

7. Archivujte relace Claude Code JSONL. Už jsme to zmínili, ale opakujeme jako samostatné pravidlo: naplánujte týdenní rsync složky ~/.claude/projects/ na externí disk. Je to zdarma a do crontabu stačí jeden řádek.

Hotové hooks pro blokování nebezpečných příkazů#

Tuto položku slučte do .claude/settings.json bez nahrazení existujících hooků:

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

Vytvořte .claude/hooks/check-risk.py s následujícím skriptem 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 čte dokumentovanou událost JSON ze stdin, kontroluje tool_input.command či tool_input.file_path a při shodě vrací 2. Kontroluje Write i Edit. Před spoléháním vyzkoušejte neškodný povolený i blokovaný vstup a ověřte skutečné spuštění Pythonu a skriptu.

Jde o lexikální pojistku: mine jinak řazené přepínače, skripty, aliasy, zastřené příkazy, jiné nástroje i nepřímé zápisy a může odmítnout neškodnou citaci. Nemění oprávnění OS ani databáze. Produkční údaje ponechte mimo prostředí agenta, použijte databázovou roli pouze pro čtení a vynucený sandbox a chraňte konfiguraci hooku před změnou. Viz oficiální reference vstupu a návratových kódů.

Výjimečnou zamýšlenou operaci zkontrolujte a proveďte mimo agenta s vhodným omezeným účtem. Proměnná shellu není dokumentovaným rozhraním vypnutí hooků a hooky neřídí běžné terminálové příkazy.

Kdy dát AI agentovi oprávnění k databázi?#

Anthropic popisuje příznak --dangerously-skip-permissions (známý také jako režim YOLO) jako možnost pro „důvěryhodná prostředí“. V realitě roku 2026 je to přímá cesta ke katastrofě. Když se agent nemusí ptát, může:

• Spouštět libovolné příkazy Bash bez potvrzení
• Zapisovat soubory bez dotazu
• Spustit podagenta, který zdědí režim YOLO, a nelze to vzít zpět

Třetí bod je nejzáludnější. Pokud hlavního agenta spustíte v režimu YOLO, budou v něm i jeho podagenti a nelze to přepsat. Jedno zadání – a kaskáda 10 paralelních agentů může se systémem dělat cokoli.

Pravidlo:

Alternativa – přesná oprávnění. 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í, co smí a nesmí. Nemusíte pokaždé klikat na „ano“ nebo „ne“ – agent pracuje rychle a vy máte pod kontrolou jeho prostor oprávnění.

Dále: kontrolní seznam na 7 minut, který si uložte do záložek#

Kontrolní seznam: „AI to smazala – co mám dělat?“

1. Okamžitě zastavte skutečného destruktivního zapisovatele a ověřte ukončení dětských či vzdálených operací
2. Nerestartujte; zachovejte nesouvisející procesy držící smazané soubory
3. Na odděleném ověřeném zařízení zaznamenejte čas a důkazy příkazů
4. Na stejné oddělené zařízení zkopírujte přeživší soubory, metadata Git a relevantní logy relace
5. V zachované kopii prohlédněte git reflog --all a ověřený commit obnovte do samostatného worktree
6. Pokud git nepomohl – git fsck --lost-found
7. Databáze: PITR (AWS/Yandex/Supabase) nebo nejnovější snapshot
8. Soubory: Time Machine na Macu, lsof v Linuxu
9. Poslední možnost: podpora poskytovatele + verzování S3
10. Po obnově nastavte 7 preventivních pravidel z tohoto návodu

Dále – systematická ochrana:

• Plan Mode v Claude Code – agent nejprve připraví plán před destruktivní operací
• Hooks v Claude Code – hotové šablony pro blokování nebezpečných příkazů
• Jak vrátit změny v Claude Code – podrobný návod k /rewind, gitu a 5 standardním metodám vrácení změn
• Bezpečnostní kontrola v Claude Code – pravidelné bezpečnostní kontroly kódu

Otevřete Ailoot.