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:
- Avaa Azure Portal ja siirry App Serviceesi
- Siirry kohtaan Deployment Center > Deployment history
- Etsi aiempi onnistunut käyttöönotto
- Valitse se ja napsauta Redeploy
- 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:
- Palauta tietokanta hetkeen ennen ongelman ilmenemistä
- Varmista palautetun tietokannan sisältö
- Päivitä App Servicen yhteysmerkkijono osoittamaan palautettuun tietokantaan tai nimeä tietokannat uudelleen niiden vaihtamiseksi
SPFx:n palautus
SPFx-web-osan palauttamiseksi aiempaan versioon:
- Lataa aiemman version
.sppkg-paketti Realizer-portaalista - Avaa SharePoint App Catalog
- Lataa aiempi paketti, joka korvaa nykyisen version
- 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
- Blob Storagesta poistetut asiakirjat: Jos soft delete on käytössä, palauta blobit konfiguroidun säilytysikkunan sisällä
- 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ä:
- Azure SQL: Palauta geo-redundanteista varmuuskopioista uuteen SQL Serveriin eri alueella
- 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.
- App Service: Ota uudelleen käyttöön Bicep-mallin avulla palautusalueella
- 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:
- Suorita Bicep-malli kaikkien Azure-resurssien valmistelemiseksi
- Ota API-zip käyttöön App Servicessä (sisältyy ARM-käyttöönottoon)
- Tietokantaskeema otetaan automaattisesti käyttöön ensimmäisellä API:n käynnistyksellä
- Lataa SPFx .sppkg SharePoint App Catalogiin
- Suorita
Deploy-AccessPoint.ps1Entra-only SQL -todennuksen ja Graph-käyttöoikeuksien konfiguroimiseksi - Palauta tietokanta uusimmasta varmuuskopiosta tietojen palauttamiseksi
- 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 |