diff --git a/journals/2026-06-18.md b/journals/2026-06-18.md
index 4a9abfd..2c107b1 100644
--- a/journals/2026-06-18.md
+++ b/journals/2026-06-18.md
@@ -20,4 +20,77 @@ dev servers
 devel1.bisnode.cz - free to restart
 devel2.bisnode.cz
 
+---
 
+### 🧾 Kluczowe wnioski
+
+**1. Przegląd architektury kopii zapasowych**
+Oceniane są dwa główne podejścia:
+- Kopia zapasowa wypychana (push) z hosta Oracle do systemu backupu VM
+- Kopia zapasowa pobierana (pull) przez system backupu VM bezpośrednio z bazy danych/serwera
+Decyzja nie została ostatecznie podjęta → wymaga testów i porównania.
+
+**2. Potrzeba walidacji w środowisku testowym**
+Wymagane jest środowisko testowe (Oracle + backup + przywracanie) w celu walidacji:
+- wykonalności
+- scenariuszy przywracania
+Dostępne zasoby:
+- Istniejące serwery deweloperskie (jeden można bez problemu restartować w ciągu dnia)
+- Dodatkowy serwer testowy Linux dostępny do izolowanych testów
+
+**3. Obecna strategia kopii zapasowych jest nieefektywna**
+Obecnie skonfigurowane są codzienne pełne kopie zapasowe (full backups).
+Zidentyfikowane problemy:
+- duża rotacja wolumenu danych
+- wpływ na wydajność maszyny wirtualnej i bazy danych
+- nieefektywne wykorzystanie przestrzeni dyskowej
+Ogólna zgoda zespołu: to podejście należy zmienić.
+
+**4. Proponowana zmiana strategii kopii zapasowych**
+Przejście na:
+- Cotygodniowe pełne kopie zapasowe
+- Codzienne przyrostowe/różnicowe kopie zapasowe
+- Częste kopie zapasowe logów (co kilka godzin)
+Omówione korzyści:
+- mniejsze zużycie przestrzeni dyskowej
+- poprawa wydajności
+- możliwość przywrócenia bazy do określonego momentu w czasie (point-in-time recovery)
+
+**5. Zarządzanie zmianą i kwestie komunikacyjne**
+Zmiana musi przejść przez standardowy proces zarządzania zmianami (~5 dni roboczych).
+Wymagana komunikacja:
+- Dostawca Oracle (Digitech)
+- Wewnętrzni interesariusze
+Jeśli wymagana będzie przerwa w działaniu (downtime):
+- Konieczne powiadomienie klienta z co najmniej 2-tygodniowym wyprzedzeniem (ze względu na SLA).
+Obecnie nie jest jasne, czy wymagany będzie restart bazy danych → należy to zweryfikować.
+
+**6. Planowanie kolejnych kroków**
+Spotkanie kontrolne (follow-up) prawdopodobnie zostanie zaplanowane na przyszły tydzień.
+
+### ✅ Zadania do wykonania (z przypisanymi osobami)
+
+**🔧 Techniczne / Wdrożeniowe**
+- Ocena podejść do kopii zapasowych (push vs pull z VM) — **Właściciel:** Paweł Domański (wsparcie: Łukasz)
+- Konfiguracja środowiska testowego (walidacja Oracle + backup + przywracanie) — **Właściciel:** Paweł Domański (wsparcie: Michal Pavlina ws. dostępności serwerów dev)
+- Użycie serwerów deweloperskich do testów — **Właściciel:** Michal Pavlina (uwaga: jeden z serwerów potwierdzony jako bezpieczny do restartów w ciągu dnia)
+- Sprawdzenie, czy zmiana strategii kopii zapasowych wymaga restartu bazy danych — **Właściciel:** Paweł Domański
+
+**📦 Zmiana strategii kopii zapasowych**
+- Zaprojektowanie nowego harmonogramu kopii zapasowych (cotygodniowy full + przyrostowe + logi) — **Właściciel:** Paweł Domański
+- Zaplanowanie i ustalenie harmonogramu zmiany na produkcji (standardowy proces zmiany) — **Właściciel:** Paweł Domański
+
+**📢 Komunikacja**
+- Koordynacja komunikacji z interesariuszami — **Właściciel:** Jan Dvořák + Michal Pavlina
+- Powiadomienie dostawcy Oracle (Digitech) o zmianie — **Właściciel:** Jan Dvořák (potwierdził odpowiedzialność)
+- Ocena potrzeby powiadomienia klienta (jeśli wymagany jest downtime) — **Właściciel:** Zespół (zależy od wyników weryfikacji konieczności restartu bazy)
+
+**📅 Koordynacja**
+- Zaplanowanie spotkania kontrolnego na przyszły tydzień — **Właściciel:** Leszek Wroński
+
+### ⚡ Szybkie podsumowanie (bardzo zwięzłe)
+- **Obecnie:** Codzienne pełne kopie zapasowe → nieefektywne → podlegają zmianie.
+- **Cel:** Cotygodniowe pełne + przyrostowe + kopie logów.
+- Wymagane testy i ostateczna decyzja między architekturami (push vs pull).
+- Zmiana wymaga przejścia formalnego procesu i zakomunikowania interesariuszom.
+- Otwarte ryzyko: weryfikacja czy wdrożenie wymusi restart lub downtime.