# AI smazala databázi: plán obnovy za 7 minut > Co dělat po smazání dat: zastavte agenta, zdokumentujte incident a použijte git reflog, PITR, snapshoty a obnovu souborů. Příklady a ochranná opatření. Source: https://ailoot.ai/blog/cs/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/cs/ai-deleted-database-recovery/ Language: cs Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-7928b92d2f3d6b7e06794a3e5c0e5bdfede24ee6bc0672368b88d424b2bb6930
Hlavní poznatek AI agent právě smazal vaši databázi, soubory nebo celé produkční prostředí. Prvních 7 minut rozhodne o tom, zda svá data obnovíte, nebo je navždy ztratíte. Tento návod nabízí konkrétní příkazy pro každou minutu. Nejprve zastavte agenta, potom zdokumentujte incident a pak data obnovte. Zachovejte klid a postupujte podle kontrolního seznamu.
[Praktické informace o práci s Ailootem najdete v dokumentaci](https://ailoot.ai/docs/). ## Co udělat jako první, když AI smaže databázi?
Hlavní poznatek Destruktivního zapisovatele zastavte okamžitě včetně pokračujících dětských procesů. Nerestartujte ani neukončujte nesouvisející procesy, které mohou držet smazané soubory. Obnova není zaručena: přepis a SSD discard/TRIM ji mohou znemožnit. Před změnou poškozené kopie zachovejte důkazy a přeživší data na odděleném ověřeném zařízení.
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
Hlavní poznatek Než začnete s obnovou, zjistěte, co se stalo. Bez přesného přehledu o tom, „co bylo smazáno, kým, kdy a jakými příkazy“, budete obnovovat naslepo a můžete zničit data, která jsou stále neporušená. Otevřete nové okno terminálu (ne to, ve kterém běží agent), spusťte `git status`, `git log --since` a `ps aux | grep claude`. Okamžitě zkopírujte složku `~/.claude/projects/` – obsahuje úplný záznam relací agenta, který může pomoci při obnově.
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:** ```bash 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ěží:** ```bash 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: ```bash 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
Hlavní poznatek Reflog může najít commity zmizelé z historie větví, neuchovává ale necommitnuté soubory pracovní kopie. Po zachování přeživších dat a metadat Git na odděleném zařízení prozkoumejte kopii repozitáře a ověřený commit obnovte do samostatného worktree. Nezačínejte resetem poškozené pracovní kopie.
`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:** ```bash 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: ```bash 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](https://git-scm.com/docs/git-worktree). **Pokud byl vyčištěn i reflog (agent stihl spustit `git gc`):** ```bash 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: ```bash git cat-file -p > 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
Hlavní poznatek PostgreSQL Point-In-Time Recovery (PITR) obnoví databázi do libovolného okamžiku během 7–35denního období. Funguje s Yandex Cloud Managed Postgres, AWS RDS, Supabase Pro i s místní úlohou cron pro `pg_dump` v Coolify. Zásadní podmínkou je, že PITR muselo být povoleno **před** incidentem; zpětně ho povolit nelze. Vždy obnovujte do nové instance, nikdy přes živou databázi, aby návrat nezničil ještě více dat. Pokud PITR nebylo povoleno, použijte nejnovější snapshot.
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:** | Poskytovatel | Období PITR | Příkaz pro obnovu | |----|----|----| | AWS RDS | 1–35 dní (lze nastavit) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 dní (ve výchozím nastavení) | Obnovte zálohu v konzoli a zadejte čas | | Supabase Pro | 7 dní (pouze Pro+) | UI: Database → Backups → Restore | | Coolify + místní pg_dump | Podle plánu cron | `pg_restore -d new_db backup.dump` | **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:** ```bash # 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
Hlavní poznatek Pokud byly smazány soubory z disku – nikoli z gitu nebo databáze – existují tři praktické metody obnovy. V macOS použijte Time Machine s hodinovými snapshoty (pokud byl notebook připojený k Time Capsule nebo externímu disku). V Linuxu spusťte `sudo lsof | grep deleted` – umožní získat soubory, které má proces stále otevřené (šance 95 %); zkopírujte je přes `/proc/PID/fd/N`. V kritických případech vytvořte snapshot celého oddílu pomocí `dd` a pak obnovujte pomocí `extundelete` nebo `photorec`.
**macOS – Time Machine:** ```bash # 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ý:** ```bash # 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`:** ```bash lsof | grep deleted ``` Zkopírovat soubor je obtížnější (neexistuje `/proc/`), ale lze to udělat pomocí `lldb`: ```bash lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **Snapshot celého disku (Linux, poslední možnost):** ```bash 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
Hlavní poznatek Není záloha, reflog je prázdný a na disk už byla zapsána nová data. Zbývají dvě poslední možnosti: kontaktovat podporu poskytovatele (AWS, Yandex Cloud a Google Cloud někdy obnovují data ze svého interního úložiště) nebo obnovit data přes verzování S3 (pokud bylo povoleno, všechny verze jsou fyzicky stále k dispozici).
**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é“. ```bash # 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: ```bash # 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í
Hlavní poznatek Sedm pravidel brání AI agentovi smazat databázi nebo kód. Před destruktivními operacemi používejte Plan Mode. Otestovanými hooky rozpoznávejte vybrané nebezpečné řetězce spolu s vynucenými hranicemi oprávnění. Dejte agentovi databázového uživatele pouze pro čtení. Po každé úpravě souboru automaticky vytvářejte commit. Pro experimenty používejte izolovanou složku sandboxu. Každou hodinu pořizujte snapshoty disku pomocí `restic`. Relace JSONL archivujte na externí disk.
**1. Plan Mode před každou destruktivní operací.** V Claude Code: ```bash 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](https://ailoot.ai/blog/cs/claude-code-plan-mode/). **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](https://ailoot.ai/blog/cs/claude-code-hooks/). **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`: ```sql 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í: ```json { "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`.** ```bash # 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ů
Hlavní poznatek Následující příklad je PreToolUse pojistka vybraných příkazů Bash a citlivých cest Write/Edit. Čte stdin JSON a při shodě vrací 2. Nepřímé či zastřené akce může minout, doplňuje proto sandbox a omezené přihlašovací údaje. Hook slučte s existující konfigurací a před použitím otestujte.
Tuto položku slučte do `.claude/settings.json` bez nahrazení existujících hooků: ```json { "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: ```python 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ů](https://code.claude.com/docs/en/hooks). 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?
Hlavní poznatek Pro projekty se skutečnými daty agentovi kategoricky NEDÁVEJTE příznak `--dangerously-skip-permissions`. V režimu YOLO jsou vypnuté všechny ochrany, agent spouští libovolné příkazy Bash a zapisuje soubory bez potvrzení a jím spuštění podagenti dědí režim YOLO, který nelze přepsat. YOLO používejte pouze ve složce sandboxu při experimentech s novými MCP servery nebo zadáními na testovacích datech. Ve všech ostatních případech použijte přesná oprávnění prostřednictvím `.claude/settings.json` s výslovnými pravidly `allow` a `deny`.
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:** | Situace | Je YOLO přijatelné? | |--------------------------------------------------|--------------------| | Experimentování s novým MCP serverem ve složce sandboxu | ✅ Ano | | Testování nového zadání na testovacích datech | ✅ Ano | | Práce se skutečnými soubory projektu | ❌ Ne | | Jakýkoli příkaz, který zasahuje databázi | ❌ Nikdy | | Nasazení do produkce | ❌ Nikdy | | Správa infrastruktury (AWS, Yandex Cloud) | ❌ Nikdy | **Alternativa – přesná oprávnění.** V `.claude/settings.json`: ```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
Hlavní poznatek Uložte si tento návod do záložek hned teď. Až dojde ke katastrofě, otevřete stránku a postupujte podle desetibodového seznamu. Ušetří vám 30 minut paniky a zabrání tomu, abyste omylem přepsali data, která lze ještě obnovit. Po obnově se vraťte a nastavte 7 preventivních pravidel, aby se katastrofa příští týden neopakovala.
**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](https://ailoot.ai/blog/cs/claude-code-plan-mode/) – agent nejprve připraví plán **před** destruktivní operací - [Hooks v Claude Code](https://ailoot.ai/blog/cs/claude-code-hooks/) – hotové šablony pro blokování nebezpečných příkazů - [Jak vrátit změny v Claude Code](https://ailoot.ai/blog/cs/claude-code-undo-changes/) – podrobný návod k `/rewind`, gitu a 5 standardním metodám vrácení změn - [Bezpečnostní kontrola v Claude Code](https://ailoot.ai/blog/cs/claude-code-security-review/) – pravidelné bezpečnostní kontroly kódu
### Zdroje - [Dokumentace Hooks pro Claude Code od společnosti Anthropic](https://code.claude.com/docs/en/hooks-guide) - [Dokumentace Plan Mode pro Claude Code od společnosti Anthropic](https://code.claude.com/docs/en/common-workflows) - [Dokumentace PostgreSQL Point-In-Time Recovery (PITR)](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS – obnovení instance databáze k určitému okamžiku](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL – zálohování a obnova](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [Dokumentace Git reflog](https://git-scm.com/docs/git-reflog) - [Git fsck – režim `--lost-found`](https://git-scm.com/docs/git-fsck)
[Otevřete Ailoot](https://ailoot.ai/). ## Časté otázky ### Mám počkat, než agent dokončí aktuální příkaz? Ne. Destruktivního zapisovatele zastavte okamžitě a ověřte zastavení dětské, vzdálené či databázové operace. Zachovejte nesouvisející procesy s potenciálně obnovitelnými otevřenými soubory; samotné zastavení agenta může ponechat jiného zapisovatele. ### Mohu obnovu začít příkazem git reset --hard? Nejprve na odděleném zařízení zachovejte přeživší sledované, nesledované a ignorované soubory i metadata Git. Prohlédněte kopii repozitáře a ověřený commit obnovte do samostatného worktree; hard reset původní kopie může zničit přeživší necommitnuté změny. ## Ailoot · Společnost a její portfolio projektů Ailoot staví na dlouhodobých provozních zkušenostech, široké klientské základně, stabilních službách a průběžném sledování KPI. Společnost a její portfolio projektů: miliony zákazníků; měsíční tržby v miliardách. Ailoot využívá tyto provozní zkušenosti k poskytování přístupu přes API k funkcím AI v produktech zákazníků, agentech, aplikacích a automatizacích.