Pravidlá zálohovania, uchovávania a obnovy dát

Článok 1

Predmet a účel pravidiel

1. Tieto Pravidlá zálohovania, uchovávania a obnovy dát (ďalej len „Pravidlá“) upravujú podmienky vytvárania, uchovávania, správy, používania a obnovy záloh dát v rámci služieb poskytovaných spoločnosťou WebHouse, s.r.o. (ďalej len „WebHouse“ alebo „Poskytovateľ“).
2. Účelom týchto Pravidiel je najmä:
   • transparentne vymedziť rozsah zálohovania jednotlivých služieb,
   • určiť základné pravidlá vytvárania a uchovávania záloh,
   • stanoviť spôsob a podmienky obnovy dát,
   • vysvetliť technické a prevádzkové obmedzenia zálohovania,
   • vymedziť zodpovednosť Poskytovateľa a Zákazníka v oblasti zálohovania a ochrany dát,
   • predchádzať nesprávnemu predpokladu, že poskytovanie hostingovej, e-mailovej, serverovej alebo inej služby automaticky zahŕňa úplné alebo neobmedzené zálohovanie všetkých dát Zákazníka,
   • stanoviť pravidlá nakladania so zálohami po ukončení, zrušení alebo expirácii služby.
3. Tieto Pravidlá upravujú najmä:
   • ktoré dáta a časti služby môžu byť predmetom zálohovania,
   • ktoré dáta môžu byť zo zálohovania vylúčené,
   • frekvenciu alebo spôsob vytvárania záloh,
   • počet a dostupnosť bodov obnovy,
   • dobu uchovávania jednotlivých záloh,
   • spôsob rotácie a odstraňovania starších záloh,
   • technické princípy uchovávania záloh,
   • možnosti a spôsob obnovy dát,
   • podmienky samoobslužnej alebo manuálnej obnovy,
   • možné spoplatnenie obnovy,
   • postup pri strate, poškodení, vymazaní alebo kompromitácii dát,
   • postup pri obnove po bezpečnostnom incidente,
   • pravidlá uchovávania záloh po skončení služby,
   • bezpečnostné opatrenia súvisiace so zálohami,
   • povinnosti Zákazníka týkajúce sa vlastných záloh,
   • vzťah zálohovania k SLA, technickej podpore, bezpečnosti služieb a ochrane osobných údajov.
4. Tieto Pravidlá sa vzťahujú iba na služby, pri ktorých:
   • je zálohovanie výslovne uvedené ako súčasť služby,
   • je zálohovanie uvedené v technickej špecifikácii alebo cenníku služby,
   • si Zákazník objednal samostatnú zálohovaciu službu,
   • alebo sa Poskytovateľ so Zákazníkom na zálohovaní osobitne dohodol.
5. Ak pri konkrétnej službe nie je zálohovanie výslovne uvedené, Zákazník nesmie predpokladať, že Poskytovateľ vytvára alebo uchováva zálohy dát tejto služby.

6. Samotné poskytovanie:

   • webhostingovej služby,
   • e-mailovej služby,
   • databázovej služby,
   • virtuálneho servera,
   • dedikovaného servera,
   • serverhousingu,
   • cloudovej alebo úložiskovej služby,
   • alebo inej technickej služby

   automaticky neznamená, že všetky alebo akékoľvek dáta Zákazníka sú zálohované.

7. Skutočnosť, že Poskytovateľ technicky disponuje zálohovacím systémom alebo vytvára zálohy niektorých častí svojej infraštruktúry na vlastné prevádzkové účely, sama osebe nezakladá Zákazníkovi právo na obnovu jeho dát, pokiaľ zálohovanie alebo obnova nie sú súčasťou objednanej služby.

8. Rozsah zálohovania sa môže pri jednotlivých službách významne líšiť.

   V závislosti od konkrétnej služby môže zálohovanie zahŕňať napríklad:

   • všetky zákaznícke dáta,
   • iba vybrané súbory,
   • iba databázy,
   • iba e-mailové schránky,
   • celý virtuálny server,
   • iba systémové alebo konfiguračné dáta,
   • prípadne inú vymedzenú časť služby.
9. Rozsah zálohovania môže byť rozdielny aj medzi rôznymi programami alebo variantmi rovnakého typu služby.
10. Konkrétny rozsah, frekvencia, retenčná doba a možnosti obnovy sú určené najmä:

• popisom konkrétnej služby,
• technickou špecifikáciou,
• cenníkom,
• zákazníckym rozhraním,
• osobitnými podmienkami služby,
• individuálnou zmluvou alebo objednávkou.

11. Ak je konkrétny parameter zálohovania výslovne uvedený pri objednanej službe, má takto uvedený parameter prednosť pred všeobecným ustanovením týchto Pravidiel.
12. Zálohovanie poskytované WebHouse je určené predovšetkým ako technický mechanizmus na zníženie rizika následkov:

• technickej poruchy,
• neúmyselného poškodenia dát,
• neúmyselného vymazania,
• zlyhania systému,
• niektorých bezpečnostných incidentov,
• inej udalosti, pri ktorej môže byť vhodné obnoviť starší stav dát.

13. Zálohovanie nie je určené ako náhrada za:

• dlhodobý archív,
• dokumentový archív,
• účtovný archív,
• systém elektronickej registratúry,
• právne alebo regulačné uchovávanie dokumentov,
• vlastnú zálohovaciu stratégiu Zákazníka,
• geograficky alebo technologicky nezávislé zálohy kritických dát,

pokiaľ konkrétna služba výslovne neposkytuje takúto funkcionalitu.

14. Zákazník berie na vedomie, že záloha predstavuje kópiu alebo technický obraz dát existujúcich v určitom čase.
15. Záloha preto môže obsahovať aj dáta, ktoré boli už v okamihu jej vytvorenia:

• poškodené,
• neúplné,
• nesprávne,
• kompromitované,
• infikované škodlivým kódom,
• alebo inak nepoužiteľné.

16. Vytvorenie zálohy samo osebe nepredstavuje potvrdenie Poskytovateľa, že obsah zálohy je:

• bezchybný,
• úplný,
• bezpečný,
• funkčný,
• alebo vhodný na konkrétny účel Zákazníka.

17. Záloha ani dostupnosť bodu obnovy nepredstavujú automatickú garanciu, že bude možné obnoviť:

• každý jednotlivý súbor,
• každú e-mailovú správu,
• každý databázový záznam,
• presný stav služby k ľubovoľne zvolenému okamihu,
• alebo úplnú funkčnosť aplikácie po obnove.

18. Obnova dát predstavuje technický úkon, ktorého výsledkom je spravidla obnovenie dostupnej kópie dát z konkrétneho bodu obnovy.
19. Obnova dát neznamená automaticky:

• opravu webovej aplikácie,
• odstránenie bezpečnostnej zraniteľnosti,
• odstránenie malvéru,
• opravu zdrojového kódu,
• opravu databázovej logiky,
• obnovenie externých služieb,
• ani odstránenie príčiny, ktorá viedla k strate alebo poškodeniu dát.

20. Ak bola strata alebo poškodenie dát spôsobené chybou, zraniteľnosťou alebo kompromitáciou aplikácie Zákazníka, samotná obnova staršej zálohy nemusí zabrániť opakovaniu rovnakého incidentu.
21. Zákazník je preto zodpovedný za odstránenie príčiny incidentu v tej časti služby, ktorú podľa podmienok služby spravuje Zákazník.
22. Zákazník je povinný primerane posúdiť význam, hodnotu a nahraditeľnosť svojich dát.
23. Ak by strata dát mohla mať pre Zákazníka významné finančné, prevádzkové, právne alebo iné následky, odporúča sa, aby Zákazník disponoval aj vlastnou zálohou nezávislou od zálohovacieho systému WebHouse.
24. Pri kritických alebo nenahraditeľných dátach by Zákazník nemal používať zálohu poskytovanú WebHouse ako jedinú existujúcu zálohu.
25. Zodpovednosť za určenie toho, či rozsah zálohovania poskytovaný v rámci konkrétnej služby zodpovedá potrebám Zákazníka, nesie Zákazník.
26. Ak Zákazník požaduje vyššiu úroveň ochrany dát, než poskytuje štandardná služba, môže si podľa ponuky WebHouse objednať najmä:

• samostatnú zálohovaciu službu,
• dlhšiu retenčnú dobu,
• vyššiu frekvenciu zálohovania,
• samostatné zálohovacie úložisko,
• geograficky alebo technologicky oddelenú zálohu,
• individuálne dohodnuté RPO alebo RTO,
• inú individuálnu zálohovaciu službu.

27. Tieto Pravidlá neupravujú zákonnú alebo zmluvnú zodpovednosť Poskytovateľa za vady alebo škodu nad rámec otázok priamo súvisiacich so zálohovaním a obnovou dát.
28. Skutočnosť, že určitý incident možno odstrániť použitím zálohy, sama osebe neznamená:

• uznanie vady služby,
• uznanie zodpovednosti Poskytovateľa,
• ani vznik nároku na náhradu škody.

29. Rovnako skutočnosť, že záloha nie je dostupná alebo použiteľná, sa posudzuje podľa:

• rozsahu konkrétnej objednanej služby,
• dohodnutých parametrov zálohovania,
• príčiny nedostupnosti zálohy,
• okolností konkrétneho prípadu.

30. Tieto Pravidlá treba vykladať spolu s ďalšími zmluvnými a prevádzkovými dokumentmi WebHouse, najmä:

• Všeobecnými obchodnými podmienkami,
• Reklamačným poriadkom,
• SLA – Garanciou dostupnosti služieb,
• Rozsahom a podmienkami technickej podpory,
• Bezpečnosťou služieb a rozdelením zodpovednosti,
• Podmienkami spracúvania osobných údajov – DPA,
• osobitnými podmienkami konkrétnej služby.

31. Ak osobitné podmienky konkrétnej služby upravujú zálohovanie, retenciu alebo obnovu dát podrobnejšie alebo odlišne, použijú sa vo vzťahu k tejto službe prednostne.
32. Žiadne ustanovenie týchto Pravidiel nemožno vykladať ako obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 2

Vymedzenie pojmov

Na účely týchto Pravidiel sa rozumie:

1. Zálohou samostatná kópia dát alebo technický obraz dát vytvorený zálohovacím procesom s cieľom umožniť ich prípadnú obnovu v prípade straty, poškodenia, vymazania, technickej poruchy, bezpečnostného incidentu alebo inej udalosti.

   Záloha môže obsahovať celé dáta služby alebo iba ich určenú časť a nemusí byť identická s aktuálnym stavom produkčných dát.

2. Bodom obnovy konkrétny historický stav dát alebo systému zachytený zálohovacím mechanizmom, z ktorého môže byť technicky možné vykonať obnovu.

   Jednotlivé body obnovy môžu byť vytvárané v rozdielnych časoch a nemusia existovať pre každý okamih prevádzky služby.

3. Retenčnou dobou obdobie, počas ktorého je záloha alebo bod obnovy podľa parametrov konkrétnej služby štandardne uchovávaný v zálohovacom systéme.

   Po uplynutí retenčnej doby môže byť záloha automaticky odstránená, prepísaná alebo nahradená novšou zálohou bez ďalšieho upozornenia Zákazníka.

4. Retenčným cyklom spôsob postupného uchovávania, rotácie a odstraňovania záloh alebo bodov obnovy v priebehu času.

   Retenčný cyklus môže byť určený napríklad:

   • počtom dní,
   • počtom dostupných bodov obnovy,
   • počtom generácií záloh,
   • kombináciou uvedených parametrov.

5. Obnovou technický proces, pri ktorom sa dáta alebo ich časť získajú zo zálohy a:

   • vrátia do produkčného prostredia,
   • obnovia do náhradného alebo dočasného prostredia,
   • alebo sprístupnia Zákazníkovi na ďalšie použitie.

   Obnova nemusí automaticky znamenať obnovenie úplnej funkčnosti aplikácie alebo systému.

6. Úplnou obnovou obnova celej zálohovanej jednotky, napríklad:
   • celého hostingového účtu,
   • celej databázy,
   • celej e-mailovej schránky,
   • celého virtuálneho servera,
   • alebo iného celku podľa charakteru služby.

7. Čiastočnou alebo selektívnou obnovou obnova iba určitej časti dát, napríklad konkrétneho súboru, adresára, databázy alebo inej podporovanej jednotky.

   Možnosť selektívnej obnovy závisí od použitej technológie a nemusí byť dostupná pri každej službe.

8. Produkčnými dátami aktuálne dáta používané alebo dostupné v rámci aktívnej prevádzky služby Zákazníka.

   Produkčnými dátami môžu byť podľa typu služby najmä:

   • webové súbory,
   • databázy,
   • e-mailové správy,
   • konfigurácie,
   • virtuálne disky,
   • dokumenty,
   • používateľské dáta.
9. Produkčným prostredím aktívne technické prostredie, v ktorom je služba Zákazníka bežne prevádzkovaná a v ktorom sa používajú produkčné dáta.
10. Archiváciou dlhodobé alebo účelové uchovávanie dát na zabezpečenie ich dostupnosti v budúcnosti, najmä na:

• evidenčné účely,
• právne alebo regulačné účely,
• účtovné účely,
• interné potreby Zákazníka,
• dlhodobé uchovávanie historických údajov.

Archivácia je odlišná od bežného zálohovania a nie je automaticky súčasťou zálohovacej služby.

11. Snapshotom technický obraz stavu systému, úložiska, virtuálneho disku alebo dát v určitom okamihu, ktorý môže umožniť návrat k predchádzajúcemu stavu.

Snapshot nemusí predstavovať nezávislú zálohu a môže byť uložený na rovnakej alebo súvisiacej infraštruktúre ako produkčné dáta.

12. Plnou zálohou záloha obsahujúca celý rozsah dát určených na zálohovanie v rámci konkrétnej zálohovanej jednotky.
13. Inkrementálnou zálohou záloha obsahujúca spravidla iba zmeny vykonané od predchádzajúcej zálohy príslušného typu.
14. Diferenciálnou zálohou záloha obsahujúca spravidla zmeny vykonané od poslednej plnej zálohy.
15. Zálohovacou úlohou automatizovaný alebo manuálne spustený technický proces, ktorého účelom je vytvorenie zálohy.
16. Zálohovacím cyklom opakovaný proces vytvárania záloh podľa harmonogramu alebo technických pravidiel konkrétnej služby.
17. Zálohovacím systémom technická infraštruktúra, softvér, úložisko a súvisiace mechanizmy používané Poskytovateľom na vytváranie, správu, uchovávanie alebo obnovu záloh.
18. Zálohovacím úložiskom úložný priestor používaný na uchovávanie záloh.

Zálohovacie úložisko môže byť podľa charakteru služby:

• lokálne,
• oddelené od produkčného úložiska,
• geograficky oddelené,
• alebo prevádzkované prostredníctvom inej vhodnej technickej architektúry.

19. Externou zálohou Zákazníka záloha vytvorená, spravovaná alebo uchovávaná Zákazníkom nezávisle od zálohovacieho systému WebHouse.

Za externú zálohu sa môže považovať najmä kópia uložená:

• na zariadení Zákazníka,
• na inom serveri,
• v inom dátovom centre,
• u iného poskytovateľa,
• v inom cloudovom alebo zálohovacom systéme.

20. Nezávislou zálohou záloha vytvorená alebo uchovávaná spôsobom, ktorý primerane znižuje riziko, že rovnaká udalosť súčasne poškodí produkčné dáta aj ich zálohu.
21. Manuálnou zálohou záloha vytvorená na základe konkrétneho pokynu Zákazníka alebo Poskytovateľa mimo štandardného automatického zálohovacieho cyklu.
22. Automatickou zálohou záloha vytváraná automatizovaným zálohovacím systémom podľa nastaveného harmonogramu alebo technických pravidiel.
23. Konzistentnou zálohou záloha vytvorená spôsobom, ktorý je z technického hľadiska vhodný na zachovanie vzájomnej konzistencie zálohovaných dát v rozsahu podporovanom príslušnou technológiou.
24. Poškodenou zálohou záloha, ktorú nie je možné úplne alebo čiastočne použiť na obnovu z dôvodu technickej chyby, poškodenia dát, nekonzistencie alebo iného problému.
25. Použiteľnou zálohou záloha, z ktorej je podľa dostupných technických možností možné obnoviť aspoň rozsah dát, na ktorý je určená.

Použiteľnosť zálohy neznamená automaticky, že obnovená aplikácia alebo služba bude po obnove plne funkčná.

26. Kompromitovanými dátami dáta, pri ktorých došlo alebo mohlo dôjsť k neoprávnenému prístupu, zmene, odstráneniu, poškodeniu, zašifrovaniu alebo inému bezpečnostnému zásahu.
27. Kompromitovanou zálohou záloha obsahujúca dáta, ktoré boli už v čase jej vytvorenia kompromitované, alebo záloha, ktorej integrita bola následne narušená.
28. Dobou obnoviteľnosti obdobie, za ktoré môžu existovať použiteľné body obnovy podľa retenčných podmienok konkrétnej služby.

Doba obnoviteľnosti nemusí byť totožná s nominálnou retenčnou dobou, ak napríklad niektorý plánovaný bod obnovy nevznikol alebo nie je použiteľný.

29. RPO (Recovery Point Objective) cieľový alebo garantovaný maximálny časový rozdiel medzi okamihom incidentu a najnovším bodom obnovy, ak je takýto parameter pri konkrétnej službe výslovne stanovený.

Samotná frekvencia zálohovania automaticky nepredstavuje garantované RPO.

30. RTO (Recovery Time Objective) cieľová alebo garantovaná doba potrebná na obnovenie služby alebo dát po incidente, ak je takýto parameter pri konkrétnej službe výslovne stanovený.

Samotná existencia zálohy automaticky nepredstavuje garantované RTO.

31. Technickou retenciou dočasné uchovávanie dát alebo záloh vyplývajúce z technického fungovania systému, ktoré nemusí predstavovať službu archivácie ani garantovanú dostupnosť dát pre Zákazníka.
32. Exspirovanou službou služba, ktorej predplatené alebo zmluvné obdobie skončilo a nebolo riadne predĺžené.
33. Ukončenou službou služba, ktorej poskytovanie bolo ukončené z dôvodu výpovede, zrušenia, odstúpenia, expirácie alebo iného dôvodu podľa zmluvných podmienok.
34. Kritickými dátami dáta, ktorých strata, poškodenie alebo dlhšia nedostupnosť môže mať pre Zákazníka významné prevádzkové, finančné, právne, bezpečnostné alebo iné následky.
35. Nenahraditeľnými dátami dáta, ktoré Zákazník po ich strate nemôže primerane znovu vytvoriť, získať z iného zdroja alebo rekonštruovať.
36. Obnovovacím zásahom úkon vykonaný Poskytovateľom alebo automatizovaným systémom smerujúci k obnove dát alebo služby zo zálohy.
37. Samoobslužnou obnovou obnova, ktorú môže Zákazník vykonať prostredníctvom dostupného zákazníckeho alebo administratívneho rozhrania bez manuálneho zásahu pracovníka WebHouse.
38. Manuálnou obnovou obnova, ktorá vyžaduje zásah pracovníka alebo administrátora WebHouse.
39. Dočasným obnovovacím priestorom technický priestor, do ktorého môže byť záloha obnovená bez okamžitého prepísania aktuálnych produkčných dát, aby mohol Zákazník obsah zálohy skontrolovať alebo z nej vybrať potrebné dáta.
40. Zákazníkom osoba využívajúca príslušnú službu WebHouse, ktorá je oprávnená nakladať s dátami uloženými alebo spracúvanými v rámci tejto služby.
41. Poskytovateľom alebo WebHouse sa rozumie spoločnosť WebHouse, s.r.o.

Článok 3

Základný princíp zálohovania

1. Zálohovanie slúži ako technický a prevádzkový nástroj na zníženie rizika následkov straty, poškodenia, vymazania, kompromitácie alebo inej nedostupnosti dát.
2. Účelom zálohovania je vytvárať v primeraných intervaloch kópie alebo technické obrazy dát, ktoré môžu byť podľa podmienok konkrétnej služby použité na ich úplnú alebo čiastočnú obnovu.
3. Zálohovanie predstavuje jednu z vrstiev ochrany dát. Nenahrádza ostatné bezpečnostné, prevádzkové alebo organizačné opatrenia potrebné na ochranu dát a zabezpečenie kontinuity prevádzky.
4. Samotná existencia zálohy nepredstavuje absolútnu garanciu, že:
   • všetky dáta bude možné vždy obnoviť,
   • všetky zálohované dáta budú úplné a nepoškodené,
   • každý vytvorený bod obnovy bude technicky použiteľný,
   • záloha bude obsahovať najnovšiu verziu dát,
   • záloha bude obsahovať stav dát bezprostredne pred vznikom incidentu,
   • bude možné obnoviť každý jednotlivý súbor, správu, databázový záznam alebo inú jednotlivú položku,
   • bude možné vykonať selektívnu obnovu ľubovoľnej časti dát,
   • bude možné obnoviť dáta k ľubovoľnému historickému dátumu alebo času,
   • bude možné obnoviť dáta staršie než dostupná retenčná doba,
   • obnovená aplikácia, webová stránka, databáza, e-mailová schránka alebo server budú po obnove automaticky plne funkčné.
5. Záloha spravidla zachytáva stav dát v určitom okamihu. Medzi okamihom vytvorenia poslednej použiteľnej zálohy a vznikom incidentu preto môže dôjsť k vytvoreniu alebo zmene dát, ktoré už v príslušnej zálohe nebudú obsiahnuté.
6. Frekvencia vytvárania záloh preto sama osebe neznamená, že v prípade incidentu bude možné obnoviť úplne aktuálny stav dát.
7. Ak napríklad zálohovací systém vytvára zálohu raz denne, môže v závislosti od času vzniku incidentu dôjsť k strate zmien vykonaných od posledného použiteľného bodu obnovy.
8. Konkrétny možný rozsah straty dát závisí najmä od:
   • frekvencie zálohovania,
   • okamihu poslednej úspešnej zálohy,
   • použiteľnosti konkrétneho bodu obnovy,
   • času vzniku alebo zistenia incidentu,
   • typu a rozsahu poškodenia dát.
9. Samotná deklarovaná frekvencia zálohovania nepredstavuje garantované RPO, pokiaľ je konkrétna hodnota RPO výslovne dohodnutá pri príslušnej službe.
10. Rovnako existencia použiteľnej zálohy nepredstavuje garanciu konkrétneho času obnovy.
11. Konkrétne RTO sa považuje za garantované iba vtedy, ak je výslovne uvedené v parametroch služby, SLA alebo individuálnej dohode so Zákazníkom.
12. Žiadny zálohovací systém nemožno považovať za absolútne bezchybný.
13. Pri zálohovaní môže napriek primeraným technickým a organizačným opatreniam dôjsť najmä k:

• nevytvoreniu plánovanej zálohy,
• prerušeniu zálohovacieho procesu,
• neúplnému vytvoreniu zálohy,
• poškodeniu zálohovaných dát,
• poškodeniu samotnej zálohy,
• chybe zálohovacieho softvéru,
• chybe úložiska,
• nekonzistencii dát,
• zlyhaniu obnovovacieho procesu,
• strate jednotlivého bodu obnovy.

14. Úspešné dokončenie zálohovacej úlohy samo osebe nemusí znamenať, že každý jednotlivý súbor alebo záznam v zálohe je technicky použiteľný.
15. Nie je technicky ani prevádzkovo možné po vytvorení každej zálohy vykonať úplnú testovaciu obnovu všetkých dát každého Zákazníka.
16. Poskytovateľ môže používať automatizovaný monitoring, kontrolu integrity, testovanie alebo iné primerané mechanizmy na zvýšenie spoľahlivosti zálohovania, ich použitie však nepredstavuje absolútnu garanciu obnoviteľnosti všetkých dát.
17. Záloha môže obsahovať rovnaký chybný, poškodený alebo nežiaduci stav, aký sa nachádzal v produkčných dátach v čase jej vytvorenia.
18. Záloha môže preto obsahovať napríklad:

• chybnú databázu,
• poškodené súbory,
• nesprávnu konfiguráciu,
• zraniteľnú verziu aplikácie,
• škodlivý kód,
• malware,
• neoprávnene zmenené dáta,
• dáta už poškodené v dôsledku bezpečnostného incidentu.

19. Samotné obnovenie staršej zálohy preto nemusí odstrániť príčinu pôvodného problému.
20. Ak napríklad kompromitáciu webovej stránky spôsobila zraniteľnosť aplikácie alebo pluginu, môže byť rovnaká zraniteľnosť prítomná aj v obnovenej zálohe.
21. Zákazník je po obnove povinný vykonať primerané opatrenia na odstránenie príčiny incidentu v rozsahu, za ktorý podľa konkrétnej služby zodpovedá.
22. Obnova dát zo zálohy predstavuje technickú obnovu dostupného historického stavu dát, nie automaticky:

• opravu aplikácie,
• opravu zdrojového kódu,
• odstránenie zraniteľnosti,
• odstránenie malvéru,
• aktualizáciu CMS alebo pluginov,
• opravu databázovej logiky,
• rekonfiguráciu systému,
• obnovenie služieb tretích strán.

23. Obnovená služba môže vyžadovať ďalšie technické alebo administrátorské zásahy pred tým, ako bude možné ju opäť riadne používať.
24. Možnosť obnovy závisí vždy od toho, či v čase požiadavky existuje vhodný a technicky použiteľný bod obnovy.
25. Ak požadovaný bod obnovy neexistuje, je poškodený alebo ho nemožno technicky použiť, WebHouse môže podľa dostupnosti ponúknuť iný, spravidla starší bod obnovy.
26. Zákazník nemá nárok na vytvorenie alebo spätné získanie bodu obnovy, ktorý nebol vytvorený, už bol odstránený v rámci retenčného cyklu alebo sa stal technicky nepoužiteľným, pokiaľ z konkrétne dohodnutých parametrov služby nevyplýva inak.
27. Zálohovanie nemožno považovať za náhradu vlastnej zálohovacej stratégie Zákazníka.
28. Zákazník je povinný primerane posúdiť:

• hodnotu svojich dát,
• ich nahraditeľnosť,
• požadovanú dobu uchovávania,
• prípustný rozsah straty dát,
• prípustnú dobu obnovy,
• následky ich straty alebo poškodenia.

29. Ak štandardné parametre zálohovania WebHouse nezodpovedajú týmto požiadavkám, Zákazník je povinný zabezpečiť si ďalšiu alebo vhodnejšiu formu zálohovania.
30. Pri kritických alebo nenahraditeľných dátach by mal Zákazník používať viac než jednu nezávislú kópiu dát a zabezpečiť, aby aspoň jedna z nich nebola závislá od rovnakého technického systému ako produkčná služba.
31. Poskytovateľ odporúča, aby kritické dáta neboli uchovávané výlučne:

• v produkčnej službe,
• ani výlučne v zálohách vytváraných tým istým poskytovateľom.

32. Externá alebo nezávislá záloha môže byť vhodná najmä na ochranu pred:

• rozsiahlym technickým zlyhaním,
• chybou administrátora,
• kompromitáciou zákazníckeho účtu,
• ransomvérom,
• poškodením viacerých vrstiev infraštruktúry,
• neúmyselným odstránením služby.

33. Zákazník zodpovedá za svoje externé zálohy a za overenie ich funkčnosti.
34. Poskytovateľ nezodpovedá za:

• zálohy vytvorené Zákazníkom,
• zálohovací softvér Zákazníka,
• externé zálohovacie systémy,
• úložiská tretích strán,
• ani za obnoviteľnosť záloh, ktoré Poskytovateľ nespravuje.

35. Zálohovanie a vysoká dostupnosť predstavujú rozdielne mechanizmy.
36. Redundancia, RAID, replikácia, vysoká dostupnosť alebo clustering môžu znížiť riziko výpadku, ale samy osebe nepredstavujú zálohu.
37. Takéto mechanizmy môžu okamžite preniesť aj:

• nesprávne zmeny,
• vymazanie dát,
• poškodenie,
• alebo kompromitované dáta

na redundantný systém.

38. Rovnako ani záloha sama osebe nezabezpečuje nepretržitú dostupnosť služby.
39. Dostupnosť služby sa posudzuje podľa podmienok príslušnej služby a SLA, zatiaľ čo zálohovanie a obnova sa posudzujú podľa týchto Pravidiel.
40. Zálohovanie nie je automaticky službou archivácie.
41. Zákazník nesmie predpokladať, že odstránené dáta zostanú v zálohách uchovávané dlhodobo alebo po neurčitú dobu.
42. Dáta uložené v zálohe môžu byť po uplynutí retenčnej doby automaticky odstránené alebo prepísané.
43. Ak Zákazník potrebuje uchovávať určitý obsah po zákonom, zmluvou alebo vlastnými internými pravidlami určenej dobe, zodpovedá za zabezpečenie vhodného archivačného riešenia.
44. Zálohovací systém WebHouse nemožno bez výslovnej dohody považovať za:

• účtovný archív,
• právny archív,
• elektronickú registratúru,
• nemenný archív,
• alebo systém určený na preukazovanie historického obsahu dát.

45. Skutočnosť, že WebHouse dokáže v konkrétnom prípade obnoviť dáta nad rámec štandardných parametrov služby, neznamená vznik povinnosti poskytovať rovnakú možnosť pri inom incidente alebo v budúcnosti.
46. Rovnako jednorazová manuálna pomoc pri vyhľadaní alebo obnove konkrétnych dát nevytvára právo Zákazníka na rovnaký rozsah zásahu pri ďalšej požiadavke.
47. Pri posudzovaní funkčnosti zálohovacej služby je rozhodujúci rozsah a parametre zálohovania výslovne dohodnuté pri konkrétnej službe.
48. Samotná existencia straty dát, poškodenia dát alebo nemožnosti obnoviť konkrétny historický stav automaticky neznamená poruchu alebo vadu zálohovacej služby.
49. Pri posúdení konkrétnej situácie sa prihliada najmä na:

• rozsah objednaného zálohovania,
• deklarovanú frekvenciu,
• retenčnú dobu,
• dostupné body obnovy,
• príčinu straty alebo poškodenia dát,
• príčinu prípadnej nepoužiteľnosti zálohy,
• technické okolnosti konkrétneho incidentu.

50. Tieto ustanovenia nemožno vykladať ako vylúčenie alebo obmedzenie zodpovednosti WebHouse v prípadoch, v ktorých takúto zodpovednosť podľa všeobecne záväzných právnych predpisov nemožno vylúčiť alebo obmedziť.

Článok 4

Rozsah zálohovania

1. Rozsah zálohovania závisí od druhu, variantu a technických parametrov konkrétnej objednanej služby.
2. Zálohovanie sa vykonáva iba v rozsahu, ktorý je:
   • súčasťou konkrétnej služby,
   • uvedený v jej technickej špecifikácii,
   • uvedený v cenníku alebo zákazníckom rozhraní,
   • dohodnutý v osobitných podmienkach,
   • alebo individuálne dohodnutý so Zákazníkom.
3. Samotná existencia dát v rámci služby neznamená, že tieto dáta sú automaticky zahrnuté do zálohovania.
4. Podľa typu služby môžu byť predmetom zálohovania najmä:
   • súbory webhostingového účtu,
   • webové aplikácie a ich súbory,
   • databázy,
   • e-mailové schránky,
   • vybrané konfigurácie,
   • používateľské dáta,
   • virtuálne disky,
   • celé virtuálne servery,
   • systémové dáta,
   • ďalšie dátové objekty podľa charakteru služby.

5. Pri zdieľanom webhostingu môže zálohovanie zahŕňať najmä:

   • webové súbory,
   • databázy,
   • prípadne e-mailové dáta,

   podľa parametrov konkrétneho webhostingového programu.

6. Pri e-mailových službách môže zálohovanie zahŕňať najmä obsah e-mailových schránok uložený na serveroch Poskytovateľa.
7. Pri databázových službách môže zálohovanie zahŕňať celú databázu alebo jej technický export v rozsahu podporovanom použitou databázovou technológiou.
8. Pri virtuálnych serveroch môže zálohovanie podľa typu služby zahŕňať napríklad:
   • celý virtuálny disk,
   • celý virtuálny server,
   • snapshot virtuálneho servera,
   • vybrané dáta,
   • alebo zálohu vykonávanú na úrovni operačného systému.
9. Pri dedikovaných serveroch, serverhousingu alebo iných službách poskytujúcich Zákazníkovi vlastné systémové prostredie nemusí byť automatické zálohovanie súčasťou služby vôbec, pokiaľ si Zákazník zálohovanie osobitne neobjednal.
10. Rozsah zálohovania jednej služby môže byť rozdelený medzi viac samostatných zálohovacích mechanizmov.
11. Napríklad:

• súbory môžu byť zálohované iným spôsobom ako databázy,
• databázy môžu mať odlišnú frekvenciu zálohovania,
• e-mailové schránky môžu používať samostatný zálohovací systém,
• konfigurácie môžu byť uchovávané oddelene od používateľských dát.

12. Jednotlivé časti tej istej služby preto nemusia mať:

• rovnakú frekvenciu zálohovania,
• rovnakú retenčnú dobu,
• rovnaký počet bodov obnovy,
• rovnaký spôsob obnovy.

13. Skutočnosť, že je určitá časť služby zálohovaná, neznamená, že sú automaticky zálohované všetky ostatné časti tejto služby.
14. Niektoré služby môžu obsahovať iba čiastočné zálohovanie.
15. Čiastočné zálohovanie môže znamenať napríklad, že sa zálohujú:

• iba používateľské dáta, ale nie celý operačný systém,
• iba databázy, ale nie súbory,
• iba súbory, ale nie externé databázy,
• iba obsah schránok uložený na serveri, ale nie lokálne e-mailové archívy,
• iba vybrané adresáre alebo technické objekty.

16. Zálohovanie sa nemusí vzťahovať na všetky dáta, ktoré sú technicky dostupné alebo viditeľné v rámci služby.
17. Niektoré údaje môžu byť zo zálohovania vylúčené z technických, bezpečnostných alebo prevádzkových dôvodov.
18. Zálohovanie nemusí zahŕňať najmä:

• dočasné súbory,
• cache,
• session dáta,
• systémové dočasné adresáre,
• dočasné pracovné kópie,
• swap,
• runtime dáta,
• vybrané logy,
• súbory vytvárané automaticky a jednoducho rekonštruovateľné,
• dáta uložené mimo priestoru určeného na zálohovanie,
• pripojené externé úložiská,
• dáta služieb tretích strán,
• dáta uložené výhradne na zariadení Zákazníka.

19. Konkrétny zoznam vylúčených dát môže závisieť od technológie použitej pri danej službe.
20. WebHouse môže v primeranom rozsahu technicky vylúčiť zo zálohovania aj dáta, ktorých zálohovanie:

• by nemalo praktický význam,
• by neprimerane zaťažovalo zálohovací systém,
• by bolo technicky nevhodné,
• by mohlo ohroziť stabilitu alebo bezpečnosť systému,

pokiaľ tým nie sú porušené výslovne dohodnuté parametre služby.

21. Ak je pri konkrétnej službe uvedené, že sa zálohujú „dáta Zákazníka“, tento pojem sa vykladá podľa technickej špecifikácie danej služby a neznamená automaticky všetky dáta existujúce v ľubovoľnej časti infraštruktúry.
22. Zálohovanie sa spravidla vzťahuje iba na dáta nachádzajúce sa v podporovanom a určenom úložnom priestore služby.
23. Ak Zákazník uloží dáta:

• do nepodporovaného adresára,
• mimo štandardnej dátovej štruktúry,
• na externé úložisko,
• do dočasného priestoru,
• alebo iným spôsobom mimo rozsahu zálohovania,

takéto dáta nemusia byť súčasťou zálohy.

24. Zákazník je povinný oboznámiť sa s tým, ktoré časti jeho služby sú zahrnuté do zálohovania.
25. Ak má Zákazník pochybnosť, či sú konkrétne dáta zálohované, mal by si túto skutočnosť overiť ešte predtým, ako začne službu používať ako jediné miesto ich uloženia.
26. Niektoré služby nemusia obsahovať žiadne automatické zálohovanie.
27. Pri takýchto službách zodpovedá za vytvorenie a správu záloh Zákazník, ak si samostatnú zálohovaciu službu neobjednal.
28. Táto zásada sa môže týkať najmä:

• nespravovaných VPS,
• dedikovaných serverov,
• serverhousingu,
• vlastných serverov Zákazníka,
• externých úložísk,
• iných služieb, pri ktorých nie je zálohovanie uvedené ako súčasť služby.

29. Samotná technická možnosť WebHouse vytvoriť zálohu určitého systému neznamená, že je povinný takúto zálohu vytvárať.
30. WebHouse môže na vlastné prevádzkové, bezpečnostné alebo technologické účely vytvárať interné kópie, snapshoty alebo iné technické obrazy niektorých systémov.
31. Takéto interné prevádzkové kópie:

• nemusia byť vytvárané pravidelne,
• nemusia byť uchovávané počas určenej doby,
• nemusia obsahovať všetky zákaznícke dáta,
• nemusia byť technicky vhodné na individuálnu obnovu,
• a nemusia byť Zákazníkovi sprístupnené.

32. Existencia internej technickej kópie sama osebe nezakladá Zákazníkovi nárok na:

• jej vydanie,
• jej uchovanie,
• obnovu dát z nej,
• ani predĺženie jej retenčnej doby.

33. Nárok na zálohovanie alebo obnovu vzniká iba v rozsahu parametrov objednanej služby alebo individuálnej dohody.
34. Ak WebHouse napriek tomu v konkrétnom prípade použije internú technickú kópiu na pomoc Zákazníkovi, ide o pomoc nad rámec štandardného rozsahu služby, pokiaľ zo zmluvných podmienok nevyplýva inak.
35. Takýto jednorazový postup nevytvára povinnosť WebHouse poskytnúť rovnakú možnosť pri inom incidente alebo inému Zákazníkovi.
36. Rozsah zálohovania môže závisieť aj od kapacitných alebo technických limitov služby.
37. Ak Zákazník prekročí stanovený limit alebo používa službu spôsobom, ktorý znemožňuje alebo neprimerane komplikuje štandardné zálohovanie, WebHouse môže požadovať:

• zníženie objemu dát,
• zmenu spôsobu používania služby,
• prechod na vhodnejší program,
• objednanie individuálneho zálohovacieho riešenia.

38. Ak zálohovanie konkrétnej služby podlieha kapacitnému limitu, rozhodujúci je limit uvedený v parametroch služby.
39. Zálohovanie sa nemusí vykonať v plnom rozsahu, ak technický stav dát objektívne neumožňuje ich štandardné spracovanie, napríklad pri:

• poškodenom súborovom systéme,
• chybe úložiska,
• nekonzistentnom obraze virtuálneho disku,
• technicky nečitateľných dátach.

40. Takýto stav sa posudzuje podľa príčiny a rozsahu povinností WebHouse pri konkrétnej službe.
41. Zálohovanie dát neznamená automaticky zálohovanie všetkých údajov potrebných na kompletné obnovenie funkčnosti služby.
42. Napríklad obnova webovej aplikácie môže okrem zálohovaných súborov vyžadovať aj:

• správnu databázu,
• DNS konfiguráciu,
• externé API,
• licencie,
• certifikáty,
• konfiguračné údaje,
• služby tretích strán.

43. Ak niektorý z týchto prvkov nie je súčasťou zálohovania WebHouse, jeho absencia neznamená neúplnosť zálohy, pokiaľ záloha zodpovedá dohodnutému rozsahu služby.
44. Rozsah zálohovania sa môže v priebehu poskytovania služby meniť v dôsledku:

• zmeny technológie,
• migrácie služby,
• zmeny produktu,
• zmeny zálohovacieho systému,
• zmeny technických parametrov.

45. Podstatná zmena rozsahu zálohovania sa vykonáva v súlade so zmluvnými podmienkami a príslušnými právnymi predpismi.
46. Konkrétny a rozhodujúci rozsah zálohovania je uvedený najmä:

• v popise konkrétnej služby,
• v aktuálnom cenníku,
• v zákazníckom rozhraní,
• v technickej dokumentácii,
• v osobitných podmienkach služby,
• v objednávke,
• alebo v individuálnej zmluve.

47. Ak sa informácie uvedené v rôznych dokumentoch líšia, použije sa pre konkrétnu službu osobitnejšia úprava, najmä individuálna dohoda alebo technická špecifikácia konkrétneho produktu, pokiaľ tým nie sú dotknuté práva Zákazníka, ktoré nemožno zmluvne obmedziť.
48. Zákazník zodpovedá za posúdenie, či rozsah zálohovania zahrnutý v objednanej službe zodpovedá významu a charakteru jeho dát.
49. Ak je rozsah štandardného zálohovania pre potreby Zákazníka nedostatočný, Zákazník je povinný zabezpečiť ďalšiu nezávislú zálohu alebo si objednať vhodnejšiu zálohovaciu službu.
50. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie zodpovednosti WebHouse za nesplnenie rozsahu zálohovania, ktorý bol pri konkrétnej službe výslovne dohodnutý.

Článok 5

Dáta, ktoré nemusia byť zálohované

1. Ak pri konkrétnej službe, jej technickej špecifikácii, cenníku, zákazníckom rozhraní alebo individuálnej dohode nie je výslovne uvedené inak, zálohovanie sa nemusí vzťahovať na všetky dáta, ktoré sa technicky nachádzajú v rámci služby alebo infraštruktúry používanej Zákazníkom.
2. Zo zálohovania môžu byť podľa charakteru konkrétnej služby vylúčené najmä dáta, ktorých uchovávanie v zálohách nie je potrebné na štandardnú obnovu zákazníckych dát, ktoré sú dočasné, automaticky obnoviteľné, uložené mimo určeného zálohovaného priestoru alebo ktorých zálohovanie nie je technicky alebo bezpečnostne vhodné.
3. Ak nie je pri konkrétnej službe uvedené inak, zálohovanie nemusí zahŕňať najmä:
   • dočasné súbory,
   • cache a vyrovnávacie pamäte,
   • session dáta,
   • systémové dočasné adresáre,
   • dočasné pracovné adresáre,
   • dočasné exporty a importné súbory,
   • dočasné inštalačné súbory,
   • lock súbory,
   • PID súbory,
   • sockety,
   • swap súbory alebo swap priestory,
   • pamäťové obrazy a runtime dáta,
   • súbory, ktoré systém alebo aplikácia vytvára automaticky a ktoré možno štandardne znovu vytvoriť,
   • cache databáz alebo aplikácií,
   • technické logy, ak nie sú výslovne súčasťou zálohy,
   • debug logy,
   • dočasné bezpečnostné alebo prevádzkové logy,
   • dáta v adresároch alebo úložiskách výslovne vylúčených zo zálohovania.
4. Zo zálohovania môžu byť vylúčené aj dáta, ktoré sú uložené mimo štandardného alebo určeného dátového priestoru konkrétnej služby.
5. Za dáta uložené mimo zálohovaného priestoru sa môžu považovať najmä dáta:
   • na externom úložisku,
   • na pripojenom sieťovom úložisku,
   • na externom disku,
   • v objektovom úložisku tretej strany,
   • v inom cloudovom úložisku,
   • na inom serveri,
   • v inom zákazníckom účte,
   • v inom dátovom centre,
   • alebo na inom technickom systéme, ktorý nie je súčasťou zálohovanej služby.
6. Zálohovanie jednej služby automaticky nezahŕňa dáta inej služby, aj keď sú tieto služby technicky alebo aplikačne prepojené.

7. Ak napríklad webová aplikácia používa:

   • externú databázu,
   • externé objektové úložisko,
   • externé API,
   • externý mailový systém,
   • externý cloud,
   • externú CDN,

   záloha webhostingového účtu automaticky nezahŕňa dáta uložené v týchto externých systémoch.

8. Poskytovateľ nezodpovedá za zálohovanie dát nachádzajúcich sa v službách tretích strán, ktoré nespravuje.
9. Zálohovanie e-mailovej služby sa môže vzťahovať iba na dáta, ktoré sa v okamihu vytvorenia zálohy nachádzajú na serveroch WebHouse.
10. Zálohovanie nemusí zahŕňať najmä:

• správy stiahnuté zo servera a uložené iba lokálne,
• lokálne PST, OST, MBOX alebo iné archívne súbory,
• lokálne kontakty,
• lokálne kalendáre,
• dáta uložené iba v e-mailovom klientovi,
• dáta uložené na mobilnom telefóne, počítači alebo inom zariadení Zákazníka.

11. Ak Zákazník používa POP3 alebo inú konfiguráciu, ktorá po stiahnutí správ odstraňuje správy zo servera, správy odstránené pred vytvorením príslušnej zálohy nemusia byť v zálohe dostupné.
12. Zálohovanie databáz nemusí zahŕňať:

• externé databázy,
• databázy prevádzkované mimo infraštruktúry WebHouse,
• databázy, ku ktorým zálohovací systém nemá technický prístup,
• databázy alebo ich časti výslovne vylúčené z rozsahu služby.

13. Záloha databázy nemusí zahŕňať všetky súvisiace dáta aplikácie, ak sú uložené mimo databázy.
14. Rovnako záloha súborov automaticky nemusí obsahovať databázu, ak je databáza zálohovaná samostatným mechanizmom alebo nie je súčasťou objednaného zálohovania.
15. Pri virtuálnych alebo dedikovaných serveroch môže byť zo zálohovania podľa technológie vylúčené najmä:

• pripojené externé úložisko,
• ďalší disk nezaradený do zálohovacej politiky,
• ISO obrazy,
• swap,
• dočasné disky,
• dátové priestory označené ako nezálohované,
• zariadenia alebo filesystemy, ktoré zálohovací systém nepodporuje.

16. Snapshot alebo záloha virtuálneho servera nemusí zahŕňať externé služby, ktoré server používa.
17. Zo zálohovania môžu byť vylúčené dáta, ktoré Zákazník sám označí alebo nakonfiguruje ako nezálohované, ak služba takúto možnosť poskytuje.
18. Zákazník zodpovedá za následky nastavenia, ktorým:

• vylúči určitý adresár,
• vypne zálohovanie,
• zmení zálohovaciu politiku,
• odstráni existujúcu manuálnu zálohu,
• zmení cieľ zálohovania,

pokiaľ je takáto konfigurácia v jeho správe.

19. Zo zálohovania nemusia byť zahrnuté dáta, ktoré boli z produkčného prostredia odstránené pred vytvorením príslušného bodu obnovy.
20. Zálohovací systém nevytvára spätne kópiu dát, ktoré v čase vytvorenia zálohy už neexistovali.
21. Ak boli napríklad dáta odstránené v pondelok a najstarší dostupný bod obnovy pochádza z utorka, v dostupných zálohách sa už nemusia nachádzať.
22. Zálohy vytvorené pred odstránením dát môžu príslušné dáta obsahovať len dovtedy, kým zostávajú súčasťou retenčného cyklu.
23. Zálohovanie nemusí zahŕňať dáta, ktoré vznikajú iba krátkodobo medzi jednotlivými bodmi obnovy a pred vytvorením ďalšej zálohy boli opätovne odstránené.
24. Samotná existencia dát v určitom okamihu počas dňa preto neznamená, že sa tieto dáta museli dostať do zálohy.
25. Zo zálohovania môžu byť vylúčené aj nadmerne veľké alebo technicky nevhodné súbory, ak tak stanovujú parametre konkrétnej služby.
26. Môže ísť napríklad o:

• veľmi veľké dočasné archívy,
• diskové obrazy,
• duplicity záloh vytvorených Zákazníkom,
• veľké cache súbory,
• súbory presahujúce technický limit zálohovacieho systému.

27. Konkrétne kapacitné alebo veľkostné limity sa riadia parametrami príslušnej služby.
28. Zákazník by nemal ukladať vlastné zálohy do priestoru, ktorý je následne opätovne zálohovaný WebHouse, ak takýto spôsob používania vedie k zbytočnému reťazeniu alebo násobeniu záloh.
29. WebHouse môže z automatického zálohovania vylúčiť adresáre alebo súbory obsahujúce ďalšie zálohy, snapshoty alebo exporty, ak je to potrebné na zabránenie neprimeranému rastu objemu záloh.
30. Takéto obmedzenie sa použije iba v rozsahu zodpovedajúcom technickým podmienkam konkrétnej služby.
31. Zálohovanie nemusí zahŕňať technické údaje, ktorých rekonštrukcia je jednoduchšia alebo vhodnejšia než ich obnova zo zálohy.
32. Môže ísť napríklad o:

• cache,
• indexy, ktoré možno znovu vytvoriť,
• generované náhľady,
• kompilované súbory,
• dočasné pracovné dáta.

33. Poskytovateľ môže zo zálohovania vylúčiť dáta, ktorých zálohovanie by mohlo:

• ohroziť bezpečnosť zálohovacieho systému,
• neprimerane zaťažiť infraštruktúru,
• narušiť zálohovanie ostatných zákazníkov,
• byť technicky nekompatibilné s použitým zálohovacím mechanizmom.

34. Takéto vylúčenie však nesmie byť použité spôsobom, ktorý by bez zodpovedajúcej zmeny podmienok fakticky poprel výslovne dohodnutý rozsah zálohovacej služby.
35. Ak určitý typ dát predstavuje neprimerané bezpečnostné alebo technické riziko, WebHouse môže namiesto jeho zálohovania:

• upozorniť Zákazníka,
• odporučiť zmenu spôsobu ukladania dát,
• odporučiť inú službu,
• navrhnúť individuálne zálohovacie riešenie.

36. Zálohovací systém nemusí ukladať súbory, ktoré sú v čase zálohovania:

• technicky nedostupné,
• nečitateľné,
• poškodené na úrovni súborového systému,
• zablokované spôsobom znemožňujúcim ich štandardné spracovanie,

ak použitá technológia neumožňuje ich bezpečné zálohovanie.

37. Ak zálohovací proces určitú položku nedokáže spracovať, nemusí byť táto položka súčasťou vytvoreného bodu obnovy.
38. To neznamená, že WebHouse môže bez obmedzenia ignorovať chyby zálohovania; opakované alebo systémové problémy sa posudzujú podľa dohodnutých parametrov služby a okolností konkrétneho prípadu.
39. Zálohovanie sa môže vykonávať na úrovni celej technickej jednotky a nemusí umožňovať individuálne rozlišovať význam jednotlivých súborov.
40. Poskytovateľ preto nie je povinný pri vytváraní zálohy posudzovať:

• obchodnú hodnotu jednotlivého súboru,
• jeho právny význam,
• jeho nenahraditeľnosť,
• ani to, či ide pre Zákazníka o kritické dáta.

41. Zákazník zodpovedá za identifikáciu dát, ktoré sú pre neho kritické alebo nenahraditeľné, a za zabezpečenie primeranej nezávislej ochrany takýchto dát.
42. Ak má Zákazník pochybnosť, či konkrétny typ dát, adresár, databáza, schránka alebo úložisko patrí do zálohovaného rozsahu, je oprávnený požiadať WebHouse o vysvetlenie technických parametrov služby.
43. Samotná skutočnosť, že WebHouse v konkrétnom prípade technicky dokáže obnoviť dáta, ktoré štandardne nie sú súčasťou garantovaného rozsahu zálohovania, neznamená vznik nároku na ich obnovu.
44. Ak Poskytovateľ takúto obnovu napriek tomu vykoná, môže ísť o individuálnu pomoc nad rámec štandardných parametrov služby.
45. Jednorazové poskytnutie takejto pomoci nevytvára povinnosť WebHouse zachovávať alebo obnovovať rovnaký typ dát v budúcnosti.
46. Rozhodujúce pre určenie toho, či konkrétne dáta mali byť zálohované, sú parametre objednanej služby platné pre príslušné obdobie.
47. Ak je v technických parametroch služby výslovne uvedené, že určitý typ dát je zálohovaný, WebHouse ho nemôže považovať za vylúčený iba na základe všeobecnej formulácie tohto článku.
48. Tým nie je dotknutá možnosť technickej chyby alebo inej udalosti, ktorá sa posudzuje podľa príčiny, rozsahu dohodnutej služby a ostatných ustanovení týchto Pravidiel.
49. Zákazník je povinný pri kritických alebo nenahraditeľných dátach používať vlastnú nezávislú zálohu aj v prípade, ak sú tieto dáta zahrnuté do štandardného zálohovania WebHouse.
50. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne zúžiť rozsah zálohovania, ktorý bol pri konkrétnej službe výslovne dohodnutý.

Článok 6

Frekvencia zálohovania

1. Frekvencia vytvárania záloh závisí od druhu, variantu a technických parametrov konkrétnej objednanej služby.
2. Konkrétna frekvencia zálohovania môže byť uvedená najmä:
   • v popise služby,
   • v technickej špecifikácii,
   • v cenníku,
   • v zákazníckom rozhraní,
   • v osobitných podmienkach služby,
   • v individuálnej zmluve alebo objednávke.
3. Jednotlivé služby alebo jednotlivé časti tej istej služby môžu mať rozdielnu frekvenciu zálohovania.
4. Napríklad:
   • webové súbory môžu byť zálohované v inom intervale ako databázy,
   • databázy môžu byť zálohované častejšie ako ostatné dáta,
   • e-mailové dáta môžu používať samostatný zálohovací systém,
   • virtuálne servery môžu byť zálohované iným mechanizmom ako zdieľaný webhosting.
5. Zálohy môžu byť podľa typu služby vytvárané najmä:
   • priebežne alebo takmer priebežne,
   • viackrát denne,
   • raz denne,
   • niekoľkokrát týždenne,
   • raz týždenne,
   • v inom pravidelnom intervale,
   • alebo na základe konkrétnej udalosti alebo požiadavky.
6. Ak je pri službe uvedené napríklad „denné zálohovanie“, znamená to, že zálohovací systém je štandardne nastavený tak, aby vytváral zálohu približne raz za príslušný zálohovací cyklus.
7. Označenie „denné“, „hodinové“, „týždenné“ alebo obdobné označenie frekvencie samo osebe neznamená, že záloha musí byť vytvorená vždy v presne rovnakom čase.
8. Ak pri konkrétnej službe nie je výslovne uvedený presný čas vytvorenia zálohy, WebHouse nie je viazaný konkrétnou hodinou alebo minútou jej vytvorenia.
9. Zálohovací proces môže byť spustený podľa interného harmonogramu Poskytovateľa s prihliadnutím najmä na:
   • kapacitu zálohovacej infraštruktúry,
   • zaťaženie produkčných systémov,
   • objem zálohovaných dát,
   • technické závislosti,
   • optimalizáciu prevádzky.
10. Čas začatia alebo dokončenia konkrétnej zálohovacej úlohy sa preto môže medzi jednotlivými dňami alebo cyklami odlišovať.
11. Ak je pri službe uvedený interval zálohovania, ide o štandardnú alebo cieľovú frekvenciu zálohovacieho procesu, pokiaľ pri konkrétnej službe nie je výslovne uvedené, že ide o garantovaný parameter.
12. Cieľová frekvencia znamená, že WebHouse nastavuje a prevádzkuje zálohovací systém tak, aby zálohy štandardne vznikali v uvedenom intervale.
13. Cieľová frekvencia však nepredstavuje absolútnu garanciu, že každý jednotlivý plánovaný zálohovací cyklus bude za všetkých okolností:

• spustený,
• dokončený,
• úspešný,
• alebo použiteľný na obnovu.

14. V jednotlivom zálohovacom cykle môže dôjsť k oneskoreniu, prerušeniu alebo nevytvoreniu zálohy najmä v dôsledku:

• zvýšeného zaťaženia zálohovacieho systému,
• zvýšeného zaťaženia produkčnej infraštruktúry,
• mimoriadne veľkého objemu dát,
• neobvykle veľkého objemu zmien,
• údržby zálohovacej infraštruktúry,
• údržby produkčného systému,
• technickej poruchy,
• chyby úložiska,
• sieťového problému,
• nedostupnosti zdrojového systému,
• bezpečnostného incidentu,
• bezpečnostného zásahu,
• potreby chrániť integritu dát,
• inej technickej okolnosti.

15. Krátkodobé odchýlenie od štandardného času alebo intervalu zálohovania samo osebe nemusí znamenať poruchu zálohovacej služby.
16. Pri posúdení riadneho poskytovania zálohovacej služby sa prihliada najmä na:

• dohodnutú frekvenciu,
• charakter služby,
• skutočný priebeh zálohovania,
• dostupné body obnovy,
• príčinu prípadného nevytvorenia zálohy,
• trvanie a opakovanie problému.

17. Jednorazové nevytvorenie plánovaného bodu obnovy sa posudzuje odlišne od dlhodobého alebo systematického neplnenia deklarovanej frekvencie zálohovania.
18. Opakovaný alebo dlhodobý stav, pri ktorom zálohy nevznikajú v rozsahu zodpovedajúcom dohodnutým parametrom služby, môže predstavovať poruchu alebo vadu zálohovacej služby podľa okolností konkrétneho prípadu.
19. Týmto ustanovením nie je dotknutá zodpovednosť WebHouse za výslovne dohodnuté garantované parametre služby.
20. Ak sa plánovaná záloha nevytvorí, zálohovací systém môže podľa použitej technológie:

• vykonať nový pokus automaticky,
• pokračovať v prerušenej úlohe,
• vytvoriť zálohu v neskoršom čase,
• alebo pokračovať ďalším plánovaným zálohovacím cyklom.

21. Náhradný zálohovací cyklus nemusí byť dostupný pri každom type služby.
22. WebHouse nie je povinný manuálne spúšťať náhradnú zálohu po každom jednotlivom neúspešnom automatickom pokuse, ak je funkčnosť systému primerane zabezpečená iným spôsobom.
23. Ak technická chyba spôsobí, že sa zálohovanie nemôže vykonať, WebHouse môže najskôr odstrániť príčinu problému a následne obnoviť štandardný zálohovací cyklus.
24. Zálohovanie môže byť dočasne pozastavené aj vtedy, ak by jeho pokračovanie mohlo:

• poškodiť produkčné dáta,
• poškodiť existujúce zálohy,
• zhoršiť bezpečnostný incident,
• neprimerane ohroziť stabilitu infraštruktúry.

25. Pri takomto postupe má ochrana integrity dát a infraštruktúry prednosť pred mechanickým dodržaním bežného harmonogramu zálohovania.
26. Ak je zálohovanie vytvárané priebežne alebo s vysokou frekvenciou, nemusí to znamenať existenciu samostatného bodu obnovy pre každý okamih alebo každú jednotlivú zmenu dát.
27. Technológia môže zmeny:

• zoskupovať,
• agregovať,
• ukladať v určitých intervaloch,
• alebo ich následne konsolidovať v rámci retenčného cyklu.

28. Zákazník preto nemá nárok na obnovu k ľubovoľnej sekunde alebo minúte iba preto, že služba používa priebežný alebo veľmi častý spôsob zálohovania.
29. Počet dostupných bodov obnovy nemusí priamo zodpovedať počtu vykonaných zálohovacích operácií.
30. Zálohovací systém môže napríklad:

• uchovávať viac bodov z posledných dní,
• staršie body následne konsolidovať,
• časť starších bodov odstrániť podľa retenčnej politiky.

31. Konkrétnu dostupnosť historických bodov obnovy preto určuje kombinácia:

• frekvencie zálohovania,
• retenčnej politiky,
• spôsobu rotácie záloh,
• použitej technológie.

32. Frekvencia zálohovania a retenčná doba predstavujú rozdielne parametre.
33. Napríklad denná frekvencia zálohovania automaticky neznamená, že budú dostupné denné body obnovy za celé retenčné obdobie, ak konkrétny retenčný model používa neskoršiu konsolidáciu alebo rotáciu bodov.
34. Rozhodujúce sú konkrétne parametre objednanej služby.
35. Frekvencia zálohovania sama osebe nepredstavuje garantované RPO (Recovery Point Objective).
36. Ak napríklad služba používa denné zálohovanie, znamená to štandardnú frekvenciu vytvárania záloh, nie automaticky zmluvný záväzok, že pri každom incidente bude možné obnoviť dáta so stratou najviac 24 hodín.
37. Skutočný najnovší použiteľný bod obnovy môže byť starší najmä v prípade, ak:

• posledná záloha nebola úspešná,
• záloha bola poškodená,
• zdrojové dáta boli v čase vytvárania zálohy nedostupné,
• alebo nastala iná technická okolnosť.

38. Konkrétne maximálne RPO je garantované iba vtedy, ak je pri službe alebo individuálnej dohode výslovne uvedené ako garantovaný parameter.
39. Rovnaký princíp platí aj pri RTO; frekvencia zálohovania neurčuje dobu, za ktorú bude možné dáta obnoviť.
40. Zákazník, ktorý potrebuje konkrétne garantované RPO alebo RTO, je povinný zvoliť službu, pri ktorej sú tieto hodnoty výslovne dohodnuté.
41. Zákazník nesmie odkladať vlastnú zálohu kritických dát iba preto, že sa blíži plánovaný čas automatického zálohovania WebHouse.
42. Pred významným zásahom do služby, napríklad pred:

• rozsiahlym upgrade aplikácie,
• zmenou databázovej štruktúry,
• migráciou,
• hromadným importom,
• zásadnou zmenou konfigurácie,

sa odporúča vytvoriť samostatnú aktuálnu zálohu, ak to služba umožňuje.

43. Zákazník nesmie predpokladať, že bezprostredne pred jeho zásahom automaticky vznikla záloha WebHouse.
44. Ak Zákazník potrebuje bod obnovy presne pred vykonaním vlastného rizikového zásahu, mal by použiť dostupnú funkciu manuálnej zálohy, snapshotu alebo vlastnej nezávislej zálohy.
45. Frekvencia automatického zálohovania sa môže pri jednotlivých technických platformách meniť v dôsledku migrácie alebo modernizácie služby.
46. WebHouse môže meniť konkrétny čas spúšťania zálohovacích úloh bez oznámenia Zákazníkovi, ak:

• zostáva zachovaná dohodnutá frekvencia alebo obdobný rozsah ochrany,
• zmena nemá podstatný negatívny vplyv na parametre objednanej služby.

47. WebHouse môže meniť aj technický spôsob dosiahnutia deklarovanej frekvencie, napríklad prechodom:

• z plných záloh na kombináciu plných a inkrementálnych záloh,
• na snapshotovú technológiu,
• na kontinuálnu ochranu dát,
• na inú porovnateľnú zálohovaciu technológiu.

48. Zákazník nemá nárok na používanie konkrétneho technického mechanizmu, ak zostávajú zachované zmluvne dohodnuté parametre služby.
49. Ak WebHouse plánuje podstatne znížiť deklarovanú frekvenciu zálohovania konkrétnej služby, postupuje podľa pravidiel pre zmenu podmienok alebo parametrov služby.
50. Skutočnosť, že WebHouse v konkrétnom prípade vytvorí zálohu častejšie, než stanovuje štandardný parameter služby, neznamená trvalé zvýšenie garantovanej frekvencie.
51. Rovnako existencia dodatočných technických bodov obnovy nevytvára nárok na ich zachovanie do budúcnosti, pokiaľ nie sú súčasťou dohodnutých parametrov služby.
52. Pri individuálnych zálohovacích riešeniach môže byť dohodnutá presnejšia frekvencia alebo osobitný harmonogram.
53. Individuálne dohodnutý garantovaný parameter má v rozsahu konkrétnej dohody prednosť pred všeobecnými ustanoveniami tohto článku.
54. Zákazník zodpovedá za posúdenie, či frekvencia zálohovania konkrétnej služby zodpovedá prípustnej strate dát pri jeho spôsobe používania služby.
55. Ak je napríklad pre Zákazníka neprijateľná strata niekoľkých hodín nových dát, nemal by používať službu s denným zálohovaním ako jediný mechanizmus ochrany týchto dát.
56. Pri dátach s vysokou frekvenciou zmien môže byť vhodné použiť:

• častejšie zálohovanie,
• databázovú replikáciu,
• transakčné logy,
• kontinuálnu ochranu dát,
• vlastné aplikačné zálohy,
• alebo iné primerané riešenie.

57. Zodpovednosť za výber frekvencie zodpovedajúcej potrebám Zákazníka nesie Zákazník, pokiaľ WebHouse neposkytol konkrétnu individuálnu garanciu vhodnosti služby na určený účel.
58. Rozhodujúca frekvencia zálohovania je vždy tá, ktorá je uvedená pri konkrétnej objednanej službe.
59. Všeobecné príklady frekvencií uvedené v týchto Pravidlách nepredstavujú prísľub, že každý typ služby používa všetky alebo niektorú konkrétnu z uvedených frekvencií.
60. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse dlhodobo alebo systematicky nedodržiavať frekvenciu zálohovania, ktorá bola pri konkrétnej službe výslovne dohodnutá.

Článok 7

Retenčná doba

1. Zálohy a body obnovy sa uchovávajú počas retenčnej doby alebo podľa retenčného modelu stanoveného pre konkrétnu objednanú službu.
2. Konkrétna retenčná doba môže byť uvedená najmä:
   • v popise služby,
   • v technickej špecifikácii,
   • v cenníku,
   • v zákazníckom rozhraní,
   • v osobitných podmienkach služby,
   • v individuálnej zmluve alebo objednávke.
3. Retenčná doba môže byť vyjadrená najmä:
   • počtom kalendárnych dní,
   • počtom hodín,
   • počtom dostupných bodov obnovy,
   • počtom generácií záloh,
   • kombináciou uvedených parametrov,
   • alebo iným technicky primeraným spôsobom.
4. Retenčná doba určuje štandardný časový alebo generačný rozsah, počas ktorého môžu byť jednotlivé zálohy uchovávané v zálohovacom systéme.
5. Retenčná doba sama osebe neznamená, že pre každý deň, hodinu alebo iný časový úsek retenčného obdobia musí existovať samostatný bod obnovy.
6. Počet a časové rozloženie dostupných bodov obnovy závisí najmä od:
   • frekvencie zálohovania,
   • použitej zálohovacej technológie,
   • spôsobu rotácie záloh,
   • konsolidácie starších záloh,
   • úspešnosti jednotlivých zálohovacích cyklov,
   • technického stavu konkrétnych záloh.
7. Ak je napríklad pri službe uvedená retenčná doba 14 dní, neznamená to automaticky existenciu presne 14 samostatných denných bodov obnovy, pokiaľ parametre služby výslovne neustanovujú inak.
8. Retenčný model môže byť nastavený napríklad tak, že:
   • novšie zálohy sú uchovávané vo vyššej frekvencii,
   • staršie zálohy sú postupne konsolidované,
   • staršie body obnovy sú uchovávané vo väčších časových rozostupoch,
   • najstaršie body obnovy sú priebežne odstraňované.
9. Po uplynutí príslušnej retenčnej doby alebo po prekročení stanoveného počtu generácií môže byť staršia záloha automaticky:
   • odstránená,
   • prepísaná,
   • nahradená novšou zálohou,
   • konsolidovaná,
   • vyradená z dostupných bodov obnovy.
10. Takýto proces je štandardnou súčasťou fungovania zálohovacieho systému a nevyžaduje osobitný pokyn Zákazníka.
11. WebHouse nie je povinný pred odstránením jednotlivého bodu obnovy v rámci riadneho retenčného cyklu Zákazníka osobitne upozorňovať.
12. Zákazník je povinný vychádzať z retenčnej doby uvedenej pri konkrétnej službe a nesmie predpokladať, že staršie zálohy budú uchovávané dlhšie.
13. Po uplynutí retenčnej doby WebHouse nemá povinnosť príslušnú zálohu ďalej uchovávať.
14. Zákazník nemá nárok na obnovu dát z obdobia, pre ktoré už podľa štandardného retenčného cyklu neexistuje dostupný bod obnovy.
15. WebHouse nie je povinný spätne vytvoriť alebo rekonštruovať zálohu, ktorá:

• nebola vytvorená,
• bola riadne odstránená v rámci retenčného cyklu,
• bola prepísaná,
• bola konsolidovaná spôsobom, ktorý už neumožňuje požadovanú obnovu,
• alebo sa stala technicky nepoužiteľnou.

16. Zákazník, ktorý potrebuje uchovať konkrétny historický stav dát dlhšie než štandardnú retenčnú dobu služby, je povinný:

• vytvoriť si vlastnú samostatnú zálohu,
• exportovať príslušné dáta,
• alebo si objednať vhodnú službu s dlhšou retenciou.

17. Retenčná doba zálohovacej služby nepredstavuje službu archivácie.
18. Zálohovací systém nie je bez výslovnej dohody určený na:

• trvalé uchovávanie historických verzií dát,
• právnu archiváciu,
• účtovnú archiváciu,
• elektronickú registratúru,
• uchovávanie dát po zákonom požadovanú dobu v mene Zákazníka.

19. Zákazník zodpovedá za určenie toho, ako dlho musí svoje dáta uchovávať z právnych, účtovných, regulačných, obchodných alebo interných dôvodov.
20. Ak zákonná alebo interná povinnosť Zákazníka vyžaduje dlhšiu dobu uchovávania, než poskytuje štandardná retenčná doba WebHouse, Zákazník je povinný zabezpečiť si vhodné archivačné alebo zálohovacie riešenie.
21. Retenčná doba sa môže líšiť medzi jednotlivými časťami tej istej služby.
22. Napríklad:

• súbory môžu mať inú retenciu ako databázy,
• databázy môžu mať inú retenciu ako e-mailové dáta,
• snapshoty virtuálnych serverov môžu mať inú retenciu ako samostatné zálohy,
• manuálne vytvorené zálohy môžu mať inú retenciu ako automatické zálohy.

23. Retenčná doba môže byť rozdielna aj pre:

• automatické zálohy,
• manuálne zálohy,
• snapshoty,
• dočasné obnovovacie kópie,
• migračné kópie.

24. Konkrétna retencia každého typu zálohy sa riadi parametrami danej služby.
25. Manuálne vytvorená záloha nemusí byť uchovávaná neobmedzene.
26. Ak služba umožňuje manuálne zálohy, WebHouse môže stanoviť:

• maximálny počet takýchto záloh,
• maximálnu dobu ich uchovávania,
• maximálnu kapacitu,
• pravidlá automatického odstránenia.

27. Zákazník je povinný stiahnuť alebo exportovať manuálnu zálohu, ak ju potrebuje uchovať dlhšie, než umožňuje služba.
28. Snapshoty môžu mať výrazne kratšiu retenčnú dobu než plnohodnotné zálohy.
29. Snapshot nemožno bez výslovného uvedenia považovať za dlhodobú zálohu.
30. Retenčná doba sa môže počítať od:

• času vytvorenia zálohy,
• času jej úspešného dokončenia,
• vytvorenia novšej generácie,
• alebo iného technického momentu podľa použitej technológie.

31. WebHouse nie je povinný garantovať presnú sekundu alebo minútu odstránenia zálohy po uplynutí retencie.
32. Technicky môže nastať stav, keď záloha zostane fyzicky uložená v systéme určitý čas aj po uplynutí deklarovanej retenčnej doby.
33. Takáto technická existencia starej zálohy po uplynutí retencie:

• neznamená predĺženie retenčnej doby,
• nevytvára nárok Zákazníka na jej zachovanie,
• nevytvára nárok na jej obnovu,
• neznamená záväzok WebHouse uchovávať rovnako staré zálohy aj v budúcnosti.

34. Ak je takáto technická kópia ešte použiteľná a WebHouse sa rozhodne Zákazníkovi z nej pomôcť s obnovou, môže ísť o pomoc nad rámec štandardných parametrov služby.
35. Takáto pomoc nevytvára precedens ani nárok na obdobnú obnovu v budúcnosti.
36. Rovnako môže dôjsť k tomu, že staršia záloha bude technicky odstránená krátko pred uplynutím nominálnej kalendárnej hranice, ak je retenčný model definovaný počtom generácií a nie presným počtom hodín alebo dní.
37. Rozhodujúci je preto spôsob, akým je retencia pri konkrétnej službe definovaná.
38. Retenčná doba predstavuje štandardný rozsah uchovávania, nie absolútnu garanciu existencie každého jednotlivého bodu obnovy počas celého obdobia.
39. Konkrétny bod obnovy môže byť nedostupný napríklad z dôvodu:

• nevytvorenia príslušnej zálohy,
• technického poškodenia zálohy,
• chyby zálohovacieho procesu,
• poškodenia dát,
• bezpečnostného incidentu,
• inej technickej udalosti.

40. Jednorazová nedostupnosť konkrétneho bodu obnovy sa posudzuje odlišne od dlhodobého alebo systematického nedodržiavania deklarovanej retenčnej politiky.
41. Ak WebHouse dlhodobo alebo systematicky neposkytuje retenčný rozsah, ktorý bol pri konkrétnej službe výslovne dohodnutý, takýto stav sa posudzuje podľa okolností ako možné nesplnenie parametrov služby.
42. Týmto článkom nie je dotknutá zodpovednosť WebHouse za výslovne garantované parametre zálohovacej služby.
43. Pri zmene alebo migrácii služby môže dôjsť aj k zmene retenčného modelu.
44. Staré body obnovy z predchádzajúcej technickej platformy nemusia byť prenositeľné do nového systému.
45. Pred významnou migráciou alebo zmenou služby môže WebHouse odporučiť Zákazníkovi vytvorenie vlastnej zálohy.
46. Ak Zákazník zmení produkt na službu s kratšou retenčnou dobou, staršie zálohy nemusia zostať dostupné podľa pôvodných podmienok, ak nie je dohodnuté inak.
47. Podstatná zmena retenčnej doby služby zo strany WebHouse sa vykonáva podľa pravidiel zmeny parametrov služby, Všeobecných obchodných podmienok a príslušných právnych predpisov.
48. Skutočnosť, že WebHouse pri určitej službe fakticky uchováva zálohy dlhšie, než je deklarovaná minimálna alebo štandardná retenčná doba, neznamená automatickú zmenu zmluvných parametrov služby.
49. Zákazník sa nemôže spoliehať na historicky dlhšiu faktickú retenciu, ak nebola súčasťou zmluvne dohodnutých parametrov.
50. Pri bezpečnostnom incidente môže WebHouse v odôvodnenom prípade určitý bod obnovy dočasne uchovať dlhšie než stanovuje štandardná retencia, napríklad na účely:

• ochrany dát,
• analýzy incidentu,
• obnovy služby,
• zachovania technických dôkazov,
• splnenia právnej povinnosti.

51. Takéto mimoriadne uchovanie neznamená všeobecné predĺženie retenčnej doby služby.
52. Ak právny predpis alebo vykonateľné rozhodnutie oprávneného orgánu vyžaduje uchovanie určitých dát alebo záloh, WebHouse môže príslušné dáta uchovať aj nad rámec štandardnej retenčnej doby v rozsahu tejto povinnosti.
53. Pri osobných údajoch sa nakladanie so zálohami po uplynutí potreby spracúvania riadi aj DPA, zásadami ochrany osobných údajov a príslušnými právnymi predpismi.
54. Vymazanie dát z produkčného systému nemusí viesť k okamžitému odstráneniu ich historických kópií zo záloh.
55. Takéto historické kópie môžu zostať v zálohovacom systéme až do uplynutia štandardného retenčného cyklu, pričom nie sú určené na bežné ďalšie používanie.
56. Zákazník nemá právo požadovať zachovanie konkrétneho bodu obnovy nad rámec jeho štandardnej retenčnej doby, pokiaľ:

• nebola dohodnutá osobitná archivácia,
• nebola vytvorená samostatná záloha určená na dlhšie uchovanie,
• alebo neexistuje iný zmluvný či zákonný dôvod.

57. Ak Zákazník predpokladá budúcu potrebu konkrétneho historického stavu dát, musí túto potrebu riešiť ešte počas obdobia, keď je príslušný bod obnovy dostupný.
58. WebHouse nie je povinný po uplynutí retenčnej doby zisťovať, či Zákazník mohol mať o staršiu zálohu budúci záujem.
59. Retenčná doba sama osebe neurčuje dobu obnovy dát.
60. Skutočnosť, že určitý bod obnovy je ešte v retenčnej lehote, neznamená, že jeho obnova musí byť vykonaná okamžite alebo v konkrétnej lehote, pokiaľ nie je výslovne dohodnuté RTO.
61. Zákazník zodpovedá za posúdenie, či retenčná doba konkrétnej služby zodpovedá jeho potrebám.
62. Ak napríklad Zákazník potrebuje možnosť obnoviť dáta šesť mesiacov spätne, nemal by sa spoliehať na službu s deklarovanou 14- alebo 30-dňovou retenciou.
63. Pri kritických dátach sa odporúča kombinovať štandardnú retenciu WebHouse s vlastnou nezávislou dlhodobou zálohou alebo archívom.
64. Individuálne zálohovacie služby môžu obsahovať:

• predĺženú retenciu,
• viac historických bodov obnovy,
• mesačné alebo ročné archívne body,
• nemenné zálohy,
• inú osobitne dohodnutú retenčnú politiku.

65. Individuálne dohodnutá retenčná politika má v rozsahu príslušnej dohody prednosť pred všeobecnými ustanoveniami tohto článku.
66. Rozhodujúca retenčná doba je vždy tá, ktorá je uvedená pri konkrétnej objednanej službe.
67. Všeobecné príklady retenčných modelov uvedené v týchto Pravidlách nepredstavujú prísľub konkrétnej retenčnej doby pre všetky služby WebHouse.
68. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne alebo systematicky nedodržiavať retenčnú dobu, ktorá bola pri konkrétnej službe výslovne dohodnutá.
69. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 8

Rotácia záloh

1. Zálohovací systém môže používať rotačný mechanizmus, ktorého účelom je priebežne spravovať počet, vek a objem uchovávaných záloh v súlade s retenčnou politikou konkrétnej služby.
2. Rotácia záloh môže zahŕňať najmä:
   • vytváranie nových bodov obnovy,
   • odstraňovanie najstarších bodov obnovy,
   • nahrádzanie starších záloh novšími,
   • konsolidáciu viacerých starších záloh,
   • znižovanie hustoty historických bodov obnovy,
   • prechod starších záloh do iného retenčného režimu.
3. Vytvorením novej zálohy preto môže dôjsť k automatickému:
   • odstráneniu najstaršej zálohy,
   • prepísaniu staršej generácie,
   • zlúčeniu starších bodov obnovy,
   • alebo inej zmene štruktúry dostupných záloh.
4. Takýto proces je štandardnou súčasťou technického fungovania zálohovacieho systému a nevyžaduje individuálny súhlas ani osobitné upozornenie Zákazníka pri každej jednotlivnej rotácii.
5. Rotácia sa môže riadiť najmä:
   • počtom uchovávaných generácií,
   • vekom záloh,
   • počtom bodov obnovy,
   • dostupnou kapacitou,
   • technickou architektúrou služby,
   • kombináciou uvedených kritérií.
6. Konkrétny rotačný model sa môže pri jednotlivých službách líšiť.
7. Niektoré služby môžu používať jednoduchú rotáciu, pri ktorej nová záloha nahrádza najstaršiu zálohu.
8. Iné služby môžu používať viacúrovňový retenčný model, pri ktorom sa napríklad:
   • najnovšie zálohy uchovávajú vo vyššej frekvencii,
   • staršie zálohy uchovávajú v menšej frekvencii,
   • časť historických bodov postupne konsoliduje alebo odstraňuje.
9. Počet dostupných bodov obnovy preto nemusí byť totožný s:
   • počtom dní retenčnej doby,
   • počtom vykonaných zálohovacích cyklov,
   • ani počtom kalendárnych dní od vzniku najstaršej zálohy.
10. Ak je napríklad služba zálohovaná denne a retenčná doba je 14 dní, nemusí to automaticky znamenať, že bude vždy dostupných presne 14 samostatných denných bodov obnovy, pokiaľ konkrétna služba výslovne nestanovuje inak.
11. Pri rotačnom modeli môže byť počet bodov obnovy nižší aj v dôsledku:

• nevytvorenia niektorej plánovanej zálohy,
• technickej chyby,
• poškodenia konkrétnej zálohy,
• konsolidácie starších záloh,
• manuálneho odstránenia bodu obnovy oprávnenou osobou,
• bezpečnostného zásahu,
• zmeny technickej platformy.

12. Rotácia záloh neznamená, že všetky historické body obnovy majú rovnakú úroveň detailu.
13. Pri niektorých technológiách môže byť napríklad možné obnoviť:

• viac bodov z posledných hodín alebo dní,
• menej bodov zo staršieho obdobia,
• iba vybrané konsolidované historické stavy.

14. Zákazník preto nemá automatický nárok na rovnomerné časové rozloženie bodov obnovy počas celej retenčnej doby.
15. Rozhodujúce sú parametre konkrétnej objednanej služby.
16. Rotácia záloh môže prebiehať automatizovane bez zásahu pracovníka WebHouse.
17. Automatizovaný systém môže staršiu zálohu odstrániť bez ďalšieho upozornenia Zákazníka, ak:

• uplynula jej retenčná doba,
• prekročila stanovený počet generácií,
• alebo je jej odstránenie súčasťou bežnej retenčnej politiky služby.

18. Zákazník je povinný včas exportovať alebo samostatne uchovať bod obnovy, ktorý potrebuje zachovať dlhšie, než umožňuje štandardná rotácia služby.
19. WebHouse nie je povinný automaticky identifikovať, že určitá konkrétna záloha má pre Zákazníka osobitnú historickú, právnu, účtovnú alebo inú hodnotu.
20. Ak Zákazník potrebuje konkrétny historický bod obnovy zachovať mimo štandardnej rotácie, musí:

• vytvoriť vlastnú kópiu,
• požiadať o samostatnú zálohu,
• alebo si objednať službu umožňujúcu dlhšie uchovanie,

ak je takáto možnosť dostupná.

21. Rotácia záloh môže byť ovplyvnená aj kapacitou zálohovacieho systému.
22. Kapacitné riadenie však nesmie byť použité spôsobom, ktorý by svojvoľne poprel výslovne dohodnutú retenčnú dobu alebo počet generácií záloh.
23. Ak dôjde k mimoriadnej technickej udalosti, môže byť rotačný proces dočasne:

• pozastavený,
• oneskorený,
• upravený,
• alebo vykonaný odlišným spôsobom,

ak je to potrebné na ochranu existujúcich záloh alebo integrity systému.

24. Takáto situácia môže nastať najmä pri:

• poruche zálohovacieho úložiska,
• poškodení produkčných dát,
• bezpečnostnom incidente,
• ransomvérovom útoku,
• mimoriadnej migrácii,
• výpadku infraštruktúry.

25. Pri bezpečnostnom incidente môže WebHouse dočasne uchovať určitý bod obnovy dlhšie, než by vyplývalo zo štandardnej rotácie, ak je to potrebné najmä na:

• obnovu služby,
• ochranu dát,
• analýzu incidentu,
• zachovanie technických dôkazov.

26. Takéto mimoriadne uchovanie neznamená všeobecnú zmenu retenčného alebo rotačného modelu služby.
27. Rovnako môže WebHouse v odôvodnenom prípade dočasne zabrániť vytvoreniu novej zálohy, ak by táto operácia spôsobila automatické odstránenie posledného známeho použiteľného bodu obnovy.
28. Takýto postup je prípustný najmä v prípade, ak existuje podozrenie, že aktuálne produkčné dáta sú:

• poškodené,
• kompromitované,
• zašifrované ransomvérom,
• alebo inak nevhodné na prepísanie staršieho použiteľného bodu obnovy.

29. WebHouse nie je povinný takýto ochranný zásah vykonať pri každom incidente; jeho možnosť závisí od:

• času zistenia incidentu,
• použitej technológie,
• technického stavu systému,
• dostupných možností zásahu.

30. Zákazník preto nesmie predpokladať, že rotácia bude automaticky zastavená vždy, keď dôjde k poškodeniu produkčných dát.
31. Ak sa poškodenie alebo kompromitácia zistí až po tom, čo rotačný mechanizmus odstránil staršie čisté body obnovy, nemusí už existovať vhodná záloha spred incidentu.
32. Z tohto dôvodu je dôležité bezpečnostný incident alebo podozrenie na poškodenie dát oznámiť WebHouse bez zbytočného odkladu.
33. Rotácia záloh môže viesť aj k situácii, keď sa poškodený alebo kompromitovaný stav dát postupne objaví vo viacerých novších bodoch obnovy.
34. Samotná existencia viacerých záloh preto neznamená, že aspoň jedna z nich musí obsahovať stav pred vznikom incidentu.
35. Čím neskôr je incident zistený, tým väčšie je riziko, že staršie použiteľné body obnovy už boli odstránené v rámci bežného rotačného cyklu.
36. Rotácia záloh a frekvencia zálohovania preto spolu určujú praktickú schopnosť vrátiť sa k určitému historickému stavu.
37. Zákazník, ktorý potrebuje možnosť návratu k výrazne starším historickým stavom, by mal používať:

• dlhšiu retenciu,
• archívne zálohy,
• nezávislé periodické zálohy,
• alebo iné vhodné riešenie.

38. Manuálna záloha vytvorená Zákazníkom nemusí byť automaticky vyňatá zo štandardnej rotácie.
39. Ak konkrétna služba neumožňuje manuálnu zálohu označiť ako trvalo uchovávanú, môže byť aj takáto záloha po uplynutí stanovenej doby automaticky odstránená.
40. Zákazník je povinný overiť retenčné pravidlá manuálnych záloh, ak ich potrebuje uchovávať dlhodobo.
41. Snapshoty môžu mať samostatný rotačný mechanizmus odlišný od plnohodnotných záloh.
42. Odstránenie snapshotu v rámci jeho štandardnej rotácie neznamená odstránenie plnohodnotnej zálohy, ak ide o oddelené systémy.
43. Rovnako existencia snapshotu nemusí znamenať existenciu samostatnej dlhodobej zálohy.
44. Pri technológiách používajúcich inkrementálne alebo diferenciálne zálohy môžu byť jednotlivé body obnovy technicky závislé od iných častí zálohovacieho reťazca.
45. Odstránenie alebo konsolidácia starších častí reťazca sa preto môže vykonávať špecifickým technickým spôsobom a nemusí zodpovedať jednoduchému modelu „jeden súbor = jeden deň“.
46. Zákazník nemá nárok na konkrétnu vnútornú technickú štruktúru zálohovacieho reťazca.
47. Rozhodujúca je schopnosť poskytovať body obnovy v rozsahu parametrov príslušnej služby.
48. WebHouse môže počas poskytovania služby zmeniť technický spôsob rotácie, napríklad prechodom:

• na inú zálohovaciu technológiu,
• z plných záloh na kombinované zálohy,
• na deduplikačný systém,
• na snapshotový alebo objektový model,

ak zostanú zachované zmluvne dohodnuté parametre služby alebo je ich zmena vykonaná v súlade so zmluvnými podmienkami.

49. Zákazník nemá nárok na zachovanie konkrétnej technológie rotácie alebo konkrétneho interného spôsobu ukladania záloh.
50. Ak WebHouse pri technickej zmene dočasne uchová väčší počet bodov obnovy, nevzniká tým Zákazníkovi trvalý nárok na takýto vyšší počet bodov.
51. Rovnako dočasne nižší počet bodov obnovy spôsobený jednorazovou technickou udalosťou sa posudzuje podľa okolností konkrétneho prípadu.
52. Jednorazová odchýlka sa posudzuje odlišne od dlhodobého alebo systematického nedodržiavania dohodnutého retenčného a rotačného modelu.
53. Ak WebHouse výslovne garantuje určitý minimálny počet bodov obnovy, tento počet musí byť posudzovaný podľa podmienok konkrétnej služby.
54. V takom prípade všeobecné ustanovenia tohto článku nemožno použiť na svojvoľné zníženie garantovaného počtu bodov.
55. Ak konkrétny počet bodov obnovy garantovaný nie je, rozhodujúca je deklarovaná retenčná politika a technický model služby.
56. Zákazník zodpovedá za posúdenie, či rotačný a retenčný model služby vyhovuje jeho potrebe návratu k historickým dátam.
57. Pri kritických alebo nenahraditeľných dátach by Zákazník nemal byť odkázaný výlučne na automatický rotačný mechanizmus jednej zálohovacej služby.
58. Odporúča sa kombinovať rotačné zálohy WebHouse s:

• nezávislou externou zálohou,
• dlhodobým archívom,
• alebo iným zálohovacím systémom primeraným významu dát.

59. Rotácia záloh nie je archiváciou a jej účelom nie je zachovať všetky historické verzie dát.
60. Skutočnosť, že určitý bod obnovy bol v súlade s retenčnou politikou automaticky odstránený, sama osebe nepredstavuje stratu dát spôsobenú poruchou zálohovacieho systému.
61. Rozhodujúce je, či bol rotačný proces vykonaný v súlade s parametrami objednanej služby.
62. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne alebo systematicky odstraňovať zálohy skôr, než umožňuje výslovne dohodnutá retenčná politika.
63. Tým nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 9

Záloha nie je archív

1. Zálohovacia služba slúži predovšetkým na technickú obnovu dát po ich strate, poškodení, vymazaní, kompromitácii alebo inom incidente.
2. Zálohovacia služba nie je určená na dlhodobú archiváciu dát, pokiaľ pri konkrétnej službe nie je výslovne uvedené inak.
3. Záloha a archív predstavujú rozdielne technické a prevádzkové mechanizmy s odlišným účelom.
4. Účelom zálohy je najmä umožniť návrat k dostupnému predchádzajúcemu stavu dát.
5. Účelom archívu je spravidla zabezpečiť dlhodobé, systematické alebo účelovo určené uchovávanie konkrétnych dát počas vopred určenej doby.
6. Zálohovací systém preto bez výslovnej dohody nemožno považovať za:
   • elektronický archív,
   • dokumentový archív,
   • účtovný archív,
   • daňový archív,
   • elektronickú registratúru,
   • dôkazný archív,
   • nemenné úložisko,
   • systém určený na plnenie zákonných archivačných povinností,
   • ani systém garantujúci dlhodobé zachovanie každej historickej verzie dát.
7. Dáta odstránené z produkčného prostredia môžu byť určitý čas obsiahnuté v starších zálohách, ak tieto zálohy ešte existujú v rámci retenčného cyklu.
8. Zákazník však nesmie predpokladať, že odstránené dáta zostanú v zálohovacom systéme trvalo alebo počas konkrétnej doby dlhšej než retenčná doba príslušnej služby.
9. Po uplynutí retenčnej doby môžu byť zálohy obsahujúce takéto dáta automaticky:
   • odstránené,
   • prepísané,
   • konsolidované,
   • alebo inak vyradené z dostupných bodov obnovy.
10. WebHouse nie je povinný pred odstránením konkrétnej historickej zálohy preverovať, či môže mať jej obsah pre Zákazníka:

• obchodnú hodnotu,
• účtovný význam,
• právny význam,
• dôkaznú hodnotu,
• historický význam,
• alebo inú osobitnú hodnotu.

11. Zákazník je preto povinný včas identifikovať dáta, ktoré potrebuje uchovávať dlhodobo.
12. Ak Zákazník potrebuje dáta uchovávať:

• z účtovných dôvodov,
• z daňových dôvodov,
• z právnych dôvodov,
• z regulačných dôvodov,
• na účely auditu,
• na účely registratúry,
• na účely dokazovania,
• na účely evidencie,
• z interných obchodných dôvodov,
• alebo z akéhokoľvek iného dôvodu vyžadujúceho dlhodobé uchovanie,

je povinný zabezpečiť vhodný archivačný alebo iný systém určený na tento účel.

13. WebHouse nezodpovedá za určenie doby, počas ktorej je Zákazník podľa právnych predpisov alebo vlastných interných pravidiel povinný uchovávať konkrétne dáta.
14. WebHouse rovnako nezodpovedá za posúdenie toho, či štandardná zálohovacia služba spĺňa osobitné:

• účtovné,
• daňové,
• právne,
• regulačné,
• odvetvové,
• alebo interné archivačné požiadavky Zákazníka.

15. Zákazník je povinný tieto požiadavky posúdiť samostatne a podľa potreby si zabezpečiť vhodné technické riešenie.
16. Štandardná záloha nemusí zabezpečovať:

• nemennosť obsahu,
• ochranu pred každou následnou zmenou,
• časové pečiatkovanie,
• kvalifikované elektronické podpisovanie,
• garantovanú integritu po právne určenej dobe,
• evidenciu všetkých zmien,
• uchovávanie všetkých historických verzií,
• okamžité vyhľadanie konkrétneho historického dokumentu,
• individuálne indexovanie obsahu,
• alebo inú funkcionalitu typickú pre archivačné systémy.

17. Skutočnosť, že sa určitý historický dokument alebo súbor nachádza v zálohe, sama osebe neznamená, že zálohovací systém garantuje:

• jeho autenticitu,
• jeho právnu účinnosť,
• jeho pôvod,
• čas jeho vzniku,
• alebo jeho dôkaznú hodnotu.

18. WebHouse nie je povinný viesť evidenciu všetkých historických verzií jednotlivého súboru alebo databázového záznamu.
19. Zálohovací systém môže podľa svojej technológie uchovávať iba vybrané stavy dát zachytené v jednotlivých bodoch obnovy.
20. Zmena dát medzi dvomi bodmi obnovy nemusí byť v zálohách samostatne zachytená.
21. Ak napríklad dokument:

• vznikne,
• následne sa zmení,
• a ešte pred ďalšou zálohou sa odstráni,

nemusí sa v zálohovacom systéme nachádzať žiadna jeho verzia.

22. Zálohovanie preto nemožno používať ako spoľahlivý systém na evidenciu všetkých historických zmien vykonaných v produkčných dátach.
23. Rovnako nemožno zálohovanie považovať za systém verzovania, pokiaľ konkrétna služba výslovne takúto funkciu neposkytuje.
24. Záloha nemusí umožňovať individuálne vyhľadať konkrétny historický údaj podľa:

• mena osoby,
• obsahu dokumentu,
• predmetu e-mailu,
• databázového poľa,
• alebo iného obsahového kritéria.

25. WebHouse môže byť schopný identifikovať zálohu podľa technických parametrov, napríklad:

• dátumu,
• času,
• služby,
• databázy,
• schránky,
• alebo inej technickej jednotky,

ale nie je povinný poskytovať obsahové archívne vyhľadávanie.

26. Zálohy môžu byť vytvárané alebo uchovávané v technickom formáte určenom predovšetkým na obnovu systému, nie na samostatné prezeranie alebo archiváciu jednotlivých dokumentov.
27. WebHouse preto nemusí byť schopný alebo povinný sprístupniť konkrétny bod obnovy vo forme:

• používateľsky čitateľného archívu,
• zoznamu všetkých súborov,
• samostatného exportu každej historickej verzie,
• alebo iného formátu požadovaného Zákazníkom.

28. Ak je potrebné obnoviť historické dáta výlučne na účely ich vyhľadania, môže byť potrebné vykonať technickú obnovu celého alebo čiastočného bodu obnovy.
29. Takýto zásah môže byť spoplatnený podľa podmienok konkrétnej služby a rozsahu technickej práce.
30. Zálohovacia retencia a zákonná doba uchovávania dát sú rozdielne pojmy.
31. Ak napríklad právny predpis vyžaduje, aby Zákazník uchovával určitý dokument niekoľko rokov, existencia zálohovacej služby s kratšou retenčnou dobou túto povinnosť Zákazníka nenahrádza.
32. Zákazník nesmie predpokladať, že WebHouse bude meniť retenčné pravidlá svojej zálohovacej služby podľa individuálnych zákonných archivačných povinností každého Zákazníka.
33. Ak Zákazník potrebuje dlhšiu dobu uchovávania, musí si:

• vytvoriť vlastný archív,
• exportovať príslušné dáta,
• objednať službu s dlhšou retenciou,
• alebo použiť osobitnú archivačnú službu.

34. Ak WebHouse ponúka osobitnú archivačnú službu, jej podmienky, retenčné lehoty, spôsob prístupu, nemennosť a ďalšie parametre sa riadia podmienkami tejto služby.
35. Samotné predĺženie retenčnej doby záloh ešte nemusí zo zálohovacej služby vytvoriť archivačnú službu.
36. Napríklad záloha uchovávaná jeden rok môže byť stále zálohou určenou na technickú obnovu a nemusí poskytovať vlastnosti potrebné pre právnu alebo dokumentovú archiváciu.
37. Rozhodujúci je účel, technické vlastnosti a výslovne dohodnuté parametre služby.
38. Zálohy môžu podliehať automatickej rotácii bez ohľadu na to, či Zákazník údaje obsiahnuté v zálohe považuje za historicky významné.
39. Zákazník, ktorý potrebuje určitý konkrétny stav dát zachovať dlhodobo, je povinný tento stav včas exportovať alebo vytvoriť samostatnú kópiu určenú na dlhodobé uchovanie.
40. WebHouse nie je povinný automaticky vytvárať samostatné archívne body:

• na konci mesiaca,
• na konci roka,
• pred zmenou aplikácie,
• pred migráciou,
• pred zrušením účtu,

pokiaľ takáto funkcionalita nie je súčasťou konkrétnej služby.

41. Ak Zákazník potrebuje uchovať stav dát pred významnou zmenou, odporúča sa vytvoriť alebo vyžiadať samostatnú zálohu ešte pred vykonaním takejto zmeny.
42. Ani manuálna záloha nemusí byť automaticky určená na dlhodobú archiváciu.
43. Manuálne zálohy môžu podliehať:

• časovej retencii,
• kapacitným limitom,
• automatickému odstráneniu,
• alebo iným pravidlám konkrétnej služby.

44. Zákazník je povinný samostatnú zálohu stiahnuť alebo exportovať, ak ju potrebuje zachovať mimo štandardnej retenčnej politiky WebHouse.
45. Existencia historickej technickej zálohy po uplynutí deklarovanej retenčnej doby nevytvára povinnosť WebHouse túto zálohu ďalej uchovávať.
46. Ak WebHouse v konkrétnom prípade disponuje staršou technickou kópiou a umožní z nej obnovu, ide o pomoc nad rámec štandardnej retenčnej politiky, pokiaľ z podmienok služby nevyplýva inak.
47. Takáto jednorazová pomoc nevytvára právo Zákazníka na obdobnú obnovu v budúcnosti.
48. Zálohovací systém nie je určený ani ako dlhodobé úložisko dát, ktoré Zákazník už nechce uchovávať v produkčnom prostredí.
49. Zákazník by preto nemal postupovať spôsobom, že:

• dáta z produkčnej služby odstráni,
• ponechá ich iba v zálohách,
• a následne sa na zálohy spolieha ako na jediné miesto ich uchovania.

50. Takýto spôsob používania je v rozpore so základným účelom zálohovania.
51. Po odstránení dát z produkčného prostredia môže v dôsledku rotácie záloh dôjsť postupne k odstráneniu všetkých ich historických kópií.
52. Ak Zákazník potrebuje dáta dlhodobo uchovávať, mal by zabezpečiť, aby existovala aspoň jedna aktívna alebo archívna kópia mimo bežného rotačného zálohovacieho systému.
53. Pri osobných údajoch nemožno existenciu historickej zálohy automaticky považovať za oprávnenie Zákazníka uchovávať osobné údaje bez časového obmedzenia.
54. Zákazník ako prevádzkovateľ osobných údajov zodpovedá za určenie primeranej doby ich uchovávania a za splnenie svojich povinností podľa príslušných právnych predpisov.
55. Technické uchovávanie historickej kópie v rámci bežného retenčného cyklu sa posudzuje osobitne podľa podmienok spracúvania osobných údajov a DPA.
56. WebHouse nezodpovedá za nesplnenie:

• zákonnej archivačnej povinnosti,
• evidenčnej povinnosti,
• účtovnej povinnosti,
• daňovej povinnosti,
• povinnosti uchovať dôkazy,
• alebo obdobnej povinnosti Zákazníka,

iba z dôvodu, že Zákazník sa rozhodol spoliehať na štandardnú zálohovaciu službu namiesto vhodného archivačného riešenia.

57. Predchádzajúci bod sa neuplatní v rozsahu, v ktorom WebHouse výslovne prevzal povinnosť poskytovať Zákazníkovi osobitnú archivačnú službu alebo konkrétny garantovaný spôsob dlhodobého uchovávania.
58. Ak WebHouse výslovne poskytuje službu označenú ako archívna, rozhodujúce sú osobitné parametre tejto služby.
59. Zálohovacia služba a archivačná služba môžu byť technicky prepojené, ale zmluvne ide o rozdielne funkcie, pokiaľ nie je výslovne uvedené inak.
60. Zákazník zodpovedá za posúdenie, či zvolený spôsob uchovávania zodpovedá:

• hodnote dát,
• požadovanej dobe uchovania,
• požadovanej dostupnosti,
• požadovanej nemennosti,
• právnym a regulačným požiadavkám.

61. Ak štandardné zálohovanie týmto požiadavkám nezodpovedá, Zákazník je povinný zabezpečiť si vhodnejšie riešenie.
62. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse odstrániť zálohu skôr, než umožňuje výslovne dohodnutá retenčná politika konkrétnej služby.
63. Týmto článkom nie sú dotknuté zákonné práva Zákazníka ani povinnosti WebHouse, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 10

Povinnosť Zákazníka vytvárať vlastné zálohy

1. Zákazník je povinný primerane posúdiť význam, hodnotu, nahraditeľnosť a citlivosť dát, ktoré prostredníctvom služby WebHouse ukladá alebo spracúva.
2. Pri tomto posúdení je Zákazník povinný zohľadniť najmä:
   • následky úplnej straty dát,
   • následky čiastočnej straty dát,
   • prípustný rozsah straty nových alebo zmenených dát,
   • prípustnú dobu nedostupnosti dát,
   • možnosť opätovného získania alebo vytvorenia dát,
   • právne alebo regulačné požiadavky,
   • obchodnú hodnotu dát,
   • význam dát pre kontinuitu prevádzky,
   • riziko bezpečnostného incidentu,
   • závislosť svojej činnosti od dostupnosti týchto dát.
3. Zákazník je povinný oboznámiť sa s parametrami zálohovania objednanej služby, najmä s:
   • rozsahom zálohovania,
   • frekvenciou záloh,
   • retenčnou dobou,
   • dostupnými bodmi obnovy,
   • spôsobom obnovy,
   • prípadnými obmedzeniami služby.
4. Zákazník nesmie automaticky predpokladať, že štandardná zálohovacia služba WebHouse zodpovedá všetkým jeho individuálnym požiadavkám na ochranu dát.
5. Ak by strata, poškodenie alebo dlhšia nedostupnosť dát mohla mať pre Zákazníka významné finančné, prevádzkové, právne, reputačné alebo iné následky, Zákazník je povinný prijať primerané dodatočné opatrenia na ich ochranu.
6. Takýmto opatrením je najmä vytvorenie vlastnej nezávislej zálohy mimo štandardného zálohovacieho systému WebHouse.
7. Pri kritických alebo nenahraditeľných dátach nemá byť záloha poskytovaná WebHouse jedinou existujúcou kópiou týchto dát.
8. Zákazník by mal zabezpečiť, aby pri kritických alebo nenahraditeľných dátach existovali najmenej dve navzájom primerane nezávislé kópie dát, pričom aspoň jedna z nich by mala byť oddelená od produkčnej služby.
9. Externá alebo nezávislá záloha by mala byť podľa významu dát uchovávaná najmä:
   • mimo produkčnej služby,
   • na inom úložisku,
   • na inom technickom systéme,
   • na inom fyzickom zariadení,
   • v inom dátovom centre,
   • u iného poskytovateľa,
   • alebo iným spôsobom znižujúcim riziko súčasnej straty produkčných dát a ich zálohy.
10. Miera technickej alebo geografickej nezávislosti zálohy má zodpovedať významu dát a následkom ich prípadnej straty.
11. Pri bežných dátach môže byť primeraná vlastná lokálna alebo externá kópia.
12. Pri kritických dátach môže byť vhodné používať viacúrovňovú zálohovaciu stratégiu kombinujúcu napríklad:

• produkčné dáta,
• zálohu WebHouse,
• externú zálohu Zákazníka,
• geograficky oddelenú kópiu,
• dlhodobý archív.

13. WebHouse odporúča pri kritických dátach princíp, podľa ktorého Zákazník nemá byť závislý od jediného:

• servera,
• úložiska,
• zákazníckeho účtu,
• zálohovacieho systému,
• poskytovateľa,
• ani fyzického miesta.

14. Zmyslom nezávislej zálohy je znížiť riziko, že jedna technická alebo bezpečnostná udalosť súčasne zasiahne produkčné dáta aj všetky dostupné zálohy.
15. Nezávislá záloha môže byť osobitne významná napríklad pri:

• ransomvérovom útoku,
• kompromitácii administrátorského účtu,
• neoprávnenom vymazaní dát,
• rozsiahlej technickej havárii,
• poškodení súborového systému,
• chybe automatizácie,
• ľudskej chybe,
• zrušení služby,
• dlhodobo nezistenom poškodení dát.

16. Zákazník nesmie predpokladať, že samotná existencia viacerých bodov obnovy v jednom zálohovacom systéme predstavuje viacero úplne nezávislých záloh.
17. Viaceré body obnovy môžu byť technicky závislé od:

• rovnakého zálohovacieho systému,
• rovnakého úložiska,
• rovnakej infraštruktúry,
• spoločného zálohovacieho reťazca.

18. Rovnako RAID, replikácia, clustering, vysoká dostupnosť alebo snapshoty nemusia predstavovať nezávislú zálohu.
19. Zákazník je povinný pri výbere vlastnej zálohovacej stratégie zohľadniť rozdiel medzi:

• vysokou dostupnosťou,
• redundanciou,
• zálohovaním,
• archiváciou.

20. Ak Zákazník potrebuje uchovávať dáta počas dlhšieho obdobia, než umožňuje retenčná politika WebHouse, je povinný vytvoriť si vlastnú dlhodobú kópiu alebo použiť vhodný archivačný systém.
21. Zákazník nesmie ponechať dáta, ktoré chce dlhodobo zachovať, výlučne v rotačných zálohách WebHouse po tom, ako ich odstránil z produkčného prostredia.
22. Pri odstránení dát z produkčného prostredia sa môžu ich historické kópie v rámci bežnej rotácie postupne odstrániť zo všetkých záloh WebHouse.
23. Ak Zákazník potrebuje zachovať konkrétny historický stav, je povinný tento stav včas:

• exportovať,
• uložiť do vlastného archívu,
• vytvoriť samostatnú zálohu,
• alebo použiť inú vhodnú službu.

24. Zákazník je zodpovedný za technickú a organizačnú správu vlastných externých záloh.
25. To zahŕňa najmä:

• ich pravidelné vytváranie,
• kontrolu úspešnosti,
• ochranu prístupových údajov,
• ochranu pred neoprávneným vymazaním,
• primerané šifrovanie, ak je potrebné,
• kontrolu kapacity,
• kontrolu retenčnej doby,
• pravidelné testovanie obnovy.

26. Vlastná záloha, ktorú Zákazník nikdy netestoval, nemusí byť v prípade incidentu použiteľná.
27. Zákazník by preto mal primerane overovať, či je z vlastných záloh možné dáta reálne obnoviť.
28. WebHouse nezodpovedá za:

• úspešnosť vlastného zálohovacieho procesu Zákazníka,
• kvalitu jeho externých záloh,
• poškodenie jeho záloh,
• ich stratu,
• nesprávnu konfiguráciu,
• nefunkčnosť softvéru tretej strany,
• ani za nemožnosť obnovy zo záloh, ktoré WebHouse nespravuje.

29. Ak Zákazník používa zálohovací softvér alebo externé úložisko tretej strany, zodpovedá za správne nastavenie a správu tejto služby.
30. WebHouse môže Zákazníkovi poskytnúť technickú súčinnosť pri vytváraní alebo exporte vlastnej zálohy, ak to umožňuje objednaná služba a rozsah technickej podpory.
31. Takáto technická pomoc však neznamená, že WebHouse preberá trvalú zodpovednosť za vlastný zálohovací systém Zákazníka.
32. Zákazník by mal vytvoriť mimoriadnu vlastnú zálohu najmä pred významným zásahom do dát alebo aplikácie.
33. Ide najmä o situácie pred:

• veľkou aktualizáciou CMS,
• aktualizáciou pluginov alebo tém,
• zmenou verzie aplikácie,
• migráciou,
• hromadným importom alebo exportom,
• hromadnou zmenou databázy,
• zásadnou zmenou konfigurácie,
• zásahom externého programátora,
• iným úkonom s vyšším rizikom poškodenia dát.

34. Zákazník nesmie automaticky predpokladať, že WebHouse vytvoril aktuálny bod obnovy bezprostredne pred jeho vlastným zásahom.
35. Ak je potrebný presný stav bezprostredne pred plánovaným zásahom, Zákazník je povinný vytvoriť vlastnú zálohu alebo použiť funkciu manuálnej zálohy či snapshotu, ak ju príslušná služba poskytuje.
36. Zákazník by mal mimoriadnu zálohu vytvoriť aj pred ukončením alebo významnou zmenou služby, najmä pred:

• zrušením služby,
• transferom k inému poskytovateľovi,
• migráciou na inú platformu,
• prechodom na iný typ služby,
• zmenou technológie.

37. Zákazník je povinný pred ukončením služby exportovať všetky dáta, ktoré chce ďalej uchovávať.
38. Existencia záloh WebHouse po ukončení služby nenahrádza túto povinnosť.
39. Zákazník nesmie počítať s tým, že po zrušení alebo expirácii služby bude možné dáta zo záloh ešte obnoviť.
40. Pri osobných údajoch, obchodnom tajomstve alebo inom citlivom obsahu je Zákazník povinný zabezpečiť primeranú ochranu aj svojich vlastných záloh.
41. Zákazník zodpovedá najmä za:

• kontrolu prístupu,
• bezpečnosť hesiel,
• šifrovanie podľa potreby,
• bezpečné uchovávanie zálohovacích médií,
• bezpečné odstránenie nepotrebných záloh.

42. Zákazník je povinný zohľadniť, že vlastná externá záloha môže sama predstavovať bezpečnostné riziko, ak nie je primerane chránená.
43. Nešifrovaná záloha uložená na ľahko dostupnom zariadení môže pri odcudzení alebo kompromitácii viesť k úniku rovnakých dát ako samotný produkčný systém.
44. Zákazník je preto povinný prispôsobiť bezpečnosť vlastnej zálohy citlivosti jej obsahu.
45. Pri zálohách obsahujúcich osobné údaje Zákazník zodpovedá za dodržiavanie príslušných pravidiel ochrany osobných údajov aj pri ich externom uchovávaní.
46. Ak Zákazník používa tretiu stranu ako poskytovateľa externého zálohovania, zodpovedá za posúdenie právnych a bezpečnostných podmienok takéhoto spracúvania.
47. Pri vysoko kritických systémoch môže byť vhodné používať aj nemenné alebo offline zálohy, ktoré nie je možné jednoducho zmeniť alebo odstrániť prostredníctvom kompromitovaného produkčného účtu.
48. WebHouse však týmto ustanovením negarantuje dostupnosť takejto funkcie v rámci štandardných služieb.
49. Zákazník, ktorý potrebuje osobitnú úroveň zálohovania, je povinný zvoliť vhodný produkt alebo si dohodnúť individuálne riešenie.
50. Individuálne riešenie môže zahŕňať napríklad:

• vyššiu frekvenciu záloh,
• dlhšiu retenciu,
• oddelené zálohovacie úložisko,
• geografickú redundanciu,
• nemenné zálohy,
• individuálne RPO,
• individuálne RTO,
• pravidelné testovanie obnovy.

51. Zákazník zodpovedá za posúdenie, či štandardná alebo individuálne objednaná úroveň ochrany zodpovedá jeho potrebám.
52. Ak Zákazník vedome používa službu s parametrami zálohovania, ktoré sú objektívne nižšie než jeho vlastné požiadavky na prípustnú stratu dát alebo dobu obnovy, nesmie sa spoliehať výlučne na zálohovanie WebHouse.
53. WebHouse môže poskytovať odporúčania týkajúce sa zálohovania, ale takéto všeobecné odporúčanie samo osebe nepredstavuje individuálne posúdenie všetkých potrieb a rizík Zákazníka.
54. Zákazník nesie zodpovednosť za konečné rozhodnutie o svojej zálohovacej stratégii, pokiaľ nebola uzatvorená individuálna dohoda, podľa ktorej WebHouse výslovne prevzal širší rozsah povinností.
55. Povinnosť Zákazníka primerane chrániť kritické alebo nenahraditeľné dáta nezbavuje WebHouse povinnosti riadne poskytovať zálohovanie, ktoré je súčasťou objednanej služby.
56. WebHouse sa preto nemôže dovolávať absencie vlastnej zálohy Zákazníka ako dôvodu na to, aby nemusel plniť výslovne dohodnuté parametre svojej zálohovacej služby.
57. V prípade straty dát sa zodpovednosť jednotlivých strán posudzuje podľa:

• príčiny incidentu,
• rozsahu objednanej služby,
• dohodnutých parametrov zálohovania,
• povinností Zákazníka,
• povinností WebHouse,
• a okolností konkrétneho prípadu.

58. Samotná skutočnosť, že Zákazník nemal vlastnú nezávislú zálohu, automaticky neznamená zánik jeho práv voči WebHouse, ak WebHouse porušil vlastnú zmluvnú alebo zákonnú povinnosť.
59. Rovnako samotná existencia zálohovacej služby WebHouse neznamená, že WebHouse preberá všetky riziká spojené s uchovávaním jediného exemplára kritických dát Zákazníka.
60. Cieľom tohto článku je vytvoriť primerané rozdelenie zodpovednosti: WebHouse zabezpečuje zálohovanie v dohodnutom rozsahu a Zákazník zabezpečuje, aby úroveň ochrany jeho dát zodpovedala ich skutočnému významu.
61. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 11

Dáta s vysokou hodnotou alebo kritickým významom

1. Zákazník, ktorý prostredníctvom služby WebHouse ukladá, spracúva alebo prevádzkuje dáta s vysokou hodnotou, kritickým významom alebo zvýšenou citlivosťou, je povinný prispôsobiť tomu svoju zálohovaciu a obnovovaciu stratégiu.
2. Za dáta s vysokou hodnotou alebo kritickým významom sa môžu považovať najmä:
   • kritické obchodné dáta,
   • nenahraditeľné dáta,
   • účtovné alebo finančné dáta,
   • databázy zákazníkov,
   • objednávkové a transakčné dáta,
   • produkčné databázy,
   • dáta informačných systémov nevyhnutných na chod podnikania,
   • dokumenty s vysokou právnou alebo obchodnou hodnotou,
   • osobitne citlivé alebo regulované údaje,
   • osobné údaje vo veľkom rozsahu,
   • zdravotné alebo iné citlivé údaje,
   • zdrojové kódy,
   • výsledky dlhodobého vývoja,
   • jedinečné fotografie, audiovizuálne materiály alebo iný nenahraditeľný obsah,
   • dáta, ktorých strata by mohla viesť k významnej finančnej škode,
   • dáta, ktorých strata by mohla vážne obmedziť alebo zastaviť činnosť Zákazníka.
3. Rozhodujúce nie je iba množstvo dát alebo ich veľkosť, ale najmä následky ich prípadnej straty, poškodenia, nedostupnosti alebo neoprávnenej zmeny.
4. Aj relatívne malý súbor alebo databáza môže predstavovať kritické dáta, ak je pre Zákazníka:
   • nenahraditeľná,
   • časovo citlivá,
   • právne významná,
   • potrebná na zabezpečenie prevádzky,
   • alebo ju nemožno primerane znovu vytvoriť.
5. Posúdenie významu a kritickosti dát vykonáva Zákazník.
6. WebHouse spravidla nemá vedomosť o:
   • obchodnej hodnote jednotlivých dát,
   • ich nenahraditeľnosti,
   • právnych povinnostiach Zákazníka,
   • následkoch ich prípadnej straty,
   • maximálne prípustnom výpadku alebo rozsahu straty dát.
7. Samotná skutočnosť, že WebHouse technicky ukladá alebo zálohuje určité dáta, preto neznamená, že WebHouse prevzal individuálnu zodpovednosť za ich obchodný alebo právny význam.
8. Zákazník je povinný pred používaním služby posúdiť najmä:
   • aký objem dát môže potenciálne stratiť bez závažných následkov,
   • ako starý bod obnovy je ešte akceptovateľný,
   • ako dlho môže byť služba alebo dáta nedostupné,
   • či je možné dáta znovu vytvoriť,
   • či má povinnosť dáta uchovávať počas určenej doby,
   • či potrebuje viac geograficky alebo technicky oddelených kópií.
9. Bežná záloha poskytovaná v rámci štandardnej hostingovej alebo serverovej služby nemusí byť vhodná ako jediný mechanizmus ochrany kritických alebo nenahraditeľných dát.
10. Zákazník nesmie pri takýchto dátach vychádzať z predpokladu, že existencia jedinej zálohovacej služby úplne odstraňuje riziko ich straty.
11. Pri kritických dátach sa odporúča viacvrstvová ochrana, ktorá môže podľa významu dát zahŕňať najmä:

• produkčné dáta,
• automatickú zálohu WebHouse,
• vlastnú nezávislú zálohu Zákazníka,
• ďalšiu geograficky oddelenú kópiu,
• dlhodobý archív,
• nemennú alebo offline zálohu,
• pravidelné testovanie obnovy.

12. Zákazník by mal primerane zohľadniť princíp, aby kritické dáta neboli závislé od jediného:

• servera,
• úložiska,
• zálohovacieho systému,
• dátového centra,
• zákazníckeho účtu,
• ani poskytovateľa.

13. Viaceré body obnovy v rámci jedného zálohovacieho systému nemusia predstavovať viacero nezávislých záloh.
14. Jedna rozsiahla technická alebo bezpečnostná udalosť môže podľa okolností ovplyvniť viacero bodov obnovy, najmä ak sú technicky alebo organizačne prepojené.
15. Zákazník je preto pri kritických dátach povinný primerane znižovať riziko súčasnej straty:

• produkčných dát,
• aj ich záloh.

16. Pri kritických dátach môže byť vhodné používať princíp viacnásobných kópií, pričom aspoň jedna kópia je uložená na technicky alebo geograficky oddelenom systéme.
17. Konkrétny počet kópií ani ich technická architektúra nie sú týmito Pravidlami univerzálne stanovené, pretože primeraná úroveň ochrany závisí od významu konkrétnych dát.
18. Zákazník, ktorého činnosť vyžaduje veľmi nízku prípustnú stratu dát, by mal používať riešenie s primerane krátkym RPO.
19. Zákazník, ktorý potrebuje veľmi rýchle obnovenie prevádzky, by mal používať riešenie s primerane krátkym RTO.
20. Štandardná frekvencia záloh alebo retenčná doba sama osebe nepredstavuje garantované RPO ani RTO.
21. Ak Zákazník potrebuje konkrétne garantované RPO alebo RTO, musí byť takýto parameter výslovne uvedený:

• v konkrétnom produkte,
• v SLA,
• alebo v individuálnej dohode.

22. Ak napríklad Zákazník nemôže akceptovať stratu viac než niekoľkých minút nových databázových transakcií, bežné denné zálohovanie nie je samo osebe primeraným jediným mechanizmom ochrany týchto dát.
23. V takom prípade môže byť potrebné použiť napríklad:

• častejšie zálohovanie,
• transakčné logy,
• kontinuálnu ochranu dát,
• databázovú replikáciu v kombinácii so zálohami,
• aplikačné zálohovanie,
• alebo individuálne riešenie.

24. Replikácia sama osebe nie je náhradou zálohy.
25. Ak dôjde k:

• vymazaniu dát,
• neoprávnenej zmene,
• poškodeniu,
• alebo kompromitácii,

môže byť rovnaká zmena okamžite prenesená aj na repliku.

26. Zákazník by preto pri kritických systémoch mal kombinovať vysokú dostupnosť a redundanciu s nezávislým zálohovaním.
27. Pri dátach vysokej hodnoty môže byť vhodné používať zálohy chránené pred jednoduchým odstránením alebo prepísaním.
28. Môže ísť napríklad o:

• nemenné úložisko,
• časovo uzamknutú zálohu,
• offline kópiu,
• samostatný zálohovací účet,
• inú technológiu primerane chránenú pred kompromitáciou produkčného systému.

29. Štandardné služby WebHouse nemusia automaticky poskytovať všetky takéto mechanizmy.
30. Ak Zákazník takúto úroveň ochrany potrebuje, je povinný zvoliť zodpovedajúcu službu alebo individuálne riešenie.
31. Pri dátach s vysokou finančnou alebo obchodnou hodnotou by mal Zákazník primerane pravidelne testovať, či je možné zo záloh vykonať obnovu.
32. Samotná existencia súboru alebo bodu obnovy nepostačuje na posúdenie funkčnosti celej zálohovacej stratégie.
33. Test obnovy môže podľa typu dát zahŕňať napríklad:

• obnovu vybraného súboru,
• obnovu databázy,
• obnovenie virtuálneho servera do testovacieho prostredia,
• overenie integrity kľúčových dát,
• overenie funkčnosti aplikácie po obnove.

34. Ak štandardná služba WebHouse neobsahuje pravidelné individuálne testovanie obnovy, Zákazník si musí potrebu takéhoto testovania zabezpečiť sám alebo si dohodnúť samostatnú službu.
35. Pri kritických dátach je Zákazník povinný venovať zvýšenú pozornosť aj bezpečnosti vlastných záloh.
36. Záloha kritických dát môže obsahovať rovnaké:

• osobné údaje,
• obchodné tajomstvá,
• prístupové údaje,
• citlivé informácie

ako produkčný systém.

37. Záloha preto môže sama predstavovať významný cieľ útoku.
38. Zákazník je povinný svoje vlastné zálohy chrániť primerane citlivosti ich obsahu.
39. Pri osobitne citlivých dátach môže byť potrebné najmä:

• šifrovanie,
• obmedzenie prístupov,
• viacfaktorová autentifikácia,
• oddelenie administrátorských oprávnení,
• bezpečné nakladanie so zálohovacími médiami.

40. Ak Zákazník používa na externé zálohovanie tretiu stranu, zodpovedá za posúdenie primeranosti jej:

• bezpečnostných podmienok,
• geografického umiestnenia dát,
• pravidiel ochrany osobných údajov,
• retenčnej politiky,
• zmluvných podmienok.

41. Pri osobných údajoch osobitných kategórií alebo inom regulovanom obsahu je Zákazník povinný posúdiť aj svoje právne povinnosti súvisiace so zálohovaním a uchovávaním takýchto údajov.
42. Skutočnosť, že technická platforma WebHouse umožňuje uloženie určitého typu dát, automaticky neznamená, že štandardná služba je vhodná pre každý regulovaný alebo osobitne kritický účel.
43. Ak charakter systému vyžaduje osobitné:

• bezpečnostné,
• auditné,
• retenčné,
• geografické,
• alebo obnovovacie

požiadavky, Zákazník je povinný preveriť, či ich vybraná služba spĺňa.

44. WebHouse môže Zákazníkovi odporučiť vhodnejší typ služby alebo individuálne riešenie.
45. Takéto odporúčanie však nenahrádza vlastné odborné, právne alebo rizikové posúdenie Zákazníka.
46. Zákazník by mal mať pri kritických systémoch primeraný plán obnovy po havárii alebo strate dát.
47. Takýto plán by mal podľa významu systému určovať najmä:

• ktoré dáta sa obnovujú ako prvé,
• odkiaľ sa obnovujú,
• aký bod obnovy je prijateľný,
• kto je oprávnený obnovu požadovať,
• ako sa overí správnosť obnovených dát,
• aký je náhradný postup, ak primárna záloha nie je použiteľná.

48. WebHouse nie je zodpovedný za vytvorenie individuálneho disaster recovery plánu Zákazníka, pokiaľ takáto služba nebola osobitne objednaná.
49. Zákazník je povinný zohľadniť aj riziko dlhodobo nezisteného poškodenia dát.
50. Ak sa napríklad chyba alebo kompromitácia zistí až po uplynutí retenčnej doby, všetky dostupné zálohy už môžu obsahovať rovnaký chybný stav.
51. Pri dátach, kde existuje významné riziko neskorého zistenia chyby, môže byť vhodná dlhšia retencia alebo samostatné dlhodobé body obnovy.
52. Zákazník nesmie predpokladať, že bežný rotačný systém vždy zachová čistú zálohu spred vzniku incidentu.
53. Ak Zákazník zistí poškodenie alebo kompromitáciu kritických dát, mal by WebHouse kontaktovať bez zbytočného odkladu.
54. Včasné oznámenie môže zvýšiť možnosť:

• zachovať existujúci bod obnovy,
• zabrániť jeho odstráneniu rotáciou,
• alebo identifikovať vhodnejšiu historickú zálohu.

55. WebHouse však negarantuje, že pri každom incidente bude možné štandardnú rotáciu včas zastaviť alebo zachovať vhodný bod obnovy.
56. Pri kritických dátach je Zákazník povinný primerane plánovať aj situáciu úplnej nedostupnosti záloh WebHouse.
57. Zálohovacia stratégia kritického systému by preto mala primerane počítať aj so scenárom, keď:

• posledná záloha nie je použiteľná,
• viacero posledných bodov je poškodených,
• zálohovací systém je dočasne nedostupný,
• alebo incident zasiahol viacero technických vrstiev.

58. Zákazník, ktorý potrebuje vyššiu úroveň ochrany, než poskytuje štandardná služba, môže podľa ponuky WebHouse požadovať individuálne riešenie.
59. Individuálne riešenie môže zahŕňať najmä:

• vyššiu frekvenciu zálohovania,
• dlhšiu retenciu,
• väčší počet bodov obnovy,
• geograficky oddelené zálohy,
• samostatné zálohovacie úložisko,
• nemenné zálohy,
• individuálne RPO,
• individuálne RTO,
• pravidelné testovanie obnovy,
• osobitné bezpečnostné opatrenia.

60. Parametre individuálneho riešenia musia byť výslovne dohodnuté.
61. WebHouse nie je povinný poskytovať nadštandardné parametre kritickým systémom iba preto, že Zákazník na štandardnej službe takéto dáta prevádzkuje.
62. Samotné používanie štandardnej služby na kritický účel nemení automaticky jej:

• frekvenciu zálohovania,
• retenciu,
• RPO,
• RTO,
• ani rozsah zodpovednosti WebHouse.

63. Zákazník nemôže bez osobitnej dohody odvodiť vyššiu úroveň garancie zo skutočnosti, že WebHouse vedel alebo mohol predpokladať, že služba je pre Zákazníka významná.
64. Rozhodujúce sú výslovne dohodnuté parametre služby.
65. Ak Zákazník prevádzkuje kritický systém na štandardnom produkte, ktorého parametre sú objektívne nižšie než jeho vlastné požiadavky, je povinný rozdiel riešiť vlastnými opatreniami alebo vhodnejším produktom.
66. Povinnosť Zákazníka používať pri kritických dátach primeranú zálohovaciu stratégiu však nezbavuje WebHouse povinnosti riadne poskytovať zálohovanie, ktoré je súčasťou objednanej služby.
67. Ak WebHouse výslovne garantoval určitý:

• rozsah zálohovania,
• retenčný parameter,
• RPO,
• RTO,
• alebo inú vlastnosť,

posudzuje sa plnenie tejto povinnosti podľa príslušnej zmluvy a týchto Pravidiel.

68. Samotná skutočnosť, že Zákazník nemal dodatočnú externú zálohu, automaticky nezbavuje WebHouse zodpovednosti za porušenie jeho vlastnej zmluvnej alebo zákonnej povinnosti.
69. Rovnako však samotná skutočnosť, že WebHouse poskytuje zálohovanie, neznamená, že preberá celé podnikateľské alebo prevádzkové riziko spojené s tým, že Zákazník uchováva kritické alebo nenahraditeľné dáta iba v jednej službe.
70. Pri posudzovaní konkrétneho incidentu sa prihliada najmä na:

• povahu a význam dát,
• objednaný rozsah služby,
• dohodnuté parametre zálohovania,
• opatrenia Zákazníka,
• príčinu straty alebo poškodenia,
• technické okolnosti incidentu,
• povinnosti oboch zmluvných strán.

71. Účelom tohto článku je zabezpečiť, aby úroveň ochrany dát primerane zodpovedala ich skutočnej hodnote a významu, a aby pri kritických dátach nebola ochrana založená výlučne na jednom technickom mechanizme.
72. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 12

Zálohovanie zdieľaného webhostingu

1. Ak je zálohovanie súčasťou konkrétnej webhostingovej služby, vykonáva sa v rozsahu a podľa parametrov určených pre príslušný webhostingový program.
2. Zálohovanie zdieľaného webhostingu môže podľa typu služby zahŕňať najmä:
   • webové súbory Zákazníka,
   • databázy,
   • vybrané konfiguračné dáta,
   • prípadne ďalšie zákaznícke dáta podľa parametrov služby.
3. Skutočnosť, že webhostingová služba obsahuje zálohovanie, neznamená automaticky, že všetky technické súčasti webhostingového účtu sú predmetom rovnakej zálohy.
4. Jednotlivé časti webhostingovej služby môžu byť zálohované:
   • samostatne,
   • rozdielnymi technológiami,
   • v rozdielnych časoch,
   • s rozdielnou frekvenciou,
   • s rozdielnou retenčnou dobou.
5. Webové súbory a databázy preto nemusia mať totožný čas vytvorenia bodu obnovy.
6. Ak napríklad záloha webových súborov vznikne v inom čase ako záloha databázy, môže po spoločnej obnove vzniknúť stav, ktorý nezodpovedá presne jednému okamihu pôvodnej prevádzky aplikácie.
7. Takýto rozdiel môže byť významný najmä pri dynamických webových aplikáciách, ktoré často zapisujú údaje do databázy.
8. WebHouse negarantuje časovú konzistenciu medzi samostatne zálohovanými časťami služby, pokiaľ je takáto vlastnosť pri konkrétnej službe výslovne uvedená ako garantovaný parameter.
9. Pri zdieľanom webhostingu môžu byť zo zálohovania podľa všeobecných pravidiel a parametrov služby vylúčené najmä:
   • dočasné súbory,
   • cache,
   • session dáta,
   • technické logy,
   • súbory v osobitne vylúčených adresároch,
   • dáta uložené mimo webhostingového priestoru,
   • externé databázy,
   • externé úložiská,
   • dáta služieb tretích strán.
10. Zálohovanie webhostingového účtu automaticky nezahŕňa obsah systémov, ktoré webová aplikácia používa mimo infraštruktúry WebHouse.
11. Ide najmä o:

• externé API,
• externé databázy,
• cloudové úložiská,
• externé CDN,
• externé e-mailové služby,
• platobné systémy,
• systémy tretích strán.

12. Obnova webhostingového účtu môže byť podľa technických možností vykonaná:

• priamo do pôvodného produkčného umiestnenia,
• do dočasného obnovovacieho priestoru,
• do iného technicky vhodného priestoru,
• sprístupnením alebo exportom dostupných dát Zákazníkovi,
• alebo kombináciou uvedených spôsobov.

13. Spôsob obnovy určuje WebHouse s prihliadnutím na:

• typ služby,
• rozsah požadovanej obnovy,
• dostupnú zálohu,
• riziko prepísania aktuálnych dát,
• technické možnosti zálohovacieho systému.

14. Zákazník nemá automatický nárok na konkrétny spôsob obnovy, ak je možné požadované dáta primerane sprístupniť alebo obnoviť iným podporovaným spôsobom.
15. Pri obnove priamo do pôvodného umiestnenia môže dôjsť k prepísaniu aktuálnych produkčných dát starším stavom zo zálohy.
16. V takom prípade môžu byť nenávratne stratené zmeny vykonané po vytvorení príslušného bodu obnovy.
17. Pred vykonaním obnovy môže WebHouse od Zákazníka požadovať potvrdenie, že:

• rozumie dôsledkom obnovy,
• súhlasí s prepísaním aktuálnych dát,
• a zvolil požadovaný bod obnovy.

18. Ak to technické možnosti umožňujú, WebHouse môže pred obnovou vytvoriť kópiu aktuálneho stavu produkčných dát.
19. Vytvorenie takejto dodatočnej kópie však nie je automaticky garantované a môže závisieť od:

• dostupnej kapacity,
• technického stavu služby,
• rozsahu dát,
• charakteru incidentu.

20. Ak existuje riziko, že aktuálne dáta môžu byť ešte potrebné, môže byť vhodnejšie vykonať obnovu najprv do dočasného priestoru.
21. Dočasný obnovovací priestor umožňuje Zákazníkovi napríklad:

• preveriť obsah zálohy,
• porovnať aktuálne a historické dáta,
• vybrať iba potrebné súbory,
• preveriť, či požadovaný bod obnovy obsahuje hľadané dáta.

22. Poskytnutie dočasného obnovovacieho priestoru závisí od technických možností a nemusí byť dostupné pri každej službe alebo každej požiadavke.
23. Dočasný obnovovací priestor môže byť kapacitne alebo časovo obmedzený.
24. WebHouse môže po uplynutí určenej doby obsah dočasného obnovovacieho priestoru automaticky odstrániť.
25. Dočasný obnovovací priestor nie je určený na trvalú produkčnú prevádzku, pokiaľ WebHouse výslovne neurčí inak.
26. Obnova webových súborov môže byť podľa technológie vykonaná:

• ako obnova celého webového priestoru,
• konkrétneho adresára,
• konkrétneho súboru,
• alebo inej podporovanej jednotky.

27. Možnosť selektívnej obnovy jednotlivého súboru nie je automaticky garantovaná pri každej zálohovacej technológii.
28. WebHouse môže v prípade potreby obnoviť väčší technický celok, z ktorého si Zákazník následne vyberie požadované dáta.
29. Obnova databázy môže byť vykonaná najmä:

• prepísaním existujúcej databázy,
• obnovením do novej databázy,
• poskytnutím databázového exportu,
• alebo iným technicky primeraným spôsobom.

30. Obnova databázy nemusí umožňovať obnovenie:

• jediného databázového riadku,
• konkrétnej tabuľky,
• konkrétnej transakcie,
• alebo jednotlivého údaja,

pokiaľ použitá technológia takúto selektívnu obnovu nepodporuje.

31. Zálohovacia jednotka môže byť celá databáza.
32. Ak Zákazník potrebuje iba konkrétny záznam, môže byť potrebné obnoviť celú databázu do dočasného priestoru a požadovaný údaj následne manuálne identifikovať.
33. Takýto nadštandardný zásah môže byť podľa rozsahu práce spoplatnený.
34. WebHouse negarantuje, že po obnove webových súborov alebo databázy bude webová stránka alebo aplikácia automaticky plne funkčná.
35. Funkčnosť webovej aplikácie po obnove môže závisieť najmä od:

• vzájomnej konzistencie súborov a databázy,
• verzie PHP,
• verzie databázového systému,
• konfigurácie webového servera,
• konfiguračných súborov aplikácie,
• prístupových údajov,
• DNS konfigurácie,
• SSL/TLS certifikátov,
• externých služieb,
• externých API,
• licenčných serverov,
• dostupnosti služieb tretích strán,
• aktuálneho technického stavu aplikácie.

36. Obnovenie dát nepredstavuje automaticky obnovenie celého pôvodného technického prostredia v stave, v akom existovalo v čase vytvorenia zálohy.
37. WebHouse nie je povinný spätne poskytovať rovnakú historickú verziu:

• PHP,
• databázového servera,
• webového servera,
• operačného systému,
• alebo inej systémovej technológie,

iba preto, že bola používaná v čase vytvorenia zálohy.

38. Ak bola aplikácia pôvodne prevádzkovaná na staršej technológii, ktorá už nie je podporovaná alebo dostupná, obnovená aplikácia nemusí na aktuálnom prostredí fungovať bez ďalšej úpravy.
39. Samotná nemožnosť spustiť obnovenú aplikáciu na aktuálnom technickom prostredí neznamená, že záloha bola chybná.
40. WebHouse je zodpovedný za správne vykonanie obnovy v rozsahu zálohovaných dát a technických možností služby, nie automaticky za kompatibilitu aplikácie Zákazníka s aktuálnym hostingovým prostredím.
41. Obnova dát nepredstavuje automaticky:

• opravu aplikácie,
• aktualizáciu aplikácie,
• opravu programového kódu,
• opravu databázovej štruktúry,
• odstránenie bezpečnostnej zraniteľnosti,
• odstránenie malvéru,
• opravu pluginu alebo témy,
• rekonfiguráciu aplikácie.

42. Ak bola príčinou problému chyba alebo zraniteľnosť aplikácie Zákazníka, môže byť rovnaká chyba alebo zraniteľnosť prítomná aj v obnovenej zálohe.
43. Ak bola webová stránka kompromitovaná už pred vytvorením zálohy, obnovená záloha môže obsahovať:

• škodlivý kód,
• backdoor,
• neoprávnene upravené súbory,
• kompromitované účty,
• škodlivé databázové záznamy.

44. Obnova takejto zálohy preto nemusí znamenať odstránenie bezpečnostného incidentu.
45. Zákazník je zodpovedný za odstránenie príčiny kompromitácie v tej časti služby, ktorú podľa podmienok služby spravuje Zákazník.
46. WebHouse môže z bezpečnostných dôvodov odmietnuť okamžité obnovenie kompromitovanej aplikácie priamo do verejne dostupného produkčného prostredia, ak by tým mohlo dôjsť k:

• pokračovaniu útoku,
• rozosielaniu škodlivého obsahu,
• napadnutiu ďalších systémov,
• ohrozeniu infraštruktúry alebo ostatných zákazníkov.

47. V takom prípade môže byť obnova vykonaná do izolovaného alebo dočasného priestoru, ak je to technicky možné.
48. WebHouse môže pred opätovným sprístupnením kompromitovanej aplikácie požadovať primerané nápravné opatrenia.
49. Obnova webhostingových dát nemusí zahŕňať obnovu DNS konfigurácie, ak DNS nie je súčasťou príslušného zálohovacieho mechanizmu.
50. Rovnako nemusí zahŕňať automatické obnovenie:

• doménovej registrácie,
• externých DNS záznamov,
• externých CDN nastavení,
• nastavení externých poskytovateľov.

51. Ak webová aplikácia používa DNS spravované treťou stranou, ich správnu konfiguráciu zabezpečuje Zákazník alebo príslušný externý poskytovateľ.
52. Obnova webhostingu automaticky neznamená ani obnovenie licencií softvéru alebo platených doplnkov.
53. Ak licencia:

• exspirovala,
• bola deaktivovaná,
• je viazaná na inú IP adresu,
• je viazaná na konkrétne prostredie,
• alebo vyžaduje aktiváciu treťou stranou,

môže byť potrebná jej samostatná reaktivácia.

54. WebHouse nezodpovedá za funkčnosť externých licencií, ktoré nespravuje.
55. Pri obnove webhostingového účtu môže byť potrebné zmeniť alebo znovu nastaviť aj:

• prístupové údaje,
• databázové heslá,
• konfiguračné súbory,
• cesty k súborom,
• oprávnenia,
• cron úlohy,
• alebo iné zákaznícke nastavenia.

56. Potreba takýchto následných úprav sama osebe neznamená, že obnova bola vykonaná nesprávne.
57. Zákazník je po obnove povinný bez zbytočného odkladu preveriť:

• úplnosť požadovaných dát,
• funkčnosť webovej aplikácie,
• funkčnosť databázového spojenia,
• správnosť konfiguračných údajov,
• bezpečnostný stav aplikácie.

58. Ak Zákazník zistí po obnove nedostatok, je povinný ho oznámiť WebHouse bez zbytočného odkladu, najmä ak ešte existujú ďalšie použiteľné body obnovy.
59. Neskoré oznámenie môže viesť k tomu, že staršie alternatívne body obnovy budú medzičasom odstránené v rámci bežnej rotácie.
60. Zákazník by preto po obnove nemal odkladať kontrolu výsledku.
61. Ak Zákazník po obnove začne produkčné dáta ďalej meniť, môže byť následná obnova z iného historického bodu komplikovanejšia alebo môže opätovne viesť k strate novších zmien.
62. Ak má Zákazník pochybnosť o vhodnom bode obnovy, môže požiadať WebHouse o informáciu o dostupných technických možnostiach.
63. WebHouse však nemusí byť schopný určiť, ktorý bod obnovy obsahuje posledný funkčný stav aplikácie, pretože:

• nemusí poznať okamih vzniku aplikačnej chyby,
• nemusí poznať okamih kompromitácie,
• nemusí poznať význam jednotlivých zmien Zákazníka.

64. Voľba požadovaného historického stavu preto môže vyžadovať súčinnosť Zákazníka.
65. Ak Zákazník nevie presne určiť vhodný bod obnovy, WebHouse môže podľa možností navrhnúť technicky dostupný bod, bez garancie, že ide o posledný funkčný stav aplikácie.
66. Pri rozsiahlej obnove môže byť webhostingová služba alebo jej časť dočasne:

• obmedzená,
• nedostupná,
• uvedená do režimu údržby.

67. Takéto dočasné obmedzenie môže byť potrebné na zabezpečenie konzistencie a bezpečnosti obnovy.
68. Doba potrebná na obnovu závisí najmä od:

• objemu dát,
• počtu súborov,
• veľkosti databáz,
• typu zálohy,
• technológie zálohovacieho systému,
• zaťaženia infraštruktúry,
• rozsahu požadovanej obnovy.

69. Samotná existencia zálohy neznamená, že obnova musí byť dokončená v konkrétnom čase, pokiaľ pri službe nie je výslovne dohodnuté RTO alebo iná lehota obnovy.
70. Obnova webhostingových dát môže byť podľa konkrétnej služby:

• samoobslužná,
• zahrnutá v cene služby,
• zahrnutá iba v určitom rozsahu,
• alebo poskytovaná ako spoplatnený administrátorský zásah.

71. Konkrétne cenové podmienky obnovy sa riadia cenníkom a podmienkami príslušnej služby.
72. Ak je obnova potrebná v dôsledku preukázanej vady alebo poruchy služby na strane WebHouse, jej posúdenie a prípadné spoplatnenie sa riadi zmluvnými podmienkami, Reklamačným poriadkom a príslušnými právnymi predpismi.
73. Ak je obnova požadovaná v dôsledku:

• chyby Zákazníka,
• neúmyselného vymazania,
• chybnej aktualizácie,
• chybného zásahu programátora,
• kompromitácie aplikácie spravovanej Zákazníkom,
• alebo inej udalosti mimo zodpovednosti WebHouse,

manuálna obnova môže byť spoplatnená podľa aktuálneho cenníka.

74. Skutočnosť, že WebHouse pri jednej požiadavke vykoná manuálnu obnovu bezplatne alebo nad rámec štandardnej služby, nevytvára nárok na rovnaký postup v budúcnosti.
75. Záloha webhostingu nepredstavuje náhradu vlastnej zálohy Zákazníka.
76. Pred zásadnou zmenou webovej aplikácie, najmä pred:

• aktualizáciou CMS,
• aktualizáciou pluginov alebo tém,
• migráciou,
• hromadnou zmenou databázy,
• importom veľkého množstva dát,
• zásahom externého dodávateľa,

by mal Zákazník vytvoriť vlastnú aktuálnu zálohu alebo manuálny bod obnovy, ak ho služba umožňuje.

77. Zákazník nesmie predpokladať, že automatický zálohovací systém vytvoril použiteľný bod obnovy bezprostredne pred jeho plánovaným zásahom.
78. Pri webových aplikáciách s kritickými alebo nenahraditeľnými dátami je Zákazník povinný primerane zabezpečiť aj nezávislú externú zálohu podľa článkov X a XI týchto Pravidiel.
79. Rozsah zálohovania zdieľaného webhostingu je vždy obmedzený na rozsah konkrétnej objednanej služby.
80. Samotná skutočnosť, že WebHouse technicky disponuje ďalšou internou kópiou webhostingových dát, nevytvára Zákazníkovi nárok na jej uchovanie alebo obnovu, ak nie je súčasťou štandardných parametrov služby.
81. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne zúžiť rozsah zálohovania, ktorý bol pri konkrétnom webhostingovom programe výslovne dohodnutý.
82. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 13

Zálohovanie databáz

1. Databázy môžu byť zálohované:
   • samostatne,
   • ako súčasť zálohy webhostingovej služby,
   • ako súčasť zálohy virtuálneho alebo iného servera,
   • alebo iným technickým spôsobom podľa charakteru konkrétnej služby.
2. Rozsah, frekvencia, retenčná doba a spôsob zálohovania databáz závisia od parametrov konkrétnej objednanej služby.
3. Záloha databázy predstavuje stav databázy alebo jej technický obraz zachytený v určitom čase alebo počas určitého zálohovacieho procesu.
4. Záloha databázy môže byť podľa použitej technológie vytvorená najmä ako:
   • logický export databázy,
   • fyzická kópia databázových dát,
   • snapshot úložiska,
   • záloha databázového servera,
   • inkrementálna alebo diferenciálna záloha,
   • kombinácia uvedených mechanizmov.
5. WebHouse nie je povinný používať konkrétny technický spôsob zálohovania databázy, ak použitý mechanizmus zodpovedá parametrom objednanej služby.
6. WebHouse môže počas poskytovania služby zmeniť používanú zálohovaciu technológiu bez súhlasu Zákazníka, ak tým nedôjde k svojvoľnému zníženiu výslovne dohodnutých parametrov služby.
7. Pri aktívne používanej databáze môže počas zálohovania dochádzať k súbežnému:
   • čítaniu dát,
   • zápisu dát,
   • vykonávaniu transakcií,
   • zmene tabuliek,
   • zmene indexov,
   • alebo iným databázovým operáciám.
8. Z dôvodu zabezpečenia obnoviteľnosti databázy môže zálohovací systém používať technické mechanizmy primerané konkrétnemu databázovému systému.
9. Môže ísť najmä o:
   • transakčne konzistentný export,
   • snapshot,
   • uzamknutie vybraných objektov,
   • využitie databázových logov,
   • koordináciu so samotným databázovým serverom,
   • alebo iný mechanizmus podporovaný príslušnou technológiou.
10. WebHouse používa pri zálohovaní databáz mechanizmy primerané technológii a typu konkrétnej služby.
11. Pojem konzistentná záloha neznamená absolútnu garanciu, že databázové dáta budú zodpovedať všetkým externým alebo aplikačným dátam nachádzajúcim sa mimo databázy.
12. Databázová záloha môže byť konzistentná z pohľadu databázového systému, ale nemusí byť časovo totožná napríklad so zálohou:

• webových súborov,
• nahratých dokumentov,
• externého objektového úložiska,
• externého systému,
• alebo inej súčasti aplikácie.

13. Ak sa webové súbory a databáza zálohujú samostatne, môžu byť ich body obnovy vytvorené v rozdielnych časoch.
14. Po spoločnej obnove súborov a databázy preto nemusí výsledný stav presne zodpovedať jednému historickému okamihu prevádzky aplikácie.
15. Takýto rozdiel môže byť významný najmä pri:

• e-shopoch,
• rezervačných systémoch,
• účtovných systémoch,
• CRM systémoch,
• diskusných systémoch,
• systémoch s častým zápisom dát.

16. Ak Zákazník vyžaduje presnú transakčnú konzistenciu medzi viacerými technickými komponentmi, musí používať riešenie, ktoré takúto vlastnosť výslovne zabezpečuje.
17. Štandardné zálohovanie databázy nemusí zahŕňať priebežné zachytávanie každej jednotlivej databázovej transakcie.
18. Samotná frekvencia zálohovania preto neznamená možnosť obnoviť databázu do ľubovoľne zvoleného okamihu medzi dvoma bodmi obnovy.
19. Možnosť tzv. point-in-time recovery existuje iba vtedy, ak ju konkrétna služba alebo použitý zálohovací mechanizmus výslovne podporuje.
20. Ak point-in-time recovery nie je súčasťou služby, WebHouse nie je povinný rekonštruovať databázu na základe jednotlivých historických transakcií.
21. Záloha databázy môže obsahovať dáta v stave, v akom existovali v okamihu alebo počas obdobia vytvárania zálohy.
22. Dáta vytvorené alebo zmenené po príslušnom bode obnovy nebudú po obnove tejto zálohy automaticky zachované.
23. Obnovou staršej databázy do produkčného prostredia preto môže dôjsť k strate novších:

• objednávok,
• používateľských účtov,
• platieb,
• formulárov,
• komentárov,
• transakcií,
• alebo iných databázových zmien.

24. Pred obnovou celej databázy môže WebHouse požadovať výslovné potvrdenie Zákazníka, že rozumie riziku prepísania novších dát.
25. Ak to technické možnosti umožňujú, môže byť databáza obnovená najprv:

• do novej databázy,
• do dočasného priestoru,
• alebo vo forme exportu,

aby mohol Zákazník historické dáta najprv preveriť.

26. Takýto spôsob obnovy nie je automaticky dostupný pri každej službe.
27. Štandardnou jednotkou obnovy môže byť celá databáza alebo celý dostupný zálohovací obraz databázy.
28. Záloha databázy nemusí umožňovať samostatnú obnovu:

• jedného databázového riadku,
• jedného používateľského účtu,
• jednej objednávky,
• jedného záznamu,
• jednej hodnoty,
• jednej transakcie,
• ani jednej tabuľky.

29. Ak použitá technológia umožňuje obnovu iba celej databázy, WebHouse nie je povinný manuálne rekonštruovať jednotlivé záznamy priamo zo zálohovacieho formátu.
30. Ak Zákazník potrebuje iba jednotlivý záznam, môže byť potrebné:

• obnoviť celú historickú databázu do dočasného prostredia,
• identifikovať požadovaný údaj,
• a následne ho manuálne preniesť do produkčnej databázy.

31. Takýto postup môže predstavovať nadštandardný administrátorský alebo databázový zásah a môže byť spoplatnený podľa cenníka alebo dohody so Zákazníkom.
32. WebHouse nemusí vykonávať aplikačnú analýzu databázy s cieľom určiť, ktoré databázové záznamy patria ku konkrétnemu obchodnému prípadu Zákazníka.
33. WebHouse nemusí poznať význam:

• jednotlivých tabuliek,
• databázových vzťahov,
• interných identifikátorov,
• aplikačnej logiky,
• ani väzieb medzi databázovými záznamami.

34. Pri selektívnej obnove dát je preto nevyhnutná primeraná súčinnosť Zákazníka alebo správcu jeho aplikácie.
35. Záloha databázy nemusí automaticky zahŕňať:

• externé databázy,
• databázy hostované u tretej strany,
• databázy mimo rozsahu objednanej služby,
• lokálne databázy na zariadení Zákazníka,
• cache alebo dočasné databázy,
• databázy, ku ktorým zálohovací systém nemá technický prístup.

36. Ak aplikácia používa viac databáz, nemusí byť každá z nich súčasťou rovnakého zálohovacieho procesu.
37. Zákazník je povinný overiť, či sú všetky databázy nevyhnutné na prevádzku jeho aplikácie zahrnuté do rozsahu zálohovania.
38. Záloha databázy nemusí obsahovať dáta uložené mimo samotnej databázy, napríklad:

• súbory používateľov,
• obrázky,
• dokumenty,
• videá,
• externé objekty,
• súbory uložené na inom serveri.

39. Rovnako záloha webových súborov nemusí sama osebe obsahovať databázu.
40. Na úplnú obnovu aplikácie preto môže byť potrebná kombinácia viacerých samostatných záloh.
41. Záloha databázy môže obsahovať databázu v stave, ktorý bol chybný už pred vytvorením zálohy.
42. Môže ísť napríklad o:

• nesprávne údaje,
• poškodené aplikačné záznamy,
• chybné databázové zmeny,
• neoprávnené úpravy,
• dáta zasiahnuté bezpečnostným incidentom.

43. Zálohovací systém spravidla neposudzuje vecnú správnosť jednotlivých údajov uložených v databáze.
44. Vytvorenie zálohy preto nepredstavuje potvrdenie WebHouse, že obsah databázy je:

• správny,
• úplný z obchodného hľadiska,
• bez škodlivého obsahu,
• alebo v súlade s aplikačnou logikou Zákazníka.

45. Ak bola databáza kompromitovaná už pred vytvorením zálohy, môže byť rovnaký kompromitovaný stav obsiahnutý aj v zálohe.
46. To môže zahŕňať napríklad:

• neoprávnene vytvorené administrátorské účty,
• zmenené heslá,
• vložené škodlivé dáta,
• zmenené nastavenia,
• alebo odstránené záznamy.

47. Obnova databázy preto sama osebe neznamená odstránenie príčiny bezpečnostného incidentu.
48. Po obnove databázy je Zákazník povinný vykonať primerané kontroly a bezpečnostné opatrenia v rozsahu svojej zodpovednosti.
49. Obnova databázy nemusí byť možná do ľubovoľnej verzie databázového systému.
50. Kompatibilita zálohy môže závisieť najmä od:

• typu databázového systému,
• jeho verzie,
• spôsobu vytvorenia zálohy,
• použitých dátových typov,
• používaných funkcií,
• collation alebo character setu,
• interného formátu zálohy.

51. WebHouse negarantuje, že historická záloha bude bez ďalšej úpravy kompatibilná s ľubovoľnou budúcou alebo externou databázovou platformou.
52. Ak bola služba medzičasom migrovaná na novšiu databázovú technológiu, môže byť pri obnove potrebná:

• konverzia,
• import,
• úprava exportu,
• alebo iný technický postup.

53. Takáto technická potreba sama osebe neznamená, že pôvodná záloha bola chybná.
54. Ak Zákazník požaduje export databázy na použitie mimo WebHouse, WebHouse poskytuje dáta iba vo formáte, ktorý je technicky dostupný alebo podporovaný príslušnou službou.
55. WebHouse nie je povinný konvertovať databázu do ľubovoľného formátu požadovaného Zákazníkom.
56. Konverzia alebo migrácia databázy môže byť poskytovaná ako samostatná alebo spoplatnená služba.
57. Pri veľkých databázach môže zálohovanie alebo obnova trvať dlhšie než pri bežných databázach.
58. Čas zálohovania a obnovy môže závisieť najmä od:

• veľkosti databázy,
• počtu tabuliek,
• počtu záznamov,
• množstva indexov,
• frekvencie zápisov,
• technológie zálohy,
• zaťaženia servera,
• rýchlosti úložiska.

59. Samotná existencia databázovej zálohy neznamená, že jej obnova bude vykonaná v konkrétnom čase, pokiaľ nie je pri službe výslovne dohodnuté RTO.
60. Pri veľmi aktívnych databázach môže samotné vytváranie zálohy ovplyvniť výkon služby.
61. WebHouse môže preto zálohovacie procesy:

• časovo plánovať,
• obmedzovať ich intenzitu,
• rozdeliť ich do viacerých fáz,
• alebo použiť technológiu minimalizujúcu dopad na produkčný systém.

62. Ak je to potrebné na ochranu stability produkčnej služby, môže mať zachovanie jej bezpečnej prevádzky prednosť pred presným časom spustenia zálohovacej úlohy.
63. Pri databázach môže dôjsť k technickému zlyhaniu zálohy napríklad v dôsledku:

• poškodenia databázy,
• poškodenia tabuľky,
• nedostatku systémových zdrojov,
• chyby databázového servera,
• chyby úložiska,
• nedostupnosti databázovej služby,
• nekonzistentného technického stavu.

64. Ak zálohovací systém zistí chybu, WebHouse môže podľa technických možností:

• zopakovať zálohovací proces,
• použiť alternatívny mechanizmus,
• použiť starší dostupný bod obnovy,
• alebo vykonať iný primeraný zásah.

65. WebHouse však negarantuje úspešnú rekonštrukciu databázy, ktorá bola už v produkčnom prostredí technicky poškodená spôsobom znemožňujúcim jej riadne zálohovanie.
66. Ak Zákazník prevádzkuje databázu na nespravovanom VPS alebo dedikovanom serveri a zálohovanie databázy nie je súčasťou objednanej služby, zodpovedá za jej zálohovanie Zákazník.
67. Samotné zálohovanie celého virtuálneho disku nemusí predstavovať databázovo konzistentnú zálohu, ak konkrétna služba výslovne nezabezpečuje aplikačne alebo databázovo konzistentný mechanizmus.
68. Snapshot bežiaceho servera môže zachytiť stav databázy odlišným spôsobom než databázový export vytvorený priamo databázovým systémom.
69. Zákazník, ktorý potrebuje garantovanú databázovú konzistenciu, je povinný používať zálohovaciu službu, ktorá takýto parameter výslovne poskytuje.
70. Pred vykonaním významnej databázovej operácie by mal Zákazník vytvoriť vlastný aktuálny bod obnovy, ak to technológia umožňuje.
71. Ide najmä o operácie ako:

• hromadné DELETE alebo UPDATE,
• zmena databázovej schémy,
• migrácia,
• import veľkého množstva dát,
• upgrade aplikácie,
• manuálny zásah administrátora,
• optimalizácia alebo reštrukturalizácia databázy.

72. Zákazník nesmie predpokladať, že automatická záloha bola vytvorená bezprostredne pred jeho zásahom.
73. Ak Zákazník potrebuje presný stav pred vykonaním rizikovej operácie, mal by si vytvoriť samostatnú zálohu alebo export databázy.
74. Po obnove databázy je Zákazník povinný primerane preveriť:

• úplnosť požadovaných dát,
• funkčnosť aplikácie,
• správnosť databázového spojenia,
• existenciu očakávaných tabuliek a záznamov,
• bezpečnostný stav databázy.

75. Ak Zákazník zistí nedostatok, mal by ho oznámiť bez zbytočného odkladu, kým môžu byť dostupné ďalšie historické body obnovy.
76. WebHouse nemusí byť schopný určiť, ktorý bod obnovy obsahuje posledný vecne správny alebo funkčný stav databázy.
77. WebHouse spravidla nevie, kedy:

• Zákazník vykonal chybnú zmenu,
• vznikla aplikačná chyba,
• bol odstránený konkrétny záznam,
• došlo ku kompromitácii.

78. Určenie vhodného bodu obnovy preto môže vyžadovať súčinnosť Zákazníka.
79. Ak Zákazník nevie určiť presný čas incidentu, WebHouse môže podľa dostupnosti poskytnúť informáciu o existujúcich bodoch obnovy, ale negarantuje, že konkrétny bod obsahuje požadovaný vecný stav.
80. Ak databázová obnova vyžaduje manuálny zásah WebHouse nad rámec štandardnej služby, môže byť takýto zásah spoplatnený podľa aktuálneho cenníka.
81. Ak je obnova potrebná v dôsledku preukázanej poruchy alebo vady služby na strane WebHouse, jej posúdenie sa riadi zmluvnými podmienkami, Reklamačným poriadkom a príslušnými právnymi predpismi.
82. Samotná existencia poškodenej databázy alebo chýbajúceho databázového záznamu automaticky neznamená poruchu zálohovacej služby.
83. Pri posúdení sa prihliada najmä na:

• príčinu poškodenia alebo straty dát,
• dohodnutý rozsah zálohovania,
• frekvenciu záloh,
• retenčnú politiku,
• dostupnosť bodov obnovy,
• technické okolnosti konkrétneho incidentu.

84. Zálohovanie databáz nenahrádza vlastnú zálohovaciu stratégiu Zákazníka pri kritických alebo nenahraditeľných databázových dátach.
85. Pri databázach s vysokou frekvenciou zmien alebo vysokou obchodnou hodnotou je Zákazník povinný primerane zvážiť:

• kratšie RPO,
• viacúrovňové zálohovanie,
• nezávislé externé zálohy,
• dlhšiu retenciu,
• point-in-time recovery,
• pravidelné testovanie obnovy.

86. Štandardná hostingová databázová záloha nemusí poskytovať všetky uvedené vlastnosti.
87. Ak ich Zákazník potrebuje, je povinný zvoliť zodpovedajúcu službu alebo individuálne riešenie.
88. Individuálne dohodnuté parametre zálohovania databáz majú v rozsahu konkrétnej dohody prednosť pred všeobecnými ustanoveniami tohto článku.
89. WebHouse je povinný dodržať rozsah a parametre databázového zálohovania, ktoré boli pri konkrétnej službe výslovne dohodnuté.
90. Povinnosť Zákazníka vytvárať vlastné zálohy kritických databáz nezbavuje WebHouse zodpovednosti za riadne poskytovanie zálohovacej služby v dohodnutom rozsahu.
91. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 14

E-mailové schránky

1. Ak konkrétna e-mailová služba zahŕňa zálohovanie e-mailových schránok, rozsah, frekvencia, retenčná doba a spôsob obnovy sa riadia parametrami tejto služby.
2. Zálohovanie e-mailovej schránky sa spravidla vzťahuje iba na dáta, ktoré sa v čase vytvárania príslušného bodu obnovy nachádzajú na serveroch WebHouse a patria do rozsahu zálohovanej služby.
3. Záloha e-mailovej schránky môže podľa konkrétnej technológie zahŕňať najmä:
   • prijaté e-mailové správy,
   • odoslané správy uložené na serveri,
   • používateľské priečinky,
   • systémové priečinky,
   • prílohy uložené ako súčasť správ,
   • prípadne ďalšie serverové dáta schránky podľa parametrov služby.
4. Skutočnosť, že e-mailová služba obsahuje zálohovanie, neznamená automaticky, že sú zálohované všetky údaje súvisiace s používaním e-mailového účtu.
5. Zálohovanie nemusí zahŕňať najmä:
   • lokálne e-mailové archívy,
   • lokálne PST, OST, MBOX alebo obdobné súbory,
   • správy uložené iba v e-mailovom klientovi,
   • lokálne kontakty,
   • lokálne kalendáre,
   • lokálne poznámky alebo úlohy,
   • dáta uložené iba na počítači, mobilnom telefóne alebo inom zariadení Zákazníka,
   • obsah externých e-mailových služieb,
   • dáta uložené u iného poskytovateľa.
6. WebHouse nemôže zálohovať dáta, ktoré sa v príslušnom čase na jeho serveroch nenachádzajú.
7. Ak Zákazník používa protokol alebo konfiguráciu, pri ktorej sa správy po prevzatí zo servera odstránia, nemusí byť možné takéto správy zahrnúť do neskôr vytvorených záloh.
8. To sa môže týkať najmä používania POP3 s nastavením odstraňovania správ zo servera po ich stiahnutí.
9. Ak bola správa zo servera odstránená pred vytvorením najstaršieho dostupného bodu obnovy, nemusí už existovať žiadna dostupná záloha obsahujúca túto správu.
10. Skutočnosť, že správa bola v minulosti doručená do schránky, preto sama osebe neznamená, že ju bude možné kedykoľvek neskôr obnoviť.
11. Zálohovanie e-mailových schránok podlieha rovnako ako ostatné zálohy retenčnému a rotačnému mechanizmu.
12. Správy odstránené zo schránky môžu určitý čas zostať obsiahnuté v starších bodoch obnovy, ale iba dovtedy, kým tieto body zostávajú v rámci štandardnej retenčnej politiky.
13. Po ich odstránení alebo prepísaní v rámci rotácie nemusí byť možné staršie e-mailové správy obnoviť.
14. Záloha e-mailovej schránky nepredstavuje trvalý e-mailový archív.
15. Zákazník nesmie používať zálohu WebHouse ako jediný systém dlhodobého uchovávania e-mailovej komunikácie, ak potrebuje správy zachovať:

• z právnych dôvodov,
• z účtovných dôvodov,
• na účely auditu,
• na účely interného archívu,
• alebo počas obdobia dlhšieho než retenčná doba služby.

16. Ak Zákazník potrebuje dlhodobú archiváciu e-mailovej komunikácie, je povinný použiť vhodný archivačný systém alebo samostatnú službu určenú na tento účel.
17. Záloha e-mailovej schránky nemusí umožňovať vyhľadanie a obnovenie jednej konkrétnej správy.
18. Technická jednotka zálohy môže predstavovať napríklad:

• celú schránku,
• celý priečinok,
• určitý dátový objekt,
• alebo celý stav e-mailového úložiska v určitom bode obnovy.

19. WebHouse preto nie je povinný poskytovať selektívnu obnovu jednej konkrétnej správy, ak ju použitá zálohovacia technológia nepodporuje.
20. Štandardná obnova môže zahŕňať najmä:

• obnovenie celej schránky,
• obnovenie vybraného priečinka,
• obnovenie dostupného historického stavu schránky,
• obnovenie do samostatného dočasného priestoru,
• alebo inú technicky podporovanú formu obnovy.

21. Možnosť obnovy jednotlivého priečinka závisí od konkrétnej technológie a nemusí byť dostupná pri každej službe.
22. Ak Zákazník požaduje jednu konkrétnu správu a zálohovací systém podporuje iba obnovu celej schránky alebo väčšieho celku, môže byť potrebné:

• obnoviť historickú kópiu schránky do dočasného priestoru,
• následne požadovanú správu manuálne vyhľadať,
• a potom ju samostatne sprístupniť Zákazníkovi.

23. Takýto postup môže predstavovať nadštandardný administrátorský zásah.
24. Individuálne vyhľadávanie konkrétnej e-mailovej správy v zálohách môže byť:

• technicky nemožné,
• neprimerane časovo náročné,
• alebo spoplatnené podľa aktuálneho cenníka alebo individuálnej dohody.

25. WebHouse nemusí vykonávať obsahové vyhľadávanie správ podľa:

• textu správy,
• obsahu prílohy,
• interných obchodných údajov,
• alebo iného kritéria, ktoré zálohovací systém nepodporuje.

26. Ak Zákazník potrebuje konkrétnu správu, mal by podľa možností poskytnúť čo najpresnejšie údaje, najmä:

• približný dátum alebo čas,
• odosielateľa,
• príjemcu,
• predmet správy,
• názov priečinka,
• približný čas jej odstránenia.

27. Ani poskytnutie týchto údajov však negarantuje, že bude možné konkrétnu správu identifikovať alebo obnoviť.
28. WebHouse nemusí byť schopný určiť, v ktorom bode obnovy sa konkrétna správa nachádza.
29. Ak Zákazník nevie určiť približný čas odstránenia správy, môže byť potrebné preveriť viac historických bodov obnovy.
30. Takýto rozsiahlejší zásah môže byť spoplatnený podľa skutočného rozsahu administrátorskej práce.
31. Obnova celej e-mailovej schránky do pôvodného produkčného umiestnenia môže viesť k prepísaniu alebo zmene aktuálneho obsahu schránky.
32. Pri takejto obnove môže vzniknúť riziko straty novších správ, ktoré boli prijaté alebo vytvorené po dátume zvoleného bodu obnovy.
33. WebHouse môže preto pred úplnou obnovou schránky požadovať potvrdenie Zákazníka, že rozumie dôsledkom obnovy staršieho stavu.
34. Ak to technické možnosti umožňujú, WebHouse môže uprednostniť obnovu do:

• dočasnej schránky,
• samostatného priestoru,
• alebo iného oddeleného prostredia,

aby sa znížilo riziko prepísania aktuálnych e-mailov.

35. Poskytnutie takéhoto dočasného priestoru nie je automaticky garantované pri každej službe.
36. Dočasná obnovená schránka alebo priestor môže byť:

• časovo obmedzený,
• kapacitne obmedzený,
• určený iba na export alebo kontrolu dát.

37. WebHouse môže po uplynutí určenej doby dočasne obnovené dáta odstrániť.
38. Zákazník je povinný potrebné správy alebo dáta z dočasného priestoru včas prevziať alebo exportovať.
39. Záloha e-mailovej schránky nemusí zachovať všetky serverové metadáta presne v stave pôvodnej schránky.
40. V závislosti od použitej technológie nemusí obnova zachovať napríklad:

• všetky interné identifikátory správ,
• stav prečítania,
• označenia správ,
• niektoré používateľské príznaky,
• poradie zobrazovania,
• iné technické metadáta.

41. Rozhodujúce je, aký rozsah dát a metadát podporuje konkrétna zálohovacia služba.
42. Obnova správy alebo schránky automaticky neznamená obnovenie všetkých súvisiacich nastavení e-mailového účtu.
43. Zálohovanie obsahu schránky nemusí automaticky zahŕňať:

• heslo e-mailového účtu,
• aliasy,
• presmerovania,
• automatické odpovede,
• filtre,
• antispamové pravidlá,
• whitelisty alebo blacklisty,
• iné nastavenia e-mailovej služby.

44. Tieto nastavenia môžu byť:

• zálohované iným mechanizmom,
• rekonštruované zo systémovej konfigurácie,
• alebo nemusia byť súčasťou zálohy používateľských dát.

45. Obnova schránky preto nemusí automaticky obnoviť všetky nastavenia služby do historického stavu.
46. Zákazník nesmie predpokladať, že obnovením historickej schránky dôjde automaticky aj k obnove historickej konfigurácie:

• presmerovania,
• filtrov,
• antispamu,
• alebo iných funkcií.

47. Záloha schránky zachytáva stav dát dostupných v príslušnom bode obnovy, nie kompletnú históriu všetkých e-mailových udalostí.
48. Zálohovací systém preto nemusí obsahovať samostatný záznam každej:

• prijatej správy,
• odstránenej správy,
• presunutej správy,
• zmeny priečinka,
• alebo používateľského zásahu.

49. Ak správa vznikla a bola odstránená medzi dvoma bodmi obnovy, nemusí sa nachádzať v žiadnej zálohe.
50. Napríklad správa prijatá o 10:00 a odstránená o 11:00 sa nemusí nachádzať v zálohe vytvorenej o 02:00 ani v ďalšej zálohe vytvorenej až nasledujúcu noc.
51. Samotná frekvencia zálohovania preto určuje aj praktickú pravdepodobnosť zachytenia krátkodobo existujúcich dát.
52. WebHouse negarantuje obnovu každej správy, ktorá sa kedy nachádzala v schránke, pokiaľ takýto parameter nie je pri konkrétnej službe výslovne uvedený.
53. Zálohovanie schránky nemusí obsahovať správu, ktorá bola:

• odmietnutá ešte pred doručením do schránky,
• zablokovaná antispamovým alebo bezpečnostným systémom,
• nedoručená z dôvodu chyby odosielateľa,
• doručená do iného systému,
• alebo nikdy uložená na serveroch WebHouse.

54. Záloha preto nie je nástrojom na obnovenie správy, ktorú e-mailový systém nikdy neprijal alebo neuložil.
55. Rovnako nie je záloha určená ako náhrada e-mailových logov.
56. Logy prenosu e-mailov a obsah e-mailových schránok predstavujú odlišné technické údaje a môžu mať rozdielnu retenčnú dobu.
57. Existencia logového záznamu o doručení správy automaticky neznamená, že obsah tejto správy je dostupný v zálohe.
58. Rovnako existencia správy v zálohe nemusí znamenať, že bude dostupný kompletný historický prenosový log.
59. Obnova e-mailovej správy neznamená jej opätovné doručenie pôvodným protokolom SMTP.
60. Správa môže byť obnovená priamo do schránky alebo sprístupnená iným technickým spôsobom.
61. Obnovená správa preto môže mať niektoré lokálne alebo serverové charakteristiky odlišné od stavu bezprostredne po pôvodnom doručení.
62. Zálohovanie e-mailovej služby neznamená automatickú ochranu pred následkami kompromitácie e-mailového účtu.
63. Ak útočník získa prístup k schránke, môže:

• odstrániť správy,
• presunúť správy,
• zmeniť nastavenia,
• vytvoriť presmerovanie,
• alebo vykonať iný neoprávnený zásah.

64. Ak sa kompromitácia zistí neskoro, môže sa kompromitovaný stav nachádzať vo viacerých novších bodoch obnovy.
65. Starší bod spred incidentu môže byť medzičasom odstránený v rámci štandardnej rotácie.
66. Zákazník je preto povinný pri podozrení na kompromitáciu schránky kontaktovať WebHouse bez zbytočného odkladu.
67. WebHouse môže v odôvodnenom prípade podľa technických možností:

• pozastaviť ďalšiu rotáciu vybraného bodu,
• zachovať dostupný historický stav,
• dočasne obmedziť prístup k schránke,
• alebo vykonať iné primerané bezpečnostné opatrenie.

68. WebHouse však negarantuje, že pri každom incidente bude možné zachovať čistý bod obnovy spred kompromitácie.
69. Obnova schránky neodstraňuje automaticky príčinu kompromitácie.
70. Po obnove môže byť potrebné najmä:

• zmeniť heslo,
• zrušiť neoprávnené presmerovania,
• skontrolovať filtre,
• preveriť zariadenia Zákazníka,
• odstrániť škodlivý softvér,
• zmeniť ďalšie kompromitované prístupové údaje.

71. Zákazník zodpovedá za bezpečnosť svojich zariadení, hesiel a e-mailových klientov v rozsahu podľa pravidiel bezpečnosti služieb.
72. Zálohovanie schránky nenahrádza povinnosť Zákazníka chrániť prístup k e-mailovému účtu.
73. Po obnove je Zákazník povinný bez zbytočného odkladu preveriť, či obnovená schránka obsahuje požadované dáta.
74. Ak požadované dáta chýbajú, Zákazník by mal túto skutočnosť oznámiť čo najskôr, pretože ďalšie historické body obnovy môžu byť v rámci rotácie postupne odstránené.
75. WebHouse nemusí byť schopný určiť, ktorý bod obnovy obsahuje posledný požadovaný stav schránky, ak nie je známy čas odstránenia alebo poškodenia dát.
76. Výber vhodného bodu obnovy preto môže vyžadovať súčinnosť Zákazníka.
77. Doba potrebná na obnovu e-mailovej schránky môže závisieť najmä od:

• veľkosti schránky,
• počtu správ,
• počtu priečinkov,
• typu zálohovacieho systému,
• rozsahu požadovanej obnovy,
• počtu bodov, ktoré je potrebné preveriť,
• aktuálneho zaťaženia systému.

78. Samotná existencia zálohy schránky neznamená garantovanú dobu obnovy, pokiaľ pri konkrétnej službe nie je výslovne dohodnuté RTO.
79. Manuálna obnova e-mailovej schránky môže byť podľa konkrétnej služby:

• zahrnutá v cene,
• poskytovaná v obmedzenom rozsahu,
• alebo spoplatnená ako administrátorský zásah.

80. Najmä individuálne vyhľadávanie jednej správy, preverovanie viacerých historických bodov alebo selektívny export môže byť spoplatnený podľa rozsahu práce.
81. Ak je obnova potrebná v dôsledku preukázanej vady alebo poruchy služby na strane WebHouse, jej posúdenie a prípadné spoplatnenie sa riadi príslušnými zmluvnými podmienkami, Reklamačným poriadkom a právnymi predpismi.
82. Ak je obnova potrebná napríklad v dôsledku:

• náhodného odstránenia správy Zákazníkom,
• odstránenia celej schránky,
• nesprávneho nastavenia e-mailového klienta,
• kompromitácie používateľského účtu,
• zásahu tretej osoby,
• alebo inej udalosti mimo zodpovednosti WebHouse,

manuálna obnova môže byť spoplatnená podľa aktuálneho cenníka.

83. Jednorazová bezplatná pomoc WebHouse pri obnove alebo vyhľadaní e-mailu nevytvára nárok na rovnaký rozsah bezplatnej pomoci v budúcnosti.
84. Zákazník s e-mailovou komunikáciou s vysokým právnym, finančným alebo obchodným významom je povinný primerane posúdiť, či štandardná retenčná politika e-mailovej služby zodpovedá jeho potrebám.
85. Ak potrebuje:

• dlhodobé uchovávanie všetkých správ,
• nemennosť správ,
• auditovateľnú históriu,
• právnu archiváciu,
• rozsiahle fulltextové vyhľadávanie,
• alebo osobitné retenčné pravidlá,

bežné zálohovanie e-mailovej schránky nemusí byť vhodným riešením.

86. V takom prípade je Zákazník povinný použiť samostatnú e-mailovú archivačnú službu alebo iné vhodné riešenie.
87. Záloha poskytovaná WebHouse nemá byť jedinou kópiou kritickej alebo nenahraditeľnej e-mailovej komunikácie Zákazníka.
88. Ak má e-mailová komunikácia pre Zákazníka kritický význam, mal by primerane používať aj nezávislé archivovanie alebo zálohovanie.
89. Rozsah zálohovania konkrétnej e-mailovej služby je vždy určený parametrami objednanej služby.
90. Samotná technická existencia inej internej kópie e-mailových dát nezakladá Zákazníkovi nárok na jej zachovanie, sprístupnenie alebo obnovu, ak nie je súčasťou zmluvne dohodnutých parametrov služby.
91. WebHouse je povinný dodržiavať rozsah a parametre zálohovania e-mailových schránok, ktoré boli pri konkrétnej službe výslovne dohodnuté.
92. Povinnosť Zákazníka zabezpečiť vlastnú ochranu kritickej e-mailovej komunikácie nezbavuje WebHouse zodpovednosti za riadne poskytovanie dohodnutej zálohovacej služby.
93. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 15

POP3 a lokálne uložené správy

1. WebHouse môže zálohovať iba tie e-mailové správy a súvisiace dáta, ktoré sa v čase vytvárania príslušnej zálohy nachádzajú na serveroch WebHouse a patria do rozsahu zálohovanej e-mailovej služby.
2. WebHouse nemôže zálohovať e-mailovú správu, ktorá sa v čase zálohovania už na serveri WebHouse nenachádza.
3. Ak Zákazník používa e-mailový protokol POP3, e-mailový klient môže byť nastavený tak, že po stiahnutí správy:
   • ponechá jej kópiu na serveri,
   • ponechá ju na serveri iba určitý čas,
   • alebo ju zo servera okamžite odstráni.
4. Konkrétne správanie závisí od nastavenia e-mailového klienta Zákazníka.
5. Ak je POP3 klient nastavený tak, že správy po stiahnutí zo servera odstraňuje, môžu sa tieto správy následne nachádzať už iba:
   • v počítači Zákazníka,
   • v mobilnom zariadení,
   • v lokálnom e-mailovom archíve,
   • alebo v inom úložisku spravovanom Zákazníkom.
6. Po odstránení správy zo servera WebHouse už táto správa nebude zahrnutá do záloh vytvorených po jej odstránení.
7. Ak správa nebola zachytená v žiadnom staršom bode obnovy, nemusí byť možné ju zo zálohovacieho systému WebHouse vôbec obnoviť.
8. Skutočnosť, že správa bola prostredníctvom servera WebHouse v minulosti prijatá alebo doručená do schránky, sama osebe neznamená, že jej obsah bude neskôr dostupný v zálohe.

9. Ak napríklad:

   • správa príde na server o 10:00,
   • POP3 klient ju o 10:05 stiahne a zo servera odstráni,
   • a ďalšia záloha schránky vznikne až neskôr,

   táto správa sa nemusí dostať do žiadneho bodu obnovy WebHouse.

10. Zálohovací systém nie je priebežnou evidenciou každej správy, ktorá sa kedy krátkodobo nachádzala v e-mailovej schránke.
11. Zákazník preto nesmie predpokladať, že správy odstránené POP3 klientom budú automaticky dostupné v zálohách WebHouse.
12. Ak POP3 klient ponecháva kópiu správ na serveri iba počas určitého času, dostupnosť správ v zálohách závisí aj od:

• času doručenia správy,
• času jej odstránenia zo servera,
• frekvencie zálohovania,
• dostupných bodov obnovy,
• retenčnej politiky.

13. Ani nastavenie „ponechať správu na serveri X dní“ samo osebe negarantuje, že všetky takéto správy budú zachytené v konkrétnom bode obnovy.
14. Ak chce Zákazník zvýšiť pravdepodobnosť, že správy zostanú dostupné aj na serveri a v jeho zálohách, je vhodné používať konfiguráciu, pri ktorej sa správy zo servera automaticky neodstraňujú bez potreby.
15. Pri používaní protokolu IMAP spravidla zostávajú správy uložené na serveri a e-mailový klient s nimi pracuje synchronizovane.
16. Ani používanie IMAP však neznamená, že správa bude uchovávaná neobmedzene.
17. Ak Zákazník alebo jeho e-mailový klient správu zo servera prostredníctvom IMAP odstráni a odstránenie sa synchronizuje so serverom, správa môže byť následne odstránená aj z produkčnej schránky.
18. Takáto správa môže zostať dostupná iba v starších zálohách a len počas ich príslušnej retenčnej doby.
19. Rozdiel medzi POP3 a IMAP preto nemení základnú zásadu, že WebHouse môže zálohovať iba dáta, ktoré sa nachádzajú v zálohovanom serverovom prostredí v čase zachytenom príslušným bodom obnovy.
20. WebHouse nezodpovedá za lokálne uložené e-mailové správy alebo iné dáta, ktoré sa nachádzajú iba na zariadeniach Zákazníka.
21. Ide najmä o správy a dáta uložené:

• v lokálnom e-mailovom klientovi,
• v súboroch PST,
• v súboroch OST,
• v súboroch MBOX,
• v lokálnom profile používateľa,
• na počítači,
• na notebooku,
• na mobilnom telefóne,
• na tablete,
• na externom disku,
• alebo inom zariadení Zákazníka.

22. WebHouse nemá technickú kontrolu nad týmito zariadeniami a štandardná e-mailová zálohovacia služba ich obsah nezálohuje.
23. Zákazník zodpovedá za vytváranie vlastných záloh lokálne uložených e-mailových správ.
24. Zákazník je povinný primerane zabezpečiť najmä dáta, ktoré po odstránení zo servera existujú už iba v jeho lokálnom zariadení.
25. Ak lokálne uložená správa predstavuje jedinú existujúcu kópiu, jej strata v dôsledku:

• poruchy disku,
• poškodenia počítača,
• zmazania používateľského profilu,
• ransomvéru,
• poškodenia e-mailového klienta,
• odcudzenia zariadenia,
• alebo inej udalosti

nemusí byť odstrániteľná obnovou zo záloh WebHouse.

26. Zákazník by mal pri dôležitej lokálne uchovávanej e-mailovej komunikácii používať primeraný zálohovací mechanizmus svojho zariadenia alebo e-mailových dát.
27. Takáto záloha môže zahŕňať napríklad:

• zálohu používateľského profilu,
• zálohu dát e-mailového klienta,
• export e-mailov,
• zálohu celého zariadenia,
• externú alebo cloudovú zálohu.

28. Konkrétny spôsob vlastného zálohovania si volí a spravuje Zákazník.
29. WebHouse nezodpovedá za správnosť nastavenia:

• Microsoft Outlook,
• Mozilla Thunderbird,
• Apple Mail,
• mobilného e-mailového klienta,
• alebo iného programu používaného Zákazníkom,

pokiaľ nejde o zásah vykonaný WebHouse v rámci osobitne dohodnutej služby.

30. WebHouse rovnako nezodpovedá za následky nastavenia e-mailového klienta Zákazníka, ktorý automaticky odstraňuje správy zo servera.
31. Ak Zákazník zmení e-mailového klienta, zariadenie alebo nastavenie účtu, je povinný preveriť, či zvolená konfigurácia:

• ponecháva správy na serveri,
• odstraňuje správy zo servera,
• alebo uchováva jedinú kópiu lokálne.

32. Zákazník by mal takejto kontrole venovať zvýšenú pozornosť najmä pri konfigurácii POP3.
33. Ak rovnakú schránku používa viac zariadení alebo používateľov, môže nastavenie jedného POP3 klienta ovplyvniť dostupnosť správ pre ostatných.
34. Ak jedno zariadenie po stiahnutí správ odstráni ich serverové kópie, ostatné zariadenia už tieto správy nemusia zo servera prevziať.
35. Takýto stav nie je poruchou e-mailovej služby WebHouse, ak server vykonal pokyn e-mailového klienta v súlade s použitým protokolom a nastavením.
36. WebHouse spravidla nevie posúdiť, či odstránenie konkrétnej správy zo servera bolo:

• úmyselné,
• neúmyselné,
• spôsobené používateľom,
• alebo automatickým nastavením jeho e-mailového klienta.

37. Ak Zákazník nahlási chýbajúce správy, WebHouse môže podľa dostupných technických údajov preveriť stav serverovej služby a dostupné body obnovy.
38. WebHouse však negarantuje, že bude možné spätne zrekonštruovať presný spôsob, akým lokálny e-mailový klient so správou nakladal.
39. Samotná existencia záznamu o prihlásení cez POP3 alebo IMAP nemusí umožniť určiť všetky konkrétne používateľské operácie so správou.
40. E-mailové logy zároveň nepredstavujú zálohu obsahu e-mailovej komunikácie.
41. Záznam, že určitá správa bola prijatá alebo prevzatá, preto nemusí znamenať, že WebHouse disponuje jej obsahom.
42. Ak bola správa odstránená zo servera, môže byť ešte určitý čas dostupná v staršom bode obnovy.
43. Táto možnosť závisí od:

• času jej odstránenia,
• času vytvorenia jednotlivých záloh,
• retenčnej doby,
• rotačnej politiky,
• použiteľnosti konkrétnych bodov obnovy.

44. WebHouse negarantuje obnovu správy iba na základe toho, že bola zo servera odstránená počas deklarovanej retenčnej doby.
45. Retenčná doba určuje dobu uchovávania existujúcich záloh; neznamená, že každá správa odstránená počas tejto doby musela byť pred odstránením zachytená v niektorej zálohe.
46. Ak je konkrétna správa dostupná v zálohe, jej individuálna obnova sa riadi pravidlami článku XIV.
47. Môže byť potrebná obnova:

• celej schránky,
• priečinka,
• historickej kópie schránky do dočasného priestoru,
• alebo iného väčšieho technického celku.

48. WebHouse negarantuje možnosť obnoviť jednu konkrétnu POP3 správu ako samostatnú položku.
49. Individuálne vyhľadávanie jednej správy môže byť technicky nemožné alebo spoplatnené podľa rozsahu administrátorského zásahu.
50. Pri dôležitej alebo právne významnej e-mailovej komunikácii by Zákazník nemal používať lokálny POP3 archív bez ďalšieho nezávislého zálohovania ako jediné miesto jej uchovania.
51. Ak je potrebné zabezpečiť dlhodobé uchovávanie e-mailovej komunikácie, je vhodné použiť:

• e-mailový archivačný systém,
• samostatnú dlhodobú zálohu,
• alebo inú službu určenú na archiváciu.

52. Bežný POP3 klient ani štandardná serverová záloha WebHouse nie sú automaticky službou právnej alebo dlhodobej e-mailovej archivácie.
53. Zákazník zodpovedá za posúdenie, či spôsob používania POP3 zodpovedá jeho požiadavkám na:

• dostupnosť správ,
• zálohovanie,
• synchronizáciu,
• archiváciu,
• bezpečnosť.

54. Ak strata lokálne uloženej e-mailovej komunikácie môže mať pre Zákazníka významné následky, Zákazník je povinný prijať primerané opatrenia na jej nezávislé zálohovanie.
55. Povinnosť Zákazníka zálohovať lokálne uložené správy nezbavuje WebHouse zodpovednosti za zálohovanie dát, ktoré sa podľa parametrov konkrétnej služby nachádzali na jeho serveroch a boli súčasťou dohodnutého rozsahu zálohovania.
56. Pri posudzovaní možnosti obnovy chýbajúcej správy je preto rozhodujúce najmä:

• či bola správa uložená na serveri,
• ako dlho tam bola uložená,
• kedy bola odstránená,
• či existuje bod obnovy z obdobia, keď sa na serveri nachádzala,
• a či je daný bod obnovy technicky použiteľný.

57. Samotná strata lokálnej kópie správy nepredstavuje poruchu služby WebHouse, ak sa príslušná správa už nenachádzala v rozsahu dát spravovaných alebo zálohovaných WebHouse.
58. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 16

Virtuálne servery

1. Zálohovanie virtuálnych serverov (ďalej len „VPS“) závisí od konkrétnej objednanej služby, jej technických parametrov a prípadne od samostatne objednanej zálohovacej služby.
2. Automatické zálohovanie nemusí byť súčasťou každého VPS.
3. Samotné poskytovanie virtuálneho servera neznamená, že WebHouse automaticky vytvára alebo uchováva zálohy jeho obsahu.
4. Zákazník je povinný pred začatím používania VPS preveriť najmä:
   • či je VPS zálohovaný,
   • aký rozsah dát je zálohovaný,
   • akým technickým spôsobom sa záloha vytvára,
   • ako často sa záloha vytvára,
   • aká je retenčná doba,
   • koľko bodov obnovy je dostupných,
   • aký spôsob obnovy služba umožňuje.
5. Ak zálohovanie nie je výslovne uvedené ako súčasť služby alebo osobitne objednané, zodpovedá za vytvorenie a správu záloh VPS Zákazník.
6. Zálohovanie VPS môže byť podľa konkrétnej služby realizované najmä ako:
   • záloha celej virtuálnej inštancie,
   • záloha virtuálneho disku,
   • snapshot virtuálneho servera,
   • záloha vybraných virtuálnych diskov,
   • záloha prostredníctvom agenta vo vnútri operačného systému,
   • záloha vybraných súborov alebo dát,
   • kombinácia uvedených mechanizmov.
7. Jednotlivé spôsoby zálohovania majú rozdielne technické vlastnosti a nemusia poskytovať rovnaké možnosti obnovy.
8. Pri zálohe celej virtuálnej inštancie môže byť štandardnou jednotkou obnovy celý virtuálny server.

9. Takáto obnova môže zahŕňať najmä:

   • virtuálne disky,
   • operačný systém,
   • nainštalovaný softvér,
   • systémové konfigurácie,
   • používateľské dáta nachádzajúce sa na zahrnutých virtuálnych diskoch,

   v rozsahu podporovanom konkrétnym zálohovacím mechanizmom.

10. Záloha celej virtuálnej inštancie nemusí automaticky zahŕňať všetky technické prvky súvisiace s VPS.
11. Podľa konkrétnej architektúry nemusia byť súčasťou zálohy najmä:

• externé alebo pripojené úložiská,
• samostatné dátové disky nezahrnuté do zálohovacej politiky,
• objektové úložiská,
• externé databázy,
• služby tretích strán,
• DNS,
• externé licencie,
• externé zálohovacie úložiská.

12. Ak VPS používa viac virtuálnych diskov, zálohované môžu byť iba tie disky, ktoré sú podľa parametrov konkrétnej služby zahrnuté do zálohovania.
13. Zákazník je povinný preveriť, či sú všetky disky alebo dátové priestory kritické pre jeho prevádzku zahrnuté do rozsahu zálohovania.
14. Pri obnove celej virtuálnej inštancie môže byť VPS obnovený do stavu zodpovedajúceho dostupnému bodu obnovy.
15. Takáto obnova môže prepísať celý aktuálny stav virtuálneho servera vrátane zmien vykonaných po vytvorení zvoleného bodu obnovy.
16. Môže tým dôjsť k strate novších:

• súborov,
• databáz,
• e-mailov,
• konfigurácií,
• používateľských účtov,
• systémových aktualizácií,
• logov,
• alebo iných zmien vykonaných po vytvorení zálohy.

17. WebHouse môže pred úplnou obnovou VPS požadovať výslovné potvrdenie Zákazníka, že rozumie dôsledkom prepísania aktuálneho stavu.
18. Ak to technické možnosti umožňujú, WebHouse môže VPS alebo jeho zálohu obnoviť:

• do pôvodnej virtuálnej inštancie,
• ako novú dočasnú virtuálnu inštanciu,
• do samostatného technického priestoru,
• alebo iným podporovaným spôsobom.

19. Obnova do samostatnej dočasnej inštancie môže byť vhodná najmä vtedy, ak je potrebné:

• porovnať historický a aktuálny stav,
• vybrať iba konkrétne súbory,
• preveriť databázu,
• skontrolovať stav systému pred jeho nasadením do produkcie.

20. Poskytnutie dočasnej virtuálnej inštancie závisí od technických možností, dostupných zdrojov a podmienok konkrétnej služby.
21. Dočasná obnovená inštancia môže byť:

• časovo obmedzená,
• kapacitne obmedzená,
• bez verejného sieťového prístupu,
• alebo určená iba na získanie dát.

22. WebHouse môže takúto dočasnú inštanciu po uplynutí určenej doby odstrániť.
23. Zákazník je povinný potrebné dáta z dočasnej obnovy včas prevziať.
24. Záloha celého VPS nemusí umožňovať selektívnu obnovu:

• jedného súboru,
• jedného adresára,
• jednej databázy,
• jednej tabuľky,
• jedného databázového záznamu,
• jednej konfigurácie.

25. Ak použitá technológia podporuje iba obnovu celej virtuálnej inštancie, WebHouse nie je povinný extrahovať jednotlivé dáta priamo zo zálohovacieho formátu.
26. Ak Zákazník potrebuje iba konkrétny súbor alebo inú časť dát, môže byť potrebné:

• obnoviť celý VPS do dočasnej inštancie,
• pripojiť obnovený virtuálny disk,
• alebo použiť iný technický postup na získanie požadovaných dát.

27. Takýto individuálny zásah môže byť spoplatnený podľa aktuálneho cenníka alebo rozsahu vykonanej administrátorskej práce.
28. Záloha VPS vytvorená na úrovni virtualizačnej platformy nemusí predstavovať aplikačne konzistentnú zálohu všetkých služieb bežiacich vo vnútri VPS.
29. To je významné najmä pri:

• databázových serveroch,
• mailových serveroch,
• transakčných systémoch,
• účtovných systémoch,
• iných aplikáciách, ktoré v čase zálohovania aktívne zapisujú dáta.

30. Záloha alebo snapshot virtuálneho disku môže zachytiť stav podobný náhlemu vypnutiu alebo inému bodu zachytenia úložiska podľa použitej technológie.
31. Takýto stav nemusí byť totožný so zálohou vytvorenou priamo databázovým alebo aplikačným zálohovacím mechanizmom.
32. Ak Zákazník potrebuje garantovanú aplikačnú alebo databázovú konzistenciu, musí používať zálohovanie, ktoré takúto vlastnosť výslovne podporuje.
33. Samotné označenie služby ako „záloha VPS“ neznamená automaticky garanciu databázovo konzistentnej zálohy.
34. Pri kritických databázach môže byť potrebné kombinovať zálohu celého VPS s:

• databázovým exportom,
• databázovým backup agentom,
• transakčnými logmi,
• point-in-time recovery,
• alebo iným mechanizmom primeraným konkrétnej databáze.

35. Za konfiguráciu takéhoto aplikačného zálohovania zodpovedá Zákazník, pokiaľ nie je výslovne súčasťou spravovanej služby WebHouse.
36. Pri nespravovanom VPS zodpovedá Zákazník najmä za:

• operačný systém,
• databázový systém,
• webový server,
• e-mailový server,
• aplikácie,
• konfigurácie,
• aplikačné zálohovanie,
• overenie použiteľnosti svojich vlastných záloh,

ak nie je pri konkrétnej službe dohodnuté inak.

37. Záloha vytváraná WebHouse na úrovni celej virtuálnej inštancie nemení rozdelenie zodpovednosti za správu softvéru vo vnútri nespravovaného VPS.
38. WebHouse preto pri štandardnej zálohe celej VM nemusí kontrolovať:

• funkčnosť databázy,
• správnosť aplikačných dát,
• stav webovej aplikácie,
• úspešnosť interných cron úloh,
• správnosť zákazníckych skriptov,
• ani aplikačnú konzistenciu jednotlivých služieb.

39. Úspešné vytvorenie zálohy VPS nepredstavuje potvrdenie, že všetky aplikácie vo vnútri virtuálneho servera sú funkčné alebo v bezchybnom stave.
40. Záloha môže obsahovať rovnaký chybný alebo kompromitovaný stav, aký existoval vo VPS v čase jej vytvorenia.
41. Môže zahŕňať napríklad:

• poškodený operačný systém,
• chybnú konfiguráciu,
• poškodenú databázu,
• malware,
• ransomware,
• backdoor,
• kompromitovaný používateľský účet,
• neoprávnene zmenené súbory.

42. Obnova takéhoto VPS preto sama osebe nemusí odstrániť pôvodnú príčinu incidentu.
43. Ak bol VPS kompromitovaný už pred vytvorením dostupných záloh, môže byť kompromitovaný stav obsiahnutý vo viacerých alebo všetkých dostupných bodoch obnovy.
44. Zákazník by mal pri podozrení na kompromitáciu VPS informovať WebHouse bez zbytočného odkladu.
45. Včasné oznámenie môže zvýšiť možnosť uchovať starší bod obnovy pred jeho odstránením v rámci bežnej rotácie.
46. WebHouse však negarantuje, že pri každom incidente bude možné identifikovať alebo zachovať čistú zálohu spred kompromitácie.
47. WebHouse môže z bezpečnostných dôvodov odmietnuť okamžite pripojiť obnovený kompromitovaný VPS do verejnej siete, ak by tým mohlo dôjsť k:

• pokračovaniu útoku,
• šíreniu škodlivého kódu,
• ďalšiemu napádaniu externých systémov,
• rozosielaniu spamu,
• ohrozeniu infraštruktúry WebHouse alebo ostatných zákazníkov.

48. V takom prípade môže byť obnovený systém podľa technických možností:

• izolovaný,
• spustený bez verejného prístupu,
• sprístupnený iba na získanie dát,
• alebo aktivovaný až po vykonaní primeraných nápravných opatrení.

49. Obnova VPS nie je automaticky:

• forenznou analýzou,
• bezpečnostným auditom,
• odstránením malvéru,
• opravou operačného systému,
• opravou aplikácií,
• ani hardeningom servera.

50. Takéto činnosti môžu byť poskytované iba ako osobitná alebo spoplatnená služba, ak ich WebHouse poskytuje.
51. Záloha VPS nemusí byť automaticky prenositeľná na ľubovoľnú inú virtualizačnú platformu.
52. Interný formát zálohy môže byť viazaný na:

• konkrétnu virtualizačnú technológiu,
• konkrétny typ virtuálneho disku,
• konkrétnu zálohovaciu platformu,
• alebo internú infraštruktúru WebHouse.

53. WebHouse preto negarantuje, že Zákazníkovi poskytne zálohu celej VM v ľubovoľnom požadovanom formáte.
54. Ak je technicky možné vytvoriť export virtuálneho servera, môže ísť o samostatnú službu alebo administrátorský zásah.
55. Zákazník, ktorý potrebuje prenositeľnú vlastnú zálohu, je povinný zabezpečiť si ju vhodným mechanizmom vo vnútri svojho VPS alebo objednať príslušnú službu.
56. Záloha VPS nemusí zachovať všetky vlastnosti virtualizačnej inštancie mimo samotných dát.
57. Podľa použitej technológie môže byť po obnove potrebné znovu nastaviť alebo prideliť napríklad:

• IP adresu,
• sieťové rozhrania,
• MAC adresu,
• firewallové pravidlá mimo VPS,
• rDNS,
• externé storage pripojenia,
• licenčné väzby,
• inú infraštruktúrnu konfiguráciu.

58. Obnovená virtuálna inštancia preto nemusí byť technicky identická vo všetkých infrastrukturných parametroch s pôvodnou inštanciou.
59. Ak softvér Zákazníka viaže svoju licenciu na:

• MAC adresu,
• IP adresu,
• identifikátor virtuálneho stroja,
• hardvérový fingerprint,
• alebo inú technickú vlastnosť,

môže byť po obnove potrebná opätovná aktivácia licencie.

60. WebHouse nezodpovedá za podmienky alebo funkčnosť licencií tretích strán.
61. Pri obnove VPS môže byť potrebné systém po prvom spustení technicky skontrolovať.
62. Zákazník je po obnove povinný primerane preveriť najmä:

• boot operačného systému,
• súborový systém,
• databázy,
• webové služby,
• mailové služby,
• firewall,
• cron úlohy,
• aplikačné služby,
• bezpečnostný stav.

63. Pri nespravovanom VPS túto kontrolu vykonáva Zákazník alebo ním poverený administrátor.
64. WebHouse nie je pri nespravovanom VPS povinný vykonať komplexný aplikačný test po obnove celej virtuálnej inštancie.
65. Ak sa VPS po obnove nespustí, príčinou môže byť napríklad:

• poškodený operačný systém už v čase zálohy,
• poškodený súborový systém,
• chybný bootloader,
• chyba aplikácie,
• historická zákaznícka konfigurácia,
• nekompatibilná aktualizácia,
• iný stav nachádzajúci sa už v zálohe.

66. Samotná skutočnosť, že obnovený VPS nefunguje správne, preto automaticky neznamená, že zálohovací alebo obnovovací proces WebHouse bol chybný.
67. Pri posúdení je potrebné odlíšiť:

• správnosť technickej obnovy virtuálnej inštancie,
• od funkčnosti operačného systému a aplikácií uložených v obnovenej zálohe.

68. Ak bola chyba spôsobená nesprávnou obnovou zo strany WebHouse, posudzuje sa podľa zmluvných podmienok a príslušných právnych predpisov.
69. Ak bol chybný stav už súčasťou bodu obnovy, jeho opätovný výskyt po obnove nie je sám osebe vadou procesu obnovy.
70. Zálohovanie VPS môže mať kapacitné limity.
71. Takéto limity môžu byť stanovené napríklad:

• maximálnou veľkosťou virtuálneho disku,
• maximálnym objemom zálohovaných dát,
• počtom uchovávaných bodov,
• počtom zálohovaných diskov.

72. Ak Zákazník zvýši diskovú kapacitu VPS alebo pridá ďalší disk, nemusí byť nový priestor automaticky zahrnutý do existujúceho zálohovania.
73. Zákazník je povinný preveriť rozsah zálohovania aj po zmene konfigurácie VPS.
74. Ak nová konfigurácia presahuje parametre objednanej zálohovacej služby, môže byť potrebné:

• rozšíriť zálohovaciu službu,
• zmeniť program,
• alebo použiť iný spôsob zálohovania.

75. Zálohovanie VPS môže byť počas určitého obdobia ovplyvnené aj tým, že virtuálny server je:

• vypnutý,
• technicky nedostupný,
• v procese migrácie,
• poškodený,
• alebo v inom neštandardnom technickom stave.

76. Vplyv takéhoto stavu závisí od použitej zálohovacej technológie.
77. Niektoré zálohovacie mechanizmy môžu fungovať nezávisle od operačného systému VPS, iné môžu vyžadovať jeho funkčnosť alebo komunikáciu s nainštalovaným agentom.
78. Ak Zákazník odstráni, vypne alebo nesprávne nakonfiguruje zálohovacieho agenta, ktorý je potrebný na vytváranie záloh, môže tým znemožniť alebo obmedziť zálohovanie.
79. Ak je správa takéhoto agenta v kompetencii Zákazníka, zodpovedá Zákazník aj za dôsledky jeho nefunkčnosti.
80. Ak agenta spravuje WebHouse ako súčasť spravovanej služby, zodpovednosť sa posudzuje podľa rozsahu tejto služby.
81. WebHouse môže pri migrácii VPS na inú fyzickú alebo virtualizačnú platformu použiť iný technický zálohovací mechanizmus.
82. Historické zálohy z pôvodnej platformy nemusia byť technicky prenositeľné na novú platformu.
83. Zákazník by mal pred významnou migráciou kritického VPS disponovať aj vlastnou aktuálnou nezávislou zálohou.
84. Ak je zmena platformy vykonávaná WebHouse, podstatná zmena zmluvne dohodnutých parametrov zálohovania sa riadi podmienkami služby.
85. Zálohovanie virtuálneho servera a snapshot virtuálneho servera nie sú automaticky totožnou službou.
86. Snapshot môže byť určený predovšetkým na:

• krátkodobý návrat pred aktualizáciou,
• migráciu,
• technickú zmenu,
• krátkodobú ochranu pred plánovaným zásahom.

87. Snapshot môže byť uložený na rovnakej alebo súvisiacej infraštruktúre ako produkčný virtuálny disk.
88. Z tohto dôvodu nemusí poskytovať rovnakú úroveň nezávislosti ako samostatná záloha.
89. Snapshot preto nemožno bez výslovného uvedenia považovať za náhradu nezávislej zálohy VPS.
90. Zákazník by mal pred významným zásahom do VPS, napríklad pred:

• upgrade operačného systému,
• upgrade databázového servera,
• zásadnou zmenou firewallu,
• zmenou partitioningu,
• migráciou dát,
• zásahom externého administrátora,

vytvoriť vlastnú aktuálnu zálohu alebo snapshot, ak je to technicky možné.

91. Zákazník nesmie predpokladať, že automatické zálohovanie WebHouse vytvorilo bod obnovy bezprostredne pred jeho vlastným zásahom.
92. Ak VPS obsahuje kritické alebo nenahraditeľné dáta, Zákazník je povinný primerane zabezpečiť aj nezávislú zálohu podľa článkov X a XI.
93. Pri produkčných VPS s vysokým významom môže byť vhodné používať kombináciu:

• zálohy celej VM,
• aplikačných záloh,
• databázových záloh,
• geograficky oddelenej kópie,
• pravidelných testov obnovy.

94. Bežná štandardná záloha VPS nemusí všetky tieto mechanizmy obsahovať.
95. Ak ich Zákazník potrebuje, musí si objednať vhodné riešenie alebo ich zabezpečiť vo vlastnej réžii.
96. Samotná záloha VPS nepredstavuje garanciu vysokej dostupnosti ani disaster recovery služby.
97. Záloha môže umožniť obnovu systému, ale neznamená automaticky okamžité spustenie náhradnej inštancie pri poruche produkčného VPS.
98. Vysoká dostupnosť, failover, clustering, replikácia a disaster recovery sú samostatné technické mechanizmy, pokiaľ nie sú výslovne súčasťou konkrétnej služby.
99. Frekvencia zálohovania VPS sama osebe nepredstavuje garantované RPO.
100. Existencia použiteľnej zálohy sama osebe nepredstavuje garantované RTO.
101. Garantované RPO alebo RTO existuje iba vtedy, ak je výslovne uvedené v parametroch konkrétnej služby, SLA alebo individuálnej dohode.
102. Doba obnovy celého VPS môže závisieť najmä od:

• veľkosti virtuálnych diskov,
• objemu obsadených dát,
• typu zálohy,
• spôsobu uloženia zálohy,
• kapacity infraštruktúry,
• rozsahu incidentu,
• aktuálneho počtu súčasných obnovovacích operácií.

103. Pri rozsiahlej havárii môže byť potrebné obnovovať väčší počet virtuálnych serverov súčasne.
104. V takom prípade môže WebHouse určovať poradie obnovy s prihliadnutím na:

• technické závislosti,
• bezpečnosť,
• stabilitu infraštruktúry,
• charakter objednaných služieb,
• prípadne individuálne dohodnuté priority.

105. Bez osobitne dohodnutého RTO alebo priority nemá Zákazník automatický nárok na prednostnú obnovu iba z dôvodu vlastného obchodného významu VPS.
106. Obnova VPS môže byť podľa konkrétnej služby:

• zahrnutá v cene,
• samoobslužná,
• poskytovaná v určitom obmedzenom rozsahu,
• alebo spoplatnená ako administrátorský zásah.

107. Ak je obnova potrebná v dôsledku udalosti spôsobenej Zákazníkom alebo jeho softvérom, môže byť manuálny zásah WebHouse spoplatnený.
108. Ide napríklad o:

• nesprávnu administrátorskú operáciu,
• chybné vymazanie dát,
• poškodenie operačného systému,
• chybnú aktualizáciu,
• kompromitáciu systému v zákazníkom spravovanej vrstve.

109. Ak je obnova potrebná v dôsledku preukázanej vady služby na strane WebHouse, jej posúdenie sa riadi zmluvnými podmienkami, Reklamačným poriadkom a príslušnými právnymi predpismi.
110. Jednorazové vykonanie manuálnej obnovy VPS nad rámec služby bezplatne alebo ako goodwill nevytvára nárok na rovnaký postup v budúcnosti.
111. Rozhodujúci rozsah zálohovania VPS je vždy rozsah výslovne dohodnutý pri konkrétnej službe.
112. Samotná existencia interného snapshotu, replík alebo inej technickej kópie na strane WebHouse nezakladá Zákazníkovi nárok na jej:

• zachovanie,
• vydanie,
• sprístupnenie,
• ani použitie na individuálnu obnovu,

ak táto kópia nie je súčasťou objednanej zálohovacej služby.

113. WebHouse je povinný riadne poskytovať zálohovanie VPS v rozsahu, ktorý bol pri konkrétnej službe výslovne dohodnutý.
114. Povinnosť Zákazníka vytvárať vlastné zálohy kritických dát nezbavuje WebHouse zodpovednosti za nesplnenie jeho vlastných dohodnutých alebo zákonných povinností.
115. Rovnako však samotné používanie štandardného VPS na kritický alebo vysoko hodnotný účel automaticky nerozširuje parametre ani rozsah zodpovednosti WebHouse nad rámec objednanej služby.
116. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 17

Snapshot nie je plnohodnotná záloha

1. Snapshot virtuálneho servera, virtuálneho disku, súborového systému alebo úložiska predstavuje technický obraz alebo referenciu na stav dát v určitom okamihu.
2. Snapshot môže byť použitý ako krátkodobý bod obnovy, najmä pred:
   • aktualizáciou operačného systému,
   • aktualizáciou aplikácie,
   • významnou zmenou konfigurácie,
   • migráciou,
   • administrátorským zásahom,
   • alebo inou plánovanou operáciou.
3. Snapshot nie je automaticky plnohodnotnou ani nezávislou zálohou.
4. Technické vlastnosti snapshotu závisia od použitej virtualizačnej, storage alebo filesystemovej technológie.
5. Snapshot môže byť uložený:
   • na rovnakom fyzickom úložisku ako produkčné dáta,
   • na rovnakom storage systéme,
   • v rovnakom diskovom poli,
   • na rovnakej virtualizačnej platforme,
   • alebo na inej technicky súvisiacej infraštruktúre.
6. Z tohto dôvodu môže byť snapshot vystavený niektorým rovnakým rizikám ako produkčné dáta.
7. Ak dôjde k závažnej poruche alebo strate úložiska, na ktorom sa nachádzajú produkčné dáta aj snapshot, môže dôjsť k strate oboch súčasne.
8. Samotná existencia snapshotu preto neznamená, že existuje nezávislá kópia dát uložená mimo produkčnej infraštruktúry.
9. Zákazník nesmie snapshot automaticky považovať za náhradu samostatnej zálohy.
10. Snapshot môže byť v závislosti od použitej technológie vytvorený napríklad ako:

• copy-on-write snapshot,
• redirect-on-write snapshot,
• filesystemový snapshot,
• storage snapshot,
• snapshot virtuálneho disku,
• snapshot celej virtuálnej inštancie,
• alebo iný obdobný technický mechanizmus.

11. Niektoré snapshoty nemusia obsahovať úplnú samostatnú fyzickú kópiu všetkých dát.
12. Môžu byť technicky závislé od:

• pôvodných dátových blokov,
• základného virtuálneho disku,
• storage metadát,
• ďalších častí snapshotového reťazca.

13. Poškodenie alebo strata niektorej závislej časti môže preto ovplyvniť použiteľnosť snapshotu.
14. Viacero snapshotov toho istého systému nemusí predstavovať viacero nezávislých záloh.
15. Aj viac snapshotov môže byť závislých od rovnakého:

• storage systému,
• základného disku,
• virtualizačného prostredia,
• snapshotového reťazca.

16. Snapshoty preto nemožno hodnotiť iba podľa ich počtu.
17. Rozhodujúca je najmä ich technická nezávislosť od produkčných dát a od ostatných bodov obnovy.
18. Snapshot môže byť vhodným mechanizmom na rýchly návrat pred krátkodobým technickým zásahom.
19. Typickým príkladom môže byť vytvorenie snapshotu bezprostredne pred:

• aktualizáciou systému,
• zmenou konfigurácie,
• inštaláciou nového softvéru,
• zásadnou databázovou alebo aplikačnou zmenou.

20. Ak zásah spôsobí bezprostredný problém, môže snapshot umožniť rýchlejší návrat do predchádzajúceho stavu.
21. Snapshot však nie je určený ako jediný mechanizmus dlhodobej ochrany dát.
22. Zákazník by nemal používať snapshot ako jedinú ochranu najmä pred:

• fyzickou poruchou storage systému,
• stratou celého úložiska,
• poškodením dát,
• rozsiahlym technickým incidentom,
• kompromitáciou systému,
• ransomvérom,
• chybou administrátora,
• neoprávneným odstránením dát,
• neoprávneným odstránením samotných snapshotov.

23. Snapshot nemusí chrániť ani pred incidentom, pri ktorom útočník alebo oprávnený používateľ získa dostatočné oprávnenia na jeho odstránenie alebo zmenu.
24. Ak je snapshot sprístupnený prostredníctvom rovnakého administrátorského účtu ako produkčný systém, kompromitácia tohto účtu môže podľa technológie umožniť:

• odstránenie produkčných dát,
• odstránenie snapshotov,
• alebo zásah do oboch vrstiev ochrany.

25. Nezávislá záloha by preto mala byť podľa významu dát chránená spôsobom, ktorý znižuje riziko spoločnej kompromitácie.
26. Snapshot môže obsahovať rovnaký chybný, poškodený alebo kompromitovaný stav ako produkčný systém.
27. Ak bol snapshot vytvorený až po vzniku chyby alebo kompromitácie, návrat k snapshotu nemusí problém odstrániť.
28. Snapshot môže obsahovať napríklad:

• poškodené systémové súbory,
• chybnú konfiguráciu,
• malware,
• ransomware,
• backdoor,
• kompromitovanú aplikáciu,
• poškodenú databázu,
• neoprávnene zmenené dáta.

29. Vytvorenie snapshotu samo osebe neznamená, že jeho obsah bol bezpečnostne alebo aplikačne overený.
30. Snapshotovací systém spravidla neposudzuje:

• správnosť aplikácie,
• správnosť databázových údajov,
• neprítomnosť škodlivého kódu,
• ani obchodnú správnosť uložených dát.

31. Snapshot môže byť vytvorený na úrovni diskového alebo storage systému bez vedomosti aplikácií bežiacich vo virtuálnom serveri.
32. Takýto snapshot nemusí automaticky predstavovať aplikačne konzistentný stav všetkých služieb.
33. To je významné najmä pri:

• databázových systémoch,
• mailových serveroch,
• transakčných aplikáciách,
• účtovných systémoch,
• systémoch s vysokou frekvenciou zápisov.

34. Pri vytváraní snapshotu môže byť časť dát:

• zapísaná na disku,
• časť ešte v operačnej pamäti,
• časť v cache,
• alebo súčasťou práve prebiehajúcej transakcie.

35. Použitá technológia môže obsahovať mechanizmy na zníženie tohto rizika, avšak samotná existencia snapshotu neznamená automaticky databázovú alebo aplikačnú konzistenciu.
36. Ak Zákazník potrebuje garantovanú konzistenciu databázy alebo aplikácie, musí použiť mechanizmus, ktorý takúto vlastnosť výslovne podporuje.
37. Môže ísť napríklad o kombináciu snapshotu s:

• databázovým zálohovaním,
• aplikačným agentom,
• quiescing mechanizmom,
• transakčnými logmi,
• alebo iným podporovaným postupom.

38. Snapshot virtuálneho servera nemusí byť vhodný na dlhodobé uchovávanie.
39. Dlhodobé uchovávanie veľkého počtu snapshotov môže podľa konkrétnej technológie:

• zvyšovať spotrebu úložného priestoru,
• zvyšovať technickú zložitosť,
• predlžovať snapshotový reťazec,
• ovplyvňovať výkon,
• zvyšovať riziko problémov pri konsolidácii.

40. WebHouse môže preto obmedziť:

• maximálny počet snapshotov,
• maximálnu dobu ich uchovávania,
• maximálny objem priestoru obsadeného snapshotmi.

41. Takéto limity sa riadia parametrami konkrétnej služby.
42. Snapshot môže byť po uplynutí určenej doby alebo po prekročení stanoveného limitu automaticky odstránený.
43. Zákazník nesmie predpokladať, že manuálne vytvorený snapshot bude uchovávaný neobmedzene.
44. Ak Zákazník potrebuje konkrétny stav dlhodobo zachovať, je povinný vytvoriť alebo objednať samostatnú zálohu určenú na dlhšie uchovávanie.
45. Snapshot nemusí podliehať rovnakej retenčnej politike ako štandardné zálohy.
46. Snapshoty a zálohy môžu mať:

• rozdielnu retenčnú dobu,
• rozdielny spôsob rotácie,
• rozdielne úložisko,
• rozdielne možnosti obnovy.

47. Existencia snapshotu preto sama osebe nemení parametre zálohovacej služby.
48. Rovnako existencia samostatnej zálohy neznamená, že bude automaticky dostupný snapshot z rovnakého okamihu.
49. Snapshot môže byť vytvorený automaticky alebo manuálne.
50. Manuálny snapshot vytvorený na požiadanie Zákazníka môže byť vhodný najmä ako krátkodobá poistka pred konkrétnym plánovaným zásahom.
51. Zákazník by však po úspešnom dokončení zásahu nemal bezdôvodne ponechávať nepotrebné snapshoty dlhodobo, ak to nie je účelom služby.
52. WebHouse môže staré alebo nepotrebné snapshoty odstrániť podľa pravidiel konkrétnej služby.
53. Obnova snapshotu môže znamenať návrat celej technickej jednotky do staršieho stavu.
54. Pri obnove môže dôjsť k strate všetkých zmien vykonaných od okamihu vytvorenia snapshotu.
55. Môžu sa tým stratiť najmä:

• nové súbory,
• nové databázové záznamy,
• nové e-maily,
• zmeny konfigurácie,
• aktualizácie,
• používateľské účty,
• alebo iné dáta vytvorené neskôr.

56. Pred návratom k snapshotu môže WebHouse požadovať potvrdenie Zákazníka, že rozumie dôsledkom obnovenia staršieho stavu.
57. Ak to technológia umožňuje, môže byť pred návratom vytvorený ďalší snapshot aktuálneho stavu.
58. WebHouse však jeho vytvorenie negarantuje pri každom incidente, najmä ak:

• je storage poškodený,
• systém je kompromitovaný,
• nie je dostatok kapacity,
• ďalší snapshot by zvýšil riziko poškodenia.

59. Snapshot nemusí umožňovať obnovu jednotlivého súboru.
60. Pri niektorých technológiách môže byť štandardným spôsobom obnovy:

• návrat celej VM,
• návrat celého disku,
• pripojenie historického snapshotu,
• alebo vytvorenie dočasnej kópie.

61. Ak Zákazník potrebuje iba jeden súbor, môže byť potrebné obnoviť alebo pripojiť väčší technický celok a požadované dáta z neho manuálne vybrať.
62. Takýto zásah môže byť spoplatnený podľa rozsahu práce.
63. Snapshot nie je automaticky prenositeľný mimo infraštruktúry, na ktorej bol vytvorený.
64. Interný snapshotový formát môže byť viazaný na konkrétnu:

• virtualizačnú platformu,
• storage technológiu,
• filesystemovú technológiu,
• alebo internú infraštruktúru WebHouse.

65. Zákazník preto nemá automatický nárok na vydanie snapshotu vo forme samostatného súboru použiteľného u iného poskytovateľa.
66. Ak je možný export, môže ísť o osobitný technický alebo spoplatnený zásah.
67. Snapshot nie je replikácia.
68. Replikácia znamená priebežné alebo periodické kopírovanie dát na ďalší systém.
69. Replika môže zvýšiť dostupnosť alebo odolnosť voči poruche konkrétneho zariadenia, ale môže zároveň prenášať aj:

• vymazanie,
• poškodenie,
• neoprávnenú zmenu,
• ransomware,
• alebo inú nežiaducu zmenu.

70. Replikácia preto sama osebe nemusí predstavovať historickú zálohu.
71. Rovnako RAID alebo iná disková redundancia nepredstavuje zálohu.
72. RAID môže chrániť najmä pred výpadkom niektorých fyzických diskov, ale nechráni automaticky pred:

• odstránením súboru,
• poškodením aplikácie,
• kompromitáciou účtu,
• ransomvérom,
• chybou administrátora.

73. Snapshot, replikácia, RAID, vysoká dostupnosť a záloha preto predstavujú rozdielne technické mechanizmy.
74. Jednotlivé mechanizmy sa môžu vhodne dopĺňať, ale nemožno ich automaticky považovať za vzájomné náhrady.
75. Pri kritických systémoch je vhodné kombinovať viacero vrstiev ochrany podľa významu dát.
76. Môže ísť napríklad o kombináciu:

• redundantného storage,
• snapshotov,
• pravidelnej nezávislej zálohy,
• geograficky oddelenej zálohy,
• aplikačných alebo databázových záloh.

77. Konkrétna vhodná architektúra závisí od:

• významu systému,
• prípustnej straty dát,
• prípustnej doby výpadku,
• požadovaného RPO,
• požadovaného RTO.

78. Zákazník, ktorý používa snapshot ako jedinú ochranu kritických alebo nenahraditeľných dát, nesie zvýšené riziko ich straty pri udalosti zasahujúcej spoločnú infraštruktúru.
79. Pri kritických alebo nenahraditeľných dátach je Zákazník povinný primerane zabezpečiť aj samostatnú nezávislú zálohu.
80. Ak snapshot poskytuje WebHouse ako súčasť konkrétnej služby, WebHouse zodpovedá za jeho poskytovanie v rozsahu výslovne dohodnutých parametrov tejto služby.
81. Povinnosť Zákazníka vytvárať vlastné nezávislé zálohy nezbavuje WebHouse zodpovednosti za riadne poskytovanie objednanej snapshotovej alebo zálohovacej služby.
82. Samotná existencia snapshotu však nerozširuje rozsah zálohovacej služby nad rámec výslovne dohodnutých parametrov.
83. Skutočnosť, že WebHouse v konkrétnom prípade disponuje interným technickým snapshotom, ktorý nie je súčasťou objednanej služby, sama osebe nezakladá Zákazníkovi nárok na jeho:

• zachovanie,
• sprístupnenie,
• export,
• ani použitie na obnovu.

84. Ak WebHouse takýto interný snapshot použije na pomoc Zákazníkovi nad rámec služby, nevytvára tým nárok na rovnaký postup v budúcnosti.
85. Snapshot nemožno bez výslovného uvedenia považovať za:

• nezávislú zálohu,
• dlhodobý archív,
• disaster recovery riešenie,
• garantované RPO alebo RTO.

86. Rozhodujúce sú vždy parametre konkrétnej objednanej služby.
87. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse neposkytovať snapshot alebo zálohu v rozsahu, ktorý bol pri konkrétnej službe výslovne dohodnutý.
88. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 18

Dedikované servery a serverhousing

1. Dedikovaný server alebo server Zákazníka umiestnený v rámci služby serverhousingu nie je automaticky zálohovaný, pokiaľ je zálohovanie výslovne uvedené ako súčasť konkrétnej služby alebo si Zákazník neobjednal samostatnú zálohovaciu službu.

2. Samotné poskytovanie:

   • dedikovaného servera,
   • fyzického serverového priestoru,
   • rackovej pozície,
   • napájania,
   • internetovej konektivity,
   • IP adries,
   • sieťovej infraštruktúry,
   • monitoringu dostupnosti,
   • alebo iných súvisiacich infraštruktúrnych služieb

   neznamená, že WebHouse vytvára alebo uchováva zálohy dát uložených na príslušnom serveri.

3. Ak Zákazník nemá objednanú samostatnú zálohovaciu službu, zodpovedá za zálohovanie dát na dedikovanom alebo housingovom serveri Zákazník.
4. Táto zodpovednosť zahŕňa najmä:
   • výber vhodného spôsobu zálohovania,
   • konfiguráciu zálohovacieho softvéru,
   • určenie rozsahu zálohovaných dát,
   • nastavenie frekvencie záloh,
   • nastavenie retenčnej doby,
   • výber zálohovacieho úložiska,
   • kontrolu úspešnosti záloh,
   • kontrolu dostupnej kapacity,
   • zabezpečenie záloh,
   • pravidelné overovanie ich obnoviteľnosti.
5. Samotná fyzická prítomnosť servera v dátovom centre alebo infraštruktúre WebHouse nezakladá povinnosť WebHouse:
   • pristupovať k dátam Zákazníka,
   • vytvárať ich kópie,
   • kontrolovať ich integritu,
   • kontrolovať zálohovanie,
   • ani zabezpečiť ich obnovu.
6. Pri serverhousingu môže byť technická a administrátorská kontrola nad serverom úplne na strane Zákazníka.
7. WebHouse nemusí mať pri takomto serveri:
   • administrátorské heslo,
   • root prístup,
   • prístup do operačného systému,
   • prístup k súborom,
   • prístup k databázam,
   • prístup k šifrovacím kľúčom,
   • ani technickú možnosť zistiť obsah alebo stav zákazníckych dát.
8. Ak WebHouse nemá prístup potrebný na zálohovanie alebo obnovu, nemožno od neho požadovať vykonanie takéhoto úkonu bez poskytnutia potrebnej súčinnosti Zákazníkom.
9. Pri dedikovanom serveri môže rozsah správy závisieť od toho, či ide o:
   • nespravovaný server,
   • čiastočne spravovaný server,
   • plne spravovaný server,
   • alebo individuálne dohodnutú službu.
10. Samotná správa operačného systému alebo serverových služieb WebHouse ešte automaticky neznamená, že súčasťou služby je aj zálohovanie všetkých dát.
11. Zálohovanie musí byť výslovne uvedené medzi parametrami služby alebo samostatne objednané.
12. Ak je pri dedikovanom serveri objednaná zálohovacia služba, jej rozsah môže zahŕňať najmä:

• celý server,
• vybrané disky,
• vybrané súborové systémy,
• vybrané adresáre,
• databázy,
• konfigurácie,
• alebo iné dohodnuté dátové objekty.

13. Rozsah zálohovania sa určuje podľa konkrétnej objednávky a nemusí zahŕňať celý obsah servera.
14. Ak server obsahuje viac fyzických diskov, diskových polí alebo externých úložísk, Zákazník je povinný preveriť, ktoré z nich sú zahrnuté do objednanej zálohovacej služby.
15. Pridanie nového disku, diskového poľa alebo dátového priestoru nemusí automaticky znamenať jeho zaradenie do existujúcej zálohovacej politiky.
16. Zákazník je povinný oznámiť WebHouse podstatnú zmenu konfigurácie, ak môže ovplyvniť rozsah alebo funkčnosť objednaného zálohovania.
17. Ak Zákazník zvýši objem dát nad rozsah objednanej zálohovacej kapacity, môže byť potrebné:

• zvýšiť kapacitu zálohovacej služby,
• zmeniť zálohovací program,
• upraviť rozsah zálohovaných dát,
• alebo dohodnúť individuálne riešenie.

18. WebHouse nie je povinný zálohovať dáta nad rámec objednanej kapacity alebo rozsahu.
19. Zálohovanie dedikovaného servera môže byť vykonávané rôznymi technickými spôsobmi.
20. Môže ísť najmä o:

• súborovú zálohu,
• image-based zálohu,
• zálohu jednotlivých diskov,
• databázový backup,
• zálohovanie pomocou agenta,
• snapshot podporovaného úložiska,
• alebo kombináciu viacerých mechanizmov.

21. Použitý technický mechanizmus určuje možnosti následnej obnovy.
22. Nie každá záloha dedikovaného servera umožňuje:

• obnovu celého servera na nový hardvér,
• bare-metal recovery,
• obnovu jednotlivého súboru,
• obnovu databázového záznamu,
• okamžité spustenie náhradného servera.

23. Ak je štandardnou jednotkou zálohy súborový systém alebo vybraný adresár, WebHouse nemusí vedieť obnoviť celý operačný systém servera.
24. Ak je naopak zálohovaný celý systémový obraz, nemusí byť bez ďalšieho technického zásahu možné vybrať jeden konkrétny aplikačný údaj.
25. Možnosti obnovy sa preto riadia technickými parametrami konkrétnej zálohovacej služby.
26. Pri databázach na dedikovanom serveri nemusí záloha celého servera automaticky predstavovať databázovo konzistentnú zálohu.
27. Ak Zákazník prevádzkuje kritickú databázu, môže byť potrebné používať aj:

• databázový export,
• databázový backup agent,
• transakčné logy,
• point-in-time recovery,
• alebo iný aplikačne vhodný mechanizmus.

28. Za konfiguráciu takéhoto mechanizmu zodpovedá Zákazník, pokiaľ nie je výslovne zahrnutý do spravovanej služby WebHouse.
29. Pri serverhousingu je Zákazník spravidla zodpovedný aj za technický stav vlastného hardvéru, pokiaľ z konkrétnej služby nevyplýva inak.
30. WebHouse nezodpovedá za stratu dát spôsobenú poruchou komponentu vo vlastníctve alebo správe Zákazníka iba z dôvodu, že server bol fyzicky umiestnený v priestoroch WebHouse.
31. Ide najmä o poruchu:

• disku,
• RAID radiča,
• základnej dosky,
• napájacieho zdroja servera,
• pamäte,
• alebo iného zákazníckeho hardvéru.

32. Tým nie je dotknutá zodpovednosť WebHouse za infraštruktúrnu časť služby, ktorú sa zmluvne zaviazal poskytovať.
33. RAID alebo disková redundancia v dedikovanom alebo housingovom serveri nepredstavujú zálohu.
34. RAID môže znížiť riziko nedostupnosti pri poruche jednotlivého disku, ale nechráni automaticky pred:

• vymazaním dát,
• poškodením súborového systému,
• ransomvérom,
• kompromitáciou,
• chybou administrátora,
• chybnou aplikáciou,
• súčasnou stratou viacerých komponentov.

35. Zákazník preto nesmie považovať RAID za náhradu samostatného zálohovania.
36. Rovnako replikácia dát medzi dvoma servermi nemusí predstavovať nezávislú zálohu.
37. Replikácia môže preniesť na druhý systém aj:

• vymazanie,
• poškodenie,
• chybnú konfiguráciu,
• malware,
• ransomware,
• alebo inú nežiaducu zmenu.

38. Pri kritických serveroch je preto vhodné kombinovať redundanciu alebo replikáciu so samostatnými historickými zálohami.
39. Ak Zákazník používa vlastný zálohovací systém, WebHouse nezodpovedá za jeho funkčnosť, pokiaľ tento systém nespravuje ako súčasť objednanej služby.
40. To sa týka najmä:

• vlastných backup skriptov,
• cron úloh,
• externého backup softvéru,
• vlastných NAS zariadení,
• cloudových záloh,
• externých úložísk Zákazníka.

41. WebHouse nie je povinný kontrolovať, či vlastné zálohovacie úlohy Zákazníka:

• bežia,
• úspešne sa dokončujú,
• majú dostatočnú kapacitu,
• alebo vytvárajú obnoviteľné zálohy.

42. Zákazník je povinný túto kontrolu zabezpečiť sám.
43. Ak Zákazník používa zálohovacie úložisko poskytované WebHouse, ale samotný zálohovací proces konfiguruje a spúšťa Zákazník, poskytnutie úložiska samo osebe neznamená prevzatie zodpovednosti WebHouse za úspešnosť jednotlivých backup jobov.
44. V takom prípade WebHouse zodpovedá za poskytovanie objednanej úložnej služby v dohodnutom rozsahu a Zákazník za konfiguráciu svojho zálohovacieho procesu.
45. Ak je potrebné zálohovať server prostredníctvom zálohovacieho agenta, za funkčnosť agenta zodpovedá tá strana, ktorá ho podľa konkrétnej služby spravuje.
46. Ak agenta spravuje Zákazník, zodpovedá najmä za:

• jeho inštaláciu,
• aktualizáciu,
• konfiguráciu,
• potrebné oprávnenia,
• sieťovú dostupnosť.

47. Ak je správa zálohovacieho agenta súčasťou spravovanej služby WebHouse, zodpovednosť za túto časť sa posudzuje podľa rozsahu objednanej služby.
48. WebHouse nie je povinný prekonávať bezpečnostné opatrenia Zákazníka s cieľom vykonať zálohovanie.
49. Ak napríklad zákaznícka konfigurácia firewallu, autentifikácie alebo prístupových práv znemožní zálohovaciemu systému prístup k dátam, môže dôjsť k neúspechu zálohovania.
50. Ak je príslušná konfigurácia v zodpovednosti Zákazníka, zodpovedá Zákazník aj za následky takéhoto obmedzenia.
51. Zákazník nesmie predpokladať, že WebHouse automaticky zistí každú zmenu vo vnútornej konfigurácii servera, ktorá môže ovplyvniť zálohovanie.
52. Ak Zákazník vykoná zmenu, ktorá môže mať vplyv na objednanú zálohovaciu službu, je povinný túto skutočnosť primerane zohľadniť alebo oznámiť WebHouse.
53. Obnova dedikovaného servera môže podľa typu zálohy vyžadovať:

• funkčný pôvodný server,
• náhradný server,
• nové disky,
• reinstaláciu operačného systému,
• obnovu súborov,
• rekonfiguráciu aplikácií,
• alebo iné technické kroky.

54. Záloha preto automaticky neznamená možnosť okamžite obnoviť plnú prevádzku fyzického servera.
55. Ak dôjde k fyzickému poškodeniu servera, môže byť pred obnovou dát potrebné najskôr:

• opraviť hardware,
• nahradiť disk,
• zabezpečiť kompatibilný náhradný server,
• alebo vytvoriť nové technické prostredie.

56. Čas potrebný na tieto kroky nie je automaticky súčasťou RTO zálohovacej služby, pokiaľ nebolo výslovne dohodnuté inak.
57. Pri serverhousingu, kde je server vo vlastníctve Zákazníka, zodpovedá za zabezpečenie náhradného hardvéru Zákazník, ak nebola dohodnutá osobitná služba.
58. WebHouse môže poskytnúť technickú súčinnosť pri fyzickej výmene komponentov, ak je takáto služba súčasťou objednaného rozsahu alebo je individuálne dohodnutá.
59. Obnova dát po hardvérovej poruche môže predstavovať samostatný administrátorský zásah.
60. Konkrétne spoplatnenie závisí od príčiny incidentu, objednanej služby a rozsahu požadovanej práce.
61. Ak Zákazník požaduje bare-metal obnovu celého dedikovaného servera, musí takúto možnosť podporovať konkrétna objednaná zálohovacia služba.
62. Bežná súborová záloha nie je automaticky bare-metal recovery službou.
63. Obnova na odlišný hardvér môže vyžadovať:

• iné ovládače,
• inú konfiguráciu bootovania,
• zmenu sieťovej konfigurácie,
• zmenu licenčných väzieb,
• ďalšie zásahy.

64. WebHouse negarantuje automatickú prenositeľnosť historického systémového obrazu na ľubovoľný nový hardvér.
65. Ak server používa hardvérovo viazanú alebo inak špecifickú licenciu tretej strany, môže byť po obnove potrebná jej reaktivácia.
66. WebHouse nezodpovedá za licenčné podmienky alebo dostupnosť aktivácie softvéru tretích strán.
67. Pri šifrovaných dátach zodpovedá za zachovanie potrebných šifrovacích kľúčov tá strana, ktorá ich podľa konkrétnej služby spravuje.
68. Ak Zákazník používa vlastné full-disk, filesystemové alebo aplikačné šifrovanie a stratí príslušný dešifrovací kľúč, technicky korektná záloha môže byť bez tohto kľúča nepoužiteľná.
69. WebHouse nezodpovedá za stratu zákazníkom spravovaných šifrovacích kľúčov.
70. Zákazník je povinný uchovávať kritické šifrovacie kľúče bezpečným a primerane nezávislým spôsobom.
71. Pri kompromitácii dedikovaného alebo housingového servera môže záloha obsahovať rovnaký kompromitovaný stav ako produkčný systém.
72. Záloha môže obsahovať napríklad:

• malware,
• backdoor,
• ransomware,
• kompromitované účty,
• neoprávnene zmenené dáta,
• zraniteľný softvér.

73. Obnova zálohy preto nemusí automaticky odstrániť príčinu kompromitácie.
74. Zákazník zodpovedá za odstránenie príčiny incidentu v rozsahu vrstiev, ktoré spravuje.
75. WebHouse môže z bezpečnostných dôvodov obmedziť pripojenie kompromitovaného alebo obnoveného servera do siete, ak by jeho prevádzka mohla ohroziť:

• infraštruktúru WebHouse,
• ostatných zákazníkov,
• tretie strany,
• alebo bezpečnosť siete.

76. Takéto opatrenie sa riadi pravidlami ochrany infraštruktúry a bezpečnosti služieb.
77. Obnova servera nepredstavuje automaticky:

• odstránenie malvéru,
• forenznú analýzu,
• hardening systému,
• aktualizáciu softvéru,
• opravu aplikácií,
• ani bezpečnostný audit.

78. Takéto činnosti môžu byť predmetom samostatnej služby.
79. Ak Zákazník potrebuje kritický fyzický server obnoviť v konkrétnom garantovanom čase, samotná existencia zálohy nemusí postačovať.
80. Môže byť potrebná kombinácia:

• zálohovania,
• náhradného hardvéru,
• replikácie,
• hot-standby systému,
• disaster recovery riešenia,
• individuálneho RTO.

81. Štandardná zálohovacia služba nemusí automaticky zahŕňať tieto mechanizmy.
82. Frekvencia zálohovania dedikovaného servera sama osebe nepredstavuje garantované RPO.
83. Existencia použiteľnej zálohy sama osebe nepredstavuje garantované RTO.
84. Garantované RPO alebo RTO existuje iba vtedy, ak bolo pri konkrétnej službe výslovne dohodnuté.
85. Pri kritických alebo nenahraditeľných dátach je Zákazník povinný primerane zabezpečiť aj nezávislú zálohu podľa článkov X a XI týchto Pravidiel.
86. Najmä pri serverhousingu by Zákazník nemal byť závislý výlučne od:

• jedného fyzického servera,
• jedného diskového poľa,
• jedného dátového centra,
• ani jednej lokálnej zálohy.

87. Vhodná úroveň nezávislosti závisí od hodnoty a významu dát.
88. Pred významným zásahom do dedikovaného alebo housingového servera by mal Zákazník vytvoriť aktuálnu samostatnú zálohu.
89. Ide najmä o zásahy ako:

• upgrade operačného systému,
• zmena RAID konfigurácie,
• výmena diskov,
• zmena partitioningu,
• upgrade databázového systému,
• migrácia,
• rozsiahla zmena aplikácie.

90. Zákazník nesmie predpokladať, že automatická záloha WebHouse bola vytvorená bezprostredne pred jeho vlastným zásahom.
91. Ak Zákazník ukončuje serverhousing alebo službu dedikovaného servera, je povinný pred ukončením služby prevziať alebo exportovať všetky dáta a zálohy, ktoré chce ďalej uchovávať.
92. Zálohy WebHouse nesmú byť považované za trvalé úložisko dát po skončení služby.
93. Po skončení zálohovacej služby sa dostupné body obnovy môžu odstrániť podľa pravidiel retencie a ukončenia služby.
94. Samotná technická existencia internej kópie, snapshotu, servisného obrazu alebo iných dát vytvorených WebHouse na prevádzkové účely nezakladá Zákazníkovi nárok na ich:

• uchovávanie,
• sprístupnenie,
• vydanie,
• alebo obnovu.

95. Ak WebHouse takúto technickú kópiu v konkrétnom prípade použije na pomoc Zákazníkovi, nevytvára tým trvalý nárok na rovnaký postup.
96. Zálohovanie môže byť podľa konkrétnej služby:

• úplne v správe Zákazníka,
• čiastočne v správe WebHouse,
• alebo úplne spravované WebHouse.

97. Rozdelenie zodpovednosti sa vždy určuje podľa konkrétne objednaného rozsahu služby.
98. Ak WebHouse poskytuje iba zálohovacie úložisko, nezodpovedá automaticky za konfiguráciu backup jobov Zákazníka.
99. Ak WebHouse poskytuje spravovanú zálohovaciu službu, zodpovedá za jej poskytovanie v rozsahu výslovne dohodnutých parametrov.
100. Ak WebHouse poskytuje aj správu operačného systému alebo aplikácií, rozsah tejto správy sa posudzuje samostatne a nepredpokladá sa iba na základe existencie zálohovania.
101. Skutočnosť, že Zákazník používa dedikovaný alebo housingový server na kritický účel, automaticky nerozširuje rozsah zálohovacej služby ani zodpovednosti WebHouse.
102. Ak Zákazník potrebuje:

• vyššiu frekvenciu zálohovania,
• dlhšiu retenciu,
• geograficky oddelenú zálohu,
• bare-metal recovery,
• garantované RPO,
• garantované RTO,
• pravidelné testy obnovy,
• alebo disaster recovery,

musí byť príslušný parameter súčasťou objednanej alebo individuálne dohodnutej služby.

103. WebHouse je povinný riadne poskytovať zálohovanie v rozsahu a kvalite, ktoré boli pri konkrétnej službe výslovne dohodnuté.
104. Povinnosť Zákazníka vytvárať vlastné zálohy nezbavuje WebHouse zodpovednosti za nesplnenie jeho vlastných zmluvných alebo zákonných povinností.
105. Rovnako však samotná fyzická prítomnosť servera v dátovom centre WebHouse ani poskytovanie konektivity, napájania alebo inej infraštruktúry nezakladá zodpovednosť WebHouse za zálohovanie dát, ktoré nebolo súčasťou objednanej služby.
106. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 19

Nespravované služby

1. Pri nespravovanom VPS, dedikovanom serveri alebo obdobnej službe zodpovedá Zákazník za správu operačného systému, aplikácií, dát a zálohovacích mechanizmov v rozsahu, ktorý nebol výslovne zverený WebHouse.
2. Ak zálohovanie nie je výslovne súčasťou objednanej služby, Zákazník zodpovedá najmä za:
   • výber zálohovacej technológie,
   • inštaláciu zálohovacieho softvéru,
   • konfiguráciu zálohovania,
   • určenie rozsahu zálohovaných dát,
   • nastavenie harmonogramu,
   • určenie frekvencie záloh,
   • určenie retenčnej politiky,
   • výber cieľového úložiska,
   • kontrolu dostupnej kapacity,
   • kontrolu úspešnosti zálohovacích úloh,
   • riešenie chýb zálohovania,
   • pravidelné testovanie obnovy,
   • samotnú obnovu dát.
3. Samotné poskytovanie nespravovaného VPS alebo dedikovaného servera neznamená, že WebHouse:
   • kontroluje zákaznícke zálohy,
   • sleduje úspešnosť zákazníckych backup jobov,
   • overuje obnoviteľnosť dát,
   • alebo automaticky zasahuje pri ich zlyhaní.
4. Ak Zákazník používa vlastný zálohovací systém, WebHouse nezodpovedá za jeho konfiguráciu ani správnu funkčnosť, pokiaľ tento systém WebHouse výslovne nespravuje ako súčasť objednanej služby.
5. Za vlastný zálohovací systém Zákazníka sa považuje najmä:
   • vlastný shell script,
   • cron úloha,
   • rsync,
   • rclone,
   • Borg,
   • Restic,
   • duplicity,
   • Veeam agent,
   • Bacula,
   • Bareos,
   • databázový backup script,
   • aplikačný backup plugin,
   • alebo iný softvér či mechanizmus nakonfigurovaný Zákazníkom.
6. WebHouse nezodpovedá za to, že takýto systém:
   • nebol správne nainštalovaný,
   • nebol správne nakonfigurovaný,
   • nebol spustený,
   • bol vypnutý,
   • zlyhal,
   • nemal dostatočné oprávnenia,
   • nemal prístup k zdrojovým dátam,
   • nemal prístup k cieľovému úložisku,
   • alebo vytvoril technicky nepoužiteľnú zálohu.

7. Ak Zákazník používa zálohovací harmonogram vytvorený prostredníctvom:

   • cronu,
   • systemd timeru,
   • aplikačného plánovača,
   • databázového plánovača,
   • alebo iného zákazníkom spravovaného mechanizmu,

   zodpovedá za jeho správnu konfiguráciu a funkčnosť Zákazník.

8. WebHouse nie je povinný priebežne kontrolovať, či zákaznícke cron úlohy alebo iné plánované úlohy zálohovania skutočne prebehli.
9. Samotná existencia konfigurovanej zálohovacej úlohy neznamená, že záloha bola úspešne vytvorená.
10. Zákazník je povinný kontrolovať:

• návratové kódy zálohovacích úloh,
• logy,
• chybové hlásenia,
• dostupnosť cieľového úložiska,
• počet a vek vytvorených záloh,
• prípadne iné ukazovatele úspešnosti.

11. Zálohovací proces môže zlyhať aj bez toho, aby tým bola ovplyvnená samotná prevádzka VPS alebo servera.
12. Funkčnosť servera preto neznamená automaticky funkčnosť zákazníckeho zálohovacieho procesu.
13. Ak Zákazník používa zálohovacie úložisko poskytované WebHouse, je potrebné rozlišovať medzi:

• poskytovaním zálohovacieho úložiska,
• a samotným vykonávaním zálohovania.

14. Ak WebHouse poskytuje iba cieľové úložisko a Zákazník naň svoje zálohy odosiela vlastným mechanizmom, WebHouse zodpovedá za poskytovanie úložiska v dohodnutom rozsahu.
15. V takom prípade však WebHouse nezodpovedá automaticky za:

• spustenie zákazníckej zálohy,
• výber správnych dát,
• úplnosť zálohy,
• správny formát zálohy,
• ani jej obnoviteľnosť.

16. Skutočnosť, že cieľové zálohovacie úložisko je dostupné, sama osebe neznamená, že Zákazník naň úspešne uložil aktuálnu zálohu.
17. Rovnako existencia súboru v zálohovacom úložisku nemusí znamenať, že tento súbor predstavuje úplnú a použiteľnú zálohu.
18. Ak Zákazník prekročí kapacitu cieľového úložiska, môže dôjsť k zlyhaniu ďalších zálohovacích operácií.
19. Ak je kontrola kapacity zálohovacieho priestoru v kompetencii Zákazníka, zodpovedá Zákazník za jej primerané sledovanie.
20. WebHouse nemusí automaticky rozširovať zálohovaciu kapacitu iba preto, že ju Zákazník vyčerpal.
21. Ak je možné kapacitu rozšíriť, môže si Zákazník objednať ďalší priestor podľa aktuálnej ponuky WebHouse.
22. Zákazník zodpovedá za to, aby zálohovací systém obsahoval všetky dáta, ktoré chce chrániť.
23. WebHouse pri nespravovanej službe nemusí vedieť:

• kde sa nachádzajú zákaznícke dáta,
• ktoré adresáre sú kritické,
• ktoré databázy sú používané,
• ktoré konfiguračné súbory sú potrebné na obnovu,
• ani ktoré údaje majú pre Zákazníka vysokú hodnotu.

24. Zákazník preto zodpovedá za správne určenie rozsahu svojho zálohovania.
25. Ak Zákazník napríklad zálohuje iba adresár s webovými súbormi, ale nie databázu potrebnú na fungovanie aplikácie, WebHouse nezodpovedá za neúplnosť takejto zálohy.
26. Rovnako ak Zákazník zálohuje databázu, ale nezálohuje súbory alebo konfigurácie potrebné na jej použitie, výsledná záloha nemusí postačovať na úplnú obnovu služby.
27. Pri databázach zodpovedá Zákazník pri nespravovanej službe aj za výber vhodného spôsobu zálohovania.
28. Jednoduché kopírovanie databázových súborov počas aktívnej prevádzky nemusí vytvoriť konzistentnú databázovú zálohu.
29. Ak je potrebné použiť:

• databázový dump,
• hot backup,
• transaction logs,
• point-in-time recovery,
• aplikačný agent,
• alebo iný špecifický mechanizmus,

jeho konfiguráciu zabezpečuje Zákazník.

30. WebHouse nezodpovedá za databázovú nekonzistenciu spôsobenú nevhodne zvoleným zákazníckym zálohovacím postupom.
31. Pri nespravovanej službe zodpovedá Zákazník aj za správu šifrovania svojich záloh.
32. Ak Zákazník zálohy šifruje vlastným kľúčom, zodpovedá za bezpečné uchovanie:

• šifrovacieho kľúča,
• hesla,
• recovery key,
• alebo iného potrebného autentifikačného údaja.

33. Strata takéhoto kľúča môže spôsobiť, že technicky nepoškodená záloha nebude použiteľná.
34. WebHouse nezodpovedá za nemožnosť obnovy zálohy spôsobenú stratou zákazníkom spravovaného šifrovacieho alebo dešifrovacieho kľúča.
35. Zákazník je povinný kritické šifrovacie kľúče uchovávať oddelene a primerane bezpečne.
36. Ak je zálohovací proces závislý od autentifikačných údajov, API kľúčov, SSH kľúčov alebo hesiel, Zákazník zodpovedá za ich:

• správnosť,
• platnosť,
• bezpečnosť,
• aktualizáciu.

37. Zmena hesla alebo kľúča bez zodpovedajúcej aktualizácie zálohovacej konfigurácie môže viesť k zlyhaniu zálohovania.
38. WebHouse nemusí byť o takejto zákazníckej zmene informovaný.
39. Zákazník je preto povinný po zmene:

• hesiel,
• kľúčov,
• firewallových pravidiel,
• sieťovej konfigurácie,
• umiestnenia dát,
• alebo oprávnení

preveriť funkčnosť svojho zálohovacieho systému.

40. Zákazník zodpovedá aj za firewallové a sieťové nastavenia, ktoré sú v jeho správe a ktoré môžu ovplyvniť zálohovanie.
41. Ak Zákazník zablokuje komunikáciu potrebnú na zálohovanie, môže tým zálohovanie znemožniť.
42. Ak zálohovanie vyžaduje agenta nainštalovaného vo VPS alebo na serveri, zodpovedá za jeho správu tá strana, ktorej bola táto povinnosť podľa konkrétnej služby zverená.
43. Ak agenta spravuje Zákazník, zodpovedá najmä za:

• jeho inštaláciu,
• konfiguráciu,
• aktualizáciu,
• spustenie,
• potrebné oprávnenia,
• kompatibilitu so systémom.

44. Ak Zákazník agenta:

• odinštaluje,
• vypne,
• poškodí,
• zablokuje firewallom,
• alebo mu odoberie potrebné oprávnenia,

môže dôjsť k prerušeniu zálohovania.

45. WebHouse nezodpovedá za takéto prerušenie v rozsahu, v ktorom bolo spôsobené konfiguráciou alebo zásahom Zákazníka.
46. Ak je agent výslovne spravovaný WebHouse, zodpovednosť za jeho funkčnosť sa posudzuje podľa rozsahu objednanej služby.
47. Zákazník je pri nespravovanej službe povinný primerane sledovať chybové oznámenia vlastného zálohovacieho systému.
48. Zálohovací systém môže napríklad hlásiť:

• nedostatok priestoru,
• chybu autentifikácie,
• nedostupný server,
• poškodený archív,
• chybnú databázu,
• chybu prenosu,
• zlyhanie snapshotu.

49. Ignorovanie takýchto hlásení môže viesť k dlhodobému stavu, keď sa použiteľné zálohy nevytvárajú.
50. WebHouse nie je povinný analyzovať logy zákazníckeho zálohovacieho softvéru, pokiaľ takáto činnosť nie je súčasťou objednanej správy alebo technickej podpory.
51. Technická podpora WebHouse môže podľa možností Zákazníkovi pomôcť identifikovať technický problém súvisiaci so zálohovaním.
52. Takáto pomoc sama osebe neznamená prevzatie správy zákazníckeho zálohovacieho systému.
53. Ak WebHouse jednorazovo:

• opraví backup script,
• upraví cron,
• pomôže s konfiguráciou,
• alebo obnoví zálohu,

nejde tým automaticky o trvalé prevzatie zodpovednosti za budúce fungovanie takéhoto systému.

54. Jednorazová pomoc nad rámec nespravovanej služby nevytvára nárok na rovnaký zásah v budúcnosti.
55. Ak Zákazník potrebuje trvalú správu a monitoring zálohovania, musí si objednať spravovanú alebo individuálne dohodnutú službu, ak ju WebHouse poskytuje.
56. Spravovaná zálohovacia služba môže podľa dohody zahŕňať napríklad:

• konfiguráciu záloh,
• monitoring úspešnosti,
• reakciu na chyby,
• správu agenta,
• kontrolu kapacity,
• pravidelné testovanie obnovy.

57. Takéto povinnosti vznikajú WebHouse iba vtedy, ak sú výslovne uvedené v rozsahu objednanej služby.
58. Samotné označenie VPS alebo servera ako „managed“ neznamená automaticky, že WebHouse spravuje všetky zákaznícke zálohovacie procesy, pokiaľ rozsah správy neurčuje inak.
59. Rozhodujúci je konkrétny zoznam spravovaných činností.
60. Zákazník zodpovedá za pravidelné overovanie obnoviteľnosti vlastných záloh.
61. Úspešne vytvorený backup súbor nemusí automaticky znamenať, že ho bude možné použiť na úplnú obnovu.
62. Zákazník by mal preto primerane vykonávať testovacie obnovy alebo iným spôsobom preverovať použiteľnosť záloh.
63. Pri kritických systémoch by frekvencia testovania mala zodpovedať významu dát a požadovanej úrovni kontinuity prevádzky.
64. WebHouse nie je pri nespravovanej službe povinný vykonávať pravidelné testovacie obnovy zákazníckych záloh.
65. Ak Zákazník nevykonáva žiadne testy obnovy, nesie riziko, že prípadná chyba zálohovacieho procesu bude zistená až pri skutočnom incidente.
66. Pri nespravovanej službe zodpovedá Zákazník aj za postup obnovy.
67. To zahŕňa najmä znalosti a postupy potrebné na:

• získanie zálohy,
• jej dešifrovanie,
• rozbalenie alebo pripojenie,
• import databázy,
• obnovenie súborov,
• rekonfiguráciu aplikácie,
• spustenie služby.

68. WebHouse nemusí poznať vnútornú architektúru zákazníckej aplikácie ani správny postup jej obnovy.
69. Ak Zákazník potrebuje pomoc pri obnove, WebHouse ju môže podľa svojich možností poskytnúť ako:

• technickú podporu v rozsahu služby,
• platený administrátorský zásah,
• alebo individuálnu službu.

70. WebHouse negarantuje, že bude možné prevziať obnovu každej zákazníckej aplikácie alebo technológie, ktorú nespravuje.
71. Ak Zákazník používa nepodporovaný alebo neštandardný zálohovací systém, zodpovedá aj za dostupnosť:

• potrebného softvéru,
• dokumentácie,
• licencií,
• kompatibilnej verzie programu.

72. WebHouse nie je povinný udržiavať historické verzie zákazníckeho zálohovacieho softvéru iba na účely budúcej obnovy.
73. Ak je obnova možná iba prostredníctvom proprietárneho systému tretej strany, zodpovedá Zákazník za dostupnosť potrebných licencií alebo prístupov.
74. Pri vlastnom zálohovaní na externé úložisko tretej strany zodpovedá Zákazník za zmluvný vzťah s touto treťou stranou.
75. WebHouse nezodpovedá za:

• výpadok externého cloudového úložiska,
• zrušenie účtu,
• zmenu API,
• zmenu cien,
• zmenu retenčných podmienok,
• alebo inú udalosť na strane externého poskytovateľa.

76. Zákazník by nemal používať ako jedinú zálohu kópiu uloženú na tom istom serveri alebo fyzickom úložisku ako produkčné dáta.
77. Záloha uložená napríklad v adresári /backup na tom istom VPS môže byť zasiahnutá rovnakou udalosťou ako produkčné dáta.
78. Ide najmä o:

• poruchu disku,
• poškodenie filesystemu,
• ransomware,
• kompromitáciu root účtu,
• omyl administrátora,
• zrušenie celého VPS.

79. Takáto kópia môže byť užitočná ako krátkodobá pracovná záloha, ale nemusí predstavovať nezávislú zálohu.
80. Pri kritických dátach je Zákazník povinný používať primerane nezávislé zálohovacie úložisko.
81. Ak Zákazník používa ako zálohovacie úložisko iný server v rámci rovnakej infraštruktúry, musí zvážiť aj riziko spoločnej technickej udalosti.
82. Pri dátach s vysokou hodnotou môže byť vhodné uchovávať aspoň jednu kópiu:

• v inom dátovom centre,
• u iného poskytovateľa,
• offline,
• alebo inak primerane oddelene.

83. Pri nespravovanej službe je Zákazník zodpovedný aj za retenčnú politiku vlastných záloh.
84. Zákazník by mal zabezpečiť, aby automatická rotácia neodstránila posledný potrebný čistý bod obnovy.
85. Pri ransomvéri alebo dlhodobo nezistenom poškodení môžu nové zálohy postupne obsahovať rovnaký kompromitovaný stav.
86. Ak sa staršie zálohy zároveň automaticky odstraňujú, môže dôjsť k strate posledného použiteľného historického bodu.
87. Zákazník by mal pri kritických systémoch zohľadniť aj toto riziko pri nastavovaní vlastnej retencie.
88. WebHouse pri nespravovanej službe nie je povinný zasahovať do zákazníckej retenčnej politiky.
89. Ak Zákazník konfiguruje zálohy tak, že sa uchováva iba posledná kópia, nesie riziko prepísania posledného funkčného stavu novšou chybnou zálohou.
90. Pred významným zásahom do nespravovaného systému je Zákazník povinný primerane zvážiť vytvorenie samostatnej zálohy.
91. Ide najmä o zásahy ako:

• upgrade operačného systému,
• upgrade databázy,
• zmena diskových oddielov,
• zmena RAID konfigurácie,
• migrácia,
• hromadná databázová operácia,
• zásadná zmena aplikácie.

92. Zákazník nesmie predpokladať, že WebHouse vytvoril zálohu pred jeho vlastným zásahom, pokiaľ takáto záloha nie je súčasťou objednanej služby.
93. Ak WebHouse poskytuje nespravovanú službu a zároveň samostatnú automatickú zálohu celej VM alebo servera, rozdelenie zodpovednosti sa posudzuje oddelene.
94. WebHouse v takom prípade zodpovedá za poskytovanie svojej automatickej zálohovacej služby v dohodnutom rozsahu.
95. Zákazník naďalej zodpovedá za:

• aplikačné zálohy,
• databázovú konzistenciu,
• vlastné backup skripty,
• internú konfiguráciu systému,

pokiaľ neboli výslovne zahrnuté do služby WebHouse.

96. Existencia zálohy celej VM preto automaticky nemení nespravovaný charakter operačného systému a aplikácií.
97. Zákazník je povinný rozlišovať medzi:

• infraštruktúrnou zálohou poskytovanou WebHouse,
• a vlastným aplikačným zálohovaním.

98. Ak Zákazník potrebuje vyššiu úroveň ochrany než poskytuje nespravovaná služba, môže si podľa ponuky WebHouse objednať:

• spravované zálohovanie,
• monitoring záloh,
• dlhšiu retenciu,
• vyššiu frekvenciu,
• individuálne RPO,
• individuálne RTO,
• testovanie obnovy,
• alebo inú spravovanú službu.

99. Takéto rozšírenie zodpovednosti WebHouse vzniká iba v rozsahu výslovne objednaných a dohodnutých služieb.
100. Samotná skutočnosť, že WebHouse má technickú možnosť prístupu na server, neznamená povinnosť aktívne kontrolovať zákaznícky zálohovací systém.
101. Rovnako jednorazový administrátorský zásah WebHouse do nespravovaného servera nemení automaticky charakter služby na spravovanú.
102. Pri posudzovaní zodpovednosti za stratu alebo nemožnosť obnovy dát sa skúma najmä:

• kto zálohovací systém konfiguroval,
• kto ho mal spravovať,
• kto mal kontrolovať jeho úspešnosť,
• aký rozsah služby bol objednaný,
• kde vznikla príčina zlyhania,
• či bola poskytnutá potrebná súčinnosť.

103. Ak zlyhanie vzniklo v zákazníkom spravovanej vrstve, samotná skutočnosť, že server bol prevádzkovaný v infraštruktúre WebHouse, neznamená zodpovednosť WebHouse za toto zlyhanie.
104. Ak naopak zlyhanie vzniklo v zálohovacej službe, ktorú WebHouse výslovne spravoval, posudzuje sa zodpovednosť podľa parametrov tejto služby.
105. Povinnosti Zákazníka podľa tohto článku nezbavujú WebHouse zodpovednosti za riadne poskytovanie tých častí služby, ktoré podľa zmluvy spravuje WebHouse.
106. Cieľom tohto článku je jasne oddeliť zodpovednosť za infraštruktúru a služby spravované WebHouse od operačných, aplikačných a zálohovacích mechanizmov, ktoré sú pri nespravovanej službe pod kontrolou Zákazníka.
107. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 20

Vytvorenie zálohy na požiadanie

1. Ak to konkrétna služba a použitá technológia umožňujú, Zákazník môže mať možnosť vytvoriť alebo požiadať o vytvorenie manuálnej zálohy, snapshotu alebo iného samostatného bodu obnovy.
2. Manuálna záloha môže byť vytvorená najmä:
   • prostredníctvom zákazníckeho rozhrania,
   • prostredníctvom administrácie konkrétnej služby,
   • prostredníctvom podporovaného API,
   • na základe požiadavky technickej podpore,
   • alebo iným spôsobom stanoveným pre konkrétnu službu.
3. Dostupnosť manuálnej zálohy nie je automatickou vlastnosťou všetkých služieb WebHouse.
4. Skutočnosť, že určitý typ služby technicky umožňuje vytvorenie manuálnej zálohy, neznamená, že táto funkcionalita musí byť dostupná vo všetkých programoch, variantoch alebo konfiguráciách tejto služby.
5. Manuálna záloha môže podľa konkrétnej služby predstavovať najmä:
   • zálohu webových súborov,
   • zálohu databázy,
   • zálohu celého webhostingového účtu,
   • snapshot virtuálneho servera,
   • obraz virtuálneho disku,
   • export dát,
   • alebo iný technicky podporovaný bod obnovy.
6. Manuálna záloha a snapshot nie sú automaticky totožnými technickými mechanizmami.
7. Ak Zákazník vytvorí snapshot, uplatňujú sa naň aj osobitné pravidlá podľa článku XVII týchto Pravidiel.
8. Manuálna záloha nemusí predstavovať nezávislú kópiu dát uloženú mimo produkčnej infraštruktúry.
9. Technické vlastnosti, nezávislosť, spôsob uloženia a možnosti obnovy manuálnej zálohy závisia od konkrétnej služby.
10. Zákazník nesmie automaticky predpokladať, že manuálna záloha má rovnaké vlastnosti ako pravidelná automatická záloha WebHouse.
11. Manuálne a automatické zálohy môžu mať rozdielne:

• úložisko,
• retenčné podmienky,
• kapacitné limity,
• formát,
• spôsob obnovy,
• úroveň technickej nezávislosti.

12. Manuálna záloha môže podliehať:

• maximálnemu počtu záloh,
• maximálnemu objemu dát,
• maximálnej veľkosti jednej zálohy,
• maximálnej celkovej kapacite,
• minimálnemu intervalu medzi vytvorením ďalších záloh,
• časovému limitu uchovávania,
• automatickej rotácii,
• alebo iným technickým obmedzeniam.

13. Konkrétne limity sa riadia parametrami príslušnej služby.
14. Ak Zákazník dosiahne maximálny počet manuálnych záloh alebo maximálnu dostupnú kapacitu, ďalšiu zálohu nemusí byť možné vytvoriť.
15. V takom prípade môže byť potrebné:

• odstrániť staršiu manuálnu zálohu,
• uvoľniť úložný priestor,
• zvýšiť kapacitu služby,
• alebo použiť iný spôsob zálohovania.

16. WebHouse nie je povinný automaticky zvýšiť kapacitu manuálnych záloh nad parametre objednanej služby.
17. Vytvorením novej manuálnej zálohy môže podľa konkrétnej služby dôjsť aj k automatickému odstráneniu najstaršej manuálnej zálohy.
18. Zákazník je preto povinný pred vytvorením novej zálohy primerane preveriť, či tým nebude odstránený bod obnovy, ktorý ešte potrebuje.
19. Ak služba umožňuje označenie určitej zálohy ako chránenej pred automatickou rotáciou, Zákazník je povinný takúto funkciu použiť, ak chce zabrániť jej štandardnému odstráneniu.
20. Ak takáto funkcia nie je súčasťou služby, Zákazník nesmie predpokladať, že manuálne vytvorená záloha bude z rotácie automaticky vyňatá.
21. Manuálna záloha môže byť uchovávaná iba počas obmedzenej doby.
22. Po uplynutí stanovenej doby môže byť automaticky:

• odstránená,
• prepísaná,
• alebo vyradená z dostupných bodov obnovy.

23. WebHouse nie je povinný Zákazníka pred každým automatickým odstránením manuálnej zálohy osobitne upozorniť, ak takýto spôsob retencie vyplýva z parametrov služby.
24. Zákazník, ktorý potrebuje manuálnu zálohu zachovať dlhšie, než umožňuje štandardná retencia služby, je povinný:

• stiahnuť ju,
• exportovať ju,
• skopírovať ju do vlastného úložiska,
• alebo si objednať vhodné riešenie s dlhšou retenciou,

ak to daná služba technicky umožňuje.

25. Manuálna záloha nie je automaticky archívom a nemožno predpokladať jej neobmedzené uchovávanie.
26. Vytvorenie manuálnej zálohy môže byť podľa konkrétnej služby:

• bezplatné,
• zahrnuté v cene služby,
• obmedzené určitým počtom operácií,
• alebo samostatne spoplatnené.

27. Rovnako môže byť samostatne spoplatnené:

• manuálne vytvorenie zálohy pracovníkom WebHouse,
• jej export,
• presun na iné úložisko,
• alebo následná manuálna obnova.

28. Konkrétne cenové podmienky sa riadia aktuálnym cenníkom alebo individuálnou dohodou.
29. Odoslanie požiadavky na vytvorenie manuálnej zálohy alebo aktivovanie príslušnej funkcie neznamená, že záloha už bola úspešne vytvorená.
30. Zálohovací proces môže prebiehať určitý čas.
31. Doba vytvárania manuálnej zálohy závisí najmä od:

• objemu dát,
• počtu súborov,
• veľkosti databáz,
• rýchlosti úložiska,
• zálohovacej technológie,
• aktuálneho zaťaženia systému.

32. Zákazník nesmie začať rizikový zásah do dát iba na základe toho, že vytvorenie zálohy spustil.
33. Ak Zákazník vytvára manuálnu zálohu pred:

• aktualizáciou,
• migráciou,
• hromadnou zmenou databázy,
• zmenou konfigurácie,
• zásahom externého administrátora,
• alebo inou rizikovou operáciou,

mal by s vykonaním takéhoto zásahu počkať až do potvrdenia úspešného dokončenia zálohy.

34. Za úspešne vytvorenú manuálnu zálohu sa považuje až záloha, pri ktorej príslušný systém potvrdil úspešné dokončenie zálohovacej operácie, ak služba takýto stav zobrazuje.
35. Samotné vytvorenie položky, názvu alebo záznamu o požadovanej zálohe nemusí znamenať, že všetky dáta boli už fyzicky alebo logicky zálohované.
36. Zákazník je povinný kontrolovať stav manuálnej zálohy, ak mu zákaznícke rozhranie alebo iný systém túto informáciu poskytuje.
37. Ak systém zobrazí:

• chybu,
• neúspešný stav,
• varovanie,
• prerušenie,
• alebo inú informáciu naznačujúcu problém,

Zákazník nesmie takúto zálohu považovať za spoľahlivý bod obnovy bez ďalšieho preverenia.

38. Ak manuálna záloha zlyhá, môže Zákazník podľa možností služby:

• vykonať nový pokus,
• kontaktovať technickú podporu,
• alebo použiť vlastnú inú formu zálohy.

39. WebHouse negarantuje, že neúspešnú manuálnu zálohu bude vždy možné spätne dokončiť alebo opraviť.
40. Samotné hlásenie o úspešnom dokončení zálohy nepredstavuje absolútnu garanciu použiteľnosti každého jednotlivého súboru alebo aplikačného údaja.
41. Na manuálne zálohy sa primerane vzťahujú všeobecné pravidlá týchto Pravidiel týkajúce sa:

• integrity záloh,
• obnoviteľnosti,
• konzistencie,
• poškodených alebo kompromitovaných dát,
• technických obmedzení.

42. Manuálna záloha zachytáva stav dát dostupný použitým mechanizmom v čase jej vytvárania.
43. Ak počas vytvárania zálohy dochádza k aktívnym zmenám dát, výsledná konzistencia závisí od použitej zálohovacej technológie.
44. To je významné najmä pri:

• databázach,
• e-mailových systémoch,
• transakčných aplikáciách,
• aktívnych virtuálnych serveroch.

45. Manuálna záloha celého virtuálneho servera alebo snapshot nemusí automaticky predstavovať aplikačne alebo databázovo konzistentnú zálohu.
46. Ak Zákazník potrebuje takúto konzistenciu, musí použiť podporovaný aplikačný alebo databázový zálohovací mechanizmus.
47. WebHouse nie je povinný pri každej manuálnej zálohe automaticky zastaviť aplikácie alebo databázové služby, pokiaľ takýto postup nie je súčasťou konkrétnej zálohovacej technológie.
48. Zákazník nesmie predpokladať, že manuálna záloha automaticky obsahuje všetky časti služby.
49. Rozsah manuálnej zálohy môže byť rozdielny od rozsahu automatickej zálohy.
50. Manuálna záloha môže napríklad obsahovať:

• iba súbory,
• iba databázu,
• iba virtuálny disk,
• iba jednu konkrétnu časť služby.

51. Zákazník je povinný pred rizikovým zásahom preveriť, či manuálna záloha zahŕňa všetky dáta, ktoré môže byť potrebné obnoviť.
52. Ak Zákazník napríklad vytvorí iba zálohu webových súborov, ale následne vykoná nezvratnú zmenu databázy, samotná súborová záloha nemusí umožniť návrat aplikácie do pôvodného stavu.
53. Rovnako snapshot virtuálneho servera nemusí zahŕňať externé úložisko alebo externú databázu.
54. WebHouse nezodpovedá za absenciu dát, ktoré podľa parametrov zvoleného typu manuálnej zálohy neboli jej súčasťou.
55. Zákazník môže byť pri vytváraní manuálnej zálohy oprávnený zvoliť:

• rozsah dát,
• názov zálohy,
• cieľové úložisko,
• alebo iné parametre.

56. Za správnosť zákazníkom zvolených parametrov zodpovedá Zákazník.
57. Ak Zákazník omylom vylúči určitú časť dát alebo vyberie nesprávny rozsah zálohy, WebHouse nezodpovedá za dôsledky takéhoto nastavenia, ak systém vykonal požadovaný úkon správne.
58. WebHouse môže z bezpečnostných alebo prevádzkových dôvodov dočasne obmedziť možnosť vytvárania manuálnych záloh.
59. Môže ísť najmä o situáciu:

• prebiehajúcej údržby,
• poruchy úložiska,
• migrácie služby,
• bezpečnostného incidentu,
• extrémneho zaťaženia,
• alebo iného stavu, pri ktorom by vytvorenie zálohy mohlo ohroziť integritu alebo stabilitu služby.

60. Dočasná nedostupnosť funkcie manuálnej zálohy sama osebe neznamená poruchu celej služby, ak táto funkcionalita nemá výslovne garantovanú dostupnosť.
61. Ak Zákazník potrebuje vytvoriť zálohu pred plánovaným zásahom a manuálne zálohovanie je dočasne nedostupné, nemal by rizikový zásah vykonať bez zabezpečenia inej primeranej kópie dát.
62. WebHouse môže odmietnuť vytvorenie manuálnej zálohy, ak:

• nie je dostatok dostupnej kapacity,
• technický stav zdrojových dát neumožňuje bezpečné vytvorenie zálohy,
• služba je v stave, pri ktorom by zálohovanie mohlo zvýšiť riziko poškodenia,
• alebo požiadavka presahuje parametre objednanej služby.

63. Ak je možné problém odstrániť zmenou rozsahu alebo kapacity, WebHouse môže Zákazníkovi navrhnúť vhodné riešenie.
64. Pri podozrení na kompromitáciu alebo ransomware nemusí byť vždy vhodné okamžite vytvoriť novú manuálnu zálohu a následne odstrániť starší čistý bod obnovy.
65. WebHouse môže v takomto prípade podľa technických možností odporučiť alebo vykonať:

• zachovanie existujúceho historického bodu,
• izoláciu systému,
• vytvorenie forenznej alebo pracovnej kópie,
• alebo iný primeraný postup.

66. Zákazník by mal pri podozrení na bezpečnostný incident najskôr zvážiť zachovanie existujúcich starších záloh.
67. Samotné vytvorenie novej zálohy kompromitovaného systému nemusí vytvoriť „čistú“ zálohu.
68. Nová záloha môže obsahovať:

• malware,
• ransomware,
• backdoor,
• kompromitované účty,
• poškodené dáta,
• alebo inú časť už kompromitovaného stavu.

69. Manuálna záloha nemá byť považovaná za náhradu nezávislej zálohy kritických alebo nenahraditeľných dát.
70. Najmä snapshot alebo manuálna kópia uložená na rovnakom technickom systéme nemusí chrániť pred stratou celého tohto systému.
71. Pri kritických dátach sa preto naďalej uplatňujú povinnosti a odporúčania podľa článkov X a XI týchto Pravidiel.
72. WebHouse môže pri niektorých službách umožniť stiahnutie manuálnej zálohy Zákazníkom.
73. Ak si Zákazník zálohu stiahne, zodpovedá za jej ďalšie:

• bezpečné uloženie,
• ochranu pred stratou,
• ochranu pred neoprávneným prístupom,
• šifrovanie podľa potreby,
• kontrolu integrity.

74. WebHouse nezodpovedá za kópiu zálohy po jej prevzatí Zákazníkom mimo infraštruktúry WebHouse.
75. Ak záloha obsahuje osobné údaje, obchodné tajomstvo alebo iný citlivý obsah, Zákazník je povinný zabezpečiť jej primeranú ochranu aj po jej stiahnutí.
76. WebHouse nemusí umožňovať pri každom type manuálnej zálohy jej priame stiahnutie.
77. Niektoré zálohy môžu existovať iba v internom technickom formáte zálohovacieho systému.
78. V takom prípade môže byť záloha určená iba na obnovu prostredníctvom infraštruktúry WebHouse.
79. Zákazník nemá automatický nárok na konverziu takejto zálohy do ľubovoľného externého formátu.
80. Ak je technicky možný export alebo konverzia, môže byť poskytovaná ako osobitný alebo spoplatnený zásah.
81. Manuálna záloha nemusí byť automaticky prenositeľná medzi:

• rôznymi hostingovými platformami,
• rôznymi VPS technológiami,
• rôznymi verziami databáz,
• alebo medzi WebHouse a iným poskytovateľom.

82. Obnova manuálnej zálohy sa riadi technickými možnosťami konkrétneho systému, v ktorom bola vytvorená.
83. Samotná existencia manuálnej zálohy neznamená, že Zákazník má nárok na jej okamžitú obnovu.
84. Doba obnovy môže závisieť od:

• veľkosti zálohy,
• typu služby,
• technológie,
• rozsahu obnovy,
• aktuálneho zaťaženia systému.

85. Existencia manuálnej zálohy sama osebe nepredstavuje garantované RTO.
86. Ak Zákazník potrebuje garantovaný čas obnovy, musí byť takýto parameter výslovne dohodnutý.
87. Ak Zákazník požaduje manuálnu zálohu prostredníctvom technickej podpory, je povinný dostatočne identifikovať:

• službu,
• požadovaný rozsah,
• prípadne účel alebo požadovaný čas vytvorenia, ak je relevantný.

88. WebHouse môže požiadať o potvrdenie Zákazníka, ak vytvorenie zálohy môže:

• významne zaťažiť službu,
• spotrebovať ďalšiu kapacitu,
• byť spoplatnené,
• alebo mať iné podstatné dôsledky.

89. Požiadavka Zákazníka na vytvorenie zálohy neznamená garanciu jej vytvorenia k presne určenému času, pokiaľ nebola takáto lehota osobitne dohodnutá.
90. Ak je záloha potrebná pred konkrétnym plánovaným zásahom, Zákazník by mal o jej vytvorenie požiadať s primeraným predstihom alebo použiť samoobslužnú funkcionalitu, ak je dostupná.
91. Jednorazové vytvorenie manuálnej zálohy pracovníkom WebHouse bezplatne alebo nad rámec služby nevytvára nárok Zákazníka na rovnaký postup v budúcnosti.
92. Ak Zákazník potrebuje pravidelné manuálne zásahy WebHouse, môže byť vhodné dohodnúť samostatnú spravovanú zálohovaciu službu.
93. WebHouse môže automaticky odstrániť manuálnu zálohu aj po skončení alebo expirácii príslušnej služby podľa pravidiel retencie a ukončenia služby.
94. Zákazník je preto povinný pred ukončením služby prevziať všetky manuálne zálohy, ktoré chce ďalej uchovávať, ak služba ich stiahnutie alebo export umožňuje.
95. Skutočnosť, že manuálna záloha technicky zostala určitý čas dostupná aj po skončení služby, nevytvára nárok na jej ďalšie uchovanie.
96. Ak WebHouse v konkrétnom prípade obnoví dáta z manuálnej zálohy, ktorá zostala dostupná nad rámec štandardnej retencie, nejde tým automaticky o zmenu parametrov služby.
97. Rozsah a vlastnosti manuálnej zálohy sú vždy určené parametrami služby platnými pre príslušný typ zálohy.
98. WebHouse je povinný poskytnúť funkcionalitu manuálnych záloh v rozsahu, v akom bola výslovne dohodnutá pri konkrétnej službe.
99. Povinnosť Zákazníka kontrolovať úspešné vytvorenie manuálnej zálohy nezbavuje WebHouse zodpovednosti za správne fungovanie funkcie, ktorú sa zmluvne zaviazal poskytovať.
100. Ak systém WebHouse výslovne oznámi úspešné vytvorenie zálohy, posúdenie prípadného následného problému sa vykonáva podľa technických okolností, dohodnutých parametrov a ostatných ustanovení týchto Pravidiel.
101. Samotné používanie manuálnych záloh nemení rozsah automatického zálohovania konkrétnej služby.
102. Manuálne zálohy, automatické zálohy a snapshoty sa posudzujú podľa parametrov, ktoré platia pre každý z týchto mechanizmov.
103. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne neposkytovať funkciu manuálnej zálohy, ak bola výslovne dohodnutou súčasťou konkrétnej služby.
104. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 21

Integrita záloh

1. WebHouse používa technické a organizačné postupy primerané charakteru konkrétnej služby s cieľom znížiť riziko poškodenia, neúplnosti alebo nepoužiteľnosti vytváraných záloh.
2. Medzi takéto postupy môžu podľa konkrétnej technológie patriť najmä:
   • automatizovaná kontrola priebehu zálohovacích úloh,
   • kontrola návratových stavov a chybových hlásení,
   • kontrola dostupnosti zálohovacieho úložiska,
   • kontrola integrity zálohovacích dát,
   • kontrolné súčty alebo obdobné technické mechanizmy,
   • monitoring kapacity,
   • monitoring zálohovacích systémov,
   • opakovanie neúspešných zálohovacích operácií,
   • pravidelné testovanie vybraných obnovovacích postupov,
   • alebo iné mechanizmy primerané použitej technológii.
3. Konkrétny spôsob overovania integrity záloh závisí od:
   • typu služby,
   • použitej zálohovacej technológie,
   • formátu zálohy,
   • rozsahu dát,
   • technickej architektúry.
4. WebHouse nie je povinný používať rovnaký spôsob kontroly integrity pri všetkých druhoch služieb.
5. Úspešné dokončenie zálohovacej úlohy znamená, že zálohovací systém podľa dostupných technických indikátorov dokončil príslušný proces.
6. Úspešné dokončenie zálohovacej úlohy však samo osebe nepredstavuje absolútnu garanciu, že:
   • každý jednotlivý súbor je čitateľný,
   • každý databázový záznam je vecne správny,
   • všetky aplikačné dáta sú konzistentné,
   • každý objekt v zálohe je možné samostatne obnoviť,
   • celá aplikácia bude po obnove funkčná.
7. Pri posudzovaní záloh je potrebné rozlišovať najmä medzi:
   • technickou integritou zálohy,
   • integritou alebo správnosťou zdrojových produkčných dát,
   • praktickou obnoviteľnosťou konkrétneho systému alebo aplikácie.
8. Technicky nepoškodená záloha môže obsahovať produkčné dáta, ktoré boli poškodené už pred jej vytvorením.
9. Môže ísť napríklad o:
   • poškodený súbor,
   • chybnú databázu,
   • nesprávnu konfiguráciu,
   • aplikačne nekonzistentné dáta,
   • neoprávnene zmenené dáta,
   • malware,
   • ransomware,
   • backdoor,
   • kompromitovaný používateľský účet.
10. V takom prípade môže byť samotná záloha technicky správne vytvorená, aj keď obnovený obsah nie je pre Zákazníka použiteľný alebo bezpečný.
11. Zálohovací systém spravidla neposudzuje vecnú správnosť obsahu dát Zákazníka.
12. WebHouse preto pri vytvorení zálohy automaticky neoveruje napríklad:

• správnosť objednávok v databáze,
• správnosť účtovných údajov,
• funkčnosť zdrojového kódu,
• správnosť konfigurácie CMS,
• absenciu každej bezpečnostnej zraniteľnosti,
• správnosť obsahu jednotlivých dokumentov.

13. Vytvorenie zálohy preto nemožno považovať za potvrdenie WebHouse, že zálohované produkčné dáta boli v čase zálohovania vecne správne alebo bezchybné.
14. Napriek primeraným technickým opatreniam môže dôjsť k situácii, keď konkrétna záloha:

• nevznikne úplne,
• obsahuje iba časť očakávaných dát,
• je poškodená,
• obsahuje poškodené bloky,
• nie je možné ju otvoriť alebo pripojiť,
• nie je možné ju úplne obnoviť,
• alebo je inak technicky nepoužiteľná.

15. Takýto stav môže vzniknúť napríklad v dôsledku:

• chyby zdrojového úložiska,
• chyby zálohovacieho úložiska,
• prerušenia prenosu dát,
• softvérovej chyby,
• hardvérovej chyby,
• poškodenia súborového systému,
• nedostupnosti zdrojovej služby,
• nedostatku systémových prostriedkov,
• bezpečnostného incidentu,
• alebo inej technickej udalosti.

16. Záloha môže byť neúplná aj vtedy, ak niektoré zdrojové dáta nebolo možné počas zálohovacieho procesu prečítať.
17. To môže nastať napríklad pri:

• poškodenom súborovom systéme,
• poškodenom súbore,
• poškodenej databáze,
• nedostatočných oprávneniach,
• zablokovanom objekte,
• nedostupnom externom úložisku.

18. Ak je príčina nečitateľnosti alebo nedostupnosti dát v zákazníkom spravovanej vrstve, posudzuje sa zodpovednosť podľa rozdelenia zodpovednosti pri konkrétnej službe.
19. Ak je príčina v technickej vrstve spravovanej WebHouse, posudzuje sa zodpovednosť podľa objednanej služby, týchto Pravidiel a ostatných zmluvných podmienok.
20. WebHouse preto negarantuje absolútnu použiteľnosť každého jednotlivého bodu obnovy za všetkých okolností.
21. Toto ustanovenie však neznamená, že WebHouse môže dlhodobo alebo systematicky prevádzkovať zálohovaciu službu spôsobom, pri ktorom vytvárané zálohy nie sú použiteľné.
22. WebHouse je povinný zálohovaciu službu prevádzkovať s primeranou odbornou starostlivosťou a v rozsahu dohodnutých parametrov konkrétnej služby.
23. Jednorazová technická nepoužiteľnosť konkrétneho bodu obnovy sa posudzuje odlišne od:

• opakovaného poškodzovania záloh,
• dlhodobého zlyhávania zálohovacieho systému,
• systematického nevytvárania použiteľných bodov obnovy.

24. Ak by zálohovací systém dlhodobo nevytváral použiteľné zálohy v rozsahu nezodpovedajúcom objednanej službe, môže ísť podľa okolností o vadu alebo poruchu služby.
25. Samotná existencia jedného poškodeného bodu obnovy však automaticky neznamená, že zálohovacia služba ako celok bola poskytovaná vadne.
26. Pri posudzovaní sa prihliada najmä na:

• počet dostupných bodov obnovy,
• počet poškodených bodov,
• príčinu poškodenia,
• frekvenciu výskytu,
• rozsah objednanej služby,
• technické okolnosti incidentu.

27. Ak je k dispozícii viac bodov obnovy a najnovší z nich nie je použiteľný, WebHouse môže použiť starší použiteľný bod obnovy.
28. Použitie staršieho bodu obnovy môže viesť k väčšiemu rozsahu straty novších dát.
29. Ak napríklad:

• posledná záloha nie je použiteľná,
• ale predchádzajúca záloha je použiteľná,

môže byť obnova vykonaná z predchádzajúceho bodu.

30. V takom prípade nebudú v obnovenej kópii obsiahnuté dáta vytvorené alebo zmenené medzi starším použiteľným bodom a incidentom.
31. WebHouse môže Zákazníkovi oznámiť, že najnovší dostupný použiteľný bod obnovy je starší než pôvodne požadovaný bod.
32. Ak je k dispozícii viac použiteľných bodov, môže výber vhodného bodu vyžadovať súčinnosť Zákazníka.
33. WebHouse nemusí vedieť určiť, ktorý historický bod obsahuje posledný vecne správny alebo funkčný stav zákazníckej aplikácie.
34. Zákazník preto môže byť vyzvaný, aby určil:

• približný čas vzniku problému,
• požadovaný historický stav,
• alebo preferovaný dostupný bod obnovy.

35. Ak najnovší bod obsahuje už poškodený alebo kompromitovaný stav produkčných dát, môže byť vhodné použiť výrazne starší bod obnovy.
36. Najnovšia technicky použiteľná záloha preto nemusí byť zároveň najvhodnejšou zálohou na obnovu.
37. Pri bezpečnostnom incidente môže byť potrebné preveriť viac historických bodov s cieľom nájsť stav pred kompromitáciou.
38. WebHouse však negarantuje, že bude možné presne určiť okamih vzniku kompromitácie alebo poškodenia.
39. Ak sa incident zistí až po dlhšom čase, môžu všetky dostupné body obnovy už obsahovať rovnaký kompromitovaný alebo poškodený stav.
40. V takom prípade nemusí existovať použiteľná záloha spred vzniku incidentu.
41. Integrita technickej zálohy sa preto nesmie zamieňať s „čistotou“ zálohy z bezpečnostného hľadiska.
42. Technicky bezchybná záloha môže byť z bezpečnostného hľadiska nevhodná na okamžité obnovenie do produkcie.
43. WebHouse môže pri podozrení na kompromitovanú zálohu vykonať obnovu najprv do:

• izolovaného prostredia,
• dočasného priestoru,
• alebo iného bezpečného technického prostredia,

ak to možnosti služby umožňujú.

44. WebHouse môže odmietnuť bezprostredné pripojenie zjavne kompromitovaného obnoveného systému do verejnej siete, ak by tým mohlo dôjsť k ďalšiemu ohrozeniu.
45. Obnova zálohy nepredstavuje bezpečnostné potvrdenie, že obnovený obsah neobsahuje škodlivý kód.
46. Ak Zákazník potrebuje bezpečnostnú analýzu, malware scan alebo forenznú kontrolu obnoveného systému, môže ísť o samostatnú službu.
47. Nie je technicky ani prevádzkovo primerané vykonávať po každom vytvorení každej zálohy úplnú testovaciu obnovu všetkých zákazníckych dát.
48. WebHouse preto nemusí po každom zálohovacom cykle vykonávať úplný restore každého:

• webhostingového účtu,
• databázového systému,
• e-mailového účtu,
• VPS,
• alebo dedikovaného servera.

49. Overovanie funkčnosti zálohovacieho systému môže byť vykonávané výberovým, automatizovaným alebo iným technicky primeraným spôsobom.
50. Konkrétny spôsob testovania je interným technickým procesom WebHouse, pokiaľ pri konkrétnej službe nie je dohodnutý osobitný režim testovania obnovy.
51. Ak Zákazník potrebuje pravidelne garantované úplné testovacie obnovy svojich dát, musí byť takáto služba výslovne objednaná alebo individuálne dohodnutá.
52. Skutočnosť, že záloha nebola pred incidentom individuálne testovaná úplnou obnovou, sama osebe neznamená, že zálohovacia služba bola poskytovaná nesprávne.
53. WebHouse môže pri kontrole integrity používať kontrolné súčty alebo obdobné mechanizmy.
54. Takýto mechanizmus môže potvrdiť, že uložené dáta sa od určitého momentu nezmenili, nemusí však potvrdiť, že zdrojové dáta boli už pri vytvorení zálohy bezchybné.
55. Kontrola integrity zálohy preto nie je automaticky kontrolou správnosti zdrojových dát.
56. Pri inkrementálnych alebo diferenciálnych zálohách môže byť konkrétny bod obnovy závislý od viacerých častí zálohovacieho reťazca.
57. Poškodenie jednej časti reťazca môže podľa technológie ovplyvniť:

• jeden bod obnovy,
• viacero bodov obnovy,
• alebo celý závislý reťazec.

58. WebHouse môže používať technické mechanizmy na obmedzenie takéhoto rizika, avšak úplné odstránenie všetkých technických rizík nemožno garantovať.
59. Pri zálohovacom systéme používajúcom deduplikáciu môžu viaceré zálohy používať spoločné fyzické dátové bloky.
60. Samotný počet viditeľných bodov obnovy preto nemusí znamenať existenciu rovnakého počtu úplne samostatných fyzických kópií všetkých dát.
61. Technická architektúra zálohovacieho systému môže byť z bezpečnostných a prevádzkových dôvodov internou informáciou WebHouse.
62. Zákazník nemá nárok na zverejnenie detailov, ktoré by mohli:

• ohroziť bezpečnosť systému,
• odhaliť internú architektúru,
• alebo zvýšiť riziko zneužitia.

63. Tým nie je dotknuté právo Zákazníka na informácie o zmluvne relevantných parametroch jeho služby.
64. Pri obnove môže byť technická integrita zálohy overovaná až počas samotného obnovovacieho procesu.
65. Niektoré chyby sa môžu prejaviť až pri:

• dekompresii,
• dešifrovaní,
• rekonštrukcii inkrementálneho reťazca,
• pripojení virtuálneho disku,
• importe databázy,
• alebo inom konkrétnom obnovovacom úkone.

66. Skutočnosť, že záloha bola uložená bez predchádzajúceho chybového hlásenia, preto nemusí absolútne vylúčiť neskôr zistenú chybu.
67. Ak sa pri obnove zistí chyba konkrétneho bodu, WebHouse môže podľa možností:

• použiť alternatívny bod obnovy,
• zopakovať obnovovací proces,
• použiť inú dostupnú kópiu,
• alebo vykonať iný primeraný technický zásah.

68. WebHouse však negarantuje možnosť opraviť každú poškodenú zálohu.
69. WebHouse rovnako negarantuje rekonštrukciu dát, ktoré sa nenachádzajú v žiadnom použiteľnom bode obnovy.
70. Ak sú všetky dostupné zálohy technicky nepoužiteľné, možnosť ďalšej obnovy závisí od:

• existencie iných kópií dát,
• charakteru poškodenia,
• dostupnosti produkčných dát,
• externých záloh Zákazníka.

71. V takom prípade môže byť jedinou možnosťou obnova z vlastnej nezávislej zálohy Zákazníka.
72. Z tohto dôvodu sa pri kritických alebo nenahraditeľných dátach uplatňujú povinnosti a odporúčania podľa článkov X a XI týchto Pravidiel.
73. Zákazník by nemal považovať úspešný status automatickej zálohovacej úlohy za náhradu vlastnej zálohovacej stratégie pri kritických dátach.
74. Ak služba poskytuje Zákazníkovi možnosť kontrolovať dostupné body obnovy, Zákazník by mal pri kritických dátach primerane využívať túto možnosť.
75. Ak Zákazník zistí nezrovnalosť v dostupných zálohách, mal by ju WebHouse oznámiť bez zbytočného odkladu.
76. Včasné oznámenie môže umožniť preveriť problém ešte počas obdobia, keď existujú ďalšie historické body obnovy alebo technické údaje potrebné na diagnostiku.
77. Neskoré oznámenie môže viesť k tomu, že medzičasom dôjde k štandardnej rotácii starších záloh.
78. Integrita zálohy neznamená automaticky, že po obnove bude funkčná celá aplikácia alebo služba.
79. Funkčnosť môže byť ovplyvnená napríklad:

• zmenou verzie PHP,
• zmenou databázového systému,
• zmenou operačného systému,
• zmenou konfigurácie,
• externou službou,
• expirovanou licenciou,
• DNS,
• alebo inou technickou závislosťou.

80. Ak sú obnovené dáta technicky úplné, ale aplikácia ich pre inú príčinu nedokáže používať, nemusí ísť o porušenie integrity zálohy.
81. Rovnako úspešné spustenie aplikácie po obnove nie je jediným kritériom technickej integrity zálohy.
82. Pri posudzovaní sa vždy odlišuje:

• obsah zálohy,
• proces obnovy,
• aplikačná funkčnosť po obnove.

83. Samotná nemožnosť obnoviť jeden konkrétny súbor zo zálohy, ktorej technická jednotka je celý server alebo celý image, nemusí znamenať poškodenie zálohy.
84. Môže ísť iba o obmedzenie spôsobu selektívnej obnovy.
85. Preto treba odlišovať nepoužiteľnú zálohu od zálohy, ktorá neumožňuje Zákazníkom požadovaný spôsob obnovy.
86. Ak je možné zálohu obnoviť ako celý technický celok, ale nie extrahovať jednu konkrétnu položku priamo zo zálohovacieho systému, záloha sa nemusí považovať za poškodenú.
87. Integrita manuálnych záloh alebo snapshotov vytvorených Zákazníkom sa posudzuje podľa technológie a rozsahu príslušnej služby.
88. Ak Zákazník spravuje vlastný zálohovací systém, zodpovedá za kontrolu integrity vlastných záloh podľa článku XIX.
89. Ak WebHouse poskytuje iba zálohovacie úložisko a samotnú zálohu vytvára Zákazník, WebHouse nezodpovedá automaticky za integritu formátu alebo obsahu zákazníkom vytvorenej zálohy.
90. WebHouse v takom prípade zodpovedá za poskytovanie objednaného úložiska v dohodnutom rozsahu.
91. Ak WebHouse poskytuje spravovanú zálohovaciu službu, zodpovedá za technické procesy, ktoré podľa parametrov tejto služby spravuje.
92. Rozdelenie zodpovednosti sa preto vždy posudzuje podľa konkrétneho rozsahu objednanej služby.
93. WebHouse môže pri zistení systémového problému so zálohovaním vykonať primerané opatrenia, najmä:

• opravu konfigurácie,
• opravu alebo výmenu komponentu,
• zmenu zálohovacieho mechanizmu,
• opätovné vytvorenie záloh,
• migráciu na iné zálohovacie úložisko.

94. Konkrétne opatrenie závisí od charakteru a rozsahu problému.
95. WebHouse nie je povinný zachovať poškodenú zálohu neobmedzene iba preto, že je predmetom technickej chyby.
96. Ak však jej zachovanie môže byť primerane potrebné na diagnostiku závažného incidentu alebo na splnenie právnej povinnosti, WebHouse ju môže dočasne uchovať nad rámec bežného cyklu.
97. Takéto technické uchovanie nemení štandardnú retenčnú dobu služby.
98. Skutočnosť, že WebHouse pri konkrétnom incidente úspešne obnoví dáta z alternatívnej alebo internej technickej kópie, nevytvára automaticky nový garantovaný bod obnovy pre budúce prípady.
99. Rovnako úspešná obnova z jedného bodu v minulosti neznamená absolútnu garanciu použiteľnosti každého budúceho bodu obnovy.
100. Pri kritických službách môže byť možné individuálne dohodnúť vyššiu úroveň overovania integrity, napríklad:

• pravidelné testovacie obnovy,
• overovanie vybraných databáz,
• kontrolné obnovovacie testy,
• osobitný monitoring,
• nezávislé záložné kópie.

101. Takáto vyššia úroveň kontroly musí byť výslovne súčasťou objednanej alebo individuálne dohodnutej služby.
102. Štandardná zálohovacia služba nemusí zahŕňať úplnú testovaciu obnovu každej zálohy každého Zákazníka.
103. WebHouse je povinný zabezpečovať technickú integritu zálohovania v rozsahu primeranom charakteru služby a dodržiavať výslovne dohodnuté parametre.
104. Povinnosť Zákazníka používať pri kritických dátach vlastnú nezávislú zálohu nezbavuje WebHouse zodpovednosti za riadne poskytovanie jeho vlastnej zálohovacej služby.
105. Samotná existencia poškodeného bodu obnovy však automaticky neznamená vznik nároku na náhradu škody alebo uznanie vady celej služby.
106. Každý prípad sa posudzuje najmä podľa:

• príčiny poškodenia,
• rozsahu objednanej služby,
• počtu dostupných alternatívnych bodov,
• dohodnutých parametrov zálohovania,
• rozsahu skutočného dopadu,
• a povinností jednotlivých strán.

107. Ak WebHouse výslovne garantuje konkrétnu vlastnosť integrity, počet použiteľných bodov obnovy alebo inú obdobnú vlastnosť, všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie takejto garancie.
108. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne alebo systematicky prevádzkovať zálohovaciu službu spôsobom, ktorý nezodpovedá jej dohodnutým parametrom.
109. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 22

Záloha môže obsahovať poškodené alebo kompromitované dáta

1. Zálohovací systém spravidla zachytáva alebo kopíruje stav dát existujúcich v čase vytvorenia príslušného bodu obnovy.
2. Zálohovací systém preto nemusí vedieť rozlíšiť, či sú produkčné dáta:
   • vecne správne,
   • úplné,
   • bezpečné,
   • nepoškodené,
   • alebo bez neoprávnených zásahov.

3. Ak boli produkčné dáta pred vytvorením zálohy:

   • poškodené,
   • nesprávne upravené,
   • neúplné,
   • kompromitované,
   • infikované malvérom,
   • zašifrované ransomvérom,
   • obsahovali backdoor,
   • obsahovali neoprávnene vytvorený používateľský účet,
   • obsahovali škodlivý skript,
   • alebo boli iným spôsobom zmenené v dôsledku bezpečnostného incidentu,

   môže záloha obsahovať rovnaký stav.

4. Technicky správne vytvorená záloha preto môže obsahovať dáta, ktoré sú z aplikačného, bezpečnostného alebo obchodného hľadiska nevhodné na obnovenie do produkčného prostredia.
5. Skutočnosť, že záloha obsahuje kompromitovaný alebo poškodený obsah, sama osebe neznamená, že zálohovací proces bol technicky chybný, ak záloha korektne zachytila stav produkčných dát existujúci v čase jej vytvorenia.
6. Pri posudzovaní je preto potrebné rozlišovať medzi:
   • poškodením samotnej zálohy,
   • poškodením alebo kompromitáciou zdrojových dát, ktoré sa do zálohy preniesli.
7. Zálohovací systém spravidla nevykonáva úplnú obsahovú alebo bezpečnostnú analýzu všetkých zálohovaných dát.
8. WebHouse preto vytvorením zálohy automaticky nepotvrdzuje, že jej obsah:
   • neobsahuje malware,
   • neobsahuje ransomware,
   • neobsahuje backdoor,
   • neobsahuje zraniteľnú aplikáciu,
   • neobsahuje neoprávnene zmenené dáta,
   • predstavuje posledný bezpečný stav služby.
9. Zálohovanie nie je automaticky antivírusovou, antimalvérovou, forenznou ani bezpečnostnou službou.
10. Ak je pri konkrétnej službe používaný antivírusový alebo iný bezpečnostný mechanizmus, ani jeho použitie nepredstavuje absolútnu garanciu odhalenia všetkých škodlivých alebo kompromitovaných dát.
11. Niektoré bezpečnostné incidenty môžu zostať určitý čas nezistené.
12. Ak kompromitácia vznikne napríklad niekoľko dní alebo týždňov pred jej odhalením, môže byť kompromitovaný stav postupne zahrnutý do viacerých záloh.
13. V takom prípade môžu viaceré alebo všetky aktuálne dostupné body obnovy obsahovať:

• rovnaký malware,
• rovnaký backdoor,
• rovnakú zraniteľnosť,
• rovnaký neoprávnene vytvorený účet,
• alebo inú časť kompromitovaného stavu.

14. Väčší počet dostupných záloh preto automaticky neznamená, že aspoň jedna z nich musí obsahovať bezpečný stav spred incidentu.
15. Ak sa kompromitácia zistí až po uplynutí retenčnej doby starších záloh, posledný bod obnovy spred incidentu už nemusí existovať.
16. Pri dlhodobo nezistenom incidente preto môže nastať stav, keď nie je k dispozícii žiadna záloha, o ktorej možno spoľahlivo predpokladať, že vznikla pred kompromitáciou.
17. Zákazník by mal pri podozrení na bezpečnostný incident informovať WebHouse bez zbytočného odkladu.
18. Včasné oznámenie môže zvýšiť možnosť:

• zachovať starší bod obnovy,
• zabrániť jeho odstráneniu v rámci rotácie,
• identifikovať vhodnejší historický stav,
• izolovať kompromitovaný systém.

19. WebHouse však negarantuje, že bude pri každom incidente technicky možné:

• zastaviť rotáciu záloh,
• zachovať požadovaný bod obnovy,
• alebo identifikovať posledný bezpečný bod obnovy.

20. Pri bezpečnostnom incidente nemusí byť najnovšia záloha najvhodnejšou zálohou na obnovu.
21. Ak je známe alebo pravdepodobné, že kompromitácia vznikla pred vytvorením najnovšej zálohy, môže byť potrebné použiť starší bod obnovy.
22. Výber bodu obnovy môže závisieť najmä od:

• predpokladaného času incidentu,
• času posledného známeho bezpečného stavu,
• dostupných historických bodov,
• výsledkov bezpečnostnej analýzy,
• informácií poskytnutých Zákazníkom.

23. WebHouse nemusí vedieť sám určiť presný okamih, keď ku kompromitácii došlo.
24. Samotný čas, keď Zákazník incident zistil, nemusí byť totožný s časom jeho vzniku.
25. Kompromitácia mohla začať podstatne skôr a zostať určitý čas bez viditeľných prejavov.
26. WebHouse preto negarantuje, že bod obnovy bezprostredne pred nahlásením incidentu predstavuje bezpečný stav.
27. Pri závažnej kompromitácii môže byť potrebné preveriť viac historických bodov obnovy.
28. Takéto preverovanie môže zahŕňať napríklad:

• kontrolu súborov,
• kontrolu databázy,
• porovnanie zmien,
• kontrolu používateľských účtov,
• kontrolu vybraných logov,
• malware scan,
• alebo inú bezpečnostnú analýzu.

29. Takáto činnosť nie je automaticky súčasťou štandardnej zálohovacej služby.
30. Individuálna analýza historických záloh môže predstavovať:

• technickú podporu nad rámec služby,
• platený administrátorský zásah,
• alebo samostatnú bezpečnostnú službu.

31. WebHouse nemusí byť schopný vykonať plnohodnotnú forenznú analýzu každej kompromitovanej služby.
32. Ak je potrebná odborná forenzná analýza, môže byť potrebné zapojenie špecializovaného bezpečnostného odborníka.
33. Obnovenie zálohy samo osebe nezaručuje odstránenie bezpečnostného incidentu.
34. Po obnove môže byť na úplné odstránenie incidentu potrebné najmä:

• odstrániť zraniteľný softvér,
• aktualizovať aplikáciu,
• aktualizovať plugin alebo modul,
• odstrániť malware,
• odstrániť backdoor,
• zmeniť prístupové údaje,
• zrušiť kompromitované účty,
• zmeniť API kľúče,
• zmeniť SSH kľúče,
• zmeniť databázové heslá,
• preveriť zariadenia Zákazníka,
• opraviť chybnú konfiguráciu,
• alebo vykonať ďalšie bezpečnostné opatrenia.

35. Ak sa odstráni iba poškodený obsah a neodstráni sa príčina incidentu, môže dôjsť k opakovanej kompromitácii aj po úspešnej obnove.
36. Typickým príkladom je obnova webovej stránky obsahujúcej stále rovnaký zraniteľný CMS, plugin, tému alebo vlastný kód.
37. Ak sa zraniteľnosť neodstráni, môže útočník obnovenú službu opätovne kompromitovať.
38. Zákazník zodpovedá za odstránenie príčiny incidentu v tej vrstve služby, ktorú podľa zmluvných podmienok spravuje Zákazník.
39. WebHouse zodpovedá za bezpečnostné opatrenia a nápravné kroky v tej vrstve služby, ktorú podľa zmluvných podmienok spravuje WebHouse.
40. Samotná skutočnosť, že Zákazník používal:

• aktuálnu aplikáciu,
• bezpečnostný plugin,
• silné heslo,
• viacfaktorovú autentifikáciu,
• alebo iné odporúčané bezpečnostné opatrenie,

automaticky nemení rozdelenie zodpovednosti medzi WebHouse a Zákazníka.

41. Rozhodujúce je, v ktorej technickej vrstve vznikla príčina kompromitácie a ktorá strana bola za túto vrstvu zodpovedná.
42. Ak kompromitácia vznikla v aplikácii, účte alebo inom zákazníkom spravovanom komponente, samotná existencia primeraných bezpečnostných opatrení na strane Zákazníka automaticky nezakladá zodpovednosť WebHouse za následky tejto kompromitácie.
43. Ak kompromitácia vznikla v dôsledku porušenia povinnosti alebo bezpečnostného zlyhania na strane WebHouse, zodpovednosť sa posudzuje podľa príslušných zmluvných podmienok a všeobecne záväzných právnych predpisov.
44. Obnova kompromitovanej zálohy môže za určitých okolností predstavovať bezpečnostné riziko aj pre infraštruktúru WebHouse alebo tretie strany.
45. WebHouse preto môže odmietnuť okamžité obnovenie zjavne kompromitovaného systému priamo do verejne dostupného produkčného prostredia.
46. WebHouse môže podľa technických možností namiesto toho vykonať obnovu:

• do izolovaného prostredia,
• do dočasného priestoru,
• na systém bez verejného sieťového prístupu,
• alebo iným bezpečným spôsobom.

47. Takýto postup môže byť použitý najmä pri podozrení na:

• aktívny malware,
• ransomware,
• botnetový kód,
• spamovací malware,
• webshell,
• backdoor,
• alebo inú aktívnu kompromitáciu.

48. Ochrana infraštruktúry, ostatných zákazníkov a tretích strán môže v takom prípade odôvodniť dočasné obmedzenie produkčného spustenia obnovenej služby.
49. WebHouse môže pred opätovným pripojením služby do produkcie požadovať vykonanie primeraných nápravných opatrení.
50. Obnova môže byť za určitých okolností vykonaná iba s cieľom:

• zachrániť dáta,
• vykonať analýzu,
• alebo vytvoriť čistú rekonštrukciu služby.

51. Pri vážnej kompromitácii nemusí byť vždy najbezpečnejším postupom obnovenie celého systému zo starej zálohy.
52. Bezpečnejším postupom môže byť napríklad:

• vytvorenie nového čistého prostredia,
• nová inštalácia operačného systému,
• nová inštalácia aplikácie,
• následný prenos iba overených zákazníckych dát.

53. Rozhodnutie o vhodnom postupe závisí od charakteru incidentu a rozsahu objednanej služby.
54. WebHouse negarantuje, že každú kompromitovanú aplikáciu alebo server možno bezpečne vyriešiť jednoduchým restore zo zálohy.
55. Záloha môže obsahovať aj ransomwarem zašifrované dáta.
56. Ak ransomware zašifroval produkčné dáta pred vytvorením zálohy, zálohovací systém môže korektne zazálohovať už zašifrované súbory.
57. Ak sa incident nezistí včas, môžu nové zálohy postupne nahradiť staršie nezasiahnuté body obnovy.
58. Automatická rotácia preto môže postupne znížiť počet dostupných čistých historických bodov.
59. Samotné zálohovanie nie je absolútnou ochranou pred ransomvérom.
60. Úroveň ochrany pred ransomvérom môže zvýšiť najmä kombinácia:

• primeranej retencie,
• technicky oddeleného zálohovacieho systému,
• nemenných záloh,
• offline záloh,
• nezávislej zálohy Zákazníka,
• rýchlej detekcie incidentu.

61. Štandardná služba WebHouse nemusí automaticky obsahovať všetky uvedené mechanizmy.
62. Ak Zákazník vyžaduje konkrétnu ochranu, napríklad nemenné alebo dlhodobo izolované zálohy, musí byť takáto vlastnosť súčasťou objednanej služby.
63. Obdobný princíp platí pri neúmyselnom alebo nesprávnom zásahu Zákazníka.
64. Ak Zákazník napríklad:

• hromadne zmení databázu,
• odstráni veľké množstvo dát,
• prepíše konfiguráciu,
• alebo vykoná chybnú migráciu,

môže byť tento chybný stav zahrnutý do nasledujúcich záloh.

65. Zálohovací systém spravidla nevie, že takáto zmena bola nežiaduca.
66. Automatická záloha preto môže korektne zachytiť aj chybnú administrátorskú operáciu.
67. Pri včasnom zistení môže byť možné obnoviť stav zo staršieho bodu pred chybnou zmenou.
68. Pri neskorom zistení môže byť príslušný starší bod už odstránený v rámci retenčného cyklu.
69. Zákazník by preto mal závažnú stratu alebo poškodenie dát hlásiť bez zbytočného odkladu.
70. Obnova zo zálohy nemusí automaticky obnoviť všetky bezpečnostné prvky súvisiace so službou.
71. Samostatnú kontrolu alebo zmenu môžu vyžadovať napríklad:

• heslá,
• API tokeny,
• SSH kľúče,
• certifikáty,
• MFA nastavenia,
• externé integrácie,
• DNS,
• firewallové pravidlá.

72. Ak boli tieto údaje kompromitované, návrat dát do staršieho stavu nemusí kompromitáciu týchto prístupových mechanizmov odstrániť.
73. Po bezpečnostnom incidente môže byť preto potrebné vykonať tzv. credential rotation alebo inú primeranú výmenu prístupových údajov.
74. Zákazník zodpovedá za výmenu údajov, ktoré spravuje vo svojej vrstve služby.
75. WebHouse môže vykonať výmenu alebo reset údajov, ktoré spravuje vo svojej vrstve služby.
76. Obnova zálohy rovnako nemusí obnoviť dôveryhodnosť služby voči externým systémom.
77. Napríklad po kompromitácii e-mailového servera alebo webu môžu externé systémy určitý čas evidovať:

• zhoršenú reputáciu IP adresy,
• blokáciu domény,
• bezpečnostné upozornenia,
• alebo inú reputačnú informáciu.

78. Samotný restore dát tieto externé následky nemusí automaticky odstrániť.
79. WebHouse negarantuje okamžité odstránenie následkov, ktoré sú pod kontrolou externých poskytovateľov.
80. Zálohy môžu obsahovať aj osobné údaje alebo iný citlivý obsah, ktorý bol predmetom bezpečnostného incidentu.
81. Obnova takýchto dát nemení povinnosti Zákazníka alebo WebHouse súvisiace s riešením bezpečnostného incidentu alebo porušenia ochrany osobných údajov.
82. Ak incident predstavuje porušenie ochrany osobných údajov, postupuje sa aj podľa DPA a príslušných pravidiel ochrany osobných údajov.
83. Samotné úspešné obnovenie dát neznamená, že incident prestáva byť relevantný z pohľadu prípadných právnych alebo oznamovacích povinností.
84. WebHouse môže v odôvodnenom prípade určitú kompromitovanú zálohu alebo technickú kópiu dočasne uchovať na účely:

• analýzy incidentu,
• ochrany dôkazov,
• obnovy dát,
• splnenia právnej povinnosti.

85. Takéto uchovanie môže trvať aj dlhšie než štandardná retencia, ak je na to primeraný právny alebo bezpečnostný dôvod.
86. Mimoriadne uchovanie konkrétnej zálohy však neznamená všeobecnú zmenu retenčnej politiky služby.
87. WebHouse nie je povinný uchovávať každú kompromitovanú zálohu na forenzné účely, pokiaľ takáto povinnosť nevyplýva z osobitnej dohody alebo právneho predpisu.
88. Ak Zákazník potrebuje zachovať konkrétny bod obnovy na účely vlastnej analýzy alebo dokazovania, mal by o to požiadať bez zbytočného odkladu.
89. Možnosť zachovania závisí od technológie, existencie príslušného bodu a štandardnej rotácie.
90. WebHouse negarantuje, že požiadavka podaná až po odstránení príslušného bodu obnovy umožní jeho spätné získanie.
91. Zákazník by mal pri kritických systémoch používať viacvrstvovú ochranu podľa článkov X a XI.
92. Najmä pri riziku ransomvéru alebo dlhodobo nezistenej kompromitácie je vhodná nezávislá záloha s odlišnou retenčnou alebo bezpečnostnou politikou.
93. Záloha WebHouse nemá byť jedinou existujúcou kópiou kritických alebo nenahraditeľných dát.
94. Povinnosť Zákazníka používať vlastnú zálohu však nezbavuje WebHouse zodpovednosti za riadne poskytovanie zálohovania v rozsahu konkrétnej objednanej služby.
95. Samotná prítomnosť kompromitovaných dát v zálohe automaticky nepredstavuje vadu zálohovacej služby, ak takýto obsah zodpovedal stavu zdrojových dát.
96. Iná situácia nastáva, ak k poškodeniu alebo kompromitácii zálohy došlo až v zálohovacom systéme WebHouse.
97. V takom prípade sa príčina a zodpovednosť posudzujú podľa:

• technických okolností incidentu,
• rozsahu objednanej služby,
• bezpečnostných povinností WebHouse,
• a ostatných zmluvných podmienok.

98. Pri posúdení bezpečnostného incidentu sa preto odlišuje:

• kompromitácia produkčných dát pred vytvorením zálohy,
• kompromitácia samotnej zálohy po jej vytvorení,
• technické poškodenie zálohy,
• a nevhodnosť zálohy na obnovu z dôvodu obsahu, ktorý už bol kompromitovaný.

99. Toto rozlíšenie je rozhodujúce aj pri posudzovaní zodpovednosti jednotlivých strán.
100. WebHouse negarantuje, že každá dostupná záloha predstavuje bezpečnostne čistý stav.
101. Ak je však pri konkrétnej službe výslovne dohodnutá osobitná vlastnosť, napríklad malware scanning záloh, immutable backup alebo iná bezpečnostná funkcia, WebHouse je povinný túto vlastnosť poskytovať v dohodnutom rozsahu.
102. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie výslovne dohodnutých bezpečnostných parametrov zálohovacej služby.
103. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 23

Malware v zálohách

1. Záloha môže obsahovať škodlivý kód, ktorý sa v čase vytvorenia zálohy nachádzal v produkčných dátach.
2. Za škodlivý alebo potenciálne škodlivý obsah sa na účely týchto Pravidiel môže považovať najmä:
   • vírus,
   • trojan,
   • ransomware,
   • webshell,
   • backdoor,
   • rootkit,
   • škodlivý skript,
   • škodlivý plugin alebo modul,
   • neoprávnene vložený kód,
   • nástroj určený na ďalšie šírenie útoku,
   • alebo iný obsah schopný ohroziť systém, dáta alebo tretie strany.
3. Ak bol škodlivý kód prítomný v produkčných dátach pred vytvorením zálohy, môže byť technicky správne zahrnutý aj do príslušného bodu obnovy.
4. Skutočnosť, že záloha obsahuje malware, preto sama osebe neznamená, že zálohovací proces zlyhal.
5. Pri posudzovaní je potrebné rozlišovať medzi:
   • škodlivým obsahom, ktorý bol už súčasťou produkčných dát,
   • a kompromitáciou alebo infikovaním samotnej zálohy až po jej vytvorení.
6. WebHouse nie je povinný vykonávať individuálnu antivírusovú, antimalvérovú alebo forenznú analýzu každej vytvorenej zálohy, pokiaľ takáto služba nie je výslovne súčasťou konkrétneho produktu.
7. Zálohovací systém môže obsahovať automatizované bezpečnostné alebo kontrolné mechanizmy, ich použitie však neznamená absolútnu garanciu, že bude identifikovaný každý škodlivý súbor alebo kompromitovaný stav.
8. Antivírusové a obdobné bezpečnostné mechanizmy môžu byť založené najmä na:
   • signatúrach,
   • heuristike,
   • reputačných údajoch,
   • behaviorálnej analýze,
   • alebo inom automatizovanom vyhodnocovaní.
9. Žiadny takýto mechanizmus nemusí byť schopný identifikovať všetky:
   • nové druhy malvéru,
   • upravené varianty existujúceho malvéru,
   • obfuskovaný kód,
   • zero-day útoky,
   • zákaznícky špecifické backdoory,
   • škodlivý obsah ukrytý v legitímnych súboroch.
10. Skutočnosť, že určitý bod obnovy nebol označený bezpečnostným systémom ako škodlivý, preto neznamená potvrdenie WebHouse, že je bezpečnostne čistý.
11. Malware môže byť v systéme prítomný dlhší čas bez toho, aby sa navonok prejavil.
12. Kompromitovaný systém môže napríklad obsahovať backdoor, ktorý útočník nepoužíva okamžite alebo ho používa iba príležitostne.
13. Z tohto dôvodu môžu byť aj viaceré historické zálohy vytvorené počas obdobia, keď bol systém už kompromitovaný, hoci Zákazník o incidente ešte nevedel.
14. Pri obnove kompromitovaného systému preto nemusí byť najnovší bod obnovy vhodným bodom na návrat.
15. V závislosti od času vzniku incidentu môže byť potrebné použiť starší bod obnovy.
16. WebHouse však negarantuje, že bude možné presne určiť posledný bod obnovy, ktorý malware ešte neobsahoval.
17. Určenie posledného bezpečného stavu môže vyžadovať:

• bezpečnostnú analýzu,
• kontrolu historických súborov,
• kontrolu logov,
• kontrolu databázy,
• porovnanie viacerých bodov obnovy,
• alebo inú odbornú činnosť.

18. Takáto činnosť nie je automaticky súčasťou štandardnej zálohovacej služby.
19. Individuálna analýza kompromitovaného systému alebo historických záloh môže byť poskytovaná:

• v rozsahu technickej podpory,
• ako spoplatnený administrátorský zásah,
• alebo ako osobitná bezpečnostná služba,

podľa konkrétneho prípadu a ponuky WebHouse.

20. WebHouse nie je povinný vykonať úplnú forenznú analýzu systému iba na základe požiadavky na obnovu zo zálohy.
21. Pred obnovením kompromitovaného systému môže byť potrebné najmä:

• zvoliť starší bod obnovy,
• identifikovať pravdepodobný čas kompromitácie,
• odstrániť známy škodlivý kód,
• aktualizovať operačný systém alebo aplikáciu,
• aktualizovať CMS,
• aktualizovať pluginy, moduly alebo témy,
• odstrániť nepoužívané alebo zraniteľné komponenty,
• odstrániť backdoor,
• zmeniť prístupové údaje,
• zmeniť databázové heslá,
• zmeniť API tokeny,
• zmeniť SSH kľúče,
• preveriť používateľské účty,
• preveriť externé zariadenia alebo počítače Zákazníka.

22. Samotné obnovenie staršej zálohy bez odstránenia príčiny incidentu nemusí viesť k trvalému odstráneniu malvéru.
23. Ak napríklad kompromitáciu spôsobila stále existujúca zraniteľnosť webovej aplikácie, môže po obnovení dôjsť k opätovnému napadnutiu.
24. Obdobne môže dôjsť k opätovnej kompromitácii, ak útočník naďalej disponuje:

• platným heslom,
• API kľúčom,
• SSH kľúčom,
• ukradnutým session tokenom,
• alebo iným funkčným prístupovým údajom.

25. Obnova dát preto musí byť pri bezpečnostnom incidente podľa potreby kombinovaná s nápravnými opatreniami.
26. Zákazník zodpovedá za nápravné opatrenia v tej časti služby, ktorú podľa podmienok služby spravuje Zákazník.
27. WebHouse zodpovedá za nápravné opatrenia v tej časti služby, ktorú podľa podmienok služby spravuje WebHouse.
28. Obnova kompromitovanej aplikácie zo zálohy neznamená automaticky prevzatie zodpovednosti WebHouse za bezpečnosť tejto aplikácie do budúcnosti.
29. WebHouse môže pred obnovením kompromitovaného systému požadovať primeranú súčinnosť Zákazníka.
30. Môže ísť napríklad o:

• potvrdenie požadovaného bodu obnovy,
• informáciu o predpokladanom čase incidentu,
• zmenu hesiel,
• aktualizáciu aplikácie,
• odstránenie zraniteľného komponentu,
• alebo zabezpečenie správcu aplikácie.

31. Ak by okamžité obnovenie kompromitovanej zálohy do verejne dostupného produkčného prostredia predstavovalo bezpečnostné riziko, WebHouse môže takúto obnovu dočasne odmietnuť alebo obmedziť.
32. WebHouse môže podľa technických možností vykonať obnovu najprv:

• do izolovaného prostredia,
• do dočasného adresára,
• na samostatnú virtuálnu inštanciu,
• bez verejnej sieťovej dostupnosti,
• alebo iným primeraným bezpečným spôsobom.

33. Takýto postup môže byť použitý najmä vtedy, ak existuje riziko, že obnovený systém:

• začne okamžite šíriť malware,
• bude vykonávať útoky,
• bude rozosielať spam,
• bude kontaktovať riadiace servery útočníka,
• alebo inak ohrozí infraštruktúru alebo tretie strany.

34. Ochrana infraštruktúry WebHouse, ostatných zákazníkov a tretích strán má v takom prípade prednosť pred okamžitým verejným sprístupnením obnoveného kompromitovaného systému.
35. Obnovený systém môže zostať izolovaný až do vykonania primeraných nápravných opatrení.
36. WebHouse môže požadovať, aby Zákazník alebo ním poverený správca pred opätovným sprístupnením systému:

• odstránil malware,
• aktualizoval aplikáciu,
• odstránil zraniteľnosť,
• zmenil kompromitované prístupové údaje,
• alebo vykonal inú primeranú nápravu.

37. Takéto opatrenie sa nepovažuje za vadu obnovy, ak je primerane odôvodnené bezpečnostným rizikom.
38. Pri vážne kompromitovanom systéme nemusí byť najbezpečnejším riešením obnova celého historického systému.
39. V niektorých prípadoch môže byť bezpečnejší postup:

• vytvoriť nové čisté prostredie,
• vykonať novú inštaláciu operačného systému,
• vykonať novú inštaláciu aplikácie,
• následne preniesť iba overené zákaznícke dáta.

40. WebHouse negarantuje, že každý bezpečnostný incident možno vyriešiť jednoduchým návratom na starší bod obnovy.
41. Ak malware zmenil iba časť dát, môže byť technicky možné obnoviť iba určitý rozsah.
42. Selektívna obnova však závisí od konkrétnej zálohovacej technológie.
43. WebHouse nie je povinný individuálne extrahovať a bezpečnostne preverovať každý jednotlivý súbor, ak takáto služba nie je výslovne objednaná.
44. Ak je potrebné z historickej zálohy získať iba vybrané čisté dáta, môže byť potrebné:

• obnoviť celý bod do izolovaného priestoru,
• vykonať kontrolu,
• následne preniesť iba zvolené dáta.

45. Takýto postup môže predstavovať nadštandardný a spoplatnený administrátorský alebo bezpečnostný zásah.
46. Malware môže byť uložený nielen v spustiteľných súboroch.
47. Môže byť obsiahnutý aj napríklad:

• v PHP súboroch,
• JavaScript súboroch,
• makrách,
• databázových záznamoch,
• obrázkoch alebo ich metadátach,
• archívoch,
• e-mailových prílohách,
• používateľských uploadnutých súboroch.

48. WebHouse preto negarantuje, že jednoduchá kontrola podľa prípony alebo typu súboru identifikuje všetok škodlivý obsah.
49. Malware môže byť obsiahnutý aj v databáze.
50. Obnova čistých webových súborov preto nemusí postačovať, ak je škodlivý obsah uložený v databáze.
51. Rovnako obnova čistej databázy nemusí postačovať, ak je malware uložený vo webových alebo systémových súboroch.
52. Pri kompromitovaných aplikáciách môže byť preto potrebné posudzovať viacero častí služby ako jeden celok.
53. Zálohy môžu obsahovať aj súbory, ktoré bezpečnostný systém v čase vytvorenia zálohy ešte nevedel identifikovať ako škodlivé.
54. Neskoršia aktualizácia antivírusových alebo bezpečnostných signatúr môže viesť k tomu, že historický súbor bude neskôr identifikovaný ako malware.
55. Skutočnosť, že historická záloha nebola v čase svojho vzniku označená ako infikovaná, preto nepredstavuje dôkaz jej bezpečnostnej čistoty.
56. Rovnako môže nastať falošne pozitívne označenie legitímneho súboru ako škodlivého.
57. WebHouse preto môže pri automatizovanej detekcii vykonať ďalšie primerané preverenie alebo požadovať súčinnosť Zákazníka.
58. WebHouse nie je povinný automaticky odstrániť každý súbor zo zálohy iba na základe jedného bezpečnostného upozornenia.
59. Automatické odstraňovanie obsahu priamo zo zálohy môže narušiť:

• integritu zálohy,
• konzistenciu aplikácie,
• alebo možnosť neskoršej analýzy incidentu.

60. Z tohto dôvodu môže WebHouse namiesto modifikácie existujúcej zálohy:

• obmedziť jej obnovu,
• označiť ju ako podozrivú,
• obnoviť ju izolovane,
• alebo použiť iný bezpečný postup.

61. WebHouse nie je bez osobitnej dohody povinný spätne modifikovať historické zálohy s cieľom odstrániť z nich každý zistený škodlivý súbor.
62. Historické body obnovy môžu zostať technicky zachované v pôvodnom stave až do uplynutia retenčného cyklu.
63. Takéto uchovávanie neznamená, že škodlivý obsah je aktívne prevádzkovaný.
64. Záloha uložená v izolovanom zálohovacom systéme môže obsahovať malware bez toho, aby bol tento malware spustený.
65. Bezpečnostné riziko sa môže zvýšiť až pri:

• obnove,
• extrakcii,
• spustení,
• alebo inom aktívnom použití kompromitovaných dát.

66. WebHouse preto môže pri manipulácii s podozrivou zálohou používať primerané bezpečnostné obmedzenia.
67. Zákazník nemá automatický nárok na priame stiahnutie alebo sprístupnenie zálohy obsahujúcej aktívny škodlivý obsah spôsobom, ktorý by mohol ohroziť systémy WebHouse alebo tretích strán.
68. Ak je možné zálohu bezpečne sprístupniť, WebHouse môže určiť primeraný spôsob jej odovzdania alebo izolácie.
69. Pri ransomware môže záloha obsahovať:

• už zašifrované produkčné dáta,
• ransom note,
• škodlivý program,
• alebo iné súvisiace dáta.

70. Obnova takéhoto bodu nemusí priniesť použiteľné pôvodné súbory.
71. Ak všetky dostupné body obnovy vznikli až po zašifrovaní dát, nemusí byť možné obnoviť nezašifrovaný stav zo záloh WebHouse.
72. Z tohto dôvodu je pri ochrane pred ransomvérom významná:

• dostatočná retencia,
• rýchle odhalenie incidentu,
• technické oddelenie záloh,
• prípadne nemenné alebo nezávislé zálohy.

73. Štandardná zálohovacia služba nemusí automaticky poskytovať všetky uvedené vlastnosti.
74. Ak Zákazník vyžaduje osobitnú ochranu proti ransomvéru, musí byť príslušná vlastnosť výslovne súčasťou objednanej služby alebo vlastnej zálohovacej stratégie Zákazníka.
75. Pri e-mailových schránkach môže záloha obsahovať e-mail s infikovanou prílohou, ak sa táto správa nachádzala v zálohovanej schránke.
76. Samotná existencia takejto správy v zálohe neznamená, že bol škodlivý obsah na serveri WebHouse spustený.
77. Obnovenie starej e-mailovej schránky však môže opätovne sprístupniť používateľovi aj historickú škodlivú prílohu.
78. Zákazník je preto povinný zachovávať primeranú obozretnosť aj pri historicky obnovených správach.
79. Pri VPS alebo dedikovanom serveri môže byť malware súčasťou celého systémového obrazu.
80. Obnova image backupu môže preto obnoviť nielen používateľské dáta, ale aj:

• kompromitovaný operačný systém,
• škodlivé služby,
• upravené cron úlohy,
• kompromitované používateľské účty,
• backdoor.

81. Pri závažnej kompromitácii VPS alebo dedikovaného servera môže byť z bezpečnostného hľadiska vhodnejšia čistá reinštalácia než úplný restore systémového obrazu.
82. Pri nespravovaných službách rozhoduje o aplikačnom alebo systémovom postupe Zákazník alebo ním poverený administrátor, pokiaľ nie je dohodnutá osobitná bezpečnostná služba.
83. WebHouse môže odmietnuť vykonať pokyn Zákazníka na obnovenie alebo spustenie systému, ak by jeho vykonanie bezprostredne a závažným spôsobom ohrozovalo bezpečnosť infraštruktúry alebo tretích strán.
84. WebHouse môže v takom prípade navrhnúť bezpečnejší technický postup.
85. Ak je bezpečnostný incident spôsobený zraniteľnosťou alebo kompromitáciou v zákazníkom spravovanej vrstve, náklady na:

• vyhľadávanie čistého bodu obnovy,
• manuálnu analýzu,
• izolovanú obnovu,
• odstránenie malvéru,
• alebo rekonštrukciu aplikácie

môžu byť spoplatnené podľa rozsahu práce.

86. Ak incident vznikol v dôsledku porušenia povinnosti na strane WebHouse, posúdenie nákladov a zodpovednosti sa riadi príslušnými zmluvnými podmienkami a právnymi predpismi.
87. Jednorazová bezplatná pomoc WebHouse pri odstránení malvéru alebo analýze kompromitácie nevytvára nárok na rovnaký bezplatný rozsah pomoci v budúcnosti.
88. Zákazník zodpovedá za bezpečnosť aplikácií, kódu, hesiel a ostatných zákazníkom spravovaných komponentov podľa pravidiel rozdelenia zodpovednosti.
89. Obnova zo zálohy nemení toto rozdelenie zodpovednosti.
90. Zákazník by mal po obnove kompromitovanej služby primerane skontrolovať najmä:

• používateľské účty,
• administrátorské účty,
• zdrojový kód,
• pluginy a moduly,
• plánované úlohy,
• konfiguračné súbory,
• databázu,
• presmerovania,
• SSH kľúče,
• API tokeny,
• heslá.

91. Konkrétny rozsah kontroly závisí od charakteru incidentu.
92. WebHouse negarantuje, že všeobecný zoznam kontrol postačuje na odstránenie každého typu kompromitácie.
93. Pri závažnom incidente môže byť potrebná odborná bezpečnostná analýza.
94. WebHouse môže v odôvodnenom prípade zachovať podozrivý alebo kompromitovaný bod obnovy na účely:

• technickej analýzy,
• obnovy vybraných dát,
• ochrany dôkazov,
• alebo splnenia právnej povinnosti.

95. Takéto mimoriadne uchovanie nepredstavuje všeobecné predĺženie retenčnej doby.
96. WebHouse nie je povinný uchovať infikovanú zálohu nad štandardnú retenciu iba preto, že Zákazník môže mať v budúcnosti záujem o jej analýzu.
97. Ak Zákazník potrebuje zachovanie konkrétneho bodu, mal by o to požiadať bez zbytočného odkladu.
98. Záloha obsahujúca malware môže byť technicky úplná a integritne nepoškodená, ale z bezpečnostného hľadiska nevhodná na priamu produkčnú obnovu.
99. Tento rozdiel sa zohľadňuje pri posudzovaní toho, či bola zálohovacia služba poskytnutá riadne.
100. Samotná prítomnosť malvéru v zálohe, ktorý bol súčasťou produkčných dát v čase jej vytvorenia, automaticky nepredstavuje vadu zálohy.
101. Ak však malware alebo neoprávnená zmena zasiahli samotný zálohovací systém WebHouse až po vytvorení pôvodne čistej zálohy, ide o odlišnú situáciu a zodpovednosť sa posudzuje podľa príčiny a okolností konkrétneho incidentu.
102. WebHouse je povinný poskytovať výslovne dohodnuté bezpečnostné vlastnosti zálohovacej služby v rozsahu, v akom boli súčasťou konkrétnej služby.
103. Ak konkrétna služba výslovne garantuje napríklad:

• malware scanning záloh,
• nemennosť záloh,
• izoláciu záloh,
• alebo inú bezpečnostnú vlastnosť,

všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie takejto garancie.

104. Zálohovanie a bezpečnostná analýza sú odlišné služby, pokiaľ pri konkrétnom produkte nie je výslovne uvedené inak.
105. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 24

Požiadavka na obnovu

1. Zákazník môže požiadať o obnovu dát spôsobom určeným WebHouse pre konkrétnu službu.
2. Požiadavka na obnovu môže byť podaná najmä:
   • prostredníctvom zákazníckeho rozhrania,
   • prostredníctvom autorizovanej požiadavky technickej podpore,
   • prostredníctvom samoobslužného obnovovacieho nástroja,
   • alebo iným spôsobom určeným WebHouse.
3. WebHouse môže z bezpečnostných dôvodov požadovať overenie, že osoba žiadajúca obnovu je oprávnená nakladať s príslušnou službou alebo dátami.
4. WebHouse môže najmä požadovať:
   • prihlásenie do zákazníckeho účtu,
   • potvrdenie požiadavky oprávnenou osobou,
   • dodatočné overenie identity,
   • alebo iný primeraný spôsob autorizácie.
5. WebHouse nie je povinný vykonať obnovu na základe požiadavky osoby, pri ktorej nemožno primerane overiť oprávnenie nakladať s danou službou alebo dátami.
6. Požiadavka na obnovu by mala obsahovať najmä:
   • identifikáciu služby,
   • identifikáciu webhostingu, VPS, databázy, schránky alebo iného obnovovaného objektu,
   • približný požadovaný dátum alebo čas obnovy,
   • rozsah požadovaných dát,
   • požadovaný spôsob obnovy, ak je relevantný,
   • dôvod obnovy, ak môže ovplyvniť výber vhodného bodu alebo bezpečný spôsob zásahu.
7. Dôvod obnovy môže byť významný najmä v prípade:
   • náhodného vymazania dát,
   • chybnej aktualizácie,
   • poškodenia aplikácie,
   • databázovej chyby,
   • kompromitácie,
   • malvéru,
   • ransomvéru,
   • alebo iného bezpečnostného incidentu.
8. Zákazník je povinný uviesť požadovaný rozsah obnovy čo najpresnejšie.
9. Požiadavka môže smerovať napríklad na obnovu:
   • celého webhostingového účtu,
   • konkrétneho adresára,
   • konkrétneho súboru,
   • celej databázy,
   • celej e-mailovej schránky,
   • priečinka,
   • celého virtuálneho servera,
   • alebo iného technicky podporovaného objektu.
10. Skutočnosť, že Zákazník požaduje selektívnu obnovu určitej položky, neznamená, že použitá zálohovacia technológia musí takúto selektívnu obnovu umožňovať.
11. Ak požadovaný rozsah obnovy nie je technicky podporovaný, WebHouse môže navrhnúť obnovu väčšieho technického celku.
12. Môže ísť napríklad o:

• obnovu celej databázy namiesto jedného záznamu,
• obnovu celej schránky namiesto jednej správy,
• obnovu celej virtuálnej inštancie namiesto jedného súboru.

13. WebHouse preverí dostupné body obnovy, ktoré zodpovedajú rozsahu objednanej služby a aktuálne platnej retenčnej politike.
14. Preverenie dostupných bodov obnovy neznamená automaticky vykonanie úplného testovacieho restore každého bodu.
15. WebHouse môže pri preverení vychádzať najmä z:

• údajov zálohovacieho systému,
• technického stavu záloh,
• výsledkov automatizovaných kontrol,
• alebo iných dostupných technických informácií.

16. Zákazník nemá nárok na bod obnovy, ktorý:

• nebol vytvorený,
• už bol odstránený v rámci retenčného cyklu,
• bol prepísaný,
• bol konsolidovaný spôsobom, ktorý neumožňuje požadovanú obnovu,
• alebo už nie je technicky dostupný.

17. WebHouse nie je povinný spätne vytvoriť bod obnovy, ktorý v minulosti nevznikol.
18. WebHouse nie je povinný spätne rekonštruovať zálohu, ktorá už podľa štandardných retenčných pravidiel neexistuje.
19. Ak požadovaný historický bod už nie je dostupný, WebHouse môže podľa možností ponúknuť:

• najbližší starší dostupný bod,
• najbližší novší dostupný bod,
• alebo iný technicky vhodný bod obnovy.

20. Zákazník nemá automatický nárok na presný dátum alebo čas, ktorý uviedol vo svojej požiadavke, ak takýto bod obnovy neexistuje.
21. Ak Zákazník uvedie napríklad požiadavku „obnoviť stav z 15. júna“, môže byť dostupný iba bod z:

•  
  14. júna,
•  
  16. júna,
• alebo iného blízkeho času.

22. WebHouse môže Zákazníka informovať o najbližších dostupných bodoch a požiadať ho o výber.
23. Ak je požadovaný čas obnovy nejasný, WebHouse môže od Zákazníka požadovať jeho spresnenie.
24. Zákazník je povinný pri výbere bodu obnovy zohľadniť, že starší bod môže znamenať stratu väčšieho množstva novších dát.
25. WebHouse nemusí vedieť určiť, ktorý historický bod predstavuje posledný vecne správny alebo funkčný stav aplikácie Zákazníka.
26. WebHouse nemusí vedieť, kedy presne:

• Zákazník vykonal chybnú zmenu,
• vznikla chyba aplikácie,
• došlo k odstráneniu konkrétnych dát,
• začala kompromitácia,
• alebo vznikol iný problém.

27. Výber vhodného bodu obnovy preto môže vyžadovať súčinnosť Zákazníka.
28. Ak Zákazník nevie určiť presný čas incidentu, WebHouse môže podľa dostupných informácií navrhnúť technicky vhodný bod obnovy.
29. Takýto návrh však nepredstavuje garanciu, že daný bod obsahuje posledný bezchybný alebo bezpečný stav.
30. Pri bezpečnostnom incidente môže byť najnovší dostupný bod obnovy nevhodný, ak už obsahuje kompromitovaný stav.
31. WebHouse môže preto odporučiť použitie staršieho bodu obnovy alebo obnovu najprv do izolovaného prostredia.
32. Zákazník je povinný poskytnúť WebHouse primeranú súčinnosť pri výbere vhodného bodu obnovy.
33. Ak je požiadavka neúplná alebo nejednoznačná, WebHouse môže jej vykonanie primerane odložiť do času, kým bude možné bezpečne určiť:

• čo sa má obnoviť,
• z akého obdobia,
• akým spôsobom,
• a kam sa má obnova vykonať.

34. Takýto postup sa nepovažuje za neodôvodnené omeškanie, ak je spresnenie potrebné na zabránenie strate alebo prepísaniu dát.
35. WebHouse nie je povinný vykonať nejasný pokyn spôsobom, pri ktorom existuje významné riziko nenávratnej straty aktuálnych dát.
36. Pred obnovou do produkčného prostredia môže WebHouse Zákazníka upozorniť, že obnova môže prepísať aktuálne dáta.
37. WebHouse môže požadovať výslovné potvrdenie Zákazníka pred vykonaním obnovy, ktorá môže viesť k:

• strate novších dát,
• prepísaniu databázy,
• prepísaniu súborov,
• návratu celého VPS do staršieho stavu,
• alebo inej významnej zmene produkčného prostredia.

38. Zákazník je povinný pred potvrdením takejto obnovy zvážiť, či potrebuje zachovať aktuálny stav dát.
39. Ak to technické možnosti umožňujú, môže byť pred obnovou vytvorená:

• aktuálna pracovná kópia,
• dočasný snapshot,
• alebo iná ochranná kópia súčasného stavu.

40. WebHouse však vytvorenie takejto dodatočnej kópie negarantuje pri každej obnove.
41. Dodatočnú kópiu nemusí byť možné vytvoriť napríklad pri:

• poškodenom úložisku,
• nedostatku kapacity,
• bezpečnostnom incidente,
• technicky nestabilnom systéme,
• alebo inom stave, pri ktorom by ďalšie kopírovanie mohlo zvýšiť riziko poškodenia.

42. Ak Zákazník potrebuje zachovať aktuálny produkčný stav bez ohľadu na okolnosti, mal by si pred požiadaním o prepísanie dát vytvoriť vlastnú zálohu, ak je to ešte možné.
43. WebHouse môže podľa technických možností obnoviť dáta:

• priamo do pôvodného produkčného prostredia,
• do dočasného priestoru,
• do samostatnej databázy,
• do samostatnej schránky,
• ako novú virtuálnu inštanciu,
• alebo iným technicky vhodným spôsobom.

44. Výber spôsobu obnovy môže WebHouse prispôsobiť:

• rozsahu dát,
• riziku prepísania,
• bezpečnostnému stavu,
• použitej technológii,
• dostupnej kapacite.

45. Ak je bezpečnejšie najskôr vykonať obnovu do dočasného alebo izolovaného prostredia, WebHouse môže takýto postup uprednostniť.
46. Zákazník nemá automatický nárok požadovať obnovu kompromitovaného alebo škodlivého systému priamo do verejnej produkcie, ak by tým vzniklo primerane predvídateľné bezpečnostné riziko.
47. WebHouse môže pred produkčným spustením obnoveného systému požadovať primerané nápravné opatrenia.
48. Ak je obnova požadovaná v dôsledku malvéru, ransomvéru alebo iného bezpečnostného incidentu, použijú sa aj články XXII a XXIII týchto Pravidiel.
49. WebHouse môže odmietnuť vykonať obnovu z bodu, ktorý je zjavne:

• technicky poškodený,
• neúplný,
• neobnoviteľný,
• alebo nevhodný na bezpečné použitie.

50. Ak je dostupný iný vhodný bod obnovy, WebHouse môže navrhnúť jeho použitie.
51. Zákazník nemá právo vyžadovať vykonanie technicky nezmyselného alebo bezpečnostne neprimeraného zásahu iba preto, že konkrétny bod technicky existuje.
52. Ak je však cieľom Zákazníka napríklad bezpečnostná analýza poškodeného bodu, môže byť možné jeho sprístupnenie alebo izolovaná obnova ako osobitný zásah.
53. Takýto zásah môže byť spoplatnený a závisí od technických možností.
54. Požiadavka na obnovu sa považuje za dostatočne špecifikovanú až vtedy, keď má WebHouse k dispozícii údaje potrebné na bezpečné vykonanie požadovaného zásahu.
55. Ak však z pôvodnej požiadavky jednoznačne vyplýva, aké dáta a aký približný historický stav Zákazník požaduje, WebHouse nesmie vyžadovať zbytočné formality, ktoré nie sú potrebné na vykonanie obnovy.
56. Chýbajúci údaj, ktorý nie je potrebný na samotnú obnovu, nie je dôvodom na odmietnutie požiadavky.
57. WebHouse môže pri manuálnej obnove určiť technický postup, ktorý primerane minimalizuje riziko straty alebo poškodenia dát.
58. Zákazník nemá automatický nárok určovať interné technické kroky obnovy.
59. Zákazník však môže určiť výsledok, ktorý požaduje, ak je technicky podporovaný objednanou službou.
60. WebHouse môže pred začatím manuálnej obnovy informovať Zákazníka o:

• dostupnom bode obnovy,
• rozsahu obnovy,
• riziku prepísania,
• prípadnom spoplatnení,
• predpokladanom technickom postupe.

61. Ak je zásah spoplatnený a cenu nemožno určiť paušálne, WebHouse môže vyžiadať súhlas Zákazníka s cenou alebo spôsobom jej výpočtu pred vykonaním práce.
62. Ak je potrebné bezodkladne vykonať technické opatrenie na ochranu dát alebo infraštruktúry, môže WebHouse vykonať nevyhnutný bezpečnostný zásah aj pred dokončením bežného obnovovacieho procesu.
63. Takýmto zásahom môže byť napríklad:

• izolácia služby,
• zastavenie kompromitovaného VPS,
• zablokovanie verejnej dostupnosti,
• zachovanie konkrétneho bodu obnovy.

64. Bezpečnostný zásah a samotná obnova dát predstavujú rozdielne úkony.
65. Zákazník môže svoju požiadavku na obnovu zmeniť alebo zrušiť dovtedy, kým WebHouse nevykonal nezvratný krok vedúci k prepísaniu alebo zmene dát.
66. Ak už bol obnovovací proces spustený a jeho zastavenie nie je technicky možné alebo bezpečné, WebHouse nemusí byť schopný požiadavku okamžite zrušiť.
67. Ak Zákazník počas obnovy zmení požadovaný bod alebo rozsah, môže byť potrebné pôvodný proces ukončiť a spustiť novú obnovu.
68. Dodatočná práca môže byť podľa okolností spoplatnená.
69. WebHouse môže odmietnuť opakované bezúčelné obnovy, ak by neprimerane zaťažovali infraštruktúru alebo boli v rozpore s účelom služby.
70. Tým nie je dotknuté právo Zákazníka na primeranú obnovu podľa parametrov objednanej služby.
71. Ak Zákazník požaduje opakovane obnovovať rôzne historické body s cieľom manuálne vyhľadávať konkrétne dáta, môže ísť o nadštandardný administrátorský zásah.
72. Takýto zásah môže byť spoplatnený podľa rozsahu práce.
73. Počas obnovy môže byť príslušná služba alebo jej časť dočasne:

• obmedzená,
• nedostupná,
• uvedená do režimu údržby.

74. Takéto obmedzenie môže byť potrebné na zabránenie súbežným zmenám a na zabezpečenie konzistencie obnovy.
75. WebHouse môže Zákazníkovi odporučiť, aby počas obnovy nevykonával zmeny v dotknutých dátach.
76. Zmeny vykonané počas prebiehajúcej obnovy môžu byť:

• prepísané,
• stratené,
• alebo viesť k nekonzistentnému výsledku.

77. Ak Zákazník napriek upozorneniu vykonáva počas obnovy zásahy, zodpovedá za následky takýchto vlastných zmien v rozsahu, v akom ovplyvnili výsledok obnovy.
78. Doba vykonania obnovy závisí od technických okolností a nie je automaticky určená časom podania požiadavky.
79. Doba obnovy môže závisieť najmä od:

• objemu dát,
• počtu súborov,
• veľkosti databázy alebo schránky,
• veľkosti virtuálneho servera,
• typu zálohovacej technológie,
• potreby obnovy viacerých komponentov,
• aktuálneho zaťaženia systému,
• rozsahu incidentu.

80. Samotná existencia dostupnej zálohy neznamená garantovanú dobu dokončenia obnovy.
81. Garantovaná doba obnovy existuje iba v prípade, ak je pri konkrétnej službe výslovne dohodnuté RTO alebo iný časový parameter.
82. Poradie manuálnych obnovovacích zásahov môže WebHouse určovať s prihliadnutím na:

• závažnosť incidentu,
• bezpečnostné riziko,
• rozsah dopadu,
• technické závislosti,
• individuálne dohodnuté priority.

83. Bez osobitnej dohody nemá Zákazník automatický nárok na prednostnú obnovu iba preto, že jeho vlastná služba má pre neho vysoký obchodný význam.
84. Pri rozsiahlej havárii postihujúcej viac zákazníkov alebo viac služieb môže obnova trvať dlhšie než pri izolovanom incidente.
85. V takom prípade môže byť potrebné najskôr obnoviť:

• spoločnú infraštruktúru,
• sieťové služby,
• storage,
• databázové alebo iné spoločné technické komponenty.

86. WebHouse nie je povinný vykonávať individuálnu obnovu, ktorá je technicky nemožná pred obnovením spoločnej infraštruktúry.
87. Zákazník je po dokončení obnovy povinný primerane preveriť výsledok.
88. Zákazník by mal podľa typu služby skontrolovať najmä:

• prítomnosť požadovaných súborov,
• stav databázy,
• obsah schránky,
• funkčnosť aplikácie,
• alebo iné relevantné údaje.

89. Ak Zákazník zistí, že výsledok nezodpovedá požadovanému bodu alebo rozsahu, mal by to oznámiť WebHouse bez zbytočného odkladu.
90. Včasné oznámenie je dôležité najmä preto, že ďalšie historické body obnovy môžu byť medzičasom odstránené v rámci bežnej rotácie.
91. Zákazník by nemal po obnove zbytočne odkladať kontrolu výsledku.
92. Ak po obnove začne aktívne meniť produkčné dáta, môže byť ďalší návrat na iný historický bod komplikovanejší.
93. Samotná obnova dát neznamená automaticky opravu príčiny pôvodného incidentu.
94. Ak bol problém spôsobený:

• chybou aplikácie,
• kompromitáciou,
• malware,
• chybnou konfiguráciou,
• alebo inou pretrvávajúcou príčinou,

musí byť táto príčina riešená samostatne.

95. WebHouse môže odmietnuť opakované uvedenie obnovenej služby do produkcie, ak nebola odstránená príčina, ktorá bezprostredne ohrozuje infraštruktúru alebo tretie strany.
96. Zodpovednosť za odstránenie príčiny sa riadi rozdelením zodpovednosti pri konkrétnej službe.
97. Manuálna obnova môže byť podľa konkrétnej služby:

• zahrnutá v cene,
• zahrnutá v obmedzenom počte,
• samoobslužná,
• alebo spoplatnená.

98. Ak je obnova potrebná v dôsledku chyby alebo zásahu Zákazníka, môže byť administrátorská práca WebHouse spoplatnená podľa aktuálneho cenníka.
99. Ak je obnova potrebná v dôsledku preukázanej vady služby na strane WebHouse, posúdenie spoplatnenia sa riadi zmluvnými podmienkami, Reklamačným poriadkom a príslušnými právnymi predpismi.
100. Jednorazová bezplatná obnova nad rámec služby nevytvára nárok na rovnaký bezplatný postup v budúcnosti.
101. Požiadavka na obnovu nie je automaticky reklamáciou služby.
102. Ak však z obsahu požiadavky vyplýva, že Zákazník zároveň uplatňuje práva zo zodpovednosti za vady alebo namieta porušenie povinností WebHouse, posudzuje sa táto časť podania podľa jeho obsahu a Reklamačného poriadku.
103. Zákazník preto nemusí použiť konkrétne označenie „reklamácia“, ak je z jeho podania zrejmé, že uplatňuje príslušné právo.
104. Samotná skutočnosť, že WebHouse vykoná obnovu, nepredstavuje automatické uznanie:

• vady služby,
• zodpovednosti za stratu dát,
• ani nároku na náhradu škody.

105. Obnova môže byť vykonaná aj ako technická pomoc pri udalosti spôsobenej Zákazníkom alebo treťou stranou.
106. Zodpovednosť za príčinu incidentu sa posudzuje samostatne.
107. Ak Zákazník požiada o obnovu dát, ktoré už podľa štandardných retenčných pravidiel nemajú existovať, WebHouse môže preveriť, či náhodou neexistuje staršia technická kópia.
108. WebHouse však nemá povinnosť takúto kópiu vyhľadávať, pokiaľ to nie je primerane možné v rámci konkrétnej služby.
109. Ak staršia technická kópia existuje nad rámec štandardnej retencie, jej existencia nezakladá všeobecný nárok na obnovu.
110. WebHouse môže podľa technických možností takúto obnovu ponúknuť ako individuálny alebo spoplatnený zásah.
111. Takáto jednorazová obnova nepredstavuje predĺženie retenčnej doby služby ani precedens do budúcnosti.
112. Ak požadovaný bod obnovy neexistuje a nie je dostupná žiadna iná použiteľná kópia, WebHouse nie je povinný rekonštruovať dáta z neexistujúceho zdroja.
113. V takom prípade môže byť potrebné použiť vlastnú externú zálohu Zákazníka.
114. Z tohto dôvodu sa pri kritických alebo nenahraditeľných dátach uplatňujú aj články X a XI týchto Pravidiel.
115. WebHouse je povinný vykonať obnovu v rozsahu a spôsobom, ktorý zodpovedá výslovne dohodnutým parametrom konkrétnej služby.
116. Povinnosť Zákazníka presne špecifikovať požiadavku alebo potvrdiť riziko prepísania nezbavuje WebHouse zodpovednosti za správne technické vykonanie dohodnutej obnovy.
117. Ak WebHouse vykoná obnovu iného bodu alebo iného rozsahu, než Zákazník riadne požadoval a potvrdil, zodpovednosť za takýto zásah sa posudzuje podľa okolností konkrétneho prípadu.
118. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse bez primeraného dôvodu odmietnuť obnovu, ktorá je výslovne súčasťou objednanej služby a pre ktorú existuje použiteľný bod obnovy.
119. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 25

Výber bodu obnovy

1. Zákazník by mal podľa dostupných možností určiť požadovaný bod obnovy čo najpresnejšie.
2. Požadovaný bod obnovy môže Zákazník určiť najmä:
   • konkrétnym dátumom,
   • približným časom,
   • označením dostupného bodu v zákazníckom rozhraní,
   • alebo opisom posledného známeho správneho stavu.
3. Ak Zákazník nevie určiť presný bod obnovy, mal by uviesť aspoň približný čas, ku ktorému boli dáta podľa jeho vedomosti ešte:
   • úplné,
   • funkčné,
   • nepoškodené,
   • alebo nekompromitované.
4. WebHouse nemusí vedieť určiť vecne správny historický stav dát Zákazníka bez jeho súčinnosti.
5. WebHouse spravidla nevie, kedy presne Zákazník:
   • odstránil konkrétny súbor,
   • zmenil databázový záznam,
   • vykonal chybnú konfiguráciu,
   • nainštaloval chybnú aktualizáciu,
   • alebo vykonal inú zmenu.
6. Rovnako nemusí byť možné presne určiť okamih:
   • vzniku poškodenia,
   • kompromitácie,
   • infekcie malvérom,
   • alebo iného bezpečnostného incidentu.
7. Čas zistenia problému nemusí byť totožný s časom jeho vzniku.
8. Z tohto dôvodu nemusí byť najnovší dostupný bod obnovy zároveň najvhodnejším bodom na obnovu.
9. WebHouse negarantuje existenciu zálohy presne k dátumu alebo času požadovanému Zákazníkom.
10. Zálohy sa vytvárajú podľa frekvencie a technického harmonogramu konkrétnej služby.
11. Medzi jednotlivými bodmi obnovy preto môžu existovať časové intervaly, pre ktoré samostatný bod obnovy neexistuje.
12. Ak sa napríklad záloha vytvára raz denne, nemusí existovať samostatná záloha presne:

• o 10:00,
• o 14:30,
• ani k inému konkrétnemu času požadovanému Zákazníkom.

13. Rozhodujúce sú body obnovy, ktoré boli skutočne vytvorené a sú v čase požiadavky ešte dostupné.
14. Ak presný požadovaný bod nie je dostupný, WebHouse môže Zákazníkovi ponúknuť najbližší dostupný bod obnovy.
15. Najbližším dostupným bodom môže byť:

• starší bod,
• novší bod,
• alebo viacero alternatívnych bodov.

16. WebHouse môže podľa okolností odporučiť bod, ktorý považuje z technického hľadiska za najvhodnejší.
17. Takéto odporúčanie však samo osebe neznamená, že WebHouse garantuje vecnú správnosť obsahu daného bodu.
18. Ak je dostupný bod pred požadovaným časom aj bod po požadovanom čase, môže byť potrebné, aby Zákazník určil, ktorý z nich chce použiť.
19. Starší bod obnovy môže obsahovať menej nových dát, ale zároveň môže predstavovať stav pred vznikom problému.
20. Novší bod môže obsahovať viac aktuálnych dát, ale môže už obsahovať aj:

• chybnú zmenu,
• odstránenie dát,
• kompromitáciu,
• malware,
• alebo iný nežiaduci stav.

21. Výber bodu obnovy preto môže predstavovať kompromis medzi:

• zachovaním čo najväčšieho množstva novších dát,
• a návratom do staršieho bezpečného alebo funkčného stavu.

22. WebHouse nemôže bez dostatočných informácií Zákazníka vždy určiť, ktorý z týchto cieľov má mať prednosť.
23. Ak Zákazník jednoznačne určí konkrétny dostupný bod obnovy, WebHouse môže obnovu vykonať z tohto bodu, pokiaľ tomu nebráni technický alebo bezpečnostný dôvod.
24. Zákazník nesie zodpovednosť za výber historického stavu v rozsahu, v akom mu boli dostupné relevantné informácie a výber bodu vykonal on.
25. WebHouse naopak zodpovedá za správne technické použitie bodu, ktorý bol dohodnutý alebo potvrdený na obnovu.
26. Ak Zákazník označí iba približný čas, WebHouse môže vybrať najbližší technicky dostupný bod alebo Zákazníkovi ponúknuť dostupné alternatívy.
27. Ak môže mať voľba medzi viacerými bodmi významný dopad na množstvo zachovaných dát, WebHouse môže vyžiadať potvrdenie Zákazníka.
28. WebHouse môže napríklad uviesť, že sú dostupné body:

•  
  10. augusta o 02:00,
•  
  11. augusta o 02:00,

pričom Zákazník uviedol, že problém pravdepodobne vznikol 10. augusta popoludní.

29. V takom prípade môže byť starší bod bezpečnejší z hľadiska návratu pred incident, ale môže obsahovať menej nových dát.
30. Výber konkrétneho bodu môže byť preto ponechaný na Zákazníka.
31. Ak Zákazník odmietne alebo nevie vybrať medzi dostupnými bodmi, WebHouse môže podľa svojho odborného úsudku navrhnúť technicky rozumný postup.
32. Ak existuje významné riziko nenávratného prepísania produkčných dát, môže WebHouse pred vykonaním obnovy požadovať výslovné potvrdenie Zákazníka.
33. Ak Zákazník neposkytne potrebnú súčinnosť pri výbere bodu a bez jeho rozhodnutia nemožno obnovu bezpečne vykonať, môže byť obnova primerane odložená.
34. Takéto odloženie sa nepovažuje za neodôvodnené omeškanie, ak je rozhodnutie Zákazníka objektívne potrebné na zabránenie nesprávnej alebo nevratnej obnove.
35. Ak však existuje jednoznačne vhodný bod a nie je potrebné ďalšie rozhodnutie Zákazníka, WebHouse nemá vyžadovať zbytočné potvrdenia.
36. Dostupnosť bodu obnovy závisí aj od retenčnej politiky konkrétnej služby.
37. Bod obnovy, ktorý bol v minulosti dostupný, nemusí byť dostupný v čase neskoršej požiadavky.
38. Staršie body môžu byť automaticky:

• odstránené,
• prepísané,
• konsolidované,
• alebo vyradené v rámci štandardnej rotácie.

39. Zákazník preto nemá nárok na bod, ktorý už podľa retenčných pravidiel neexistuje.
40. WebHouse nie je povinný spätne vytvoriť bod obnovy, ktorý nebol vytvorený alebo už bol riadne odstránený.
41. Ak konkrétny bod už nie je dostupný, WebHouse môže podľa možností ponúknuť najbližší zachovaný bod.
42. Skutočnosť, že požadovaný bod spadal do určitého kalendárneho obdobia, neznamená automaticky, že musí existovať presne takýto bod obnovy.
43. Retenčná doba určuje uchovávanie vytvorených bodov, nie povinnosť vytvoriť samostatný bod pre každý okamih v rámci tejto doby.
44. Napríklad 14-dňová retencia neznamená možnosť obnoviť ľubovoľný stav z ľubovoľnej minúty posledných 14 dní.
45. Počet a časové rozloženie bodov obnovy závisia najmä od:

• frekvencie zálohovania,
• úspešnosti jednotlivých cyklov,
• spôsobu rotácie,
• spôsobu konsolidácie záloh,
• technológie konkrétnej služby.

46. Ak určitý zálohovací cyklus nevytvoril použiteľný bod obnovy, môže byť najbližší dostupný bod starší, než Zákazník očakáva.
47. V takom prípade môže WebHouse použiť alebo ponúknuť starší funkčný bod podľa článku XXI.
48. Zákazník nemá automatický nárok na nepoužiteľný bod iba preto, že je v systéme technicky evidovaný.
49. Ak je konkrétny bod poškodený alebo technicky neobnoviteľný, môže byť potrebné použiť iný dostupný bod.
50. Ak požadovaný bod obsahuje už poškodené alebo kompromitované produkčné dáta, môže WebHouse Zákazníka upozorniť na riziko jeho použitia.
51. WebHouse môže odporučiť starší bod, pri ktorom existuje vyššia pravdepodobnosť, že vznikol pred incidentom.
52. WebHouse však negarantuje, že starší bod je bezpečnostne čistý, pokiaľ to nebolo osobitne overené.
53. Pri malvéri, ransomvéri alebo kompromitácii sa na výber bodu obnovy použijú aj články XXII a XXIII.
54. Pri bezpečnostnom incidente môže byť potrebné obnoviť viacero bodov do izolovaného prostredia a následne ich preveriť.
55. Takýto postup nie je automaticky súčasťou štandardnej obnovy.
56. Individuálne testovanie viacerých bodov môže byť spoplatnené podľa rozsahu práce.
57. WebHouse nemusí vykonať neobmedzený počet testovacích obnov s cieľom nájsť presný obsah požadovaný Zákazníkom.
58. Ak Zákazník potrebuje napríklad nájsť:

• poslednú verziu konkrétneho súboru,
• konkrétnu e-mailovú správu,
• konkrétny databázový záznam,

môže byť potrebné preverovať viac historických bodov.

59. Takéto vyhľadávanie môže predstavovať osobitný administrátorský zásah.
60. Ak zálohovacia technológia umožňuje samoobslužný výber bodu, Zákazník zodpovedá za výber bodu, ktorý prostredníctvom zákazníckeho rozhrania zvolí.
61. Pred potvrdením samoobslužnej obnovy by mal Zákazník preveriť najmä:

• dátum bodu,
• čas bodu,
• rozsah obnovovaných dát,
• cieľ obnovy,
• prípadné riziko prepísania.

62. Ak zákaznícke rozhranie zobrazuje upozornenie na prepísanie dát, Zákazník je povinný toto upozornenie pred potvrdením obnovy zohľadniť.
63. Ak Zákazník omylom vyberie nesprávny bod a systém korektne vykoná ním zadaný pokyn, takáto okolnosť sama osebe nepredstavuje chybu zálohovacej služby.
64. Ak WebHouse pri manuálnej obnove omylom použije iný bod než bod riadne zvolený a potvrdený Zákazníkom, posudzuje sa takýto prípad odlišne.
65. Pri obnove viacerých komponentov jednej služby nemusia všetky komponenty disponovať bodom obnovy z úplne rovnakého času.
66. To sa môže týkať napríklad kombinácie:

• webových súborov,
• databázy,
• e-mailovej schránky,
• alebo ďalších častí služby.

67. Ak sú jednotlivé komponenty zálohované odlišnými mechanizmami, ich dostupné body môžu mať rozdielny čas vytvorenia.
68. Obnova webových súborov a databázy preto nemusí automaticky predstavovať stav z presne rovnakého okamihu.
69. Ak Zákazník požaduje obnovu aplikácie pozostávajúcej z viacerých komponentov, WebHouse môže zvoliť najbližšie technicky kompatibilné body.
70. Zákazník môže byť upozornený na časový rozdiel medzi jednotlivými komponentmi, ak je tento rozdiel relevantný.
71. WebHouse negarantuje časovo absolútne konzistentný bod naprieč viacerými systémami, pokiaľ takáto vlastnosť nie je výslovne súčasťou služby.
72. Ak je pre Zákazníka potrebná transakčná alebo časová konzistencia viacerých systémov, musí byť použitý zálohovací mechanizmus, ktorý ju výslovne podporuje.
73. Výber bodu obnovy sa nesmie zamieňať s RPO.
74. RPO predstavuje samostatne definovaný parameter iba vtedy, ak je pri konkrétnej službe výslovne uvedený.
75. Skutočnosť, že sú bežne dostupné body napríklad každých 24 hodín, sama osebe nepredstavuje garanciu maximálnej straty dát 24 hodín.
76. Ak je pri službe RPO výslovne garantované, výber dostupného bodu sa posudzuje aj podľa tejto garancie.
77. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie výslovne garantovaného RPO.
78. Ak je Zákazníkovi ponúknutý konkrétny bod obnovy a Zákazník ho schváli, následná obnova môže viesť k strate dát vytvorených po tomto bode.
79. Táto strata je prirodzeným dôsledkom návratu do historického stavu a sama osebe nepredstavuje chybu obnovy.
80. WebHouse však musí vykonať obnovu v rozsahu a z bodu, ktorý bol dohodnutý alebo potvrdený.
81. Ak to technické možnosti umožňujú, môže WebHouse pred prepísaním aktuálnych dát vytvoriť pracovnú kópiu súčasného stavu.
82. Takýto krok nie je automaticky garantovaný a riadi sa článkom XXIV.
83. Pri rozhodovaní medzi starším a novším bodom môže byť vhodné obnoviť historické dáta najprv do dočasného priestoru namiesto okamžitého prepísania produkcie.
84. Takýto postup môže umožniť Zákazníkovi:

• preveriť obsah,
• vybrať potrebné dáta,
• porovnať historický stav s aktuálnym stavom.

85. Dostupnosť takejto možnosti závisí od konkrétnej služby a technológie.
86. Dočasná alebo paralelná obnova môže byť spoplatnená, ak presahuje štandardný rozsah služby.
87. WebHouse môže pri výbere bodu zohľadniť aj bezpečnosť a stabilitu infraštruktúry.
88. WebHouse nie je povinný použiť bod, ktorého obnova by bola technicky nebezpečná alebo by mohla bezprostredne ohroziť:

• infraštruktúru,
• ostatných zákazníkov,
• alebo tretie strany.

89. V takom prípade môže WebHouse ponúknuť izolovanú obnovu alebo iný primeraný postup.
90. Zákazník by mal požiadavku na obnovu podať bez zbytočného odkladu po zistení straty alebo poškodenia dát.
91. Čím neskôr je požiadavka podaná, tým vyššie môže byť riziko, že požadovaný starší bod bude medzičasom odstránený v rámci štandardnej rotácie.
92. Včasné nahlásenie je obzvlášť dôležité pri:

• neúmyselnom zmazaní,
• ransomvéri,
• kompromitácii,
• postupnom poškodzovaní dát.

93. WebHouse však nie je povinný uchovávať všetky body nad rámec štandardnej retencie len preto, že Zákazník incident ešte nezistil.
94. Ak Zákazník potrebuje dlhšiu možnosť návratu do histórie, musí použiť službu s primeranou retenciou alebo vlastnú nezávislú zálohu.
95. Samotná existencia technickej kópie staršieho bodu nad rámec deklarovanej retencie nezakladá automatický nárok na jeho použitie.
96. Ak je takýto bod ešte technicky dostupný, WebHouse môže podľa okolností ponúknuť jeho obnovu ako individuálny zásah.
97. Takáto obnova nemení štandardné retenčné podmienky služby.
98. Ak Zákazník potrebuje zachovať konkrétny bod obnovy na dlhšie obdobie, musí túto potrebu riešiť ešte počas jeho dostupnosti.
99. Môže byť potrebné:

• exportovať zálohu,
• vytvoriť manuálnu zálohu,
• alebo objednať samostatnú archivačnú alebo zálohovaciu službu.

100. WebHouse nemá povinnosť predvídať, ktorý konkrétny historický bod bude mať pre Zákazníka v budúcnosti osobitnú hodnotu.
101. Výber bodu obnovy sa preto vždy vykonáva v rámci bodov, ktoré sú v danom čase skutočne dostupné a použiteľné.
102. WebHouse je povinný pravdivo informovať Zákazníka o dostupných možnostiach obnovy, ak je výber vykonávaný prostredníctvom technickej podpory.
103. Ak WebHouse vie, že konkrétny bod je nepoužiteľný alebo zjavne nevhodný na požadovaný účel, nemal by ho prezentovať ako plnohodnotne použiteľný bez príslušného upozornenia.
104. Povinnosť Zákazníka vybrať bod obnovy nezbavuje WebHouse zodpovednosti za správne vykonanie samotnej obnovy.
105. Rovnako však WebHouse nezodpovedá za obchodný alebo obsahový dôsledok správne vykonaného návratu do historického bodu, ktorý si Zákazník vedome zvolil, v rozsahu v akom tento dôsledok vyplýva zo samotného výberu staršieho stavu.
106. Ak bola voľba bodu ovplyvnená nesprávnou alebo zavádzajúcou informáciou poskytnutou WebHouse, posudzuje sa situácia podľa konkrétnych okolností.
107. WebHouse je povinný dodržiavať výslovne dohodnuté parametre frekvencie, retencie, RPO alebo iné vlastnosti, ktoré ovplyvňujú dostupnosť bodov obnovy.
108. Všeobecné ustanovenie, že presný požadovaný čas nemusí existovať, nemožno použiť na ospravedlnenie systematického nedodržiavania dohodnutej frekvencie zálohovania.
109. Ak konkrétna služba garantuje určitý počet bodov alebo konkrétnu časovú granularitu, táto osobitná garancia má prednosť pred všeobecnými ustanoveniami tohto článku.
110. Žiadne ustanovenie tohto článku nemožno vykladať ako oprávnenie WebHouse svojvoľne odmietnuť použiteľný bod obnovy, ktorý je súčasťou dohodnutého rozsahu služby.
111. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 26

Obnova môže prepísať aktuálne dáta

1. Obnovenie historických dát do produkčného prostredia môže viesť k úplnému alebo čiastočnému prepísaniu aktuálnych dát staršou verziou zo zvoleného bodu obnovy.
2. Zákazník je povinný vziať do úvahy, že pri obnove môžu byť stratené alebo nahradené zmeny vykonané:
   • po vytvorení zvoleného bodu obnovy,
   • pred samotným začatím obnovy,
   • alebo počas obnovy, ak sa produkčné dáta naďalej menia.
3. Dôsledok obnovy závisí od typu služby, rozsahu obnovy a použitej technológie.
4. Obnova môže prepísať napríklad:
   • webové súbory,
   • databázu,
   • e-mailovú schránku,
   • konfiguráciu,
   • používateľské dáta,
   • virtuálny disk,
   • celý virtuálny server,
   • alebo inú obnovovanú technickú jednotku.
5. Pri úplnej obnove môže byť celý aktuálny stav príslušnej technickej jednotky nahradený historickým stavom zo zálohy.
6. Pri čiastočnej alebo selektívnej obnove môžu byť prepísané iba vybrané súbory, adresáre, databázy, priečinky alebo iné objekty.
7. Zákazník nesmie predpokladať, že obnova automaticky zlúči historické a aktuálne dáta bez straty novších zmien.
8. Štandardná obnova môže byť založená na nahradení aktuálneho obsahu obsahom zo zvoleného bodu obnovy.
9. Automatické zlúčenie starej a novej verzie dát nemusí byť:
   • technicky možné,
   • bezpečné,
   • ani súčasťou objednanej služby.
10. Ak Zákazník potrebuje zachovať časť aktuálnych dát a zároveň obnoviť časť historických dát, môže byť potrebný individuálny postup.
11. Takýto postup môže zahŕňať najmä:

• obnovu do dočasného priestoru,
• porovnanie starého a aktuálneho stavu,
• manuálny výber dát,
• export a následný import vybraných údajov,
• alebo iný technicky vhodný zásah.

12. Takýto individuálny zásah môže byť spoplatnený podľa rozsahu práce.
13. Typickým príkladom rizika prepísania je obnova databázy.
14. Ak je napríklad databáza obnovená zo zálohy starej dva dni, môžu byť stratené všetky:

• objednávky,
• registrácie používateľov,
• platby,
• formulárové dáta,
• komentáre,
• rezervácie,
• alebo iné databázové zmeny

vytvorené po dátume použitého bodu obnovy.

15. Pri e-mailovej schránke môže úplná obnova staršieho stavu viesť k strate alebo zmene správ prijatých, odoslaných, presunutých alebo odstránených po vytvorení bodu obnovy.
16. Pri VPS môže obnova staršieho obrazu alebo snapshotu viesť k návratu celého virtuálneho servera do historického stavu.
17. Takýmto návratom môžu byť nahradené aj:

• novšie systémové aktualizácie,
• nové používateľské účty,
• zmeny konfigurácie,
• nové databázové dáta,
• nové súbory,
• logy,
• alebo iné zmeny.

18. Pri obnove webových súborov môžu byť novšie súbory nahradené staršími verziami.
19. V závislosti od použitého obnovovacieho mechanizmu môžu byť odstránené aj súbory, ktoré v historickom bode obnovy neexistovali.
20. Konkrétne správanie závisí od toho, či technológia používa:

• prepísanie existujúcich dát,
• synchronizáciu historického stavu,
• kompletnú náhradu dátového priestoru,
• alebo iný spôsob obnovy.

21. WebHouse môže pred vykonaním obnovy informovať Zákazníka o predpokladanom spôsobe zásahu, ak je to vzhľadom na charakter obnovy relevantné.
22. Pred vykonaním obnovy, ktorá môže mať významný deštruktívny účinok na aktuálne dáta, môže WebHouse požadovať výslovné potvrdenie Zákazníka.
23. Takéto potvrdenie môže byť požadované najmä pri:

• obnove celej databázy,
• obnove celej e-mailovej schránky,
• obnove celého webhostingového účtu,
• obnove VPS,
• návrate k snapshotu,
• alebo inom zásahu, pri ktorom sa aktuálny stav nahrádza historickým stavom.

24. WebHouse môže požadovať, aby Zákazník potvrdil, že rozumie tomu, že:

• budú použité historické dáta,
• novšie dáta môžu byť stratené,
• obnova nemusí byť jednoducho vratná,
• a návrat do súčasného stavu nemusí byť po dokončení obnovy možný.

25. Zákazník je povinný pred udelením takéhoto potvrdenia primerane zvážiť dôsledky obnovy.
26. Ak Zákazník výslovne potvrdí obnovu konkrétneho historického bodu, nesie zodpovednosť za rozhodnutie vrátiť príslušné dáta do tohto historického stavu.
27. Toto ustanovenie však nezbavuje WebHouse zodpovednosti za správne technické vykonanie potvrdenej obnovy.
28. Ak Zákazník napríklad potvrdí obnovu databázy z 1. augusta, WebHouse nezodpovedá za prirodzený dôsledok spočívajúci v tom, že databáza po obnove nebude obsahovať záznamy vytvorené 2. až 5. augusta.
29. WebHouse však zodpovedá za to, aby pri vykonaní takého pokynu nepoužil bez primeraného dôvodu iný bod obnovy alebo neprepísal iné dáta, než zodpovedajú potvrdenému rozsahu zásahu.
30. Zodpovednosť za výber historického bodu a zodpovednosť za správne technické vykonanie obnovy sú preto dve odlišné otázky.
31. Ak WebHouse poskytne Zákazníkovi nesprávnu alebo zavádzajúcu informáciu o dôsledkoch konkrétnej obnovy, posudzuje sa situácia podľa okolností konkrétneho prípadu.
32. Ak Zákazník požaduje obnovu, ale neuvedomuje si zjavné riziko prepísania významného množstva aktuálnych dát, WebHouse môže primerane upozorniť na tento dôsledok.
33. WebHouse nemusí vykonať zjavne nevratnú alebo rizikovú obnovu bez primeraného potvrdenia, ak existuje reálna možnosť, že požiadavka Zákazníka bola neúplná alebo nesprávne pochopená.
34. Takéto vyžiadanie potvrdenia sa nepovažuje za neodôvodnené zdržanie obnovy, ak je potrebné na ochranu dát Zákazníka.
35. Ak je však požiadavka Zákazníka jednoznačná a všetky podstatné dôsledky sú zrejmé alebo už boli potvrdené, WebHouse nemá vyžadovať opakované zbytočné potvrdenia.
36. Ak je to technicky možné a primerané, WebHouse môže pred obnovou odporučiť vytvorenie kópie aktuálneho stavu.
37. Takáto kópia môže mať formu:

• aktuálnej zálohy,
• manuálnej zálohy,
• snapshotu,
• exportu databázy,
• kópie súborov,
• alebo iného technicky vhodného bodu.

38. Cieľom takejto kópie je umožniť prípadné získanie dát, ktoré by inak boli pri obnove historického stavu prepísané.
39. Vytvorenie aktuálnej kópie pred obnovou však nemusí byť technicky možné v každom prípade.
40. Nemusí byť možné najmä vtedy, ak:

• sú produkčné dáta poškodené,
• úložisko zlyháva,
• nie je dostatok kapacity,
• služba je technicky nedostupná,
• systém je kompromitovaný,
• alebo ďalšie kopírovanie predstavuje bezpečnostné či technické riziko.

41. WebHouse preto negarantuje, že pred každou obnovou bude možné zachovať úplnú kópiu aktuálneho stavu.
42. Zákazník, pre ktorého majú aktuálne dáta význam, by mal pred potvrdením deštruktívnej obnovy podľa možností preveriť, či má ich samostatnú kópiu.
43. Ak WebHouse ponúkne možnosť vytvoriť aktuálnu kópiu pred obnovou a Zákazník ju odmietne, nesie Zákazník riziko straty novších dát v rozsahu prirodzene vyplývajúcom z potvrdenej obnovy.
44. Ak Zákazník požaduje okamžitú obnovu a výslovne trvá na jej vykonaní bez vytvorenia ochrannej kópie, môže WebHouse po primeranom upozornení takýto pokyn vykonať.
45. WebHouse však môže odmietnuť vykonať pokyn, ak by jeho vykonanie bezprostredne ohrozilo:

• integritu infraštruktúry,
• bezpečnosť,
• ostatných zákazníkov,
• alebo tretie strany.

46. Ak je cieľom obnovy iba získanie určitého historického súboru alebo údajov, môže byť bezpečnejšie obnoviť historické dáta do samostatného priestoru.
47. WebHouse môže podľa technických možností ponúknuť obnovu:

• do dočasného adresára,
• do samostatnej databázy,
• do dočasnej schránky,
• do novej virtuálnej inštancie,
• alebo do iného oddeleného priestoru.

48. Takáto obnova môže zabrániť okamžitému prepísaniu aktuálneho produkčného stavu.
49. Zákazník môže následne:

• preveriť historické dáta,
• vybrať potrebné položky,
• porovnať ich s aktuálnymi dátami,
• alebo manuálne vykonať potrebné zlúčenie.

50. Obnova do dočasného prostredia nemusí byť podporovaná pri každom type služby.
51. Môže tiež vyžadovať:

• dodatočný úložný priestor,
• dočasnú službu,
• alebo manuálnu administrátorskú prácu.

52. Takýto postup môže byť preto spoplatnený.
53. WebHouse nie je povinný vykonávať komplexné automatické zlúčenie historických a aktuálnych dát.
54. To platí najmä pri databázach, kde by automatické zlúčenie mohlo viesť ku:

• konfliktom primárnych kľúčov,
• duplicitným záznamom,
• porušeniu väzieb,
• nekonzistentným transakciám,
• alebo iným aplikačným problémom.

55. Ak Zákazník požaduje zachovanie novších databázových zmien a zároveň obnovu starších záznamov, môže byť potrebný individuálny databázový zásah.
56. Takýto zásah nie je automaticky súčasťou štandardnej obnovy.
57. Obdobne nie je WebHouse povinný automaticky zlúčiť:

• dve verzie webovej aplikácie,
• dve e-mailové schránky,
• dve konfigurácie servera,
• alebo dva rozdielne stavy VPS.

58. Pri databázovej obnove môže byť z technických dôvodov potrebné počas zásahu:

• zastaviť aplikáciu,
• obmedziť zápis do databázy,
• prepnúť službu do režimu údržby,
• alebo inak dočasne zabrániť vzniku nových dát.

59. Cieľom je zabrániť tomu, aby počas obnovy vznikali nové zmeny, ktoré by boli následne prepísané alebo spôsobili nekonzistenciu.
60. Zákazník je povinný rešpektovať pokyn WebHouse, aby počas obnovy nevykonával zmeny v dotknutej službe, ak je takýto pokyn potrebný na bezpečné dokončenie zásahu.
61. Ak Zákazník alebo jeho používatelia počas obnovy naďalej menia dáta, môžu byť tieto zmeny následne stratené.
62. WebHouse nezodpovedá za stratu takýchto zmien v rozsahu, v akom vznikla tým, že Zákazník napriek primeranému upozorneniu pokračoval v zápise do obnovovaného systému.
63. Ak služba zostane počas obnovy verejne dostupná, môže Zákazník podľa okolností zvážiť:

• dočasné vypnutie aplikácie,
• režim údržby,
• pozastavenie objednávok,
• alebo iný spôsob obmedzenia nových zápisov.

64. Konkrétny postup závisí od typu služby.
65. Pri obnove viacerých komponentov nemusí byť celý systém obnovený k úplne rovnakému časovému okamihu.
66. Webové súbory môžu mať napríklad bod obnovy z iného času než databáza.
67. Ak sa obnovujú oba komponenty, môže medzi nimi vzniknúť časový rozdiel.
68. Takýto rozdiel môže ovplyvniť aplikačnú konzistenciu.
69. Ak je časová konzistencia medzi komponentmi pre Zákazníka kritická, musí byť zabezpečená zálohovacím mechanizmom, ktorý ju výslovne podporuje.
70. Zákazník je po dokončení obnovy povinný primerane preveriť, či:

• bol obnovený požadovaný historický stav,
• sú prítomné očakávané dáta,
• aplikácia pracuje podľa očakávania,
• a nevznikla potreba doplniť novšie dáta z iného zdroja.

71. Ak Zákazník zistí problém, mal by ho oznámiť bez zbytočného odkladu.
72. Včasné oznámenie môže byť významné, pretože pôvodný produkčný stav alebo ďalšie historické body môžu byť v rámci štandardných procesov neskôr odstránené.
73. WebHouse negarantuje, že po uplynutí dlhšej doby bude možné vrátiť obnovu späť do stavu existujúceho bezprostredne pred jej vykonaním.
74. Ak nebola vytvorená samostatná kópia predobnovovacieho stavu, môže byť tento stav po prepísaní nenávratne stratený.
75. Zákazník preto nemá automatický nárok na funkciu „undo“ vykonanej obnovy.
76. Ak však existuje vhodný bod obnovy alebo ochranná kópia, môže byť technicky možné vykonať ďalšiu obnovu.
77. Takáto ďalšia obnova sa považuje za nový obnovovací zásah.
78. Opakované obnovy spôsobené zmenou rozhodnutia Zákazníka môžu byť spoplatnené.
79. Ak Zákazník po vykonanej obnove oznámi, že si želal iný bod, posudzuje sa, či:

• pôvodný bod vybral Zákazník,
• bol riadne potvrdený,
• WebHouse poskytol správne informácie,
• a WebHouse vykonal potvrdený pokyn správne.

80. Ak bol potvrdený pokyn vykonaný správne, samotná nespokojnosť Zákazníka s obsahom historického stavu neznamená chybu obnovy.
81. Ak však WebHouse použil nesprávny bod, nesprávny rozsah alebo vykonal inú chybu pri samotnej obnove, posudzuje sa zodpovednosť samostatne.
82. Ak obnova prebieha prostredníctvom samoobslužného systému, Zákazník zodpovedá za správny výber:

• služby,
• bodu obnovy,
• rozsahu,
• cieľového priestoru,

v rozsahu údajov, ktoré mu rozhranie umožňuje zvoliť.

83. WebHouse zodpovedá za to, aby samoobslužný systém v primeranom rozsahu vykonal potvrdený pokyn technicky správne.
84. Zákaznícke rozhranie môže pred deštruktívnym zásahom zobraziť upozornenie na možné prepísanie aktuálnych dát.
85. Potvrdením takéhoto upozornenia Zákazník potvrdzuje, že berie do úvahy uvedený dôsledok obnovy.
86. Samotné potvrdenie však nemožno vykladať ako vzdanie sa práv Zákazníka voči chybne fungujúcemu obnovovaciemu systému.
87. Ak je obnova potrebná v dôsledku bezpečnostného incidentu, môže byť zachovanie aktuálneho stavu dôležité aj na účely:

• analýzy príčiny incidentu,
• forenzného skúmania,
• alebo zachovania dôkazov.

88. V takom prípade môže byť vhodnejšie nevykonať okamžité prepísanie produkčného systému, ale najskôr vytvoriť dostupnú technickú kópiu.
89. Takýto postup však závisí od:

• technického stavu systému,
• dostupnej kapacity,
• naliehavosti incidentu,
• rozsahu objednanej služby.

90. Štandardná zálohovacia služba nezahŕňa automaticky forenzné uchovanie stavu pred každou obnovou.
91. Pri ransomvéri alebo malvéri sa použijú aj články XXII a XXIII.
92. Obnova staršieho bodu môže obnoviť aj historické bezpečnostné zraniteľnosti alebo kompromitované dáta.
93. Preto ani úspešná obnova historického stavu neznamená automaticky, že systém možno bez ďalšieho bezpečne uviesť do produkcie.
94. WebHouse môže podľa okolností požadovať vykonanie primeraných bezpečnostných opatrení pred opätovným spustením služby.
95. Ak je obnova vyvolaná konaním Zákazníka, napríklad:

• chybným vymazaním,
• chybnou aktualizáciou,
• neúspešnou migráciou,
• chybnou databázovou operáciou,

manuálna obnova môže byť spoplatnená podľa podmienok konkrétnej služby.

96. Ak je obnova potrebná v dôsledku preukázaného porušenia povinnosti WebHouse, posúdenie zodpovednosti a spoplatnenia sa riadi zmluvnými podmienkami, Reklamačným poriadkom a právnymi predpismi.
97. Samotné vykonanie obnovy na požiadanie Zákazníka nepredstavuje uznanie zodpovednosti WebHouse za príčinu, ktorá viedla k potrebe obnovy.
98. Zodpovednosť za príčinu incidentu a zodpovednosť za správne vykonanie následnej obnovy sa posudzujú oddelene.
99. Rozhodnutie Zákazníka obnoviť potvrdený starší historický stav nezbavuje WebHouse povinnosti konať s primeranou odbornou starostlivosťou pri samotnej obnove.
100. WebHouse nemôže ustanovenia o riziku prepísania použiť na ospravedlnenie:

• obnovy nesprávnej služby,
• použitia nesprávneho potvrdeného bodu,
• prekročenia potvrdeného rozsahu obnovy,
• alebo iného chybného technického zásahu.

101. Ak je pri konkrétnej službe výslovne dohodnutá funkcionalita nedestruktívnej, paralelnej alebo inak špecifickej obnovy, WebHouse je povinný túto vlastnosť poskytnúť v dohodnutom rozsahu.
102. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie osobitných parametrov konkrétnej služby.
103. Zákazník je povinný pri kritických dátach primerane zohľadniť riziko straty novších zmien a podľa možností udržiavať vlastné nezávislé zálohy.
104. Táto povinnosť však nezbavuje WebHouse zodpovednosti za riadne poskytovanie dohodnutej zálohovacej a obnovovacej služby.
105. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 27

Obnova do dočasného priestoru

1. Ak to technická architektúra konkrétnej služby umožňuje, WebHouse môže namiesto priameho prepísania produkčných dát obnoviť alebo sprístupniť zálohu v dočasnom, oddelenom alebo pomocnom priestore.
2. Cieľom takéhoto postupu je najmä znížiť riziko straty aktuálnych produkčných dát a umožniť Zákazníkovi preveriť historický obsah pred jeho prípadným použitím v produkcii.
3. Dočasná obnova môže byť vhodná najmä vtedy, ak:
   • Zákazník potrebuje iba konkrétny súbor,
   • potrebuje porovnať staršiu a aktuálnu verziu dát,
   • nie je isté, ktorý bod obnovy obsahuje požadované údaje,
   • je potrebné preveriť databázu,
   • existuje riziko, že priama obnova prepíše novšie dáta,
   • ide o bezpečnostný incident,
   • alebo je vhodné najskôr overiť obsah historickej zálohy.
4. Dočasný priestor môže mať podľa konkrétnej služby podobu najmä:
   • samostatného adresára,
   • dočasného webového priestoru,
   • samostatnej databázy,
   • dočasnej e-mailovej schránky,
   • pripojeného historického disku,
   • dočasnej virtuálnej inštancie,
   • izolovaného serverového prostredia,
   • alebo iného technicky vhodného priestoru.
5. Konkrétny spôsob dočasnej obnovy určuje WebHouse podľa:
   • typu služby,
   • použitej zálohovacej technológie,
   • rozsahu dát,
   • dostupnej kapacity,
   • bezpečnostných požiadaviek,
   • a účelu obnovy.
6. Zákazník nemá automatický nárok určiť konkrétnu internú technickú formu dočasného priestoru, ak WebHouse zabezpečí primeraný spôsob sprístupnenia požadovaných dát.
7. Dočasná obnova nemusí byť dostupná pri každej službe.
8. Niektoré zálohovacie systémy môžu podporovať iba:
   • priamu obnovu do pôvodného umiestnenia,
   • obnovu celej technickej jednotky,
   • alebo iný spôsob, pri ktorom samostatný dočasný priestor nie je technicky možný.
9. Samotná existencia zálohy preto neznamená automatickú možnosť jej paralelného sprístupnenia mimo produkčného prostredia.
10. Ak dočasná obnova nie je technicky možná, WebHouse môže ponúknuť iný podporovaný spôsob obnovy.
11. Dočasný priestor je spravidla určený na:

• kontrolu historických dát,
• výber potrebných súborov,
• export dát,
• porovnanie verzií,
• manuálne získanie vybraných údajov,
• alebo technickú analýzu.

12. Dočasný priestor nemusí byť určený na dlhodobú produkčnú prevádzku.
13. WebHouse nemusí pri dočasnej obnove garantovať rovnaké vlastnosti ako pri produkčnej službe.
14. Dočasný priestor môže mať obmedzenú:

• kapacitu,
• výpočtovú kapacitu,
• sieťovú dostupnosť,
• funkcionalitu,
• dobu existencie,
• alebo rozsah technickej podpory.

15. WebHouse môže dočasný priestor sprístupniť iba na čas potrebný na vykonanie kontroly alebo prevzatie dát.
16. Zákazník je povinný potrebné dáta z dočasného priestoru prevziať, exportovať alebo spracovať v určenej lehote.
17. Po uplynutí určenej doby môže WebHouse dočasný priestor a v ňom obnovené dáta odstrániť.
18. WebHouse nie je povinný dočasnú obnovenú kópiu uchovávať po dobu zodpovedajúcu štandardnej retenčnej dobe pôvodných záloh.
19. Retencia zálohy a životnosť dočasne obnovenej kópie predstavujú rozdielne technické parametre.
20. Dočasne obnovené dáta môžu byť odstránené skôr než pôvodný bod obnovy, z ktorého boli vytvorené.
21. Ak Zákazník potrebuje predĺžiť dobu dostupnosti dočasného priestoru, môže byť potrebné:

• dohodnúť predĺženie,
• objednať dodatočnú kapacitu,
• alebo preniesť dáta do vlastného priestoru.

22. Predĺženie nemusí byť technicky možné pri každej službe.
23. Poskytnutie dočasného priestoru môže byť:

• zahrnuté v cene konkrétnej obnovy,
• zahrnuté iba v určitom rozsahu,
• alebo samostatne spoplatnené.

24. Spoplatnený môže byť najmä:

• dodatočný diskový priestor,
• vytvorenie dočasného VPS,
• manuálne pripojenie zálohy,
• opakovaná obnova viacerých bodov,
• predĺžené uchovanie dočasného prostredia,
• alebo administrátorská práca.

25. Konkrétne spoplatnenie sa riadi cenníkom alebo individuálnou dohodou.
26. Obnova do dočasného priestoru neznamená automaticky, že obnovené dáta budú priamo použiteľné ako plnohodnotná produkčná služba.
27. Historické dáta môžu byť sprístupnené iba na účely čítania, exportu alebo manuálneho spracovania.
28. Dočasný webový priestor napríklad nemusí mať:

• rovnakú doménu,
• rovnaké DNS nastavenia,
• rovnaký SSL certifikát,
• rovnakú IP adresu,
• rovnaké externé integrácie,
• alebo rovnaké produkčné konfigurácie.

29. Dočasne obnovený VPS môže byť:

• bez verejnej IP adresy,
• v izolovanej sieti,
• bez niektorých externých služieb,
• alebo s odlišnou sieťovou konfiguráciou.

30. Dočasná databáza môže mať:

• iný názov,
• iného používateľa,
• iné prístupové údaje,
• alebo byť dostupná iba z obmedzeného prostredia.

31. Dočasná e-mailová schránka nemusí byť pripojená k bežnému doručovaniu novej pošty.
32. Dočasná obnova teda nemusí predstavovať presnú prevádzkovú repliku pôvodného produkčného prostredia.
33. Jej primárnym účelom môže byť iba sprístupnenie historického obsahu.
34. WebHouse negarantuje, že aplikácia spustená v dočasnom prostredí bude úplne funkčná.
35. Funkčnosť môže byť ovplyvnená napríklad:

• absenciou produkčnej domény,
• rozdielnou IP adresou,
• chýbajúcou externou databázou,
• chýbajúcou licenciou,
• chýbajúcimi API prístupmi,
• odlišnou verziou softvéru,
• alebo inými závislosťami mimo zálohy.

36. Ak je cieľom iba získanie dát, WebHouse nie je povinný rekonštruovať všetky externé závislosti potrebné na úplnú prevádzku historickej aplikácie.
37. Obnova do dočasného priestoru môže umožniť Zákazníkovi porovnať:

• historické a aktuálne súbory,
• historickú a aktuálnu databázu,
• rôzne verzie konfigurácie,
• alebo iné dátové stavy.

38. WebHouse však nie je automaticky povinný takéto porovnanie vykonať za Zákazníka.
39. Zákazník zodpovedá za obsahové rozhodnutie, ktoré historické dáta chce z dočasného priestoru následne použiť.
40. WebHouse môže poskytnúť technickú súčinnosť s:

• exportom,
• kopírovaním,
• importom,
• alebo iným presunom vybraných dát,

ak je takáto činnosť súčasťou služby alebo je osobitne dohodnutá.

41. Individuálne porovnávanie obsahu môže predstavovať spoplatnený administrátorský zásah.
42. WebHouse nemusí byť schopný určiť, ktorá z dvoch verzií dát je z obchodného alebo aplikačného hľadiska „správna“.
43. Zákazník je preto zodpovedný za rozhodnutie, ktoré historické dáta majú byť prenesené späť do produkcie.
44. To je významné najmä pri databázach.
45. Historická databáza môže obsahovať staršie záznamy, ale nemusí obsahovať novšie zmeny vzniknuté po zvolenom bode obnovy.
46. Ak Zákazník potrebuje z historickej databázy obnoviť iba:

• jednu tabuľku,
• jeden záznam,
• jednu objednávku,
• alebo inú konkrétnu časť,

môže byť potrebná manuálna databázová práca.

47. Takáto práca nemusí byť súčasťou štandardnej zálohovacej alebo obnovovacej služby.
48. Manuálne zlúčenie historických a aktuálnych databáz môže byť technicky náročné alebo nemožné bez znalosti konkrétnej aplikácie.
49. WebHouse nie je povinný automaticky vykonať zlúčenie databáz, ktoré môže viesť k:

• duplicitným záznamom,
• porušeniu referenčnej integrity,
• konfliktom identifikátorov,
• alebo inej aplikačnej nekonzistencii.

50. Ak je takýto zásah potrebný, môže byť potrebná súčinnosť:

• Zákazníka,
• vývojára aplikácie,
• databázového administrátora,
• alebo iného odborníka.

51. Podobne pri súboroch nie je WebHouse automaticky povinný rozhodnúť, ktorú z viacerých verzií súboru má Zákazník použiť.
52. WebHouse môže sprístupniť historickú verziu a Zákazník vykoná jej kontrolu a výber.
53. Dočasný priestor môže byť použitý aj na preverenie viacerých bodov obnovy.
54. Ak Zákazník nevie, v ktorom bode sa požadované dáta nachádzajú, môže byť potrebné postupne obnoviť alebo pripojiť viacero historických bodov.
55. Takýto postup môže byť časovo a technicky náročný.
56. WebHouse nie je povinný vykonať neobmedzený počet testovacích obnov bezplatne.
57. Opakované obnovovanie viacerých historických bodov môže byť spoplatnené podľa rozsahu práce.
58. WebHouse môže obmedziť počet súčasne aktívnych dočasných obnov z kapacitných alebo prevádzkových dôvodov.
59. Zákazník nemá automatický nárok na súčasné sprístupnenie všetkých historických bodov obnovy.
60. WebHouse môže jednotlivé body sprístupňovať postupne.
61. Pri bezpečnostnom incidente môže byť obnova do dočasného alebo izolovaného priestoru preferovaným spôsobom obnovy.
62. To platí najmä pri podozrení na:

• malware,
• ransomware,
• backdoor,
• webshell,
• kompromitovaný VPS,
• alebo iný škodlivý obsah.

63. Cieľom izolácie je zabrániť tomu, aby historicky obnovený škodlivý obsah:

• začal komunikovať so sieťou,
• pokračoval v útoku,
• rozosielal spam,
• napádal tretie strany,
• alebo opätovne ohrozil produkčné prostredie.

64. Dočasné prostredie môže byť preto z bezpečnostných dôvodov úplne alebo čiastočne odpojené od verejnej siete.
65. Zákazník nemá automatický nárok na verejné sprístupnenie kompromitovaného dočasného systému.
66. WebHouse môže povoliť jeho pripojenie až po vykonaní primeraných bezpečnostných opatrení.
67. Obnova do izolovaného priestoru neznamená, že WebHouse potvrdzuje bezpečnostnú čistotu obnovených dát.
68. Zákazník alebo ním poverený odborník môže byť povinný obnovený obsah preveriť pred jeho prenesením do produkcie.
69. Ak je potrebný malware scan, bezpečnostná analýza alebo forenzné preverenie, ide o samostatnú činnosť, pokiaľ nie je výslovne zahrnutá v službe.
70. Dočasný priestor môže obsahovať osobné údaje, obchodné tajomstvo alebo iné citlivé informácie.
71. WebHouse je povinný chrániť takýto priestor primerane charakteru služby a svojim povinnostiam.
72. Zákazník je povinný zabezpečiť prístupové údaje, ktoré mu boli na prístup do dočasného priestoru poskytnuté.
73. Zákazník nesmie poskytnúť prístup neoprávnenej osobe.
74. Ak WebHouse poskytne dočasné prístupové údaje, môže ich:

• časovo obmedziť,
• po skončení zásahu deaktivovať,
• alebo požiadať Zákazníka o ich zmenu.

75. Dočasný priestor nemusí mať rovnakú úroveň dostupnosti alebo redundancie ako produkčná služba.
76. Ak je jeho účelom iba krátkodobé získanie dát, nemusí byť zahrnutý do štandardného SLA produkčnej služby.
77. WebHouse negarantuje nepretržitú dostupnosť dočasného obnovovacieho prostredia, pokiaľ to nebolo výslovne dohodnuté.
78. Zákazník by preto nemal dočasný priestor používať ako náhradu riadnej produkčnej služby.
79. Zákazník by rovnako nemal do dočasného prostredia ukladať nové jedinečné dáta, ktoré nemá uložené inde.
80. Dočasný priestor môže byť po splnení účelu odstránený bez ďalšieho zálohovania jeho nového obsahu.
81. Ak Zákazník počas dočasnej obnovy vykoná zmeny v obnovených dátach, nie je automaticky garantované, že tieto zmeny budú samostatne zálohované.
82. Ak chce Zákazník výsledok takýchto zmien zachovať, musí ho pred odstránením dočasného prostredia exportovať alebo presunúť.
83. WebHouse môže Zákazníka informovať o lehote, počas ktorej bude dočasný priestor dostupný.
84. Zákazník je povinný túto lehotu dodržať.
85. Ak Zákazník v stanovenej lehote potrebné dáta neprevezme, WebHouse môže dočasnú kópiu odstrániť.
86. Odstránenie dočasnej kópie po uplynutí oznámenej doby neznamená automaticky odstránenie pôvodného bodu obnovy, ak tento bod ešte zostáva v štandardnej retencii.
87. Naopak odstránenie pôvodného bodu obnovy v rámci štandardnej rotácie nemusí automaticky znamenať okamžité odstránenie už vytvorenej dočasnej kópie.
88. Ide o dva samostatné technické objekty s potenciálne rozdielnym životným cyklom.
89. Zákazník však nesmie predpokladať, že existencia jednej z týchto kópií predlžuje retenčnú dobu druhej.
90. WebHouse môže dočasne obnovené dáta odstrániť aj skôr, ak je to nevyhnutné z dôvodu:

• bezpečnostného rizika,
• porušenia podmienok,
• technickej poruchy,
• alebo nevyhnutnej ochrany infraštruktúry.

91. Ak je to možné a primerané, WebHouse Zákazníka o takomto postupe informuje.
92. Ak Zákazník po kontrole dočasnej obnovy požiada o prenesenie vybraných dát do produkčného prostredia, ide o samostatný krok.
93. Takýto krok môže viesť k prepísaniu alebo zmene aktuálnych produkčných dát.
94. Pred jeho vykonaním sa preto primerane použijú pravidlá článku XXVI.
95. WebHouse môže pred prenesením historických dát do produkcie požadovať potvrdenie Zákazníka.
96. Zákazník zodpovedá za rozhodnutie, ktoré z historických dát chce preniesť do produkčného prostredia.
97. WebHouse zodpovedá za správne technické vykonanie rozsahu, ktorý bol potvrdený alebo dohodnutý.
98. Ak Zákazník požaduje iba prístup k dočasným dátam a následné kopírovanie vykonáva sám, zodpovedá za správnosť vlastného výberu a kopírovania.
99. WebHouse nezodpovedá za zákazníkom vykonané manuálne zmeny, ktoré boli vykonané nesprávne.
100. Ak WebHouse vykonáva samotný presun alebo import na pokyn Zákazníka, zodpovednosť za technické vykonanie sa posudzuje podľa rozsahu takéhoto zásahu.
101. Obnova do dočasného priestoru predstavuje nástroj na zníženie rizika pri obnove, nie absolútnu ochranu pred stratou alebo poškodením dát.
102. Ani pri dočasnej obnove nemožno garantovať, že:

• požadovaný súbor bude v zálohe existovať,
• konkrétny bod bude nepoškodený,
• historická aplikácia bude plne funkčná,
• alebo historické dáta budú vecne správne.

103. Na integritu a obsah dočasne obnovených dát sa primerane vzťahujú články XXI až XXIII týchto Pravidiel.
104. Ak dočasná obnova nie je súčasťou parametrov konkrétnej služby, jej jednorazové poskytnutie WebHouse nevytvára nárok na rovnaký postup pri budúcich obnovách.
105. Jednorazové bezplatné vytvorenie dočasného priestoru môže predstavovať technickú pomoc alebo goodwill nad rámec objednanej služby.
106. Takýto postup nemení rozsah služby ani cenník do budúcnosti.
107. Ak je možnosť paralelnej alebo dočasnej obnovy výslovne súčasťou konkrétnej služby, WebHouse je povinný túto funkcionalitu poskytovať v dohodnutom rozsahu.
108. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie výslovne dohodnutých parametrov dočasnej obnovy.
109. Povinnosť Zákazníka vybrať požadované dáta z dočasného priestoru nezbavuje WebHouse zodpovednosti za správne sprístupnenie historického bodu, ktorý bol určený na obnovu.
110. Zákazník naopak nemôže od WebHouse požadovať, aby bez osobitnej dohody prevzal aplikačné alebo obchodné rozhodovanie o tom, ktoré historické dáta majú nahradiť aktuálne produkčné dáta.
111. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 28

Čas obnovy

1. Doba potrebná na obnovu dát závisí od technických a prevádzkových okolností konkrétneho prípadu.
2. Čas obnovy môže byť ovplyvnený najmä:
   • objemom obnovovaných dát,
   • počtom súborov,
   • veľkosťou databáz,
   • veľkosťou e-mailových schránok,
   • veľkosťou virtuálnych diskov,
   • typom služby,
   • použitou zálohovacou technológiou,
   • formátom zálohy,
   • umiestnením zálohy,
   • spôsobom obnovy,
   • zaťažením produkčnej infraštruktúry,
   • zaťažením zálohovacej infraštruktúry,
   • dostupnou prenosovou kapacitou,
   • rozsahom poškodenia,
   • technickou použiteľnosťou zvoleného bodu obnovy,
   • potrebou preveriť viacero bodov obnovy,
   • potrebou vytvoriť dočasné alebo izolované prostredie.
3. Samotná existencia dostupného bodu obnovy neznamená, že jeho obsah je možné okamžite sprístupniť alebo obnoviť.
4. Záloha môže byť uložená v technickom formáte, ktorý pred použitím vyžaduje najmä:
   • načítanie zo zálohovacieho úložiska,
   • rekonštrukciu inkrementálneho reťazca,
   • dekompresiu,
   • dešifrovanie,
   • pripojenie virtuálneho disku,
   • import databázy,
   • alebo iný technický proces.
5. Čas potrebný na takýto proces je súčasťou celkového technického času obnovy.
6. WebHouse negarantuje okamžitú dostupnosť každej zálohy, pokiaľ takáto vlastnosť nie je výslovne súčasťou konkrétnej služby.
7. Niektoré zálohy môžu byť dostupné na rýchlom online úložisku, iné môžu vyžadovať dodatočný technický krok pred samotnou obnovou.
8. Spôsob uloženia zálohy môže byť rozdielny podľa:
   • veku bodu obnovy,
   • typu služby,
   • zálohovacej politiky,
   • alebo použitej technológie.
9. WebHouse nie je povinný uchovávať všetky historické zálohy na rovnako výkonnom alebo okamžite dostupnom úložisku, pokiaľ takýto parameter nie je výslovne dohodnutý.
10. Doba obnovy závisí aj od rozsahu požadovaného zásahu.
11. Obnova jedného súboru môže byť spravidla jednoduchšia než obnova:

• celej databázy,
• celej e-mailovej schránky,
• celého webhostingového účtu,
• celého virtuálneho servera,
• alebo celého fyzického servera.

12. Pri niektorých technológiách však môže byť na získanie jedného súboru potrebné najskôr obnoviť alebo pripojiť celý väčší technický celok.
13. Selektívna požiadavka preto nemusí automaticky znamenať kratší čas obnovy.
14. Ak je potrebné najskôr obnoviť celý VPS do dočasnej inštancie a až následne z neho vybrať jeden súbor, celkový čas môže byť porovnateľný s obnovou väčšieho rozsahu dát.
15. Doba obnovy môže byť ovplyvnená aj počtom požadovaných bodov obnovy.
16. Ak Zákazník nevie určiť správny historický bod a je potrebné postupne preverovať viacero záloh, môže sa čas zásahu predĺžiť.
17. WebHouse nie je povinný vykonávať neobmedzený počet testovacích obnov bez primeraného vplyvu na čas a prípadné spoplatnenie zásahu.
18. Pri bezpečnostnom incidente môže byť obnova časovo náročnejšia než pri bežnom neúmyselnom vymazaní dát.
19. Môže byť potrebné najmä:

• zvoliť starší bod obnovy,
• obnoviť dáta do izolovaného prostredia,
• preveriť prítomnosť škodlivého kódu,
• odstrániť bezpečnostné riziko,
• alebo vykonať ďalšie nápravné opatrenia pred produkčným spustením.

20. Samotné technické skopírovanie dát preto nemusí predstavovať celý proces bezpečného obnovenia služby.
21. Ak by okamžité produkčné spustenie obnoveného systému vytváralo bezpečnostné riziko, môže byť služba sprístupnená až po vykonaní primeraných bezpečnostných opatrení.
22. Čas potrebný na odstránenie zákazníkom spravovanej zraniteľnosti alebo kompromitácie nie je automaticky časom technickej obnovy, za ktorý zodpovedá WebHouse.
23. Ak je na pokračovanie obnovy potrebná súčinnosť Zákazníka, môže sa celkový čas dokončenia predĺžiť o dobu, počas ktorej WebHouse čaká na túto súčinnosť.
24. Môže ísť najmä o čakanie na:

• výber bodu obnovy,
• potvrdenie prepísania aktuálnych dát,
• potvrdenie ceny nadštandardného zásahu,
• poskytnutie prístupových údajov,
• odstránenie zákazníkom spravovanej zraniteľnosti,
• alebo iné rozhodnutie potrebné na bezpečné pokračovanie.

25. Doba, počas ktorej WebHouse objektívne nemôže pokračovať pre chýbajúcu potrebnú súčinnosť Zákazníka, sa nepovažuje za neodôvodnené omeškanie WebHouse.
26. WebHouse však nesmie požadovať súčinnosť, ktorá nie je na vykonanie obnovy primerane potrebná.
27. Ak nie je pri konkrétnej službe výslovne dohodnutá garantovaná doba obnovy, čas obnovy nie je garantovaným SLA parametrom.
28. V takom prípade WebHouse vykonáva obnovu v primeranom čase podľa:

• charakteru služby,
• rozsahu incidentu,
• dostupných technických možností,
• aktuálneho zaťaženia,
• a priority incidentu.

29. Pojem „primeraný čas“ neznamená pevne stanovený počet minút alebo hodín, pokiaľ takáto lehota nie je výslovne dohodnutá.
30. Primeranosť času sa posudzuje podľa konkrétnych okolností obnovy.
31. Samotná obchodná naliehavosť na strane Zákazníka nevytvára automaticky garantovanú dobu obnovy.
32. Skutočnosť, že výpadok alebo strata dát má pre Zákazníka vysoký finančný alebo prevádzkový význam, sama osebe nemení štandardnú zálohovaciu službu na službu s garantovaným RTO.
33. Ak Zákazník potrebuje obnovu v konkrétnom maximálnom čase, musí byť takýto parameter výslovne súčasťou:

• konkrétnej služby,
• SLA,
• individuálnej dohody,
• alebo osobitného disaster recovery riešenia.

34. Garantovaná doba obnovy sa označuje ako RTO iba vtedy, ak je tento parameter pri službe výslovne definovaný.
35. Samotná existencia zálohy nepredstavuje RTO.
36. Rovnako frekvencia zálohovania nepredstavuje RTO.
37. RPO a RTO predstavujú rozdielne parametre.
38. RPO sa týka prípustného časového rozdielu medzi posledným relevantným bodom obnovy a incidentom.
39. RTO sa týka času potrebného na obnovenie služby alebo dát podľa podmienok konkrétnej služby.
40. Vyššia frekvencia záloh preto automaticky neznamená rýchlejšiu obnovu.
41. Rovnako rýchla obnova neznamená, že existuje veľmi aktuálny bod obnovy.
42. Ak je pri konkrétnej službe garantované RTO, podmienky jeho počítania musia vyplývať z príslušnej služby alebo SLA.
43. Môžu zahŕňať najmä:

• okamih začatia merania,
• požadovaný spôsob nahlásenia incidentu,
• potrebnú súčinnosť Zákazníka,
• rozsah garantovanej obnovy,
• výluky,
• alebo iné podmienky.

44. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie výslovne dohodnutého RTO.
45. Ak RTO nie je dohodnuté, WebHouse negarantuje obnovenie do konkrétneho času len na základe predchádzajúcej skúsenosti.
46. Skutočnosť, že obdobná obnova bola v minulosti dokončená napríklad za jednu hodinu, neznamená, že každá budúca obnova bude dokončená v rovnakej lehote.
47. Doba obnovy sa môže medzi jednotlivými incidentmi významne líšiť.
48. Rozdiel môže vzniknúť aj pri rovnakej službe v závislosti od:

• objemu aktuálnych dát,
• stavu úložiska,
• typu incidentu,
• dostupnosti konkrétneho bodu,
• zaťaženia infraštruktúry.

49. WebHouse môže pri izolovanom incidente obnoviť službu rýchlejšie než pri udalosti postihujúcej väčšiu časť infraštruktúry.
50. Pri rozsiahlej havárii môže byť potrebné vykonávať obnovu väčšieho počtu služieb alebo zákazníkov súčasne.
51. V takom prípade môže byť potrebné najskôr obnoviť spoločné technické vrstvy, napríklad:

• storage,
• virtualizačnú platformu,
• sieťovú infraštruktúru,
• databázovú infraštruktúru,
• alebo inú spoločnú službu.

52. Individuálna obnova konkrétneho zákazníckeho účtu nemusí byť technicky možná pred obnovením tejto spoločnej vrstvy.
53. Pri rozsiahlej udalosti môže WebHouse určovať poradie obnovovacích prác.
54. Poradie môže zohľadňovať najmä:

• bezpečnostné riziko,
• technické závislosti,
• rozsah dopadu,
• efektívnosť obnovy spoločných komponentov,
• individuálne dohodnuté SLA alebo priority.

55. Bez osobitnej dohody nemá Zákazník automatický nárok na prednostnú obnovu iba preto, že jeho službu subjektívne považuje za najdôležitejšiu.
56. WebHouse môže uprednostniť obnovenie spoločnej infraštruktúry, ak tým umožní obnovenie väčšieho počtu služieb.
57. WebHouse môže takisto uprednostniť bezpečnostný zásah pred samotnou obnovou dát, ak je to potrebné na zabránenie ďalšiemu poškodeniu.
58. Priority obnovy nesmú byť určované svojvoľne spôsobom, ktorý by bol v rozpore s výslovne dohodnutými SLA záväzkami.
59. Pri viacnásobnom incidente môže byť doba obnovy ovplyvnená aj dostupnosťou technických pracovníkov a potrebou koordinácie zásahov.
60. WebHouse môže pri riešení incidentu používať automatizované aj manuálne procesy.
61. Nie každý proces obnovy je možné paralelizovať bez obmedzenia.
62. Niektoré obnovovacie operácie môžu vyžadovať:

• výhradný prístup k úložisku,
• vysokú diskovú priepustnosť,
• veľký objem sieťovej kapacity,
• alebo sekvenčné vykonanie jednotlivých krokov.

63. WebHouse môže obnovu technicky regulovať tak, aby nedošlo k neprimeranému ohrozeniu ostatných služieb.
64. WebHouse nie je povinný maximalizovať rýchlosť jednej obnovy spôsobom, ktorý by vážne ohrozil stabilitu celej infraštruktúry.
65. Pri veľkých dátových objemoch môže byť fyzická rýchlosť prenosu alebo zápisu významným limitom.
66. Napríklad obnova viacerých terabajtov dát môže objektívne vyžadovať podstatne dlhší čas než obnova malého webhostingového účtu.
67. Zákazník nemá automatický nárok na okamžité pridelenie neobmedzenej technickej kapacity na jednu obnovu.
68. Ak konkrétna služba poskytuje vyššiu prioritu alebo rezervovanú kapacitu obnovy, musí byť takáto vlastnosť výslovne uvedená.
69. Doba obnovy môže byť ovplyvnená aj poškodením zdrojových alebo cieľových dát.
70. Ak je potrebné:

• opravovať súborový systém,
• hľadať použiteľný bod,
• rekonštruovať databázu,
• alebo vykonávať iné dodatočné technické operácie,

môže sa obnova predĺžiť.

71. WebHouse negarantuje možnosť opraviť každú poškodenú zálohu.
72. Ak najnovší bod nie je použiteľný, môže byť potrebné začať nový obnovovací proces zo staršieho bodu.
73. Čas neúspešného pokusu a následného alternatívneho postupu môže zvýšiť celkovú dobu obnovy.
74. Samotná skutočnosť, že problém použiteľnosti zálohy bol zistený až pri obnove, automaticky neznamená neodôvodnené omeškanie.
75. Posúdenie závisí od technických okolností a od toho, či WebHouse postupoval primerane.
76. Pri obnove databáz môže čas závisieť aj od:

• veľkosti dumpu,
• počtu záznamov,
• veľkosti indexov,
• času potrebného na import,
• rekonštrukcie indexov,
• alebo kontroly integrity.

77. Skopírovanie záložného súboru databázy preto nemusí znamenať dokončenie obnovy databázy.
78. Pri VPS môže byť potrebné najskôr obnoviť celý virtuálny disk a následne:

• pripojiť ho,
• vykonať boot,
• skontrolovať súborový systém,
• alebo vykonať ďalšie technické úkony.

79. Pri fyzickom serveri môže byť pred obnovou potrebná oprava alebo výmena hardvéru.
80. Čas potrebný na dodanie alebo zabezpečenie zákazníkom vlastneného náhradného hardvéru nie je automaticky súčasťou zálohovacieho SLA WebHouse.
81. Pri serverhousingu môže byť celková doba návratu služby závislá aj od súčinnosti Zákazníka pri zabezpečení funkčného hardvéru.
82. Pri e-mailových schránkach môže byť čas obnovy ovplyvnený:

• veľkosťou schránky,
• počtom správ,
• počtom priečinkov,
• požiadavkou na individuálne vyhľadávanie správ.

83. Individuálne vyhľadávanie jednej správy môže trvať dlhšie než obnova celej schránky do dočasného priestoru.
84. WebHouse môže v takom prípade zvoliť technicky efektívnejší spôsob sprístupnenia dát.
85. Obnova do dočasného priestoru podľa článku XXVII môže tiež vyžadovať dodatočný čas na:

• vytvorenie priestoru,
• pridelenie kapacity,
• pripojenie zálohy,
• alebo vytvorenie dočasnej virtuálnej inštancie.

86. Tento čas je súčasťou technického procesu, ak je takýto spôsob obnovy zvolený.
87. Ak Zákazník po začatí obnovy zmení požadovaný:

• bod obnovy,
• rozsah,
• alebo cieľ,

môže sa celkový čas predĺžiť.

88. Môže byť potrebné:

• zastaviť pôvodný proces,
• odstrániť čiastočne obnovené dáta,
• spustiť nový restore,
• alebo vykonať ďalšie úkony.

89. Zmena požiadavky Zákazníka nemení spätne primeranosť času už vykonaných úkonov.
90. Ak Zákazník žiada obnovu mimo štandardného rozsahu technickej podpory alebo vyžaduje individuálny administrátorský zásah, môže byť termín jeho vykonania závislý aj od dostupnosti príslušného odborného pracovníka.
91. Takáto služba nemusí mať rovnaký reakčný alebo obnovovací čas ako incident krytý SLA.
92. WebHouse môže Zákazníkovi poskytnúť orientačnú informáciu o predpokladanom trvaní obnovy.
93. Takýto orientačný odhad nie je garantovanou lehotou, pokiaľ nebol výslovne označený ako zmluvne záväzný parameter.
94. Odhad sa môže meniť po zistení:

• skutočného objemu dát,
• poškodenia,
• nefunkčného bodu obnovy,
• alebo inej technickej okolnosti.

95. Zmena realistického technického odhadu sama osebe neznamená porušenie služby.
96. WebHouse by mal pri významnej zmene okolností primerane informovať Zákazníka o stave obnovy, ak to charakter incidentu a komunikačné možnosti umožňujú.
97. Povinnosť informovať však neznamená povinnosť poskytovať presný čas dokončenia, ak ho nemožno technicky spoľahlivo určiť.
98. Pri komplexnom incidente môže byť možné komunikovať skôr:

• aktuálny stav,
• vykonaný krok,
• alebo identifikovanú prekážku,

než presnú zostávajúcu dobu.

99. WebHouse nesmie bez primeraného dôvodu odkladať začatie alebo pokračovanie obnovy, ktorá je súčasťou objednanej služby a pre ktorú existujú technické podmienky.
100. Skutočnosť, že čas nie je garantovaným SLA parametrom, neznamená, že WebHouse môže obnovu odkladať ľubovoľne.
101. WebHouse je povinný postupovať s primeranou odbornou starostlivosťou a vykonať obnovu v primeranom čase podľa okolností.
102. Pri posudzovaní primeranosti sa prihliada najmä na:

• zložitosť zásahu,
• rozsah dát,
• rozsah incidentu,
• dostupnosť zdrojov,
• technické prekážky,
• súčinnosť Zákazníka,
• a prípadné dohodnuté priority.

103. Jednorazové dlhšie trvanie obnovy preto automaticky neznamená vadu služby.
104. Opakované alebo systematické neprimerané oneskorenia môžu byť posudzované odlišne.
105. Ak WebHouse výslovne poskytuje službu s garantovaným časom obnovy, zodpovedá za dodržanie tohto parametra podľa príslušných podmienok.
106. Všeobecná formulácia o primeranom čase nemá prednosť pred konkrétnou zmluvnou garanciou.
107. Ak je doba obnovy súčasťou SLA, prípadné následky nedodržania sa riadia príslušným SLA.
108. Samotná existencia SLA dostupnosti služby však nemusí automaticky znamenať SLA obnovy dát.
109. Dostupnosť produkčnej služby a čas obnovy zo zálohy predstavujú rozdielne parametre.
110. Napríklad 99,9 % garancia dostupnosti VPS sama osebe neznamená, že historický VPS bude zo zálohy obnovený v konkrétnom počte hodín.
111. Rovnako SLA reakčného času technickej podpory nemusí znamenať garantovaný čas dokončenia samotnej obnovy.
112. Je preto potrebné odlišovať:

• reakčný čas,
• čas začatia riešenia,
• čas technickej obnovy,
• čas úplného návratu aplikácie do produkčného stavu.

113. WebHouse môže splniť reakčný čas technickej podpory aj v situácii, keď samotná obnova vzhľadom na objem dát trvá podstatne dlhšie.
114. Ak Zákazník potrebuje konkrétny čas úplného návratu kritickej služby do prevádzky, môže byť potrebné použiť:

• vysokú dostupnosť,
• replikáciu,
• hot-standby systém,
• disaster recovery riešenie,
• alebo inú technológiu nad rámec bežného backupu.

115. Záloha je primárne mechanizmom obnovy dát, nie automaticky mechanizmom okamžitej kontinuity prevádzky.
116. Zákazník s kritickou službou je povinný primerane posúdiť, či štandardný čas obnovy bez garantovaného RTO zodpovedá jeho potrebám.
117. Ak nezodpovedá, musí si objednať vhodnejšiu službu alebo zaviesť vlastné opatrenia.
118. Táto povinnosť však nezbavuje WebHouse zodpovednosti za dodržanie parametrov, ktoré pri konkrétnej službe výslovne garantoval.
119. WebHouse nemôže všeobecné ustanovenie o technických možnostiach použiť na obchádzanie dohodnutého RTO, priority alebo iného konkrétneho časového záväzku.
120. Ak je čas obnovy ovplyvnený udalosťou alebo prekážkou na strane Zákazníka, zodpovednosť sa posudzuje podľa príčiny a rozsahu tejto prekážky.
121. Ak je naopak neprimerané oneskorenie spôsobené porušením povinnosti na strane WebHouse, posudzuje sa podľa zmluvných podmienok, Reklamačného poriadku a príslušných právnych predpisov.
122. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 29

RPO a RTO

1. Recovery Point Objective (ďalej len „RPO“) a Recovery Time Objective (ďalej len „RTO“) predstavujú samostatné parametre obnovy služby alebo dát.
2. RPO vyjadruje cieľový alebo garantovaný maximálny časový rozdiel medzi stavom dát, ktorý je možné obnoviť, a okamihom rozhodujúcej udalosti, ak je takýto parameter pri konkrétnej službe výslovne definovaný.
3. RPO sa teda týka najmä otázky, o akú časť najnovších dát môže Zákazník pri obnove teoreticky prísť.
4. RTO vyjadruje cieľový alebo garantovaný čas potrebný na obnovenie dát alebo služby do definovaného stavu po vzniku alebo riadnom nahlásení príslušnej udalosti, ak je takýto parameter pri konkrétnej službe výslovne definovaný.
5. RTO sa teda týka najmä otázky, ako dlho môže trvať obnovenie služby alebo dát v rozsahu určenom podmienkami konkrétnej služby.
6. RPO a RTO sú rozdielne a navzájom nezávislé parametre.
7. Nízke RPO automaticky neznamená nízke RTO.
8. Nízke RTO automaticky neznamená nízke RPO.
9. Služba môže mať napríklad:
   • časté body obnovy, ale časovo náročnú obnovu,
   • alebo menej časté body obnovy, ale relatívne rýchly proces obnovy.
10. Ak pri konkrétnej službe nie je výslovne uvedené inak, WebHouse negarantuje konkrétnu hodnotu:

• RPO,
• RTO.

11. Samotná existencia zálohovania neznamená, že služba obsahuje garantované RPO alebo RTO.
12. Garantované RPO alebo RTO vzniká iba vtedy, ak je príslušná hodnota výslovne uvedená najmä:

• v parametroch konkrétnej služby,
• v SLA,
• v objednávke,
• v individuálnej zmluve,
• alebo v inom záväznom dokumente vzťahujúcom sa na danú službu.

13. Všeobecná informácia o frekvencii zálohovania sama osebe nepredstavuje garanciu RPO.
14. Ak je napríklad pri službe uvedené, že záloha sa štandardne vytvára raz denne, neznamená to automaticky garantované RPO 24 hodín.
15. Dôvodom je najmä to, že frekvencia zálohovania opisuje harmonogram alebo štandardný cyklus vytvárania záloh, zatiaľ čo garantované RPO predstavuje samostatný zmluvný záväzok týkajúci sa maximálneho časového odstupu obnoviteľného stavu.
16. Pri dennom zálohovaní môže byť praktický odstup medzi posledným použiteľným bodom obnovy a incidentom podľa okolností dlhší než 24 hodín.
17. Môže sa tak stať napríklad vtedy, ak:

• posledný zálohovací cyklus zlyhal,
• posledná záloha je poškodená,
• posledný bod nie je technicky použiteľný,
• posledný bod už obsahuje poškodené alebo kompromitované dáta,
• alebo je potrebné použiť starší funkčný bod obnovy.

18. Ak nie je RPO výslovne garantované, samotná frekvencia zálohovania preto nevytvára nárok na obnoviteľný bod mladší než určitý maximálny počet hodín.
19. Rovnako označenia ako:

• denné zálohovanie,
• hodinové zálohovanie,
• zálohovanie každých šesť hodín,

opisujú frekvenciu alebo plán zálohovania, pokiaľ nie je výslovne uvedené, že ide zároveň o garantované RPO.

20. Ak je pri konkrétnej službe RPO výslovne garantované, WebHouse je povinný poskytovať službu v súlade s touto garanciou.
21. V takom prípade nemožno všeobecné ustanovenia o možnom zlyhaní jednotlivého bodu obnovy použiť na obchádzanie dohodnutého RPO.
22. Podmienky garantovaného RPO môžu bližšie určovať:

• rozsah chránených dát,
• technológiu,
• typ incidentov,
• spôsob merania,
• podmienky funkčnosti systému,
• požadovanú súčinnosť Zákazníka,
• alebo výluky podľa príslušného SLA.

23. Ak Zákazník vlastným zásahom znemožní vytváranie záloh, môže to ovplyvniť uplatnenie RPO v rozsahu vyplývajúcom z podmienok služby.
24. Môže ísť napríklad o:

• vypnutie potrebného zálohovacieho agenta,
• zmenu oprávnení,
• zablokovanie komunikácie firewallom,
• odstránenie zálohovanej služby,
• alebo inú zmenu v zákazníkom spravovanej vrstve.

25. Takáto výluka však musí zodpovedať skutočnej príčine a nemožno ju použiť na zbavenie WebHouse zodpovednosti za zlyhanie v jeho vlastnej spravovanej vrstve.
26. RPO sa vzťahuje iba na dáta a komponenty, ktoré sú zahrnuté do konkrétnej služby s daným RPO.
27. RPO jednej služby sa automaticky nevzťahuje na:

• externé databázy,
• externé úložiská,
• lokálne dáta Zákazníka,
• služby tretích strán,
• alebo iné komponenty mimo dohodnutého rozsahu.

28. Ak aplikácia využíva viacero komponentov s rozdielnymi mechanizmami zálohovania, môžu mať jednotlivé komponenty rozdielne RPO.
29. Napríklad webové súbory, databáza a externé objektové úložisko nemusia mať rovnakú časovú granularitu zálohovania.
30. Garantované RPO pre jeden komponent automaticky neznamená transakčne konzistentné RPO celej aplikácie.
31. Ak Zákazník potrebuje jednotný alebo aplikačne konzistentný bod obnovy naprieč viacerými komponentmi, musí byť takáto vlastnosť výslovne súčasťou služby.
32. RPO zároveň neznamená, že WebHouse uchováva samostatnú verziu dát z každého okamihu v rámci príslušného obdobia.
33. Napríklad RPO 4 hodiny by neznamenalo možnosť vybrať ľubovoľný historický stav s presnosťou na minútu.
34. Konkrétne body obnovy môžu byť vytvárané v časoch vyplývajúcich zo zálohovacej technológie.
35. RPO sa týka maximálneho prípustného časového odstupu podľa podmienok služby, nie ľubovoľnej historickej granularizácie dát.
36. RPO sa nesmie zamieňať s retenčnou dobou.
37. Retenčná doba určuje, ako dlho sa príslušné body obnovy uchovávajú.
38. RPO sa týka aktuálnosti obnoviteľného bodu vo vzťahu k incidentu.
39. Služba môže mať napríklad dlhú retenciu, ale relatívne vysoké RPO.
40. Rovnako môže mať nízke RPO, ale krátku retenciu.
41. RPO sa nesmie zamieňať ani s frekvenciou snapshotov, replikáciou alebo vysokou dostupnosťou.
42. Samotná replikácia môže kopírovať aktuálne zmeny veľmi rýchlo, ale nemusí umožňovať návrat do historického stavu.
43. Replikácia preto sama osebe nevytvára garantované RPO pre obnovu zo zálohy, pokiaľ takýto parameter nie je súčasťou konkrétneho riešenia.
44. RTO sa týka času obnovy, nie veku dostupnej zálohy.
45. Samotná existencia použiteľnej zálohy neznamená garantované RTO.
46. Záloha môže byť dostupná, ale jej obnova môže vyžadovať:

• načítanie veľkého objemu dát,
• dekompresiu,
• dešifrovanie,
• rekonštrukciu inkrementálneho reťazca,
• import databázy,
• vytvorenie novej virtuálnej inštancie,
• alebo iný časovo náročný technický proces.

47. Frekvencia záloh preto neurčuje dobu potrebnú na obnovu.
48. Rovnako veľký počet bodov obnovy automaticky neznamená rýchlejšiu obnovu.
49. Ak pri konkrétnej službe nie je RTO výslovne garantované, WebHouse vykonáva obnovu v primeranom čase podľa článku XXVIII.
50. Takáto služba nemá automaticky zmluvný záväzok obnovy napríklad:

• do jednej hodiny,
• do štyroch hodín,
• do jedného pracovného dňa,
• ani v inej pevnej lehote,

pokiaľ táto lehota nebola výslovne dohodnutá.

51. Skutočnosť, že WebHouse v minulosti obdobnú obnovu vykonal v určitom čase, nevytvára garantované RTO pre budúce incidenty.
52. Rovnako orientačný odhad technickej podpory o predpokladanom trvaní obnovy nepredstavuje garantované RTO, pokiaľ nebol výslovne označený ako zmluvne záväzný parameter.
53. Ak je pri konkrétnej službe RTO garantované, musí byť zároveň určené alebo zo zmluvných podmienok určiteľné, čo sa považuje za začiatok jeho plynutia.
54. Začiatok RTO môže byť podľa konkrétnej služby viazaný napríklad na:

• riadne nahlásenie incidentu,
• potvrdenie, že je obnova potrebná,
• identifikovanie požadovaného bodu obnovy,
• poskytnutie nevyhnutnej súčinnosti,
• alebo iný výslovne stanovený okamih.

55. Ak má byť RTO garantované, podmienky služby by mali zároveň určiť, čo sa považuje za jeho splnenie.
56. Môže ísť napríklad o:

• obnovenie súborov,
• obnovenie databázy,
• sprístupnenie obnovenej VM,
• technické spustenie služby,
• alebo úplný návrat definovaného systému do dohodnutého prevádzkového stavu.

57. Tieto okamihy nemusia byť totožné.
58. Napríklad technické spustenie obnoveného VPS nemusí znamenať, že všetky aplikácie Zákazníka sú už aplikačne funkčné.
59. RTO preto musí byť vykladané podľa rozsahu, ktorý je pri konkrétnej službe výslovne garantovaný.
60. Ak je garantovaná iba obnova virtuálneho disku, RTO automaticky nezahŕňa:

• opravu aplikácie,
• rekonfiguráciu externých služieb,
• odstránenie zraniteľnosti,
• alebo iné úlohy mimo dohodnutého rozsahu.

61. Ak má garantované RTO zahŕňať aj úplné aplikačné obnovenie, musí byť táto vlastnosť výslovne súčasťou služby.
62. Čas, počas ktorého WebHouse objektívne nemôže pokračovať pre chýbajúcu nevyhnutnú súčinnosť Zákazníka, môže byť pri výpočte RTO zohľadnený, ak to ustanovujú podmienky príslušnej služby.
63. Môže ísť napríklad o čakanie na:

• potvrdenie deštruktívnej obnovy,
• voľbu medzi viacerými bodmi obnovy,
• poskytnutie šifrovacieho kľúča,
• alebo odstránenie zákazníkom spravovanej prekážky.

64. WebHouse však nemôže umelo predlžovať alebo prerušovať RTO požadovaním súčinnosti, ktorá nie je na vykonanie obnovy objektívne potrebná.
65. Ak je garantované RTO, technické zaťaženie alebo interná organizácia WebHouse sa posudzujú podľa výluk a podmienok príslušného SLA.
66. Všeobecné ustanovenie, že obnova veľkého objemu dát môže trvať dlhšie, samo osebe neodstraňuje výslovne prevzatý záväzok RTO.
67. Ak je pri službe RTO garantované, WebHouse musí svoju technickú architektúru a procesy primerane nastaviť tak, aby bolo možné tento parameter za dohodnutých podmienok plniť.
68. Garantované RTO sa nemusí automaticky vzťahovať na situáciu, keď Zákazník požaduje nadštandardnú alebo inú obnovu, než je definovaná v príslušnej službe.
69. Napríklad RTO na obnovu celého VPS nemusí byť zároveň RTO na:

• vyhľadanie jedného súboru v desiatkach historických bodov,
• forenznú analýzu,
• odstránenie malvéru,
• alebo manuálne zlúčenie databáz.

70. RPO ani RTO automaticky nepredstavujú garanciu nulovej straty dát alebo nulového výpadku.
71. Nulová strata dát by zodpovedala osobitne navrhnutému cieľu RPO blízkemu nule alebo nule, ak je technicky a zmluvne garantovaný.
72. Okamžitá kontinuita služby môže vyžadovať mechanizmy odlišné od bežného zálohovania.
73. Môže ísť najmä o:

• vysokú dostupnosť,
• clustering,
• synchronnú alebo asynchrónnu replikáciu,
• hot standby,
• geograficky oddelenú infraštruktúru,
• disaster recovery riešenie.

74. Bežná zálohovacia služba nemusí tieto mechanizmy obsahovať.
75. Služba s veľmi nízkym RPO a RTO môže vyžadovať výrazne odlišnú technickú architektúru než štandardný hosting alebo bežný backup.
76. Zákazník je povinný posúdiť, akú úroveň straty dát a času obnovy je schopný vzhľadom na charakter svojej prevádzky akceptovať.
77. Pri tomto posúdení by mal zohľadniť najmä:

• hodnotu dát,
• frekvenciu ich zmien,
• finančné následky výpadku,
• právne alebo regulačné požiadavky,
• závislosť svojej prevádzky od služby.

78. Ak Zákazník potrebuje konkrétne maximálne prípustné množstvo stratených dát, mal by požadovať službu s výslovne definovaným RPO.
79. Ak Zákazník potrebuje návrat služby do konkrétneho maximálneho času, mal by požadovať službu s výslovne definovaným RTO.
80. Ak štandardná služba takéto parametre neobsahuje, Zákazník nesmie predpokladať ich existenciu iba na základe všeobecného opisu zálohovania.
81. WebHouse môže podľa možností ponúknuť individuálne riešenie s definovaným:

• RPO,
• RTO,
• retenčnou politikou,
• prioritou obnovy,
• alebo ďalšími parametrami kontinuity.

82. Takéto parametre sú záväzné iba v rozsahu výslovne dohodnutom medzi WebHouse a Zákazníkom.
83. RPO a RTO sa môžu pri jednej službe líšiť podľa typu incidentu alebo obnovovaného komponentu, ak to výslovne vyplýva z podmienok služby.
84. Napríklad iné RTO môže byť určené pre:

• obnovu jednotlivého súboru,
• obnovu databázy,
• obnovu celej VM,
• disaster recovery celej služby.

85. Ak sú pri službe uvedené viaceré úrovne RPO alebo RTO, použije sa parameter prislúchajúci konkrétnemu rozsahu obnovy.
86. RPO alebo RTO jednej služby sa automaticky neprenáša na inú službu Zákazníka.
87. Ak má Zákazník viacero produktov, každý z nich sa posudzuje podľa vlastných parametrov.
88. RPO a RTO sa nesmú zamieňať s reakčným časom technickej podpory.
89. Reakčný čas vyjadruje čas do začatia alebo prijatia riešenia požiadavky podľa podmienok podpory.
90. Dodržanie reakčného času neznamená automaticky dokončenie obnovy v rovnakom čase.
91. Napríklad reakcia technickej podpory do 30 minút neznamená RTO 30 minút.
92. Rovnako RTO neznamená, že technická podpora musí na každú požiadavku reagovať v čase rovnajúcom sa RTO, ak reakčný čas upravuje samostatný parameter.
93. RPO a RTO sa nesmú zamieňať ani so SLA dostupnosti.
94. Garancia dostupnosti servera alebo siete napríklad 99,9 % sama osebe neurčuje:

• vek poslednej použiteľnej zálohy,
• ani čas potrebný na obnovu historických dát.

95. SLA dostupnosti, RPO, RTO a reakčný čas technickej podpory predstavujú samostatné parametre.
96. Každý z nich sa uplatňuje iba v rozsahu, v akom bol pri konkrétnej službe dohodnutý.
97. Ak je služba počas incidentu stále technicky dostupná, ale Zákazník požaduje obnovu historických dát po vlastnom vymazaní, nemusí ísť o výpadok podľa SLA dostupnosti.
98. Naopak úplný výpadok služby nemusí automaticky znamenať potrebu obnovy zo zálohy.
99. Posudzovanie dostupnosti a posudzovanie obnovy sú preto oddelené.
100. Ak WebHouse poskytne pri štandardnej službe informáciu o typickom, bežnom alebo očakávanom čase obnovy, ide o orientačný údaj, pokiaľ nie je výslovne označený ako garantované RTO.
101. Obdobne orientačná informácia o obvyklej maximálnej strate dát nepredstavuje garantované RPO, pokiaľ nie je takto výslovne dohodnutá.
102. Marketingová alebo informačná komunikácia by mala byť vykladaná v súlade so záväznými parametrami služby a nesmie vytvárať zavádzajúci dojem o garantovanom RPO alebo RTO.
103. Ak WebHouse určitý údaj výslovne prezentuje ako garanciu alebo záväznú vlastnosť služby, nemožno ho následne považovať iba za nezáväznú orientačnú informáciu.
104. Pri posudzovaní existencie garantovaného RPO alebo RTO je preto rozhodujúci obsah konkrétneho zmluvného záväzku a spôsob, akým bol parameter Zákazníkovi prezentovaný.
105. Ak WebHouse pri konkrétnej službe výslovne garantuje RPO alebo RTO, musí byť všeobecná úprava týchto Pravidiel vykladaná v súlade s touto osobitnou garanciou.
106. Osobitne dohodnuté parametre majú v príslušnom rozsahu prednosť pred všeobecným ustanovením, že RPO alebo RTO nie je garantované.
107. Ak pri službe nie je žiadne RPO ani RTO výslovne dohodnuté, uplatnia sa všeobecné pravidlá:

• frekvencie zálohovania,
• retencie,
• integrity záloh,
• výberu bodu obnovy,
• a primeraného času obnovy

podľa ostatných článkov týchto Pravidiel.

108. WebHouse je aj bez garantovaného RPO alebo RTO povinný riadne poskytovať zálohovaciu službu v rozsahu jej dohodnutých parametrov.
109. Neexistenciu garantovaného RPO nemožno vykladať ako oprávnenie WebHouse svojvoľne alebo systematicky nevytvárať zálohy v dohodnutej frekvencii.
110. Neexistenciu garantovaného RTO nemožno vykladať ako oprávnenie WebHouse bezdôvodne odkladať obnovu.
111. Zálohovanie sa aj v takom prípade vykonáva podľa dohodnutých parametrov a obnova v primeranom čase podľa článku XXVIII.
112. Povinnosť Zákazníka zvoliť si službu s parametrami primeranými jeho potrebám nezbavuje WebHouse zodpovednosti za splnenie parametrov služby, ktoré skutočne poskytuje alebo garantuje.
113. Ak konkrétnu hodnotu RPO alebo RTO nemožno zo zmluvných dokumentov jednoznačne určiť, nemožno ju automaticky odvodiť iba z frekvencie zálohovania, retenčnej doby alebo dostupnosti záloh.
114. Žiadne ustanovenie tohto článku nemožno vykladať ako vylúčenie alebo obmedzenie práv Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 30

Priorita obnovy pri rozsiahlej havárii

1. Pri incidente, ktorý ovplyvňuje väčší počet služieb, systémov, zákazníkov alebo významnú časť infraštruktúry WebHouse, môže WebHouse vykonávať obnovu podľa technických, bezpečnostných a prevádzkových priorít.
2. Rozsiahlym incidentom sa na účely tohto článku rozumie najmä udalosť, ktorá:
   • zasiahne viacero serverov,
   • zasiahne viacero zákazníckych služieb,
   • ovplyvní spoločné úložisko,
   • ovplyvní virtualizačnú platformu,
   • ovplyvní sieťovú infraštruktúru,
   • ovplyvní spoločné databázové alebo e-mailové systémy,
   • vyžaduje obnovu väčšieho počtu služieb zo záloh,
   • alebo si vyžaduje koordinovaný zásah vo viacerých technických vrstvách.
3. Pri takomto incidente nemusí byť technicky ani prevádzkovo možné obnovovať jednotlivé služby výlučne podľa poradia, v akom zákazníci incident nahlásili.
4. WebHouse môže určiť poradie jednotlivých obnovovacích krokov podľa toho, aký postup najefektívnejšie a najbezpečnejšie vedie k obnoveniu čo najväčšej časti dotknutej infraštruktúry.
5. Priorita obnovy môže byť určená najmä podľa:
   • rozsahu incidentu,
   • technických závislostí medzi systémami,
   • potreby obnoviť základnú infraštruktúru,
   • počtu dotknutých zákazníkov,
   • počtu dotknutých služieb,
   • bezpečnosti infraštruktúry,
   • integrity dát,
   • rizika ďalšieho poškodenia,
   • dostupnosti záloh,
   • technickej obnoviteľnosti jednotlivých systémov,
   • individuálne dohodnutých SLA alebo priorít.
6. WebHouse môže pri rozsiahlej havárii najskôr obnoviť spoločnú alebo základnú infraštruktúru, od ktorej závisí fungovanie ďalších služieb.
7. Môže ísť najmä o:
   • napájaciu alebo technickú infraštruktúru dátového centra,
   • sieťovú infraštruktúru,
   • routing,
   • storage,
   • virtualizačné clustre,
   • spoločné databázové platformy,
   • DNS infraštruktúru,
   • autentifikačné systémy,
   • zálohovaciu infraštruktúru,
   • alebo iné spoločné technické komponenty.
8. Obnova individuálnej zákazníckej služby nemusí byť technicky možná skôr, než budú obnovené systémy, od ktorých táto služba závisí.
9. Ak napríklad virtuálne servery závisia od spoločného storage alebo virtualizačného clusteru, môže byť potrebné najskôr obnoviť tento cluster alebo storage a až následne jednotlivé VPS.
10. Takýto postup sa nepovažuje za neoprávnené odkladanie individuálnej obnovy Zákazníka.
11. WebHouse môže uprednostniť obnovu komponentu, ktorého obnovenie umožní súčasne sprevádzkovať väčší počet ďalších služieb.
12. Takýmto postupom môže byť napríklad obnovenie:

• spoločného storage,
• databázovej platformy,
• mailového clusteru,
• DNS infraštruktúry,
• alebo iného centrálneho systému.

13. Priorita preto nemusí byť určovaná podľa obchodnej hodnoty jednotlivého zákazníckeho účtu.
14. Zákazník nemá automaticky nárok na prednostné individuálne obnovenie iba preto, že svoju službu považuje za:

• kritickú,
• finančne významnú,
• obchodne nenahraditeľnú,
• alebo nevyhnutnú pre svoju prevádzku.

15. Takáto individuálna priorita vzniká iba vtedy, ak je výslovne súčasťou:

• konkrétnej objednanej služby,
• SLA,
• disaster recovery riešenia,
• individuálnej dohody,
• alebo iného zmluvne dohodnutého režimu.

16. Samotná informácia WebHouse o tom, že určitá služba má pre Zákazníka vysoký obchodný význam, automaticky nezakladá povinnosť obnoviť ju pred ostatnými službami.
17. Rovnako výška obratu Zákazníka, počet jeho používateľov alebo jeho ekonomický význam automaticky nemenia poradie obnovy, pokiaľ nie je dohodnuté inak.
18. WebHouse môže pri určovaní priorít prihliadať na dohodnuté triedy služieb alebo SLA.
19. Ak má konkrétna služba výslovne dohodnutú vyššiu prioritu obnovy, WebHouse je povinný túto prioritu rešpektovať v rozsahu príslušnej dohody.
20. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie osobitne dohodnutej priority alebo garantovaného RTO.
21. Pri rozsiahlej havárii môže WebHouse rozdeliť obnovu do viacerých fáz.
22. Jednotlivé fázy môžu zahŕňať najmä:

• stabilizáciu infraštruktúry,
• zastavenie ďalšieho poškodzovania,
• obnovu spoločných technických systémov,
• obnovenie kritických technických závislostí,
• hromadnú obnovu zákazníckych služieb,
• následnú individuálnu obnovu zostávajúcich služieb.

23. Prvým cieľom môže byť zabezpečenie stability a bezpečnosti infraštruktúry, nie okamžitý návrat všetkých zákazníckych služieb do plnej prevádzky.
24. Ak incident stále aktívne spôsobuje poškodenie, WebHouse môže pred samotnou obnovou vykonať kroky na jeho zastavenie.
25. Môže ísť najmä o:

• odpojenie poškodeného storage,
• izoláciu kompromitovaných systémov,
• zastavenie časti siete,
• vypnutie dotknutých serverov,
• zablokovanie škodlivej komunikácie,
• alebo inú bezpečnostnú izoláciu.

26. Takýto zásah môže dočasne predĺžiť nedostupnosť niektorých služieb, ak je potrebný na zabránenie väčšej strate dát alebo ďalšiemu poškodeniu.
27. Bezpečnosť a integrita dát môžu mať pri určovaní priorít prednosť pred okamžitým spustením služby.
28. WebHouse nie je povinný uviesť do produkcie systém, o ktorom má dôvodné podozrenie, že:

• je poškodený,
• je kompromitovaný,
• šíri malware,
• spôsobuje útoky,
• alebo môže poškodiť ďalšie dáta.

29. Takýto systém môže byť obnovený najskôr do izolovaného alebo dočasného prostredia.
30. Pri rozsiahlej bezpečnostnej udalosti môže byť potrebné najskôr zabezpečiť, že samotná obnovovaná infraštruktúra už nie je predmetom aktívneho útoku.
31. Obnova systému do stále kompromitovaného prostredia môže viesť k jeho opätovnému poškodeniu.
32. WebHouse preto môže pred hromadnou obnovou vykonať aj bezpečnostné opatrenia, ktoré nie sú samotným restore procesom.
33. Pri určovaní priority môže WebHouse prihliadať aj na dostupnosť konkrétnych záloh.
34. Niektoré služby môžu mať:

• okamžite dostupný bod obnovy,
• zálohu vyžadujúcu dlhšiu prípravu,
• poškodený posledný bod obnovy,
• alebo potrebu použiť starší bod.

35. WebHouse môže paralelne obnovovať služby, ktorých technické procesy sa navzájom neblokujú.
36. Nie je však povinný vykonávať všetky obnovy súčasne, ak by tým:

• došlo k preťaženiu storage,
• došlo k preťaženiu siete,
• výrazne klesla rýchlosť všetkých obnov,
• alebo bola ohrozená stabilita infraštruktúry.

37. WebHouse môže obmedziť počet súčasných restore operácií tak, aby dosiahol technicky primeraný celkový výsledok.
38. Maximálna rýchlosť obnovy jednej služby nemusí byť optimálnym riešením pre obnovu celej infraštruktúry.
39. WebHouse preto môže technické zdroje prideľovať medzi viacero obnovovacích procesov.
40. Zákazník nemá automatický nárok na pridelenie všetkej dostupnej:

• diskovej priepustnosti,
• sieťovej kapacity,
• výpočtovej kapacity,
• alebo administrátorskej kapacity

výlučne svojej službe.

41. Pri rozsiahlej havárii môže byť efektívnejšie obnovovať služby po skupinách.
42. WebHouse môže napríklad obnovovať:

• jednotlivé fyzické uzly,
• storage pooly,
• celé skupiny VPS,
• skupiny hostingových účtov,
• alebo iné technické celky.

43. Poradie jednotlivých Zákazníkov v rámci takéhoto technického celku nemusí byť možné individuálne meniť.
44. Zákazník nemá automatický nárok na manuálne vyňatie svojej služby z hromadného obnovovacieho procesu, ak by takýto zásah:

• komplikoval obnovu,
• zvýšil riziko,
• alebo neprimerane predĺžil obnovu ostatných služieb.

45. Ak však existuje osobitne dohodnutá individuálna priorita, WebHouse ju zohľadní podľa jej podmienok.
46. Pri rozsiahlej havárii môže byť potrebné obnoviť najskôr služby nevyhnutné na správu ostatných systémov.
47. Môže ísť napríklad o:

• interné autentifikačné systémy,
• monitoring,
• provisioning,
• DNS,
• sieťové riadenie,
• zálohovacie systémy.

48. Takáto interná technická priorita neznamená neoprávnené zvýhodňovanie WebHouse pred Zákazníkmi.
49. Jej účelom môže byť umožniť efektívnejšie obnovenie zákazníckych služieb.
50. WebHouse môže pri určovaní priorít zohľadniť aj to, či služba už čiastočne funguje.
51. Služba, ktorá je úplne nedostupná, môže byť podľa okolností prioritizovaná pred službou, ktorá má iba čiastočné obmedzenie.
52. Takéto pravidlo však nie je absolútne a technické závislosti môžu vyžadovať iné poradie.
53. WebHouse môže prihliadať aj na rozsah potenciálnej straty dát.
54. Ak odklad konkrétneho zásahu môže viesť k nenávratnému poškodeniu alebo strate ďalších dát, môže mať tento zásah vyššiu prioritu než obnova systému, ktorého dáta sú bezpečne zachované.
55. Prioritou môže byť napríklad:

• zastavenie prebiehajúcej korupcie dát,
• zachovanie dostupného posledného čistého bodu obnovy,
• stabilizácia poškodeného storage,
• alebo iný zásah chrániaci existujúce dáta.

56. WebHouse môže dočasne uprednostniť ochranný zásah pred obnovou už nedostupnej služby, ak tým zabráni väčšej škode.
57. Pri rozsiahlej havárii môže byť potrebné vykonať aj presun služieb na náhradnú infraštruktúru.
58. Migrácia na náhradné prostredie môže vyžadovať:

• pridelenie nových technických zdrojov,
• obnovu konfigurácií,
• presun záloh,
• zmenu sieťových nastavení,
• alebo ďalšie technické kroky.

59. WebHouse môže určiť, ktoré služby sa obnovia na pôvodnú infraštruktúru a ktoré na náhradnú infraštruktúru.
60. Zákazník nemá automatický nárok na zachovanie identického fyzického servera, storage zariadenia alebo interného technického umiestnenia, pokiaľ to nie je podstatnou vlastnosťou objednanej služby.
61. Obnovená služba môže byť technicky prevádzkovaná na inom kompatibilnom zariadení alebo systéme.
62. Pri disaster recovery udalosti môže byť cieľom najprv obnoviť základnú funkčnosť služby a až následne menej kritické doplnkové vlastnosti.
63. Ak to technická architektúra umožňuje, môže byť služba obnovená postupne.
64. Môže ísť napríklad o:

• najskôr sprístupnenie základných dát,
• následné obnovenie pomocných funkcií,
• následnú optimalizáciu alebo rekonfiguráciu.

65. Čiastočné obnovenie služby nemusí znamenať ukončenie všetkých obnovovacích prác.
66. WebHouse môže pokračovať v technických zásahoch aj po tom, ako je služba základným spôsobom dostupná.
67. Ak existujú závislosti na tretej strane, môže byť úplné obnovenie služby závislé aj od tejto tretej strany.
68. Môže ísť napríklad o:

• telekomunikačného operátora,
• externé dátové centrum,
• dodávateľa hardvéru,
• licenčný systém,
• alebo inú externú službu.

69. WebHouse môže vykonať svoje obnovovacie kroky, ale nemusí byť schopný urýchliť úkon, ktorý je pod kontrolou nezávislej tretej strany.
70. Ak je pri konkrétnej službe závislosť od externého poskytovateľa súčasťou technickej architektúry, zohľadňuje sa pri hodnotení priebehu obnovy.
71. Pri serverhousingu môže byť obnova závislá od súčinnosti Zákazníka.
72. Ak je poškodený vlastný server Zákazníka, môže byť potrebné, aby Zákazník:

• dodal náhradný server,
• zabezpečil náhradný disk,
• poskytol šifrovací kľúč,
• alebo vykonal inú činnosť vo svojej kompetencii.

73. WebHouse nie je povinný odkladať obnovu ostatných zákazníkov preto, že jeden Zákazník neposkytol potrebnú súčinnosť.
74. Takáto služba môže byť dočasne presunutá na neskoršiu fázu obnovy.
75. Ak Zákazník poskytne chýbajúcu súčinnosť neskôr, WebHouse pokračuje podľa aktuálnych technických možností a priorít.
76. Pri nespravovaných službách môže byť po obnove infraštruktúrnej vrstvy ďalšia obnova aplikácie v kompetencii Zákazníka.
77. WebHouse nemusí pri určovaní priorít zohľadňovať čas potrebný Zákazníkovi na:

• opravu aplikácie,
• aktualizáciu CMS,
• import vlastných dát,
• alebo inú zákazníkom spravovanú činnosť.

78. Ak je napríklad VPS technicky obnovený a dostupný, ďalší čas potrebný na opravu zákazníckej aplikácie nemusí byť súčasťou infraštruktúrnej obnovy WebHouse.
79. Rozdelenie zodpovednosti sa riadi charakterom konkrétnej služby.
80. WebHouse môže pri rozsiahlej havárii priebežne meniť poradie jednotlivých technických krokov, ak nové informácie ukážu, že iný postup je bezpečnejší alebo efektívnejší.
81. Priorita určená na začiatku incidentu preto nemusí zostať nezmenená počas celého riešenia.
82. Môže sa zmeniť najmä po zistení:

• väčšieho rozsahu poškodenia,
• bezpečnostného rizika,
• nefunkčnosti zálohy,
• novej technickej závislosti,
• alebo efektívnejšieho spôsobu obnovy.

83. Zmena technického plánu sama osebe neznamená, že pôvodný postup bol nesprávny.
84. Posudzuje sa, či WebHouse reagoval primerane na informácie dostupné v danom čase.
85. WebHouse môže vytvoriť interný plán obnovy alebo poradie jednotlivých krokov.
86. Takýto interný plán nemusí byť Zákazníkovi sprístupnený v plnom technickom detaile.
87. WebHouse môže neposkytnúť informácie, ktorých zverejnenie by:

• ohrozilo bezpečnosť infraštruktúry,
• komplikovalo riešenie incidentu,
• alebo zverejnilo citlivé technické informácie.

88. Zákazník môže byť primerane informovaný o stave jeho služby a priebehu riešenia podľa komunikačných možností WebHouse.
89. Pri rozsiahlej udalosti však nemusí byť možné poskytovať každému Zákazníkovi individuálne a nepretržité aktualizácie.
90. WebHouse môže informácie poskytovať prostredníctvom:

• status stránky,
• zákazníckeho rozhrania,
• hromadného oznámenia,
• e-mailu,
• alebo iného vhodného komunikačného kanála.

91. Všeobecná informácia o stave hromadného incidentu môže nahrádzať opakované individuálne odpovede, ak poskytuje relevantné informácie.
92. Zníženie objemu individuálnej komunikácie môže byť počas rozsiahlej havárie odôvodnené potrebou sústrediť technické kapacity na samotnú obnovu.
93. WebHouse však nesmie zákazníkom úmyselne poskytovať nepravdivé alebo zavádzajúce informácie o stave obnovy.
94. Odhadovaný čas obnovy poskytnutý počas rozsiahleho incidentu môže byť iba orientačný.
95. Takýto odhad môže byť priebežne upravený podľa:

• novozisteného rozsahu poškodenia,
• výkonu obnovovacích procesov,
• dostupnosti záloh,
• alebo ďalších okolností.

96. Orientačný odhad nepredstavuje garantované RTO, pokiaľ nebol výslovne dohodnutý ako záväzný parameter.
97. Ak konkrétna služba garantované RTO má, uplatní sa príslušné SLA bez ohľadu na všeobecnú orientačnú komunikáciu.
98. WebHouse môže pri rozsiahlej havárii dočasne presunúť administrátorské kapacity z bežných, menej naliehavých úloh na riešenie incidentu.
99. Môže ísť napríklad o odklad:

• bežných migračných požiadaviek,
• nepodstatných konfiguračných zmien,
• neurgentných individuálnych administrátorských zásahov.

100. Takéto prevádzkové rozhodnutie môže byť primerané, ak je nevyhnutné na riešenie závažnej havárie.
101. Tým nie sú dotknuté osobitné zmluvné záväzky, ktoré majú vlastné garantované termíny alebo priority.
102. WebHouse nie je povinný prijímať pokyny jednotlivých Zákazníkov na zmenu celkového poradia obnovy, ak by ich vykonanie bolo v rozpore s technickým plánom riešenia incidentu.
103. Zákazník môže WebHouse oznámiť osobitnú okolnosť, ktorá môže byť relevantná pre prioritu obnovy.
104. WebHouse môže takúto informáciu zohľadniť, ale bez osobitne dohodnutej priority nie je povinný zmeniť technické poradie obnovy.
105. Jednorazové prednostné obnovenie určitej služby z technických alebo prevádzkových dôvodov nevytvára Zákazníkovi nárok na rovnakú prioritu pri budúcich incidentoch.
106. Rovnako jednorazové vyhovenie individuálnej žiadosti nad rámec služby nepredstavuje zmenu zmluvných parametrov.
107. Ak Zákazník potrebuje garantovanú individuálnu prioritu obnovy, musí byť táto priorita výslovne dohodnutá.
108. Takáto dohoda môže zahŕňať napríklad:

• špecifickú triedu priority,
• rezervovanú obnovovaciu kapacitu,
• garantované RTO,
• osobitné disaster recovery prostredie,
• alebo iný konkrétny mechanizmus.

109. Samotné označenie služby ako „kritická“ zo strany Zákazníka nie je takouto dohodou.
110. WebHouse môže pri službách s rozdielnou úrovňou SLA alebo disaster recovery poskytovať rozdielnu prioritu obnovy.
111. Takéto rozdielne zaobchádzanie nie je porušením princípu rovnakého poskytovania služby, ak vyplýva z rozdielne objednaných parametrov.
112. Pri určovaní poradia obnovy bez osobitných priorít by WebHouse mal postupovať podľa objektívnych technických a prevádzkových dôvodov.
113. Priorita by nemala byť svojvoľne menená podľa neformálneho tlaku jednotlivého Zákazníka spôsobom, ktorý by neprimerane poškodil ostatných zákazníkov.
114. WebHouse môže uprednostniť postup, ktorý minimalizuje:

• celkový čas obnovy,
• celkový rozsah straty dát,
• bezpečnostné riziko,
• alebo počet nedostupných služieb.

115. Pri rozhodovaní nemusí existovať riešenie, ktoré súčasne minimalizuje všetky uvedené faktory.
116. WebHouse môže zvoliť technicky primeraný kompromis podľa okolností incidentu.
117. Samotná skutočnosť, že určitý Zákazník bol obnovený neskôr než iný Zákazník, automaticky neznamená porušenie povinnosti WebHouse.
118. Rozhodujúce je najmä:

• či existoval technický alebo zmluvný dôvod poradia,
• či bola rešpektovaná individuálne dohodnutá priorita,
• či WebHouse postupoval primerane,
• a či nedošlo k svojvoľnému alebo diskriminačnému postupu.

119. WebHouse nie je povinný garantovať rovnaký čas obnovy všetkým zákazníkom pri rozsiahlej havárii, pokiaľ takáto garancia nevyplýva z konkrétnych služieb.
120. Jednotlivé služby môžu byť obnovené v rozdielnom čase aj z čisto technických dôvodov.
121. Služba s malým objemom dát môže byť napríklad obnovená skôr než služba s niekoľkoterabajtovým objemom dát, aj keď ich obnova začala v podobnom čase.
122. Rozdielny čas dokončenia preto automaticky neznamená rozdielnu prioritu.
123. Pri posudzovaní priority treba rozlišovať medzi:

• poradím začatia obnovy,
• množstvom pridelených technických zdrojov,
• a skutočným časom dokončenia obnovy.

124. Rýchlejšie dokončenie jednej služby nemusí znamenať, že bola úmyselne zvýhodnená.
125. Ak je rozsiahla havária spôsobená poškodením zálohovacej infraštruktúry, môže byť potrebné pred samotnou obnovou zákazníckych dát obnoviť aj zálohovací systém.
126. Takýto postup môže dočasne oddialiť individuálne obnovy, ale môže byť technicky nevyhnutný.
127. Ak existuje viac nezávislých zálohovacích zdrojov, WebHouse môže ich použitie rozdeliť spôsobom, ktorý optimalizuje celkový proces obnovy.
128. WebHouse nie je povinný použiť najrýchlejší technický zdroj pre konkrétneho Zákazníka, ak je jeho použitie potrebnejšie pre inú časť obnovy.
129. Ak je rozsiahla udalosť zároveň bezpečnostným incidentom, WebHouse môže vykonať dodatočné kontroly pred uvedením obnovených systémov do prevádzky.
130. Takéto kontroly môžu zvýšiť čas obnovy, ale môžu byť primerané na ochranu infraštruktúry a dát.
131. WebHouse nie je povinný obetovať bezpečnosť obnovených systémov iba s cieľom dosiahnuť čo najkratší čas ich verejného spustenia.
132. Ak konkrétna služba obsahuje garantovaný RTO, bezpečnostné postupy a prípadné výluky sa posudzujú podľa podmienok tohto RTO.
133. Všeobecné oprávnenie určovať technické priority nemožno použiť na zrušenie alebo obchádzanie individuálne dohodnutého:

• RTO,
• SLA,
• alebo priority obnovy.

134. Ak WebHouse takýto záväzok prijal, musí ho pri plánovaní obnovy zohľadniť.
135. Neexistencia individuálnej priority však neznamená, že WebHouse môže obnovu služby bezdôvodne odkladať.
136. WebHouse je povinný postupovať pri obnove s primeranou odbornou starostlivosťou a v primeranom čase podľa článku XXVIII.
137. Oprávnenie určovať poradie obnovy slúži na efektívne a bezpečné riešenie rozsiahlej havárie, nie na svojvoľné odkladanie jednotlivých služieb.
138. Pri posudzovaní primeranosti postupu sa prihliada najmä na:

• technické okolnosti incidentu,
• rozsah havárie,
• počet dotknutých služieb,
• technické závislosti,
• bezpečnostné riziká,
• dostupnú kapacitu,
• zmluvné priority.

139. Skutočnosť, že WebHouse pri rozsiahlej havárii uprednostnil obnovenie spoločnej infraštruktúry pred individuálnym restore jedného Zákazníka, sama osebe nepredstavuje vadu služby.
140. Ak však WebHouse bez primeraného dôvodu ignoruje výslovne dohodnutú individuálnu prioritu alebo garantované RTO, posudzuje sa takýto prípad podľa príslušných zmluvných podmienok.
141. Povinnosť Zákazníka objednať si vyššiu prioritu, ak ju potrebuje, nezbavuje WebHouse povinnosti riadne a odborne obnovovať aj štandardné služby.
142. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 31

Obnova po chybe Zákazníka

1. Záloha môže byť použitá aj na obnovu dát, ktoré boli odstránené, prepísané, poškodené alebo inak zmenené konaním Zákazníka, jeho používateľa, administrátora, aplikácie alebo iného systému, za ktorý Zákazník zodpovedá.
2. Môže ísť najmä o:
   • omylom odstránený súbor,
   • odstránený adresár,
   • prepísaný súbor,
   • poškodenú databázu,
   • odstránenú databázu,
   • chybný databázový príkaz,
   • chybnú aktualizáciu,
   • chybnú migráciu,
   • nesprávnu konfiguráciu,
   • odstránenú e-mailovú schránku,
   • odstránené e-mailové správy,
   • chybnú zmenu operačného systému,
   • chybnú zmenu aplikácie,
   • chybnú zmenu oprávnení,
   • alebo inú nežiaducu zmenu vykonanú v zákazníkom spravovanej vrstve.
3. Za chybu Zákazníka sa na účely tohto článku môže považovať aj konanie osoby, ktorej Zákazník umožnil alebo poskytol prístup k službe.
4. Môže ísť najmä o:
   • zamestnanca Zákazníka,
   • externého administrátora,
   • vývojára,
   • marketingovú agentúru,
   • správcu webovej stránky,
   • alebo inú poverenú osobu.
5. WebHouse nie je povinný zisťovať interný právny alebo pracovnoprávny vzťah medzi Zákazníkom a osobou, ktorá vykonala zásah prostredníctvom oprávneného alebo platného prístupu Zákazníka.
6. Ak bol zásah vykonaný prostredníctvom účtu alebo prístupu spravovaného Zákazníkom, posudzuje sa zodpovednosť podľa pravidiel rozdelenia zodpovednosti pri konkrétnej službe.
7. Záloha môže byť použitá aj na obnovu po neúmyselnej chybe.
8. Skutočnosť, že Zákazník vykonal chybný zásah neúmyselne, sama osebe nemení technický charakter incidentu.
9. Typickým príkladom môže byť:
   • omyl pri mazaní súborov,
   • nesprávne použitie FTP,
   • nesprávny príkaz v administrácii,
   • SQL príkaz vykonaný nad nesprávnymi dátami,
   • alebo chybná konfigurácia aplikácie.
10. Záloha môže byť použitá aj po chybe automatizovaného systému, ktorý Zákazník používa alebo spravuje.
11. Môže ísť napríklad o:

• chybný cron,
• automatický deployment,
• CI/CD proces,
• migračný skript,
• synchronizačný nástroj,
• automatizovaný import,
• alebo inú zákazníkom spravovanú automatizáciu.

12. Ak takýto systém vykoná nežiaducu zmenu, nie je rozhodujúce, že zásah nevykonal človek priamo.
13. Rozhodujúce je, či príčina vznikla v zákazníkom spravovanej vrstve.
14. Obnova po chybe Zákazníka neznamená, že pôvodný stav predstavoval vadu služby WebHouse.
15. Ak napríklad Zákazník omylom odstráni databázu a WebHouse ju následne obnoví zo zálohy, samotná potreba obnovy neznamená, že databázová služba bola predtým poskytovaná vadne.
16. Rovnako obnova po nesprávnej konfigurácii aplikácie, chybnej aktualizácii alebo chybnej administrátorskej operácii sama osebe nepredstavuje uznanie vady služby WebHouse.
17. Samotné vykonanie obnovy WebHouse nepredstavuje uznanie:

• zodpovednosti za vznik incidentu,
• vady služby,
• porušenia zmluvnej povinnosti,
• ani nároku na náhradu škody.

18. Obnova môže byť vykonaná ako technická pomoc pri incidente, ktorého príčina vznikla mimo zodpovednosti WebHouse.
19. Príčina incidentu a následná technická obnova sa preto posudzujú oddelene.
20. To, že WebHouse technicky dokáže obnoviť zákazníkom poškodené dáta, neznamená, že WebHouse zodpovedal za ich pôvodné poškodenie.
21. Zároveň však platí, že ak k poškodeniu alebo strate dát došlo preukázateľne v dôsledku porušenia povinnosti na strane WebHouse, nejde o obnovu po chybe Zákazníka iba preto, že výsledkom incidentu je rovnaká potreba restore.
22. V takom prípade sa príčina incidentu posudzuje podľa:

• konkrétnej objednanej služby,
• rozdelenia zodpovednosti,
• Reklamačného poriadku,
• a príslušných právnych predpisov.

23. WebHouse nemôže označiť incident za chybu Zákazníka iba na základe toho, že poškodené dáta sa nachádzali v zákazníkom spravovanej aplikácii.
24. Rozhodujúca je skutočná príčina poškodenia.
25. Pri posudzovaní môže byť relevantné najmä:

• kto vykonal zmenu,
• prostredníctvom akého účtu alebo systému bola vykonaná,
• v ktorej technickej vrstve chyba vznikla,
• aké boli zmluvné povinnosti jednotlivých strán.

26. Ak príčinu nie je možné jednoznačne určiť, samotné vykonanie obnovy nepredstavuje automatický záver o zodpovednosti ktorejkoľvek strany.
27. Obnova po chybe Zákazníka je možná iba vtedy, ak existuje vhodný použiteľný bod obnovy.
28. WebHouse negarantuje, že bude možné obnoviť každý omyl alebo každú zákaznícku zmenu.
29. Možnosť obnovy závisí najmä od:

• času vykonania chybnej zmeny,
• frekvencie zálohovania,
• retenčnej doby,
• dostupnosti konkrétnych bodov,
• rozsahu zálohovaných dát,
• a integrity záloh.

30. Ak Zákazník vytvorí a následne odstráni dáta medzi dvoma zálohovacími cyklami, tieto dáta sa nemusia nachádzať v žiadnej zálohe.
31. V takom prípade nemusí byť možné ich obnoviť.
32. Ak Zákazník zistí chybu až po uplynutí dlhšieho času, môže byť bod obnovy spred chybného zásahu už odstránený podľa štandardnej retencie.
33. Zákazník by preto mal stratu alebo poškodenie dát nahlásiť bez zbytočného odkladu.
34. Včasné nahlásenie môže zvýšiť pravdepodobnosť, že vhodný bod obnovy ešte existuje.
35. WebHouse však nie je povinný predlžovať štandardnú retenciu len preto, že Zákazník svoju chybu ešte nezistil.
36. Ak Zákazník vie alebo má dôvod predpokladať, že vykonal chybnú zmenu, mal by podľa možností obmedziť ďalšie zásahy do dotknutých dát.
37. Ďalšie zmeny môžu:

• sťažiť identifikáciu správneho bodu obnovy,
• zvýšiť rozsah dát, ktoré by sa pri restore stratili,
• alebo znížiť možnosť jednoduchého návratu do predchádzajúceho stavu.

38. Zákazník by nemal po zistení chyby bez rozmyslu pokračovať v rozsiahlych zmenách, ak očakáva potrebu obnovy historického stavu.
39. Ak je poškodenie spôsobené chybnou aktualizáciou aplikácie, samotná obnova dát nemusí postačovať.
40. Môže byť potrebné:

• vrátiť staršiu verziu aplikácie,
• opraviť konfiguráciu,
• odstrániť chybný plugin alebo modul,
• alebo vykonať inú nápravu.

41. WebHouse nie je automaticky povinný vykonať takúto aplikačnú opravu, ak ide o zákazníkom spravovanú vrstvu.
42. Ak Zákazník obnoví staršie dáta, ale ponechá rovnakú chybnú konfiguráciu alebo aplikáciu, môže sa problém zopakovať.
43. Obnova zo zálohy preto nemusí odstrániť príčinu chyby.
44. Typickým príkladom je automatizovaný skript, ktorý opakovane maže alebo prepisuje dáta.
45. Ak zostane tento skript aktívny, môže poškodiť aj obnovené dáta.
46. Zákazník zodpovedá za odstránenie príčiny incidentu v rozsahu zákazníkom spravovaných komponentov.
47. WebHouse môže pred obnovou odporučiť alebo požadovať, aby bola príčina chyby najskôr:

• zastavená,
• odstránená,
• alebo primerane obmedzená,

ak by inak hrozilo okamžité opätovné poškodenie obnovených dát.

48. Pri nespravovaných VPS alebo dedikovaných serveroch môže byť potrebné napríklad:

• zastaviť chybný cron,
• vypnúť aplikáciu,
• zastaviť databázový skript,
• alebo upraviť konfiguráciu.

49. WebHouse nie je povinný opakovane obnovovať dáta, ktoré zákazníkom spravovaný systém bezprostredne po každej obnove opätovne poškodí.
50. Opakovaná obnova v takejto situácii môže byť podmienená odstránením príčiny.
51. Ak Zákazník potrebuje obnoviť staršiu verziu dát, použijú sa pravidlá výberu bodu obnovy podľa článku XXV.
52. Zákazník by mal podľa možností určiť:

• čas posledného správneho stavu,
• čas chybnej operácie,
• alebo vhodný dostupný bod obnovy.

53. WebHouse nemusí vedieť, kedy presne Zákazník vykonal chybný zásah.
54. Ak napríklad Zákazník omylom prepísal databázu o 14:00, ale problém zistil až nasledujúci deň, WebHouse nemusí mať informáciu o presnom čase chyby.
55. Výber bodu preto môže vyžadovať súčinnosť Zákazníka.
56. Ak je k dispozícii bod pred chybným zásahom a bod po ňom, Zákazník môže byť požiadaný o výber.
57. Starší bod môže zachovať správny stav, ale zároveň môže znamenať stratu väčšieho množstva neskorších zmien.
58. Ak obnova po chybe Zákazníka vyžaduje prepísanie aktuálnych dát, použije sa článok XXVI.
59. WebHouse môže pred deštruktívnou obnovou požadovať potvrdenie Zákazníka.
60. Zákazník je povinný vziať do úvahy, že návrat do staršieho stavu môže odstrániť aj platné dáta vytvorené po chybnom zásahu.
61. Ak je to technicky možné, môže byť vhodnejšie najskôr obnoviť historické dáta do dočasného priestoru podľa článku XXVII.
62. Takýto postup môže byť vhodný najmä vtedy, ak je potrebné:

• získať iba jeden súbor,
• vybrať iba určité databázové dáta,
• porovnať aktuálny a historický stav,
• alebo minimalizovať stratu novších zmien.

63. Obnova do dočasného priestoru však nemusí byť dostupná pri každej službe.
64. Ak je potrebné manuálne vybrať alebo zlúčiť historické a aktuálne dáta, môže ísť o nadštandardný administrátorský zásah.
65. WebHouse nie je automaticky povinný vykonávať:

• manuálne zlúčenie databáz,
• obsahové porovnávanie verzií,
• selektívne získavanie jednotlivých aplikačných objektov,
• alebo rekonštrukciu zákazníckej logiky.

66. Takýto zásah môže byť spoplatnený podľa rozsahu práce.
67. Obnova po chybe Zákazníka môže byť podľa konkrétnej služby:

• samoobslužná,
• zahrnutá v cene,
• zahrnutá v určitom počte zásahov,
• alebo spoplatnená.

68. Ak potreba obnovy vznikla v dôsledku konania alebo konfigurácie Zákazníka, WebHouse môže za manuálnu obnovu účtovať cenu podľa aktuálneho cenníka.
69. Spoplatnenie môže zahŕňať najmä:

• prácu administrátora,
• vytvorenie dočasného priestoru,
• obnovu viacerých bodov,
• individuálne vyhľadávanie dát,
• manuálny export alebo import.

70. Ak je však obnova potrebná v dôsledku vady alebo porušenia povinnosti na strane WebHouse, spoplatnenie nemožno automaticky odôvodniť týmto článkom.
71. Takáto situácia sa posudzuje podľa Reklamačného poriadku a ostatných zmluvných podmienok.
72. WebHouse môže vykonať jednorazovú obnovu po chybe Zákazníka bezplatne ako goodwill alebo technickú pomoc.
73. Takýto postup nevytvára nárok na bezplatnú obnovu pri budúcich obdobných udalostiach.
74. Jednorazová bezplatná pomoc nemení štandardný cenník ani rozsah služby.
75. Obnova po chybe Zákazníka nie je automaticky reklamáciou.
76. Ak Zákazník napríklad oznámi „omylom som vymazal web, prosím obnovte ho“, ide spravidla o požiadavku na technickú obnovu.
77. Ak však Zákazník zároveň tvrdí, že dáta boli odstránené v dôsledku chyby WebHouse, môže mať jeho podanie zároveň charakter reklamácie podľa svojho obsahu.
78. WebHouse posudzuje podanie podľa jeho obsahu, nie iba podľa názvu alebo zvoleného typu ticketu.
79. Samotné vykonanie restore počas preverovania príčiny neznamená, že WebHouse uznal reklamáciu.
80. WebHouse môže dáta obnoviť čo najskôr s cieľom minimalizovať dopad incidentu a otázku zodpovednosti posúdiť samostatne.
81. Takýto postup môže byť výhodný najmä vtedy, ak by čakanie na úplné určenie príčiny viedlo k ďalšiemu výpadku alebo strate dát.
82. Technická pomoc poskytnutá bez prejudikovania zodpovednosti nemá byť vykladaná ako priznanie pochybenia.
83. Pri chybe Zákazníka môže byť potrebná aj zmena prístupových údajov alebo oprávnení, ak incident vznikol zneužitím zákazníckeho účtu.
84. Ak však existuje podozrenie na neoprávnený prístup tretej osoby, môže ísť zároveň o bezpečnostný incident a použijú sa aj príslušné bezpečnostné ustanovenia týchto Pravidiel.
85. Nie každý zásah vykonaný prostredníctvom zákazníckeho účtu sa automaticky považuje za vedomý úkon Zákazníka.
86. Ak bol účet kompromitovaný, príčina incidentu sa posudzuje podľa pravidiel bezpečnosti a rozdelenia zodpovednosti.
87. WebHouse preto nemá incident automaticky kvalifikovať ako „chybu Zákazníka“ iba na základe toho, že technická operácia bola vykonaná cez zákaznícky účet.
88. Môže byť potrebné posúdiť, či išlo o:

• oprávnený zásah,
• zákaznícku chybu,
• kompromitáciu účtu,
• alebo inú bezpečnostnú udalosť.

89. Pri samoobslužných nástrojoch zodpovedá Zákazník za pokyny, ktoré prostredníctvom nich vedome zadá.
90. Ak napríklad prostredníctvom administrácie:

• odstráni databázu,
• zruší schránku,
• odstráni súbory,
• alebo potvrdí inú deštruktívnu operáciu,

následná potreba obnovy sama osebe nepredstavuje chybu WebHouse.

91. WebHouse je však povinný zabezpečiť, aby jeho samoobslužný systém vykonal potvrdený pokyn technicky správne.
92. Ak systém vykoná iný alebo širší zásah než Zákazník požadoval, nejde automaticky o zákaznícku chybu.
93. Pri posudzovaní je preto potrebné odlišovať:

• nesprávny pokyn Zákazníka,
• od nesprávneho vykonania správneho pokynu systémom WebHouse.

94. Zákazník by mal pred významnými vlastnými zásahmi vytvoriť aktuálnu manuálnu alebo nezávislú zálohu, ak to charakter zásahu a služby umožňuje.
95. Ide najmä o:

• upgrade systému,
• migráciu,
• hromadné SQL operácie,
• zmenu databázovej schémy,
• zmenu diskového usporiadania,
• rozsiahlu úpravu súborov.

96. Zákazník nesmie predpokladať, že automatická záloha bola vytvorená bezprostredne pred jeho zásahom.
97. Ak manuálna záloha nebola vytvorená, možnosť obnovy bude závisieť od štandardných dostupných bodov.
98. Pri kritických systémoch je vhodné používať aj mechanizmy umožňujúce rýchly návrat pred plánovanou zmenou, ak sú technicky vhodné.
99. Takýmto mechanizmom môže byť napríklad:

• manuálna záloha,
• databázový export,
• alebo snapshot,

pričom snapshot sa posudzuje podľa článku XVII.

100. Zákazník s kritickými alebo nenahraditeľnými dátami je povinný primerane dodržiavať aj povinnosti podľa článkov X a XI.
101. Vlastná nezávislá záloha môže byť potrebná najmä vtedy, ak Zákazník potrebuje obnoviť dáta, ktoré neboli zachytené v žiadnom bode WebHouse.
102. Povinnosť Zákazníka vytvárať vlastné zálohy však nezbavuje WebHouse zodpovednosti za správne poskytovanie objednanej zálohovacej služby.
103. Ak je dostupný použiteľný bod obnovy v rámci výslovne dohodnutých parametrov služby, WebHouse je povinný postupovať podľa podmienok príslušnej obnovovacej služby.
104. Samotná skutočnosť, že príčinou potreby obnovy bola chyba Zákazníka, neoprávňuje WebHouse na svojvoľné poškodenie alebo nesprávne vykonanie obnovy.
105. Zákazník nesie zodpovednosť za pôvodný chybný pokyn alebo zásah vo svojej spravovanej vrstve.
106. WebHouse nesie zodpovednosť za správne technické vykonanie následnej obnovy v rozsahu, ktorý prevzal.
107. Ide o dve samostatné otázky zodpovednosti.
108. Žiadne ustanovenie tohto článku nemožno vykladať ako všeobecnú domnienku, že každá strata dát vzniknutá v zákazníckej aplikácii je spôsobená Zákazníkom.
109. Príčina incidentu sa posudzuje podľa konkrétnych technických a zmluvných okolností.
110. Týmto článkom nie sú dotknuté práva Zákazníka, ktoré podľa všeobecne záväzných právnych predpisov nemožno zmluvne vylúčiť alebo obmedziť.

Článok 32

Spoplatnenie obnovy

1. Obnova dát môže byť podľa konkrétnej služby:
   • zahrnutá v cene služby,
   • zahrnutá iba v určitom rozsahu,
   • zahrnutá iba v určitom počte obnov,
   • dostupná samoobslužne,
   • alebo spoplatnená podľa aktuálneho cenníka či individuálnej dohody.
2. Konkrétne podmienky spoplatnenia obnovy sa riadia najmä:
   • parametrami objednanej služby,
   • cenníkom WebHouse,
   • rozsahom požadovanej obnovy,
   • technickou náročnosťou zásahu,
   • príčinou potreby obnovy,
   • a prípadnou individuálnou dohodou so Zákazníkom.
3. Samotná existencia zálohy neznamená automaticky, že všetky úkony potrebné na jej obnovu sú zahrnuté v pravidelnej cene služby.
4. Cena zálohovacej služby a cena manuálnej obnovy môžu predstavovať dve odlišné položky.

5. Zálohovacia služba môže zahŕňať najmä:

   • vytváranie záloh,
   • ich uchovávanie,
   • správu retenčného cyklu,
   • technickú dostupnosť bodov obnovy,

   pričom samotný manuálny administrátorský zásah pri obnove môže byť spoplatnený osobitne.

6. Pri niektorých službách môže byť určitý počet obnov zahrnutý v pravidelnej cene.
7. Po vyčerpaní takéhoto počtu môžu byť ďalšie obnovy spoplatnené podľa cenníka.
8. Ak konkrétna služba obsahuje neobmedzenú alebo inak definovanú bezplatnú obnovu, WebHouse je povinný túto vlastnosť rešpektovať v dohodnutom rozsahu.
9. Všeobecné ustanovenia tohto článku nemožno použiť na obchádzanie výslovne dohodnutej bezplatnej obnovy.
10. Samoobslužná obnova môže byť poskytovaná za odlišných cenových podmienok než manuálna obnova vykonaná pracovníkom WebHouse.
11. Skutočnosť, že Zákazník môže určitý úkon vykonať samoobslužne bezplatne, neznamená automaticky nárok na bezplatné vykonanie rovnakého úkonu administrátorom WebHouse.
12. Manuálny zásah môže byť spoplatnený najmä v prípade, ak:

• problém nespôsobil WebHouse,
• ide o chybu Zákazníka,
• ide o zásah osoby oprávnenej Zákazníkom,
• ide o následok zákazníkom spravovanej aplikácie alebo konfigurácie,
• je potrebné manuálne vyhľadávanie,
• je potrebné preveriť viacero bodov obnovy,
• obnova vyžaduje administrátorský zásah,
• je potrebné vytvoriť dočasný priestor,
• ide o nadštandardnú požiadavku,
• alebo požadovaný postup presahuje štandardný rozsah obnovy.

13. Spoplatnená môže byť napríklad obnova po:

• náhodnom vymazaní súboru,
• odstránení databázy,
• odstránení e-mailovej schránky,
• chybnej aktualizácii,
• neúspešnej migrácii,
• nesprávnom SQL príkaze,
• chybnej konfigurácii,
• inom zákazníckom administrátorskom zásahu.

14. Skutočnosť, že chyba Zákazníka bola neúmyselná, sama osebe nezakladá nárok na bezplatnú manuálnu obnovu.
15. Spoplatnená môže byť aj obnova po zásahu externého administrátora, vývojára alebo inej osoby, ktorej Zákazník umožnil prístup k službe.
16. Ak sa neskôr preukáže, že príčina incidentu nebola na strane Zákazníka, ale na strane WebHouse, posúdi sa spoplatnenie podľa skutočne zistenej príčiny.
17. WebHouse preto nemá automaticky považovať každý restore za platený iba preto, že príčina incidentu nebola v čase podania požiadavky ešte známa.
18. V prípade nejasnej príčiny môže WebHouse vykonať technickú obnovu bez prejudikovania otázky zodpovednosti a následne posúdiť, či má byť zásah spoplatnený.
19. Samotné vykonanie obnovy bez okamžitého vyúčtovania neznamená, že Zákazník má nárok na jej bezplatnosť, ak podľa cenníka alebo podmienok služby ide o platený zásah.
20. Rovnako samotné predbežné označenie zásahu ako plateného nebráni následnému prehodnoteniu, ak sa preukáže zodpovednosť WebHouse.
21. Manuálne vyhľadávanie konkrétnych dát môže byť spoplatnené aj vtedy, ak samotná existencia zálohy patrí do štandardnej služby.
22. Ide najmä o situácie, keď je potrebné:

• obnoviť viacero historických bodov,
• vyhľadať konkrétny súbor,
• vyhľadať konkrétnu e-mailovú správu,
• vyhľadať konkrétny databázový údaj,
• porovnať viacero historických verzií.

23. Takéto vyhľadávanie môže byť časovo náročnejšie než samotná štandardná obnova celého technického celku.
24. WebHouse preto môže účtovať administrátorský čas podľa aktuálneho cenníka.
25. Spoplatnená môže byť aj obnova do dočasného priestoru podľa článku XXVII.
26. Cena môže zahŕňať najmä:

• vytvorenie dočasného priestoru,
• diskovú kapacitu,
• dočasnú virtuálnu inštanciu,
• manuálne pripojenie historických dát,
• administrátorskú prácu.

27. Ak Zákazník požaduje predĺženie doby existencie dočasného priestoru, môže byť spoplatnená aj dodatočná kapacita alebo čas jeho používania.
28. Individuálne zlúčenie historických a aktuálnych dát môže byť spoplatnené osobitne.
29. Ide najmä o:

• zlúčenie databáz,
• selektívny import záznamov,
• manuálne kopírovanie vybraných súborov,
• porovnávanie verzií,
• alebo inú aplikačne špecifickú prácu.

30. Takéto činnosti nemusia byť vôbec technicky možné alebo ich WebHouse nemusí poskytovať ako štandardnú službu.
31. Ak ich WebHouse poskytne, môže cenu určiť podľa:

• času práce,
• technickej náročnosti,
• alebo individuálnej cenovej ponuky.

32. Bez osobitnej dohody WebHouse nie je povinný vykonávať aplikačný vývoj alebo odborné databázové rekonštrukcie ako súčasť štandardnej obnovy.
33. Spoplatnená môže byť aj bezpečnostná práca súvisiaca s obnovou kompromitovaného systému.
34. Môže ísť najmä o:

• malware scan,
• manuálnu analýzu súborov,
• kontrolu viacerých bodov obnovy,
• odstránenie škodlivého kódu,
• izolovanú obnovu,
• forenznú analýzu,
• hardening,
• alebo inú bezpečnostnú činnosť.

35. Samotná zálohovacia služba neobsahuje automaticky tieto činnosti.
36. Ak je kompromitácia spôsobená v zákazníkom spravovanej vrstve, môže byť takáto práca spoplatnená podľa rozsahu zásahu.
37. Ak však bezpečnostný incident vznikol v dôsledku porušenia povinnosti na strane WebHouse, nemožno na Zákazníka automaticky preniesť náklady na nápravu, za ktorú zodpovedá WebHouse.
38. Spoplatnenie obnovy sa preto musí posudzovať oddelene od otázky technickej možnosti obnovy.
39. To, že je určitý zásah technicky možný, neznamená automaticky, že je zahrnutý v cene služby.
40. Rovnako to, že je zásah spoplatnený, neznamená, že WebHouse môže odmietnuť splniť vlastnú povinnosť odstrániť vadu služby.
41. Ak je obnova potrebná z dôvodu vady, poruchy alebo porušenia povinnosti, za ktoré zodpovedá WebHouse, použijú sa príslušné:

• zmluvné podmienky,
• SLA,
• Reklamačný poriadok,
• a všeobecne záväzné právne predpisy.

42. WebHouse nesmie spoplatniť úkon iba s cieľom preniesť na Zákazníka náklady na odstránenie vady služby, za ktorú zodpovedá WebHouse.
43. Ak je bezplatná obnova primeraným spôsobom odstránenia vady služby, posudzuje sa podľa príslušných pravidiel zodpovednosti za vady.
44. Ak sa súčasne obnovujú aj dáta alebo komponenty, ktoré s vadou WebHouse nesúvisia a ich obnovu Zákazník požaduje nad rámec potrebnej nápravy, môže byť táto nadštandardná časť posudzovaná samostatne.
45. Jeden incident preto môže obsahovať:

• bezplatnú časť zásahu, za ktorú zodpovedá WebHouse,
• a spoplatnenú nadštandardnú časť požadovanú Zákazníkom.

46. Takéto rozdelenie musí zodpovedať skutočnému rozsahu jednotlivých prác.
47. WebHouse by nemal paušálne spoplatniť celý zásah, ak jeho podstatná časť predstavuje odstránenie vlastnej vady.
48. Ak je obnova potrebná z viacerých príčin, posudzuje sa primerane podiel jednotlivých príčin a rozsah objednaných prác.
49. Cena obnovy môže byť stanovená:

• pevnou sumou,
• cenou za jeden restore,
• hodinovou sadzbou administrátora,
• cenou za objem dát,
• cenou za využitú kapacitu,
• alebo individuálnou cenovou ponukou.

50. Spôsob určenia ceny sa riadi cenníkom alebo dohodou so Zákazníkom.
51. Ak je cena zásahu známa vopred, WebHouse môže Zákazníka pred vykonaním zásahu informovať o tejto cene.
52. Ak presnú cenu nemožno určiť vopred, WebHouse môže oznámiť:

• hodinovú sadzbu,
• spôsob výpočtu,
• orientačný rozsah prác,
• alebo maximálny schválený rozsah práce.

53. Ak zásah presahuje bežnú technickú podporu a má byť spoplatnený podľa času práce, WebHouse môže pred jeho vykonaním požadovať súhlas Zákazníka.
54. Takéto potvrdenie je vhodné najmä pri zásahoch, pri ktorých nie je vopred známy presný rozsah práce.
55. WebHouse môže napríklad požiadať Zákazníka o súhlas s:

• konkrétnou pevnou cenou,
• hodinovou sadzbou,
• alebo maximálnym počtom hodín práce bez ďalšieho potvrdenia.

56. Po dosiahnutí schváleného rozsahu môže WebHouse prácu prerušiť a požiadať o ďalší súhlas.
57. Tým sa predchádza vzniku neprimeraných alebo neočakávaných nákladov.
58. Ak Zákazník odmietne schváliť cenu nadštandardného zásahu, WebHouse nie je povinný takýto nadštandardný zásah vykonať.
59. Tým nie je dotknutá povinnosť WebHouse vykonať úkony, ktoré je povinný poskytnúť bezplatne podľa zmluvy alebo zákona.
60. Ak je potrebné bezodkladne vykonať opatrenie na ochranu infraštruktúry alebo dát, môže WebHouse vykonať nevyhnutný bezpečnostný alebo stabilizačný úkon aj pred dohodou o ďalších nadštandardných prácach.
61. Takýto úkon a následná platená obnova predstavujú dve rozdielne činnosti.
62. WebHouse môže pri kritickom incidente najskôr vykonať nevyhnutné opatrenia na:

• zastavenie ďalšieho poškodzovania,
• izoláciu služby,
• zachovanie dostupného bodu obnovy,
• alebo ochranu infraštruktúry.

63. Následná individuálna rekonštrukcia zákazníckej aplikácie môže byť predmetom samostatnej dohody.
64. Ak Zákazník výslovne požaduje okamžité vykonanie plateného zásahu a cena je určená cenníkom, WebHouse môže postupovať podľa tejto požiadavky bez osobitnej individuálnej cenovej ponuky.
65. Pri spotrebiteľovi sa však musia dodržať povinnosti týkajúce sa informovania o cene a ďalšie kogentné pravidlá ochrany spotrebiteľa.
66. Ak cenu nemožno rozumne vypočítať vopred, musí byť Zákazníkovi primerane zrejmý aspoň spôsob jej určenia, ak to vyžadujú právne predpisy.
67. WebHouse nemôže voči spotrebiteľovi požadovať platbu, ktorá nebola riadne oznámená alebo dohodnutá v súlade s príslušnými právnymi predpismi.
68. Ak obnova predstavuje osobitnú objednávanú službu nad rámec pôvodnej služby, môžu sa na ňu vzťahovať aj pravidlá uzatvárania zmluvy na diaľku.
69. Spôsob objednania a spoplatnenia obnovy musí preto zodpovedať postaveniu Zákazníka a príslušnému právnemu režimu.
70. Pri podnikateľskom Zákazníkovi môže byť cena účtovaná podľa platného cenníka alebo obchodnej dohody.
71. Ak bola konkrétna cena alebo spôsob účtovania individuálne dohodnutý, má táto dohoda prednosť pred všeobecným cenníkom v rozsahu, v akom sa na daný zásah vzťahuje.
72. WebHouse môže pred manuálnou obnovou požadovať úhradu ceny vopred, ak to vyplýva z cenníka alebo dohody.
73. Pri pravidelnom Zákazníkovi môže byť zásah podľa obchodných podmienok vyúčtovaný aj dodatočne.
74. Spôsob fakturácie môže závisieť od: