Pentru ISACA Student Group Iași și mentorul lor. ;)

Cineva respectabil îmi spunea de mult: Nimeni nu este de neînlocuit. Foarte multă dreptate în aceste vorbe. Dar mai ales în timp. J

Conjunctura

Am învățat în timp, din business-urile private, adevărata valoare aplicată a axiomei: Nimic nu se pierde. Totul se transformă. Asta se traduce în cuvinte simple că un conținut informațional construit în timp nu se șterge niciodată. Niciodată până nu se întâmplă concret.

Să lăsăm trecutul în urmă și să discutăm concret despre tema acestui articol.

Conceptul de disaster recovery nu vine niciodată în momente de liniște în activitatea profesională, ci se suprapune de cele mai multe ori cu alte momente de criză, care se acutizează odată cu indisponibilitatea unor servicii IT adresate componentei economico-financiare. Fiecare companie dispune de planuri de continuitate cunoscute sub numele de Business Continuity Plan sau Disaster Recovery Plan, dar fiecare responsabil de planurile de acțiune, cred că merge (aici sunt ironic), pe față sau mai pe ascuns, din când în când, la Biserică pentru a aprinde o lumânare în „sănătatea” și continuitatea serverelor J. De la a se întâmpla cu caracter de excepție până la a șterge just like this un întreg pachet informațional nu poate fi susținut decât printr-o decizie fermă de management cu scopul de a demonstra spusele de demult. Nu condamn pe nimeni și nimic prin acest articol. Chiar sper să vin în ajutorul celor care ajung din întâmplare la cazuri de acest gen.

În acele planuri de continuitate a afacerii există documentate proceduri clare de realizare a copiilor de siguranță și a modului de restaurare a acestora. Se spune chiar că, backup-urile trebuie testate la perioade regulate de timp.

Teoria

În SharePoint 2013 există mai multe metode de backup utile și una inutilă. Cea inutilă este să copii din Windows Explorer conținutul unui SharePoint. Da poate fi bună pentru anumite librării de documente și chiar liste cu fișiere atașate, dar este stupidă pentru pagini sau pentru conținutul listelor și alte aplicații dezvoltate.

Dintre metodele utile, amintim:

Farm backup – folosind Central Administration sau powershell.
SQL Database backup – folosit cel mai frecvent datorită mecanismelor puternice de automatizare puse la dispoziție de SQL Server.
Granular backup (articolul este pe 2010 dar funcționează și în 2013)- care presupune creare de fișiere CMP pentru site-uri, subsite-uri, până la nivel de liste.
Third-party Backup tools – care pun la dispoziția administratorilor de SharePoint o gamă largă de instrumente și facilități. Am lucrat din lista respectivă cu DocAve, Quest și Metalogix, acesta din urmă fiind cel care mi-a plăcut cel mai mult. Din păcate sunt produse foarte scumpe.

Metodele de recovery sunt și ele destul de diferite și diferă de la caz la caz. În prezentul articol ne propunem să luăm cazul maxim, acela în care nu avem decât un MDF, de pe o anumită versiune de SQL Server, din care trebuie să recuperăm un site dintr-o fostă fermă de SharePoint, despre care știm că este un SharePoint 2013 Enterprise. Noua fermă se află într-un alt domeniu Active Directory.

Puțin dramatism aplicat

Pentru cei care cunosc puțin SQL Server, o bază de date este formată la nivel fizic pe disc din cel puțin două fișiere: MDF – în care sunt stocate datele și LOG în care sunt păstrate tranzacțiile. LOG-urile devin mari în timp în SharePoint dar există metode de a le diminua. În momentul în care se realizează backup-ul unei baze de date SQL Server se poate crea ori un fișier BAK sau unul TRN. Aceste copii de siguranță se pot restaura aproape pe oricare alt server de SQL, chiar dacă mai pot apărea probleme de versiune a bazei de date, de compatibility level sau Collation.

