@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix edu: <https://knobit.org/def/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix schema: <https://schema.org/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

<https://knobit.org/id/task/dso-recovery-service-levels/C1> a edu:Question ;
    rdfs:label "C1 (3 points)"@en ;
    dcterms:license <https://creativecommons.org/licenses/by/4.0/> ;
    schema:hasPart <https://knobit.org/id/register/data-storage-operations#SO-350>,
        <https://knobit.org/id/register/data-storage-operations#SO-351>,
        <https://knobit.org/id/register/data-storage-operations#SO-352> ;
    schema:identifier "C1" ;
    schema:position 1 ;
    schema:text "Recovery commitments against how recovery actually works, 1 each. (a) SL-101: instant payments are back only when the whole chain is: the payment hub database (OL-101) needs PT1H45M and the SEPA Inst gateway (OL-102) can start only after it, PT30M more, so the service recovers in PT2H15M in both scenarios (core banking, OL-103, recovers in parallel and does not change this) - over CS-11's PT2H tolerance, though each OLA looks fine alone. Reported, with a remedy proposed for the owners (gateway recovering in parallel or kept warm, faster database recovery) or the gap raised with the Head of Payments; the tolerance is not touched. (b) SL-102 and OL-104: a synchronous replica is not a backup - it copies corruption and ransomware to the second site at once, and OL-104 has no point-in-time copy at all, so the corruption RPO of PT0S (and RTO of PT15M) is not real. Immutable point-in-time backups outside the primary's failure domain proposed for OL-104 (cards platform lead to agree), with the corruption RPO taken from their interval or left null and raised; the site-loss PT0S at 25 km stays. (c) SL-103 and OL-107: the June restore test restored 1.5 TB of the 12 TB channel store, so it does not prove the PT2H corruption RTO: a full-scope restore test planned (no result invented), and the risk raised that the full restore takes longer - scaled linearly the test suggests about PT5H20M, beyond CS-13's PT4H."@en .

edu:Question rdfs:label "Question"@en,
        "Küsimus"@et .

<https://knobit.org/id/register/data-storage-operations#SO-350> rdfs:label "dso-recovery-service-levels C1a: SL-101 recovers along the OL-101 -> OL-102 chain, past CS-11's tolerance"@en .

<https://knobit.org/id/register/data-storage-operations#SO-351> rdfs:label "dso-recovery-service-levels C1b: OL-104's synchronous replica is no copy against corruption"@en .

<https://knobit.org/id/register/data-storage-operations#SO-352> rdfs:label "dso-recovery-service-levels C1c: OL-107's partial restore test does not prove the RTO"@en .