---
title: Daily Note - 2026-06-18
date: 2026-06-18 09:26:51
tags: []
Status: Active
type: DailyNote
---

Oracle database backup server (euniappbakprl01)
Oracle databases
product.bisnode.cz
public.bisnode.cz



https://dnbenterprise.atlassian.net/wiki/spaces/AllmantITKredit/pages/1855684994/CZ+disaster+recovery+plan


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.