ReFS-Clustergröße für Veeam Backup & Replication 64 KB oder 4 KB?

ReFS ab v3.1 unterstützt bekanntlich zwei verschiedene Clustergrößen: 4 KB und 64 KB. Welches nimmt man für ein B&R Repository?

tl;dr: 64KB für ReFS als Veeam-Repository

Aber warum?

Unter anderem Microsoft hat 2019 in einem Technet-Artikel einige Empfehlungen zur Clustergröße für ReFS und NTFS veröffentlicht. Die Standard-Clustergröße beider Dateisysteme ist 4K, was bis heute die Vorgabe ist, wenn man ein neues Volume formatiert. Der Artikel enthält aber auch eine detaillierte Erklärung, warum man eine bessere Performance mit 64K großen Zuordnungseinheiten erhält, wenn man große Dateien ließt oder schreibt.

64-KB-Cluster sind grundsätzlich immer dann sinnvoll, wenn man mit großen, sequentiellen E/A-Vorgängen (auf HDDs) arbeitet. Viel weniger Verwaltungsaufwand bei der Adressierung, mehr Payload und damit höherer Durchsatz bei deutlich weniger Last (etwa ein sechzehntel). Sicherungen und Wiederherstellungen erfolgen naturgemäß in aller Regel sequentiell, daher sind Veeam-Blöcke schon immer größer gewesen, nämlich 1Mbyte.

Insbesondere die „brutto“ Read/Write-Leistung unterscheidet sich erheblich, wenn dasselbe Volume auf derselben Hardware mit einer Clustergröße von 64 KB statt mit 4 KB formatiert wird. Eine bis zu vierfachen Steigerung der Netto-Geschwindigkeit von Merge-Vorgängen (Inkremental-Forever, Synthetic-Fulls …) ist üblich. Beide Vorgänge sind dank der Block-Cloning-API (ReFS-only!) immer noch erheblich schneller als „normales“ i/o, aber der Unterschied ist gewaltig. Die reine Backup-Schreibleistung hängt meist von der Quelle ab, daher fällt der gefühlte Unterschied hier ncht so groß aus.

Nachteile?

Ein Nachteil ist der zusätzliche Speicherplatzverbrauch. Dier beträgt, aus Erfahrung, etwa 5–10% der Dateigröße (nicht Volumengröße). Der Grund dafür ist, dass von Veeam erstellte Blöcke zunächst eine feste Größe von 1MB haben. In den allermeisten Veeam-Jobs ist aber standardmäßig die Komprimierung aktiv, die „im Durchschnitt“ die Größe nachträglich um etwa etwa 50% reduziert. Je nach Quelldaten fällt das natürlich leicht unterschiedlich aus, was in variabler „Verwendung“ von Cluster-„Rändern“ mündet.

Wir halten den Preis von <10% Speicherplatz für die Geschwindigkeits-Vervielfachung für hinnehmbar und empfehlen daher ebenfalls die 64KB Blockgröße.

Veeam für Office365 Warning: Processing site […] finished with warning: Cannot change web part export mode to ‘All’, because custom scripting is disabled for site

Microsoft SharePoint in Microsoft 365 nutzt „Webparts“. Das sind diese „Dokumentenblöcke“ die man in Sites einfügen kann, zum Beispiel die Office Blöcke (Promimentes Beispiel: der Excel-Table-Block). In diesen ist „Scripting“ normalerweise aus Sicherheitsgründen abgeschaltet (Office-Macros und so).

Den Effekt hatten wir hier zwar schon, aber aufgrund einer Nachfrage nach mehr Details, hier praktisch das selbe nochmal, nur kleinschrittiger 🙂

Wenn man nun die „moderne Authentifizierung“ für Veeam nutzt, also die Anmeldung als App-Only-Authentifizierung mit dem Zertifikat, muss man für Veeam die Eigenschaft „Exportmodus“ des/der Webparts ändern. Standardmäßig ist Scripting auf „Keine“ festgelegt, aber Veeam benötigt „Alle“. Wenn die Scriptingeigenschaft auf „keine“ festgelegt ist, kann man Webparts nicht via Graph API exportieren. Das gilt auch nicht nur für Veeam.

Da seit Anfang des Jahres 2023 die Änderung der Site-Eigenschaft durch einen SharePoint-Administrator verboten ist, muss man das Globaler Admin selber übernehmen.

Lösung

1. Zuerst die notwendigen Rechte prüfen oder notfalls vergeben. Dazu öffnet man das klassische (!) SharePoint AdminCenter als „Globaler Admin“ und die Einstellungen-Seite zu SharePoint:

https://SITENAME-admin.sharepoint.com/_layouts/15/online/TenantSettings.aspx

