Fereastra de recuperare este acum configurabilă în Microsoft Backup 365

Perioada de recuperare era una dintre cele mai mari limitări ale Microsoft 365 Backup. O durată fixă de un an, fără excepții. Acum, însă, lucrurile se schimbă. Microsoft lansează o fereastră de recuperare configurabilă pentru Microsoft 365 Backup, care vă permite să o setați între 3 luni și 2 ani, în funcție de politica aplicabilă. Pe hârtie, este o schimbare minoră, dar rezolvă o problemă reală pentru oricine dorește să controleze costurile de stocare și perioada de păstrare.

În prezent, fiecare politică de backup Microsoft 365 utilizează aceeași perioadă de recuperare de 1 an, indiferent dacă faceți backup pentru un site de proiect activ sau pentru o căsuță supusă cerințelor de conformitate. Odată cu această actualizare, puteți seta perioada de recuperare pentru fiecare politică în parte: mai scurtă pentru datele pe care nu este necesar să le păstrați atât de mult timp și mai lungă pentru cele care implică cerințe de conformitate extinse.

Nota Bene: Valoarea implicită rămâne la 1 an. Nu se modifică nimic automat; trebuie să accesați setările și să le modificați manual, pentru fiecare politică în parte.

Această funcționalitate se lansează la nivel mondial începând cu sfârșitul lunii iulie 2026, disponibilitatea generală fiind preconizată pentru începutul lunii august 2026. Este asociată cu Roadmap-ul Microsoft 365 cu ID-ul 481834, așa că o puteți urmări acolo dacă doriți să aflați calendarul exact pentru tenantul dumneavoastră.

Odată ce funcția este activă, setarea unei noi perioade de recuperare este simplă:

  1. Accesați Centrul de administrare Microsoft 365
  2. Accesați secțiunea „Microsoft 365 Backup”
  3. Selectați politica de backup pe care doriți să o modificați
  4. Deschideți opțiunea „Update recovery window”
  5. Setați perioada dorită (între 3 luni și 2 ani)
  6. Verificați și confirmați.

Nota bene: Dacă reduceți intervalul de recuperare al unei politici existente, datele de rezervă care nu se încadrează în noul interval vor fi șterse definitiv după o perioadă de grație. Este o măsură ireversibilă, așa că consultați-vă cu persoana responsabilă de conformitate din organizația dumneavoastră înainte de a reduce acest interval.

Aceasta este o soluție binevenită pentru o limitare care exista încă de la lansarea serviciului Microsoft 365 Backup. Dacă organizația dvs a fost nevoită să plătească pentru o perioadă de păstrare de 12 luni de care nu avea nevoie sau și-a dorit să poată păstra anumite date mai mult timp, această actualizare vă oferă în sfârșit acest control.

Odată ce această funcționalitate va fi implementată, merită să treceți rapid în revistă politicile existente pentru a verifica dacă perioada implicită de 1 an mai este adecvată sau dacă unele dintre ele ar trebui să fie mai scurte sau mai lungi. Nu modificați însă nimic până când nu sunteți siguri de ceea ce aveți voie să ștergeți.

[mai mult...]

Cum se pot trunchia și reduce jurnalele de tranzacții din SQL Server

Jurnalele de tranzacții(Transaction logs) ale Microsoft SQL Server tind să crească în timp și pot, uneori, să ocupe tot spațiul liber de pe unitatea de stocare a serverului. Pentru a evita această situație, ar trebui efectuate copii de siguranță periodice ale jurnalelor de tranzacții sau să utilizați operațiunile de trunchiere și reducere a jurnalelor de tranzacții din SQL Server.

Diferența dintre operațiunile „truncate” și „shrink” ale fișierelor jurnal din SQL Server

Trebuie să fiți familiarizați cu modelele de recuperare din SQL Server înainte de a putea înțelege diferența dintre operațiunile „truncate” și „shrink”:

  • Modelul de recuperare simplu — SQL Server marchează fișierele jurnal virtuale inactive ca fiind reutilizabile după un punct de control și atunci când niciun factor (cum ar fi copiile de siguranță sau tranzacțiile active), nu blochează trunchierea. Acest mod de recuperare este destinat exclusiv mediilor de dezvoltare sau de testare și nu este recomandat pentru mediile de producție;
  • Modelul de recuperare complet — jurnalele de tranzacții nu vor fi șterse până când nu se finalizează o copie de rezervă a jurnalului de tranzacții (nu are loc o truncare automată a jurnalului). Jurnalul de tranzacții va fi trunchiat numai după efectuarea copiei de rezervă a acestuia. Acest mod reprezintă cea mai bună metodă de recuperare a datelor după o defecțiune și este utilizat atunci când este necesară o recuperare la un moment dat.
  • Jurnalizare în bloc — acest mod permite reducerea spațiului utilizat de jurnal prin utilizarea setărilor de jurnalizare minimă. SQL Server trunchiază jurnalul de tranzacții numai după efectuarea cu succes a unei copii de rezervă a acestuia.

Copierea de rezervă completă a bazei de date SQL Server nu trunchiază jurnalul de tranzacții. Configurarea copierii de rezervă periodice a jurnalului de tranzacții este singura modalitate valabilă de a trunchia fișierele jurnal. Operațiunea de trunchiere eliberează spațiul, dar nu reduce dimensiunea fișierului jurnalului de tranzacții de pe disc.

Reducerea dimensiunii ar trebui utilizată pentru a reduce dimensiunea jurnalului de tranzacții SQL Server de pe unitate. În timpul operațiunii de reducere, MSSQL mută paginile alocate din fișierul jurnal în spațiul liber și dezalocă VLF-urile neutilizate de la sfârșitul fișierului. Spațiul liber este apoi dezalocat și returnat sistemului de fișiere.

[mai mult...]

Ce sunt permisiunile pentru căsuțele poștale Exchange partajate?

Permisiunile pentru căsuțele poștale Exchange partajate controlează cine poate accesa și utiliza o căsuță poștală partajată. Aceste permisiuni pot fi atribuite utilizatorilor, grupurilor de utilizatori sau altor căsuțe poștale.

Tipuri de permisiuni pentru căsuțele poștale Exchange partajate

Există cinci tipuri de permisiuni pentru căsuțele poștale Exchange partajate:

  • Full Access: Acest permis este acordat utilizatorilor care au nevoie de acces complet la o căsuță poștală partajată. Acest lucru include posibilitatea de a citi, scrie, șterge și gestiona mesaje, precum și de a accesa fișiere și foldere din căsuța poștală.
  • Send As: Acest permis este acordat utilizatorilor care au nevoie să trimită mesaje de e-mail din numele unei căsuțe poștale partajate.
  • Send On Behalf: Acest permis este acordat utilizatorilor care au nevoie să trimită mesaje de e-mail din numele unei căsuțe poștale partajate, dar să fie identificate ca trimitătoare.
  • Create Full Access: Acest permis este acordat utilizatorilor care au nevoie să creeze alte căsuțe poștale cu drepturi de acces complet la o căsuță poștală partajată.
  • Delegate Full Access: Acest permis este acordat utilizatorilor care au nevoie să delege drepturi de acces complet la o căsuță poștală partajată către alte persoane.
[mai mult...]