Comarch ERP XT – Disaster Recovery dla bazy danych w kontekście systemu chmurowego wygląda inaczej niż w przypadku programów instalowanych lokalnie. Baza danych Comarch ERP XT nie znajduje się na komputerze klienta, lecz na serwerach Comarch, które objęte są własnymi procedurami tworzenia kopii zapasowych, replikacji i odtwarzania danych po awarii – to element infrastruktury dostawcy, a nie coś, co konfiguruje lub naprawia lokalny serwis komputerowy.
Nie oznacza to jednak, że po stronie klienta nie ma nic do zrobienia. Realnym tematem Disaster Recovery w tym modelu jest zabezpieczenie danych, które użytkownik pobiera z systemu i przechowuje lokalnie – oraz zapewnienie ciągłości dostępu do konta w razie problemów.
Co zabezpiecza Comarch, a czego nie
Baza danych Comarch ERP XT, wraz z historią dokumentów, danymi kontrahentów i rozliczeniami, jest utrzymywana na infrastrukturze Comarch. Tworzenie kopii zapasowych, replikacja danych między serwerami oraz procedury odtwarzania po awarii leżą po stronie dostawcy usługi i są elementem umowy SaaS – klient nie ma do nich bezpośredniego dostępu ani wpływu na ich konfigurację. Bieżący stan dostępności usług można sprawdzić na status.comarch.com.
Co realnie leży po stronie klienta
Lokalne kopie eksportowanych dokumentów
Wielu użytkowników pobiera z systemu faktury w PDF, raporty sprzedaży czy zestawienia księgowe i przechowuje je lokalnie – na dysku firmowego komputera, w folderze współdzielonym lub prywatnej chmurze. Te pliki nie są objęte mechanizmami backupu Comarch i to klient odpowiada za ich bezpieczeństwo.
Budowa lokalnej strategii kopii zapasowych
W ramach tej usługi pomagamy klientom zaplanować i wdrożyć rozsądną politykę przechowywania eksportowanych danych:
- regularne pobieranie kluczowych raportów i archiwizowanie ich w uporządkowanej strukturze folderów,
- przechowywanie kopii w co najmniej dwóch niezależnych lokalizacjach (np. dysk lokalny i chmura firmowa),
- ustalenie harmonogramu eksportu danych zgodnego z okresami rozliczeniowymi firmy,
- zabezpieczenie plików eksportowanych hasłem, jeśli zawierają dane wrażliwe.
Ciągłość dostępu do konta
Drugim filarem realnego „Disaster Recovery” po stronie klienta jest zapewnienie, że dostęp do konta Comarch ID nie zależy od jednego urządzenia czy jednej osoby. Pomagamy skonfigurować dodatkowe konto z uprawnieniami administracyjnymi, zapisać w bezpiecznym miejscu dane do logowania oraz ustawić alternatywną metodę weryfikacji dwuetapowej, tak aby awaria telefonu lub laptopa jednej osoby nie blokowała całej firmie dostępu do systemu.
Plan działania na wypadek niedostępności usługi
Choć awarie po stronie Comarch zdarzają się rzadko, warto mieć ustalony plan działania na czas niedostępności systemu – np. tymczasowe wystawianie dokumentów w formie zastępczej i ich uzupełnienie w systemie po przywróceniu usługi.
Dla kogo jest ta usługa
- firm chcących mieć realną politykę zabezpieczania danych eksportowanych z systemu,
- przedsiębiorstw wielostanowiskowych, gdzie dostęp do konta nie powinien zależeć od jednej osoby,
- klientów, którzy błędnie zakładali, że backup bazy danych to ich obowiązek.
Podsumowanie
W modelu SaaS odzyskiwanie po awarii bazy danych jest zadaniem Comarch, natomiast rolą klienta – i naszą jako serwisu – jest zabezpieczenie lokalnie przechowywanych eksportów oraz zapewnienie niezawodnego dostępu do konta.
