Katastrofipalautusmenettelyt, varmuuskopiointi ja palautus, palautusmenettelyt ja operatiivinen ohjeistus AccessPointille

Last updated: March 30, 2026 by Steve

Katastrofipalautus

AccessPoint toimii kokonaisuudessaan Azure-tilauksessasi. Katastrofipalautuksen suunnittelu hyödyntää Azuren sisäänrakennettuja redundanssi- ja palautusominaisuuksia. Julkaisijalla ei ole mitään asiakastietoja, joten palautus on täysin sinun hallinnassasi.

Palautustavoitteet

Komponentti RPO RTO Mekanismi
Azure SQL Database Minuutteja (PITR) 1–2 tuntia Ajankohtapalautus uuteen tietokantaan
Azure Blob Storage Lähes nolla (GRS) Minuuteista tunteihin Geo-redundantti replikointi tai soft delete -palautus
App Service (API) Nolla (tilaton) Minuutteja Uudelleenkäyttöönotto artefakteista tai käyttöönottopaikan vaihto
SPFx Web Part Nolla (tilaton) Minuutteja .sppkg:n uudelleenlataus julkaistuista artefakteista
Konfiguraatio Sama kuin tietokanta Sama kuin tietokanta Palautetaan tietokannan kanssa

Varmuuskopiointi ja palautus

Tietokanta

  • Ajankohtapalautus (PITR): Automaattinen, enintään 35 päivää. Manuaalista konfigurointia ei tarvita.
  • Pitkäaikaissäilytys (LTR): Konfiguroi viikoittaiset, kuukausittaiset tai vuosittaiset varmuuskopiot säännöstenmukaisuutta varten. Määritä kohdassa Azure Portal > SQL Database > Backups > Retention policies.
  • Geo-redundantti varmuuskopiointi: Käytössä oletuksena Standard- ja Premium-tasoilla. Mahdollistaa palautuksen pariksi määritettyyn Azure-alueeseen alueellisen häiriön sattuessa.

Blob Storage

  • Soft delete: Ota soft delete käyttöön blobeille ja säilöille vahingossa poistettujen asiakirjojen palauttamiseksi. Suositeltu säilytysaika: 30 päivää.
  • Versiointi: Ota blob-versiointi käyttöön ylikirjoitettujen asiakirjojen aiempien versioiden säilyttämiseksi.

Konfiguraatio

Vie tai dokumentoi konfiguraatiopakettisi ennen merkittäviä muutoksia. Jos konfiguraatiomuutos on palautettava, ainoa vaihtoehto on palauttaa tietokannan varmuuskopio.

Palautusmenettelyt

API:n palautus

API otetaan käyttöön zip-pakettina Azure App Serviceen. Aiempaan käyttöönottoon palaamiseksi:

  1. Avaa Azure Portal ja siirry App Serviceesi
  2. Siirry kohtaan Deployment Center > Deployment history
  3. Etsi aiempi onnistunut käyttöönotto
  4. Valitse se ja napsauta Redeploy
  5. Varmista, että sovellus toimii oikein

Jos käytät käyttöönottopaikkoja, vaihda takaisin aiempaan paikkaan kohdassa Deployment slots > Swap.

Tietokannan palautus

DacPac-käyttöönotot ovat oletuksena additiivisia — uudet sarakkeet ja taulut lisätään, mutta olemassa olevia objekteja ei poisteta. Tämä tarjoaa turvaverkon useimmille skeemamuutoksille.

Tietojen ongelmien (vioittuneet tai virheelliset tiedot) tapauksessa käytä Azure SQL:n ajankohtapalautusta:

  1. Palauta tietokanta hetkeen ennen ongelman ilmenemistä
  2. Varmista palautetun tietokannan sisältö
  3. Päivitä App Servicen yhteysmerkkijono osoittamaan palautettuun tietokantaan tai nimeä tietokannat uudelleen niiden vaihtamiseksi

SPFx:n palautus

SPFx-web-osan palauttamiseksi aiempaan versioon:

  1. Lataa aiemman version .sppkg-paketti Realizer-portaalista
  2. Avaa SharePoint App Catalog
  3. Lataa aiempi paketti, joka korvaa nykyisen version
  4. Napsauta Deploy

Konfiguraation palautus

Konfiguraatiopaketit ovat additiivisia — paketin tuominen lisää tai päivittää kohteita, mutta ei poista olemassa olevia. Konfiguraatiomuutosten palauttamiseksi palauta tietokanta ennen muutosta otetusta ajankohtavarmuuskopiosta.

Katastrofipalautusskenaariot

Skenaario 1: Tahaton tietojen poistaminen

  1. Blob Storagesta poistetut asiakirjat: Jos soft delete on käytössä, palauta blobit konfiguroidun säilytysikkunan sisällä
  2. Poistetut tietokantamerkinnät: Käytä Azure SQL:n ajankohtapalautusta hetkeen ennen poistoa. Kopioi tarvittavat tietueet palautetusta tietokannasta tuotantoon.

Skenaario 2: Azure-alueen häiriö

Jos käyttöönottoasi isännöivä Azure-alue ei ole käytettävissä:

  1. Azure SQL: Palauta geo-redundanteista varmuuskopioista uuteen SQL Serveriin eri alueella
  2. Blob Storage: Jos käytössä on geo-redundantti tallennus (GRS tai RA-GRS), käynnistä tilin vaihto. Jos käytössä on paikallisesti redundantti tallennus (LRS), tiedot on palautettava ulkoisesta varmuuskopiosta.
  3. App Service: Ota uudelleen käyttöön Bicep-mallin avulla palautusalueella
  4. DNS ja API-URL: Päivitä AccessPoint API-URL storage entity SharePointissa osoittamaan uuteen App Service-URL:iin

Skenaario 3: Ympäristön täydellinen uudelleenrakennus

Koko AccessPoint-ympäristö voidaan rakentaa uudelleen alusta alkaen julkaistujen käyttöönottoartefaktien avulla:

  1. Suorita Bicep-malli kaikkien Azure-resurssien valmistelemiseksi
  2. Ota API-zip käyttöön App Servicessä (sisältyy ARM-käyttöönottoon)
  3. Tietokantaskeema otetaan automaattisesti käyttöön ensimmäisellä API:n käynnistyksellä
  4. Lataa SPFx .sppkg SharePoint App Catalogiin
  5. Suorita Deploy-AccessPoint.ps1 Entra-only SQL -todennuksen ja Graph-käyttöoikeuksien konfiguroimiseksi
  6. Palauta tietokanta uusimmasta varmuuskopiosta tietojen palauttamiseksi
  7. Palauta Blob Storage -asiakirjat geo-redundanteista varmuuskopioista

Infrastructure as Code (Bicep-mallit) ja käyttöönottoskripti varmistavat, että ympäristö on täysin toistettavissa.

Suunnittelusuositukset

  • Ota geo-redundantti tallennus (GRS) käyttöön Blob Storage -tilillä asiakirjojen alueiden välisen redundanssin varmistamiseksi
  • Ota pitkäaikaissäilytys (LTR) käyttöön Azure SQL:ssä viikoittaisia, kuukausittaisia ja vuosittaisia varmuuskopioita varten oletus-PITR-ikkunan ulkopuolelle
  • Ota soft delete käyttöön Blob Storagessa 30 päivän säilytysajalla
  • Ota blob-versiointi käyttöön ylikirjoitettujen asiakirjojen palauttamiseksi
  • Dokumentoi käyttöönottoparametrisi — säilytä tiedot vuokralaisen nimestä, resurssiryhmästä, hälytyssähköpostista ja mahdollisista mukautetuista App Service -asetuksista, jotta voit ottaa nopeasti uudelleen käyttöön
  • Testaa palautus vuosittain — palauta tietokanta ja Blob Storage testiympäristöön varmistaaksesi, että varmuuskopiosi toimivat
  • Harkitse Azure Front Dooria tai Traffic Manageria, jos organisaatiosi vaatii automaattista vikasietoisuutta minimaalisella käyttökatkolla

Terveydentilan valvonta

AccessPoint tarjoaa kaksi terveystarkistuksen päätepistettä:

Päätepiste Tarkoitus
GET /api/health Perusterveystarkistus — vahvistaa, että API-prosessi on käynnissä
GET /api/health/ready Valmiustarkistus — varmentaa tietokantayhteyden, blob storagen ja riippuvaiset palvelut

Seurattavat keskeiset mittarit

Mittari Mistä löytyy Hälytyskynnys
HTTP 5xx -virhetaso Application Insights > Failures Mikä tahansa jatkuva 5xx-virhe
Keskimääräinen vasteaika Application Insights > Performance > 3 sekuntia
SQL DTU -käyttö Azure Portal > SQL Database > Monitoring > 80 % jatkuvasti
Blob storage -kapasiteetti Azure Portal > Storage Account > Metrics Lähestyy kiintiötä
App Service CPU/muisti Azure Portal > App Service > Metrics > 80 % jatkuvasti

Skaalaus

Vertikaalinen skaalaus (Scale Up)

Vaihda App Service Plan -taso kohdassa Azure Portal > App Service > Scale up (App Service plan). Uudelleenkäyttöönottoa ei tarvita.

Horisontaalinen skaalaus (Scale Out)

AccessPoint API on tilaton ja tukee useita instansseja. Konfiguroi manuaalinen tai automaattinen skaalaus kohdassa Azure Portal > App Service > Scale out (App Service plan).

SQL-skaalaus

Säädä tietokannan tasoa työkuorman mukaan. Yleiset palvelutasot: Basic, S0, S1, S2, S3, P1, P2.

Sertifikaattien ja salaisuuksien kierto

Kohde Kierto vaaditaan Huomautukset
Managed identity Ei Azure hallinnoi tunnistetietoja automaattisesti
Entra ID client secret Kyllä, jos käytössä Kierrä ennen vanhenemista; managed identity on suositeltu
SSL/TLS-sertifikaatti Riippuu App Service Managed Certificate uusiutuu automaattisesti; mukautetut sertifikaatit on uusittava manuaalisesti