Paweł Domański
4.3 KiB
title, date, tags, Status, type
| title | date | tags | Status | type |
|---|---|---|---|---|
| Daily Note - 2026-06-18 | 2026-06-18 09:26:51 | Active | DailyNote |
Oracle database backup server (euniappbakprl01) Oracle databases product.bisnode.cz public.bisnode.cz
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.