Presupunând că dintr-o eroare rămâi doar cu un MDF (fișierul cu date), există mai multe proceduri de restaurare a acestuia, din păcate unele dintre ele fără un rezultat pozitiv. Cel mai concludent articol de restaurare doar dintr-un MDF mi s-a părut acesta: http://www.sqlskills.com/blogs/paul/checkdb-from-every-angle-emergency-mode-repair-the-very-very-last-resort/. Chiar dacă este un articol excelent este exemplificat pe o bază de date cu o tabelă și totul se desfășoară în același mediu de test, ignorând permisiuni din domenii de autentificare diferite cu certificate de criptare diferite și altele.

Un recovery (aproape) normal

În cazul în care avem un backup de SharePoint Farm suficient de bine calibrat în timp pentru a putea fi utilizat la un restore, putem alege din lista de restore să selectăm doar un content database specific unui webapp.

Această operațiune va avea drept rezultat crearea și restaurarea unei baze de date în serverul de SQL dar care nu va fi montată automat pe un anumit site în cazul în care ferma este la o altă versiune decât cea a fermei din care se încearcă restaurarea.

Mesajul de eroare: Object P_Research_Content failed in event OnPostRestore. For more information, see the spbackup.log or sprestore.log file located in the backup directory. SPException: Cannot attach database to Web application. Use the command line tool or Central Administration pages to attach the database manually to the proper Web Application.

Să nu mai spună linuxiștii că numai ei au comenzi J

Presupunând că am reușit să restaurăm baza de date, pasul următor este acela al creării unei web-app sau content site nou în care să montam baza de date de recuperat. Montarea unei baze de date se poate face vizual sau din PowerShell cu comanda Mount-SPContentDatabase.

Principalele comenzi pentru bazele de date sunt:

New-SPContentDatabase
Remove-SPContentDatabase
Mount-SPContentDatabase
Dismount-SPContentDatabase
Get-SPContentDatabase
Set-SPContentDatabase
Upgrade-SPContentDatabase
Test-SPContentDatabase

Pentru montarea unei baze de date și testarea conținutului avem nevoie de un nou webapp.

Exemplu de creare webapp din PowerShell.

$ap = New-SPAuthenticationProvider

New-SPWebApplication -Name "Restore Research Site" -Port 80 -HostHeader research.uaic.ro -URL "http://research.uaic.ro" -ApplicationPool "SP_Restore_Pool" -ApplicationPoolAccount (Get-SPManagedAccount "INTRANET\admin") -AuthenticationProvider $ap –SecureSocketsLayer

Montarea bazei de date:

Mount-SPContentDatabase -Name P_research_content -WebApplication „Restore Research Site”

Inevitabilul

Invariabilul mesaj de eroare în caz în care versiunile fermelor nu sunt asemănătoare:

Mount-SPContentDatabase : This content database has a schema version which is not supported in this farm.

Cum putem afla versiunea fermei și a bazei de date?

Pentru fermă este destul de simplu din PowerShell:

PS D:\> (get-spfarm).buildversion

Major Minor Build Revision

–– –– –– –––

15 0 4420 1017

Pentru baza de date în schimb, trebuie să deschidem baza de date și să extragem informațiile din tabela Versions.

/****** Get the versions of a content database ******/

SELECT
*

FROM
[P_Research_Content].[dbo].[Versions]

Results:

VersionId Version Id

00000000-0000-0000-0000-000000000000 15.0.4505.1005 1

1A707EF5-45B2-4235-9327-021E5F9B8BB0 15.0.13.0 3

6333368D-85F0-4EF5-8241-5252B12B2E50 15.0.141.0 2

TMMNRA

Observăm din cele două comenzi că există o diferență de versiune între baza de date și ferma de restore. Microsoft recomandă pentru această situație actualizarea fermei la același nivel cu cel al bazei de date prin aplicarea service packs-urilor și a Cumulative update-urilor necesare.

Pe de altă parte un articol, pe care l-aș cataloga drept The Most Microsoft Not Recommended Article
J, este cel prin care ni se sugerează să modificăm versiunile direct în baza de date, asemănător cu ceea ce există într-o bază de date similară din acea fermă. Repet! Se recomandă editarea directă a înregistrărilor din tabela Versions. Microsoft spune foarte clar în documentele oficiale de suport pentru SharePoint că, orice modificare la nivel de baze de date va aduce cu sine pierderea suportului pe produsul respectiv. Și de aici apar o serie de interpretări și rumori: Modific structura sau datele?

Presupunând faptul că vrem doar să recuperăm ceva din acea bază de date defunctă trebuie să știm că SharePoint 2013 permite recuperarea datelor din baze de date nemontate pe webapp, dar orice tentativă de restore s-ar solda cu același mesaj de eroare legat de versiuni.

În politicile IT din organizații se specifică destul de clar faptul că orice fermă de SharePoint trebuie să aibă o fermă paralelă de test și una de dezvoltare. Pe toate aceste ferme trebuie să existe instalate aceleași pachete de tip update sau service pack pentru a asigura compatibilitatea. Nu știu câte firme din cele care au SharePoint țin la rigoarea acestei proceduri.

În cazul în care nu reușim să montăm baza de date și vrem să facem o restaurare fără montare, folosind Central Administration, vom primi mesajul de eroare: Sorry, something went wrong SharePoint object [SPContentDatabase Name=p_research_Content] is in an unsupported state, and could not be used by the current farm.

Some final action – Exportul

După modificarea valorilor din tabela Versions montarea merge cu succes așa că o să exemplificăm mai departe restaurarea granulară a unui subsite.

Din Central Administration se accesează secțiunea Backup and Restore și apoi Recover data from an unattached content database.
Se specifică numele serverului de baze de date și numele bazei de date pe care reușit să o restaurăm.
La modul de operare putem alege:
1. Browse content
2. Backup site collection
3. Export site or list
Pentru a ști ce restaurăm ar fi recomandat să explorăm conținutul bazei de date înainte de operațiunea efectivă așa că în acest exemplu am ales opțiunea Browse Content și navigăm până la site-ul dorit.
Operațiunea recomandată este aceea de Export site or list pentru a putea importa apoi fișierele CMP într-un alt subsite. Partea faină a metodei este că exportă inclusiv subsite-urile și există și bifă pentru Export full security.
În pasul următor trebuie să specificăm numele fișierului CMP de pe disc în care dorim să exportăm acest site și Start Backup

Operațiunea următoare este de a crea un subsite în cadrul unei infrastructuri existente și restaurarea cu suprascriere a fișierului CMP exportat în pasul anterior.

Unul din dezavantajele acestei metode poate fi legată de pierderea metadatelor de creare a activului informațional (Data, Autorul, Editor) fiind înlocuite cu numele restauratorului și data la care s-a produs operațiunea. Dacă o restaurare s-ar produce în același domeniu Active Directory atunci există opțiuni de export Full Security. Dacă și domeniul a fost afectat atunci întreaga ierarhie de securitate este compromisă.

Restaurarea

Scriptul meu complet pentru restaurare:

<# Adaugare Snapin SharePoint in PowerShell context #>

Add-PSSnapin
Microsoft.SharePoint.Powershell

<# Creare site nou intr-un webapp existent pentru restaurare

Foarte important este ca site-ul sa aiba acelasi template si pachet linvistic ca site-ul original.

New-SPWeb
-Url
http://intranet.uaic.ro/isg
-Language
1033
-Name
ISG
-Template
„STS#0”

<# Restaurarea exportului in noul site #>

Import-SPWeb
-Identity
http://intranet.uaic.ro/isg
-Path
D:\FarmBackup\ISG\ISG.cmp
-Force

Si pagina:

Epilog

Eh… cam așa ceva mi-ar fi plăcut să prezint la IT Camp-ul de luna aceasta de la Cluj. Succes tuturor prietenilor și profesioniștilor care se vor întâlni acolo. Sunt convins că va fi ceva foarte fain!

Și ca să închei în aceiași notă pașnică: Da! Poți înlocui salariații, dar este greu de acceptat să înlocuiești rigoarea, pasiunea și determinarea cu ambiție superficială. J