AI usunęło bazę danych: 7-minutowy plan odzyskiwania

Praktyczne informacje o korzystaniu z Ailoot znajdziesz w dokumentacji.

Co zrobić w pierwszej minucie: STOP, nie panikuj#

Gdy przydarzy się to Tobie, pierwszą rzeczą, którą należy zrobić, jest zatrzymanie agenta. Nie próbuj samodzielnie cofać jego działań, nie każ mu „przywrócić wszystkiego” i nie uruchamiaj nowych promptów. Każde kolejne działanie agenta może nadpisać bloki dysku, w których nadal mogą znajdować się Twoje dane.

1. Zamknij terminal agenta

   Natychmiast przerwij niebezpieczne polecenie przez Ctrl+C; nie czekaj na zakończenie usuwania. Zatrzymanie agenta nie musi kończyć potomków, zadań zdalnych ani zapytań bazy. Ustal faktycznego zapisującego i zatrzymaj lub anuluj operację; zwiększ siłę zakończenia, jeśli nadal niszczy dane. Zachowaj niezwiązane procesy z potencjalnie odzyskiwalnymi plikami.

2. NIE uruchamiaj ponownie laptopa

   Usunięte dane mogą być odzyskiwalne, lecz decydują magazyn, zachowanie bazy, SSD discard/TRIM i późniejsze zapisy. Ogranicz zapisy na dotkniętym woluminie; nie zakładaj zachowania bajtów.

3. NIE zamykaj otwartych procesów

   Zachowaj niezwiązane procesy trzymające otwarte usunięte pliki, bo odzyskanie może być możliwe przez deskryptory. Nie dotyczy to destrukcyjnego zapisującego: zatrzymaj go najpierw. Nie pozwalaj na dalsze usuwanie dla zachowania otwartego uchwytu.

4. Rozpocznij nagrywanie ekranu

   Zapisz dokładny czas, dotknięte ścieżki i widoczne wyjście poleceń. Nagranie lub logi zapisuj na osobnym sprawdzonym urządzeniu zamiast uszkodzonego woluminu. Przed odzyskiwaniem zachowaj tam ocalałe pliki śledzone, nieśledzone, ignorowane i metadane Git.

Pozostało 6 minut na odzyskanie danych. Zaczynajmy.

Minuty 2–3: dokładnie udokumentuj, co poszło nie tak#

Otwórz nowe okno terminala. Nie to, w którym działa agent — inne. Uruchom kolejno te trzy polecenia.

1. Zapisz dokładnie, co zmieniło się w repozytorium git:

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

Usunięty plik śledzony może nadal istnieć w indeksie lub commicie. Przed odtwarzaniem zachowaj obecne drzewo, także nieśledzone i ignorowane pliki; odtwarzanie w miejscu może nadpisać ocalałe zmiany. Oceniaj i odzyskuj w osobnej kopii.

2. Sprawdź, które procesy agenta są uruchomione:

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

Ustal proces nadal wykonujący niebezpieczne zapisy; sama zgodność nazwy nie wystarcza. Zatrzymaj go i potwierdź zatrzymanie. Zachowaj niezwiązane procesy z przydatnymi otwartymi plikami; jeśli łagodne zakończenie zawodzi, a niszczenie trwa, może być konieczne wymuszone zakończenie.

3. Zapisz dziennik sesji agenta:

Claude Code przechowuje sesje JSONL w ~/.claude/projects/. Cursor zapisuje je w ~/.cursor/. Zrób kopię od razu:

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

Zastąp /external/incident-evidence/ istniejącym katalogiem dowodów na osobnym sprawdzonym podłączonym urządzeniu. Nie zapisuj kopii na dotkniętym woluminie ani nie nadpisuj istniejących dowodów. Ten folder zawiera dosłowny zapis rozmowy z agentem — polecenia, które wykonał, jego odpowiedzi i ich kolejność. To główne źródło informacji podczas badania incydentu, a także potencjalne źródło usuniętych plików, które można odzyskać z kontekstu agenta (zobacz krok 4).

Minuta 4: git reflog — najlepsza szansa#

git reflog zapisuje ruch lokalnych referencji, dopóki wpisy są zachowane. Wygasanie i usuwanie różnią się, a nieosiągalne obiekty mogą zniknąć; nie jest to gwarantowane archiwum każdego dawnego commita. Poniższe kroki wykonuj z zachowanej kopii repozytorium na osobnym urządzeniu.

Krok 1. Wyświetl dziennik:

git reflog --all

Zobaczysz listę podobną do tej:

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

Znajdź punkt sprzed szkód wyrządzonych przez agenta. Każdy wpis to „migawka” stanu repozytorium w danym momencie.

