# AI vymazala databázu: 7-minútový plán obnovy > Čo robiť po vymazaní údajov: zastavte agenta, zdokumentujte incident, použite git reflog, PITR, snímky a obnovu súborov. Príklady a ochranné opatrenia. Source: https://ailoot.ai/blog/sk/ai-deleted-database-recovery/ Canonical: https://ailoot.ai/blog/sk/ai-deleted-database-recovery/ Language: sk Publisher: Ailoot (https://ailoot.ai/) Translation: guide-032 Revision: sha256-b795abd99065184941afd2da18aa14e24b44c0ec46f7d61716922b600767cde5
Kľúčové poznatky AI agent práve vymazal vašu databázu, súbory alebo celé produkčné prostredie. Prvých 7 minút rozhoduje o tom, či svoje údaje obnovíte, alebo ich navždy stratíte. Tento postup uvádza konkrétne príkazy pre každú minútu. Najprv zastavte agenta, potom zdokumentujte incident a napokon obnovte údaje. Nepanikárte—postupujte podľa kontrolného zoznamu.
[Praktické informácie o práci s Ailoot nájdete v dokumentácii](https://ailoot.ai/docs/). ## Čo robiť počas prvej minúty: ZASTAVTE SA, nepanikárte
Kľúčové poznatky Okamžite zastavte deštruktívneho zapisovateľa vrátane dieťaťa pokračujúceho po zastavení agenta. Nereštartujte ani neukončujte nesúvisiace procesy, ktoré môžu držať vymazané súbory otvorené. Obnova nie je zaručená: prepísanie a SSD discard/TRIM ju môžu znemožniť. Pred zmenou poškodenej kópie uchovajte dôkazy a preživšie dáta na samostatnom overenom zariadení.
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
Kľúčové poznatky Pred obnovou najprv diagnostikujte situáciu. Bez presného zistenia „čo bolo vymazané, kým, kedy a akými príkazmi“ budete obnovovať naslepo a môžete zničiť údaje, ktoré sú stále neporušené. Otvorte nové okno terminálu (nie to, v ktorom beží agent), spustite `git status`, `git log --since` a `ps aux | grep claude`. Okamžite skopírujte priečinok `~/.claude/projects/`—obsahuje úplný záznam relácie agenta, ktorý môže pomôcť pri obnove.
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:** ```bash 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é:** ```bash 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**: ```bash 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
Kľúčové poznatky Reflog môže nájsť commity stratené z histórie vetiev, no nezachraňuje necommitnuté súbory pracovného stromu. Po uchovaní preživších dát a metadát Gitu na inom zariadení skúmajte kópiu repozitára a overený commit obnovte do samostatného worktree. Nikdy nezačínajte resetovaním poškodeného pracovného stromu.
`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:** ```bash 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ľ: ```bash 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](https://git-scm.com/docs/git-worktree). **Ak bolo vyčistené aj reflog (agent dokázal spustiť `git gc`):** ```bash 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: ```bash git cat-file -p > 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
Kľúčové poznatky PostgreSQL Point-In-Time Recovery (PITR) obnoví databázu na ľubovoľnú sekundu v rámci 7–35-dňového okna. Funguje s Yandex Cloud Managed Postgres, AWS RDS, Supabase Pro a prostredníctvom miestnej úlohy cron `pg_dump` v Coolify. Základnou požiadavkou je, aby bolo PITR zapnuté **pred** incidentom; spätne ho zapnúť nemožno. Vždy obnovujte do novej inštancie, nikdy nie cez živú databázu, aby návrat nespôsobil ďalšiu stratu údajov. Ak PITR nebolo zapnuté, použite najnovšiu snímku.
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:** | Poskytovateľ | Okno PITR | Príkaz obnovy | |----|----|----| | AWS RDS | 1–35 dní (konfigurovateľné) | `aws rds restore-db-instance-to-point-in-time --restore-time 2026-05-28T14:30:00Z` | | Yandex Cloud Managed Postgres | 7 dní (predvolene) | Obnovte zo zálohy v konzole + zadajte čas | | Supabase Pro | 7 dní (iba Pro+) | UI: Database → Backups → Restore | | Coolify + miestny pg_dump | Podľa plánu cron | `pg_restore -d new_db backup.dump` | **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:** ```bash # 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
Kľúčové poznatky Ak boli súbory vymazané z disku—a nie z gitu alebo databázy—existujú tri praktické spôsoby obnovy. V systéme macOS použite Time Machine s hodinovými snímkami (ak bol notebook pripojený k Time Capsule alebo externému disku). V Linuxe spustite `sudo lsof | grep deleted`—môže získať súbory, ktoré má proces stále otvorené (pravdepodobnosť 95 %); skopírujte ich cez `/proc/PID/fd/N`. V kritických prípadoch vytvorte snímku celého oddielu pomocou `dd` a potom obnovujte pomocou `extundelete` alebo `photorec`.
**macOS—Time Machine:** ```bash # 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ý:** ```bash # 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`:** ```bash lsof | grep deleted ``` Kopírovanie súboru je náročnejšie (neexistuje `/proc/`), ale dá sa to pomocou `lldb`: ```bash lldb -p 12345 (lldb) memory read --outfile recovered.txt --binary 0xADDRESS 0xSIZE ``` **Snímka celého disku (Linux, posledná možnosť):** ```bash 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
Kľúčové poznatky Žiadna záloha, prázdny git reflog a disk už prepísaný novými údajmi. Zostávajú dve posledné možnosti: kontaktujte podporu svojho poskytovateľa (AWS, Yandex Cloud a Google Cloud pravidelne obnovujú údaje zo svojho interného úložiska) alebo obnovte údaje pomocou správy verzií S3 (ak bola zapnutá, všetky verzie tam fyzicky sú).
**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é“. ```bash # 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: ```bash # 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
Kľúčové poznatky Sedem pravidiel, ktoré zabránia AI agentovi vymazať vašu databázu alebo kód. Pred ničivými operáciami používajte Plan Mode. Otestovanými hookmi zisťujte vybrané nebezpečné reťazce príkazov spolu s vynucovanými limitmi oprávnení. Dajte agentovi databázového používateľa iba na čítanie. Po každej úprave súboru automaticky vytvorte commit. Na experimenty používajte izolovaný priečinok sandbox. Každú hodinu vytvárajte snímky disku pomocou `restic`. Archivujte relácie JSONL na externý disk.
**1. Plan Mode pred každou ničivou operáciou.** V Claude Code: ```bash 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](https://ailoot.ai/blog/sk/claude-code-plan-mode/). **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`: ```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; ``` 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: ```json { "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.** ```bash # 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
Kľúčové poznatky Nasledujúci PreToolUse príklad je nástrahou pre vybrané reťazce Bash a citlivé cesty Write/Edit. Číta stdin JSON a pri zhode vráti 2. Nepriame či maskované akcie môže minúť, preto dopĺňa sandbox a obmedzené prihlásenie, nenahrádza ich. Hook zlúčte s existujúcou konfiguráciou a pred použitím otestujte.
Túto položku zlúčte do `.claude/settings.json` bez nahradenia existujúcich hookov: ```json { "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: ```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 čí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](https://code.claude.com/docs/en/hooks). 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)
Kľúčové poznatky Agentovi pri práci na projektoch so skutočnými údajmi kategoricky NEUDEĽUJTE príznak `--dangerously-skip-permissions`. V tomto režime YOLO sú všetky ochrany vypnuté, agent spustí ľubovoľný príkaz Bash a zapisuje súbory bez potvrdenia a vytvorení podagenti zdedia režim YOLO bez možnosti jeho zmeny. YOLO používajte iba v priečinku sandbox na experimenty s novými MCP servermi alebo promptmi na testovacích údajoch. Na všetko ostatné používajte presné oprávnenia cez `.claude/settings.json` s výslovnými pravidlami `allow` a `deny`.
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:** | Situácia | Je YOLO prijateľné? | |--------------------------------------------------|--------------------| | Experimentovanie s novým MCP serverom v priečinku sandbox | ✅ Áno | | Testovanie nového promptu na testovacích údajoch | ✅ Áno | | Práca so skutočnými súbormi projektu | ❌ Nie | | Akýkoľvek príkaz, ktorý sa dotýka databázy | ❌ Nikdy | | Nasadzovanie do produkcie | ❌ Nikdy | | Správa infraštruktúry (AWS, Yandex Cloud) | ❌ Nikdy | **Alternatíva—presné oprávnenia.** 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í, č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ť
Kľúčové poznatky Uložte si tohto sprievodcu do záložiek hneď teraz. Keď dôjde ku katastrofe, otvorte stránku a postupujte podľa 10-bodového kontrolného zoznamu. Ušetrí vám 30 minút paniky a zabráni náhodnému prepísaniu údajov, ktoré sa ešte dajú obnoviť. Po obnove sa vráťte a nakonfigurujte 7 preventívnych pravidiel, aby sa katastrofa budúci týždeň nezopakovala.
**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](https://ailoot.ai/blog/sk/claude-code-plan-mode/)—agent tak vytvorí plán **pred** ničivou operáciou - [Hooky v Claude Code](https://ailoot.ai/blog/sk/claude-code-hooks/)—pripravené šablóny na blokovanie nebezpečných príkazov - [Ako vrátiť zmeny v Claude Code](https://ailoot.ai/blog/sk/claude-code-undo-changes/)—podrobný sprievodca príkazom `/rewind`, gitom a 5 štandardnými metódami vrátenia zmien - [Bezpečnostná kontrola v Claude Code](https://ailoot.ai/blog/sk/claude-code-security-review/)—pravidelné kontroly bezpečnosti kódu
### Zdroje - [Dokumentácia Anthropic Claude Code Hooks](https://code.claude.com/docs/en/hooks-guide) - [Dokumentácia Anthropic Claude Code Plan Mode](https://code.claude.com/docs/en/common-workflows) - [Dokumentácia PostgreSQL Point-In-Time Recovery (PITR)](https://www.postgresql.org/docs/current/continuous-archiving.html) - [AWS RDS—obnovenie inštancie DB k určitému časovému bodu](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html) - [Yandex Cloud Managed PostgreSQL—zálohovanie a obnova](https://yandex.cloud/ru/docs/managed-postgresql/concepts/backup) - [Dokumentácia Git reflog](https://git-scm.com/docs/git-reflog) - [Git fsck—režim `--lost-found`](https://git-scm.com/docs/git-fsck)
[Otvorte Ailoot](https://ailoot.ai/). ## Otázky a odpovede: AI vymazala databázu: 7-minútový plán obnovy ### Mám čakať na dokončenie aktuálneho príkazu agenta? Nie. Ihneď zastavte ničivého zapisovateľa a overte zastavenie jeho detskej, vzdialenej či databázovej operácie. Nesúvisiace procesy s obnoviteľnými otvorenými súbormi zachovajte; zastavenie samotného agenta môže iného zapisovateľa ponechať bežať. ### Môžem obnovu začať príkazom git reset --hard? Najprv na samostatnom zariadení uchovajte sledované, nesledované a ignorované súbory aj metadáta Gitu. Prezrite kópiu repozitára a overený commit obnovte do samostatného worktree; hard reset na mieste môže zničiť preživšie necommitnuté úpravy. ## Ailoot · Spoločnosť a jej portfólio projektov Ailoot stavia na dlhodobých prevádzkových skúsenostiach, širokej klientskej základni, stabilných službách a priebežnom sledovaní KPI. Spoločnosť a jej portfólio projektov: milióny zákazníkov; mesačné tržby v miliardách. Ailoot využíva tieto prevádzkové skúsenosti na poskytovanie prístupu cez API k funkciám AI v produktoch zákazníkov, agentoch, aplikáciách a automatizáciách.