2. Im Abschnitt „Benutzerdefiniertes Skript“ stellt man die (Radio-)Auswahl auf:
Benutzern das Ausführen benutzerdefinierter Skripts auf persönlichen Websites gestatten
UND
Benutzern das Ausführen benutzerdefinierter Skripts auf Self-Service Creation-Websites gestatten

3. Dann braucht man eine SharePoint PowerShell-Verbindung:

# Prüfen obd as SharePoint Modul installiert ist
Get-Module -Name Microsoft.Online.SharePoint.PowerShell -ListAvailable

# Wenn nicht, SharePoint Modul installieren ("Als Admin")
Install-Module -Name Microsoft.Online.SharePoint.PowerShell

# Wenn doch, Update machen (sicher ist sicher)
Update-Module -Name Microsoft.Online.SharePoint.PowerShell

# Mit der SPO-Site Verbinden 
Connect-SPOService -Url https://SITENAME-admin.sharepoint.com 

4. In dieser verbundenen Shell führt man dann aus:

Set-SPOSite https://SITENAME.sharepoint.com -DenyAddAndCustomizePages 0

Die Änderung dauert dann gerne mal 1-2 Tage, also am besten nicht sofort wieder versuchen sondern eine Weile warten.

Veeam: Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 [0x8004231f].

Veeam gibt diese Warnung in einem Backup-Job aus:

Failed to prepare guest for hot backup. Details: VSSControl: -2147467259 Backup job failed.
Cannot create a shadow copy of the volumes containing writer's data.
VSS asynchronous operation is not completed. Operation: [Shadow copies commit]. Code: [0x8004231f].  

Lösung

Der Fehlercode 0x8004231f steht für „VSS_E_INSUFFICIENT_STORAGE“ oder auch „nicht genügend Speicherplatz für die Schattenkopie“. Die Festplatte ist voll.

Schattenspeicherplatz wird für die Systemwiederherstellungspunkte von Veeam Backup & Recovery verwendet, wenn „Appication Image Aware Processing“ eingeschaltet ist (was auch empfohne ist).

Der Fehler tritt auf wenn die Festplatte tatsächlich voll ist. Das kann zum Beispiel ungewollt passieren, wenn man der 100Mbyte großen Windows „EFI-Systempartition“ oder der (möglicherweise eingerichteten) „Widerherstellungspartition“ einen Laufwerksbuchstaben gegeben hat. Naturgemäß haben diese Partitionen praktisch keinen freien Speicherplatz. „Voll“ bedeutet hier, „nicht genug Platz für eine Volumenschattenkopie“. Bei Maschinen mit viel Arbeitsspeicherbedarf, zum Beispiel ERP-Systeme oder SQL-Server, kann das plötzlich sehr viel sein. Wir haben einen SQL-Server VSS Dump „mal eben“ 20Gbyte schreiben sehen.

Veeam Job Fail [Error Unhandled exception was thrown during licensing process]

Jeden Tag laufen eine Menge Backup-Jobs. Einer nicht – oder besser, einige Maschinen darin nicht. Der Fehler im Veeam Backup & Replication Protokoll lautet:

[Error Unhandled exception was thrown during licensing process]

Die Lizenzierung wurde natürlich geprüft und alle Hosts und vCenter waren mit korrkten Lizenen ausgestatte. Es wurden auch keine Instanzen separat lizenziert oder ähnliches.

Lösung

Es stellte sich heraus, dass selbiges kein Lizenzproblem ist. Der genutzte vCenter-Server war einfach nicht erreichbar (502 nach Neustart). Der selbe Fehler tritt auch auf, wenn man das Passwort des Benutzers, der für die Verbindung mit VMware vCenter verwendet wird, ändert.

Als der vCenter wieder da war (respektive das Kennwort angepasst), läuft auch alles wieder einwandfrei.

Veeam „Active snapshots limit reached for datastore“ bei Pending VMs

Letzten hatten wir einen „Fehler“ bei einem Sicherungsjob, der mehrere brandneue Proxy- und Repository-Server verwendete. Kein anderer Job verwendete die neuen Komponenten.

Trotzdem verarbeitete Veeam nur 4 VMs gleichzeitig; alle anderen hatten den Status „Pending“. Aber die Meldung war ergänzt um diese hilfreiche Aussage:

Resource not ready: Active snapshots limit reached for datastore

Nach kurzer Untersuchung fanden wir heraus, dass sich alle VMs auf einem VVOL befanden. Ein VVOL wird scheinbar wie ein einziges VMFS behandelt und das per-datastore Limit angewendet.

Lösung

Glücklicherweise gibt es eine einfache Lösung für diese Einschränkung. Man kann einen Registrierungsschlüssel auf dem VBR-Server (VBR, nicht Proxy!) erstellen, um das Limit aktiver Snapshots pro Datenspeicher zu erhöhen:

HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication

MaxSnapshotsPerDatastore   REG_DWORD   <Anzahl (dezimal)>