Krok 2. Odzyskaj w osobnym drzewie roboczym:

Po skopiowaniu repozytorium i ocalałej pracy na osobne urządzenie wykonaj to z zachowanej kopii. Wstaw dokładny SHA sprawdzony w reflog i wybierz nieużywaną gałąź i cel:

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

Obejrzyj pliki w ../recovery-check i porównaj z zachowanymi niezacommitowanymi plikami przed kopiowaniem z powrotem. Polecenie odtwarza commit osobno, bez resetu uszkodzonego drzewa. Worktree dzieli magazyn obiektów Git skopiowanego repozytorium; to obszar odzyskiwania, nie niezależna kopia. Zobacz oficjalną dokumentację git-worktree.

Jeśli reflog również został wyczyszczony (agent zdążył uruchomić git gc):

git fsck --lost-found

To polecenie wyszukuje „utracone” commity i bloby (obiekty plików), które nie są już przypisane do żadnej gałęzi. Pojawią się w .git/lost-found/commit/ i .git/lost-found/other/. Aby odzyskać stamtąd plik:

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

Kiedy git reflog nie pomoże:

• Plik znajdował się tylko w katalogu roboczym, bez commita i stashu → reflog go nie znajdzie
• Minęło ponad 90 dni (standardowe gc.reflogExpire) i uruchomiono git gc
• Usunięto całe repozytorium (rm -rf .git) — wtedy potrzebujesz Time Machine albo migawki

Minuta 5: przywróć bazę danych z kopii zapasowej#

Baza danych została usunięta za pomocą DROP DATABASE, DROP TABLE lub DELETE FROM ... WHERE ... (bez klauzuli WHERE). Co zrobić?

Krok 1. Sprawdź, czy dostawca oferuje PITR:

Krok 2. Przywróć dane do nowej instancji, nie do starej:

Nigdy nie przywracaj danych na działającą bazę. Utwórz nową instancję z kopii zapasowej, a następnie przełącz na nią aplikację. Jeśli coś pójdzie nie tak, możesz przełączyć DNS z powrotem.

Krok 3. Jeśli PITR nie było włączone, użyj najnowszej migawki:

# AWS RDS — wyświetl migawki:
aws rds describe-db-snapshots --db-instance-identifier my-db

# Przywróć z migawki:
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

Uwaga dotycząca Supabase, która zaskoczyła wiele osób w 2026 roku: po włączeniu PITR codzienne kopie zapasowe przestają być tworzone. To sprzeczne z intuicją zachowanie może doprowadzić do sytuacji, w której nie masz żadnych kopii zapasowych. Sprawdź Dashboard → Database → Backups i upewnij się, że PITR jest aktywne ORAZ że masz migawkę do przywrócenia.

Minuta 6: Time Machine, lsof i migawki dysku#

macOS — Time Machine:

# Wyświetl migawki:
tmutil listbackups

# Przywróć plik z najnowszej kopii zapasowej:
tmutil restore /Volumes/Backup/.../my-project/file.tsx ~/projects/my-project/file.tsx

Time Machine tworzy migawki co godzinę, przechowuje godzinowe migawki przez jeden dzień, dzienne przez tydzień, a tygodniowe bezterminowo. Jeśli laptop jest podłączony do Time Capsule lub dysku zewnętrznego, możesz przywrócić projekt z dokładnością do godziny.

Linux — plik został usunięty, ale proces nadal ma go otwartego:

# Znajdź wszystkie „usunięte” pliki nadal otwarte przez proces:
sudo lsof | grep deleted

# Zobaczysz wiersze podobne do tego:
# node 12345 user 24w REG 8,1 4096 1234567 /path/to/deleted/file.txt (deleted)

# Skopiuj plik bezpośrednio z /proc/PID/fd/N:
sudo cp /proc/12345/fd/24 ~/recovered-file.txt

Jeśli proces nie został zamknięty, szansa powodzenia wynosi ~95%. Działa w systemach ext4, xfs i btrfs.

macOS — odpowiednik z użyciem lsof:

lsof | grep deleted

Skopiowanie pliku jest trudniejsze (nie ma /proc/), ale można to zrobić za pomocą lldb:

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

Migawka całego dysku (Linux, ostateczność):

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

Zapisuje całą partycję w postaci obrazu. Następnie odzyskaj dane za pomocą extundelete lub photorec. Szansa na odzyskanie zależy od ilości danych zapisanych na dysku od chwili usunięcia. Jeśli nic nie zostało zapisane, wynosi 80–90%. Jeśli dysk pracował już przez godzinę, wynosi 20–30%.

Minuta 7: co zrobić, gdy nie ma kopii zapasowej#

