Veeam trennt im Scale-Out Backup Repository (SOBR) klar zwischen Performance Tier (schnelle lokale Blocks/ReFS/XFS für Restores) und Capacity Tier (Object Storage für die günstige, skalierbare Langzeit-Kopie). intercolo i3 Object Storage ist genau dieses Capacity Tier: S3-kompatibel, strong read-after-write, angesprochen über den Endpoint https://de-fra.i3storage.com in der Region de-fra. Sie schieben Backup-Chains als Objekte off-site, ohne Bandroboter, ohne zweites RZ und ohne die Egress-Überraschungen der US-Hyperscaler — bei 99,999999% Durability und Daten, die das RZ Frankfurt nie verlassen.
In der Veeam Backup & Replication Console: Backup Infrastructure → Backup Repositories → Add Repository → Object Storage. Als Typ wählen Sie NICHT den nativen S3/Amazon-Eintrag, sondern S3 Compatible — nur dieser erlaubt einen freien Service-Point.
Service point: https://de-fra.i3storage.com · Region: de-fra. TLS bleibt aktiv (Zertifikat ist gültig, kein Haken bei 'connect using untrusted certificate' nötig). Optional gateway server auf dem Proxy belassen, der die Offload-Last trägt.
Add → Access key + Secret key aus Ihrem intercolo API-Key-Paar. Der Zugriff läuft ausschließlich über diese SigV4-Schlüssel — kein Passwort-Login. Für Mandantentrennung legen Sie pro Kunde ein eigenes Key-Paar und einen eigenen Bucket an.
Bucket aus der Liste auswählen (oder vorab per aws-cli/rclone anlegen) und einen Ordner als 'folder' für diese Backups setzen. Ein Ordner = ein SOBR-Capacity-Extent; mehrere Jobs können sich einen Bucket teilen, solange jeder Extent seinen eigenen Ordner hat.
Öffnen Sie Ihr SOBR → Reiter Capacity Tier → 'Extend scale-out backup repository capacity with object storage' und wählen das neue Repository. Move- oder Copy-Mode plus Offload-Fenster festlegen — fertig. Ab jetzt landet die Off-Site-Kopie automatisch in Frankfurt.
Path-Style: https://de-fra.i3storage.com/veeam-prod · Virtual-hosted: https://veeam-prod.de-fra.i3storage.com. Beide funktionieren; Veeam nutzt intern Virtual-hosted.
Wichtig für die Erwartungshaltung: i3 Object Storage bietet KEINE storage-seitige Immutability (kein Object Lock/WORM, keine Versionierung). Aktivieren Sie im SOBR daher NICHT die Option 'Make recent backups immutable' — dieser Haken bleibt leer. Der Sicherheitsgewinn liegt hier in der räumlichen Trennung: Dies ist Ihre off-site 2. Kopie nach 3-2-1 (3 Kopien, 2 Medien, 1 extern). Wer echte Unveränderlichkeit gegen Ransomware braucht, kombiniert dieses Ziel mit einem lokalen Hardened Linux Repository (XFS, immutable flag) als Performance Tier — die harte Kopie bleibt lokal, die günstige Distanz-Kopie liegt hier in Frankfurt. Ergänzend schützt Veeam-seitige Client-Verschlüsselung (siehe unten) die Objekte zusätzlich.
Der teuerste Fehler beim Cloud-Backup ist der ungetestete Restore. Bei US-Hyperscalern bestraft jeder Rückholtest und jede echte Wiederherstellung mit Egress-Gebühren — Admins testen deshalb zu selten. Hier ist pro gebuchtem TB Storage 1 TB Egress inklusive. Sie fahren SureBackup-Jobs, holen einzelne VMs oder Dateien aus dem Capacity Tier zurück und validieren Ihre Recovery-Kette, ohne dass die nächste Rechnung explodiert. Zusätzlicher Traffic wird transparent mit +3,99 €/TB abgerechnet — planbar statt überraschend. Das ist nicht 'kostenlos', sondern kalkulierbar: Sie wissen vor dem Test, was er kostet.
Das Standard-Ziel für aktive Backup-Chains, die aus dem lokalen Performance Tier ins Object Storage ausgelagert werden. Voll durchsuchbar, granularer Restore einzelner Objekte, strong read-after-write — ideal für die tägliche off-site Kopie.
Für sehr alte, selten benötigte Restore-Punkte jenseits Ihrer operativen Aufbewahrung. Als S3-kompatibles Ziel dient i3 als kostengünstiger Ablageort für Langzeit-GFS-Ketten — ein Tier, eine Rechnung, kein Cold-Retrieval-Aufschlag.
Verschiebt Backup-Daten nach Ablauf des operativen Fensters vom Performance- ins Capacity Tier und gibt lokalen Speicher frei. Lokal bleiben nur Metadaten. Maximale Ersparnis auf teurem Primärspeicher.
Kopiert jeden neuen Restore-Punkt sofort zusätzlich ins Object Storage — die lokale Kopie bleibt für schnelle Restores erhalten. Genau das 3-2-1-Muster: schnelle lokale Kopie plus off-site Distanz-Kopie in Frankfurt.
| intercolo i3 | Wasabi | Backblaze B2 | |
|---|---|---|---|
| Standort / Datenhoheit | RZ Frankfurt, 100% DE, DSGVO/AVV | EU-Region wählbar, US-Konzern | EU-Region wählbar, US-Konzern |
| Endpoint | https://de-fra.i3storage.com (de-fra) | s3.eu-central-*.wasabisys.com | s3.eu-central-*.backblazeb2.com |
| Egress-Modell | 1 TB inkl./TB, dann +3,99 €/TB | 'kostenlos' bis Speichermenge, dann gedrosselt | 1 TB frei/Tag, dann pro GB |
| Ab-Preis Storage | 2,49 €/TB | Listenpreis US$/TB | Listenpreis US$/TB |
| Storage-Immutability | Nein — 2. Kopie im 3-2-1 | Object Lock verfügbar | Object Lock verfügbar |
| Support / Ansprechpartner | Direkt, deutsch, RZ-Team | Ticket, EN | Ticket, EN |
| Strom | 100% Ökostrom | variiert | variiert |
i3 verschlüsselt nicht at-rest — und genau deshalb sollten Sie die Kontrolle selbst behalten: Aktivieren Sie im Veeam-Job unter Storage → Advanced → Storage die Backup-Verschlüsselung mit einem eigenen Passwort/Schlüssel. Veeam verschlüsselt die Blocks dann VOR dem Upload; im Object Storage liegen ausschließlich unlesbare Chiffrate, der Schlüssel verlässt nie Ihre Infrastruktur. Das ist der saubere Weg für sensible Daten: Transport ist per TLS gesichert, der Inhalt durch Ihren Schlüssel — kein Provider, auch wir nicht, kann die Backups lesen. Notieren Sie das Passwort sicher, ohne Schlüssel kein Restore.
Für Managed-Service-Provider ist saubere Mandantentrennung Pflicht. Legen Sie pro Endkunde ein eigenes API-Key-Paar (Access/Secret) und einen eigenen Bucket an und verknüpfen jeden als separates Capacity-Repository in der zuständigen SOBR-Konfiguration bzw. im Cloud Connect Tenant. Kompromittierte oder ausscheidende Kunden rotieren Sie isoliert, ohne andere Mandanten anzufassen. So bleibt jede Backup-Kette organisatorisch getrennt, abrechenbar pro Bucket und nachvollziehbar zuordenbar — die Grundlage für sauber auditierbare MSP-Prozesse auf Organisationsebene.
Ihre Langzeit-Wiederherstellungspunkte entstehen über die Veeam-GFS-Richtlinie (wöchentliche, monatliche, jährliche Vollsicherungen) — nicht über den Storage. Das Capacity/Archive Tier speichert diese Ketten nur günstig ab; wie viele Punkte wie lange erhalten bleiben, legen Sie in Veeam fest.
Die Lebensdauer jedes Objekts richtet sich allein nach Ihrer Veeam-Job- und SOBR-Retention: Veeam schreibt neue Restore-Punkte und räumt abgelaufene wieder ab. Da es keine storage-seitige Sperre gibt, ist die Aufbewahrung exakt das, was Sie in Veeam konfigurieren — prüfen Sie diese Richtlinien bewusst.
Trennen Sie kurzlebige operative Backups und langlebige GFS-Ketten in eigene Buckets bzw. Capacity-Repositories mit je eigenem SigV4-Schlüsselpaar. So bleiben Aufbewahrungsklassen sauber isoliert und der Wirkungsradius eines kompromittierten Schlüssels klein.
Unsere Erfahrung spricht für sich: Wir haben bereits erfolgreich Migrationen mit mehreren Petabyte an Daten und über 500 Millionen Dateien durchgeführt.