Opcja 1 — pomoc techniczna dostawcy:

AWS, Yandex Cloud, Google Cloud i DigitalOcean okresowo odzyskują dane ze swoich wewnętrznych zasobów, nawet po awarii po stronie klienta — szczególnie w płatnych planach. Utwórz zgłoszenie do pomocy technicznej, podaj dokładny czas incydentu i dołącz zrzuty ekranu przedstawiające stan systemu. Ta metoda najczęściej działa u dużych dostawców, którzy przechowują własne automatyczne kopie zapasowe. Szansa powodzenia wynosi 40–60%; czas oczekiwania na odpowiedź to 24–72 godziny.

Opcja 2 — wersjonowanie S3:

Jeśli pliki znajdowały się w S3 (lub Yandex Object Storage) i włączono wersjonowanie, wszystkie wersje fizycznie istnieją; są jedynie oznaczone jako „usunięte”.

# AWS — wyświetl wersje:
aws s3api list-object-versions --bucket my-bucket --prefix files/

# Przywróć wersję:
aws s3api copy-object \
  --bucket my-bucket \
  --copy-source my-bucket/files/data.json?versionId=ABC123 \
  --key files/data.json

Ważna uwaga: Claude Code nie przechowuje sesji bezterminowo — starsze pliki JSONL są automatycznie usuwane po kilku tygodniach. Aby mieć miesięczną historię JSONL na wypadek katastrofy, raz w tygodniu kopiuj ~/.claude/projects/ na dysk zewnętrzny za pomocą prostego zadania cron:

# W crontab, w każdą niedzielę o 03:00:
0 3 * * 0 rsync -av ~/.claude/projects/ /external/claude-history-backup/

To darmowe rozwiązanie, które ratuje Cię, gdy „wszystko zniknęło, nie ma kopii zapasowej, a reflog jest pusty”.

7 zasad, które zapobiegną ponownemu wystąpieniu takiej sytuacji#

1. Przed każdą destrukcyjną operacją używaj Plan Mode. W Claude Code:

claude --plan

Agent tworzy plan przed działaniem. Czytasz go, widzisz DROP TABLE users i anulujesz operację. Bez Plan Mode agent sam podejmuje decyzje i wykonuje je w milisekundy. Więcej informacji znajdziesz w przewodniku po Plan Mode w Claude Code.

2. Hooki jako dodatkowy alarm. Użyj przetestowanego PreToolUse czytającego JSON zdarzenia ze stdin i zwracającego 2 po wykryciu wysokiego ryzyka. Pełny przykład niżej obejmuje Bash, Write i Edit; nie jest granicą bezpieczeństwa i może pominąć pośrednie operacje. Ograniczaj uprawnienia bazy i sandbox.

3. Użytkownik bazy danych tylko do odczytu dla agenta. Utwórz osobnego użytkownika agenta, który nie ma uprawnień 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;

Kiedy agent rzeczywiście musi zapisywać dane, przełącz się ręcznie na innego użytkownika. Użytkownik z dostępem tylko do odczytu wystarczy do codziennych zadań (analizy danych, raportów, pulpitów).

4. Zapisuj w Git sprawdzone zmiany. Hook PostToolUse w .claude/settings.json może wyświetlić przypomnienie po operacjach Write i Edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "printf '%s\\n' 'Sprawdź diff i ręcznie utwórz commit tylko z uzgodnionymi plikami.' >&2"
          }
        ]
      }
    ]
  }
}

Ten przykład tylko wyświetla przypomnienie; nie dodaje plików do indeksu ani nie tworzy commitów. Sprawdź diff i ręcznie utwórz commit tylko z uzgodnionymi plikami. Reflog nie zapisuje zmian, które nie znalazły się w commicie.

5. Projekt sandbox do eksperymentów. Nigdy nie pozwalaj agentowi pracować w projekcie zawierającym prawdziwe dane klientów. Utwórz osobny folder ~/sandbox-projects/ z kopią projektu i sztucznymi danymi. Używaj go do testowania nowego promptu, agenta lub serwera MCP. Jeśli coś się zepsuje, nie wyrządzi szkód.

6. Co godzinę twórz migawki dysku za pomocą restic.

# Instalacja:
brew install restic  # macOS
sudo apt install restic  # Linux

# Utwórz repozytorium:
restic init --repo /external/backups

# Utwórz kopię zapasową bieżącego projektu:
restic --repo /external/backups backup ~/projects

# Skonfiguruj cron uruchamiany co godzinę:
crontab -e
# Dodaj:
0 * * * * restic --repo /external/backups backup ~/projects

Siedem dni kopii godzinowych, cztery tygodnie kopii dziennych — i możesz przywrócić stan z dowolnego momentu w przeszłości. To bezpłatne i zajmuje 10 minut.

7. Archiwizuj sesje JSONL Claude Code. Wspomniano o tym wyżej, ale warto powtórzyć jako osobną zasadę: zaplanuj cotygodniowe kopiowanie ~/.claude/projects/ na dysk zewnętrzny za pomocą rsync. To bezpłatne i wymaga dodania jednej linijki do crontab.

Gotowe hooki do blokowania niebezpiecznych poleceń#

Scal ten wpis z .claude/settings.json bez zastępowania istniejących hooków:

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

Utwórz .claude/hooks/check-risk.py z tym skryptem 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 czyta udokumentowane zdarzenie JSON ze stdin, sprawdza tool_input.command lub tool_input.file_path i zwraca kod 2 przy dopasowaniu. Sprawdza Write i Edit. Przed poleganiem na nim przetestuj nieszkodliwą dozwoloną próbkę i blokowaną oraz potwierdź faktyczny start Python i skonfigurowanego skryptu.

To filtr leksykalny: może przeoczyć inną kolejność flag, skrypty, aliasy, zaciemnione polecenia, inne narzędzia i pośrednie zapisy; może też odrzucić niewinne cytowane przykłady. Nie nadaje ani nie odbiera uprawnień systemu i bazy. Trzymaj poświadczenia produkcyjne poza środowiskiem agenta, używaj roli tylko do odczytu i egzekwowanego sandboxa oraz chroń konfigurację hooka przed zmianą. Zobacz oficjalne wejście i kody wyjścia hooków.

Celowy wyjątek przejrzyj i wykonaj poza agentem właściwym ograniczonym kontem. Zmienna powłoki nie jest udokumentowanym interfejsem wyłączania hooków, a hooki nie kontrolują zwykłego terminala.

Kiedy przyznawać AI uprawnienia, a kiedy nie#

Anthropic opisuje flagę --dangerously-skip-permissions (znaną również jako tryb YOLO) jako opcję dla „zaufanych środowisk”. W realiach 2026 roku to bezpośrednia droga do katastrofy. Gdy agent nie musi pytać o zgodę, może:

• Wykonywać dowolne polecenie Bash bez potwierdzenia
• Zapisywać pliki bez pytania
• Wywoływać podagenta, który dziedziczy tryb YOLO i nie można go z tego trybu wyprowadzić

Trzeci punkt jest najbardziej podstępny. Jeśli uruchomisz głównego agenta w trybie YOLO, jego podagenci również będą działać w tym trybie i nie możesz tego zmienić. Jeden prompt może wywołać lawinę 10 równoległych agentów, które mogą zrobić wszystko w Twoim systemie.

Zasada:

Alternatywa — precyzyjne uprawnienia. W .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 widzi, co jest dozwolone, a co nie. Nie musisz za każdym razem klikać „tak” lub „nie” — agent działa szybko, a Ty kontrolujesz granice uprawnień.

Dalej: 7-minutowa lista kontrolna do zapisania#

Lista kontrolna: „AI to usunęło — co mam zrobić?”

1. Natychmiast zatrzymaj faktycznego destrukcyjnego zapisującego; sprawdź zatrzymanie operacji potomnych i zdalnych
2. Nie restartuj; zachowaj niezwiązane procesy trzymające otwarte usunięte pliki
3. Zapisz czas incydentu i dowody poleceń na osobnym sprawdzonym urządzeniu
4. Skopiuj ocalałe pliki, metadane Git i właściwe logi sesji na to osobne urządzenie
5. W zachowanej kopii sprawdź git reflog --all i odzyskaj zweryfikowany commit w osobnym worktree
6. Jeśli git nie pomógł — git fsck --lost-found
7. Baza danych: PITR (AWS/Yandex/Supabase) lub najnowsza migawka
8. Pliki: Time Machine na Macu, lsof w Linuksie
9. Ostateczność: pomoc techniczna dostawcy + wersjonowanie S3
10. Po odzyskaniu danych skonfiguruj 7 zasad zapobiegawczych opisanych w tym poradniku

Dalej — systemowa ochrona:

• Plan Mode w Claude Code — agent najpierw przygotowuje plan, zanim wykona destrukcyjną operację
• Hooks w Claude Code — gotowe szablony do blokowania niebezpiecznych poleceń
• Jak cofnąć zmiany w Claude Code — szczegółowy poradnik dotyczący /rewind, gita i 5 standardowych metod wycofywania zmian
• Przegląd bezpieczeństwa w Claude Code — regularne kontrole bezpieczeństwa kodu

Otwórz Ailoot.