Partnerfy wurde gegründet, um Unternehmen ganzheitliche Software- und digitale Marketinglösungen zu liefern — der zuverlässige Technologiepartner von Agenturen und Marken.
Lust, mit uns die Zukunft zu coden?
"Gibt es Backups?" — die Antwort muss ja sein, das reicht aber nicht. Die eigentliche Frage lautet: "Können wir tatsächlich wiederherstellen, in welcher Zeit, mit welchem Datenverlust?" Stündliche verschlüsselte Backups, drei Kopien auf zwei Medien mit einem Off-Site, unveränderlicher WORM-Speicher, vierteljährliche echte Restore-Übungen und definierte RPO/RTO-Ziele — nur das zählt am schlechten Tag.
Ein ungetesteter Restore ist kein Backup — er ist eine Hoffnung. Wir verkaufen keine Hoffnung; wir liefern messbare Wiederherstellungszeiten und nachgewiesene Restore-Protokolle.
Beim Ausfall des Primärsystems übernimmt das Sekundärsystem automatisch — durch echte Übungen verifiziert.
Erste harte Wahrheit: Die überwiegende Mehrheit der Backups wird nie getestet. Der Cron läuft jede Nacht, das Log meldet "OK", das Monitoring zeigt Grün — aber beim echten Restore sind die Dateien korrupt, der Entschlüsselungsschlüssel fehlt oder die Schema-Version ist inkompatibel. Ein Backup ist erst dann ein Backup, wenn es wiederhergestellt wurde; davor ist es Hoffnung. Bei jedem Kunden ist eine vollständige Restore-Übung mindestens vierteljährlich verpflichtend und wir dokumentieren das Ergebnis.
Zweites Problem: Vieles, was "Backup" genannt wird, ist in Wirklichkeit ein Snapshot auf dem Produktionsserver selbst. Eine Kopie, die dieselbe Disk teilt, vom selben Account beschrieben werden kann und im selben Feuer brennen würde — das ist kein Backup, sondern ein zweiter Name für dieselben Daten. Bei Hardwaredefekt, Ransomware oder versehentlich gelöschter Tabelle verschwindet dieses "Backup" mit den Produktivdaten. Ein echtes Backup muss auf einem getrennten System, unter getrennter Identität und idealerweise in getrennter Geografie liegen.
Drittes Problem: keine Off-Site-Kopie. Ein Backup, das in einem einzigen Rechenzentrum oder einer einzigen Cloud-Region liegt, wird unerreichbar, sobald diese Region ausfällt, von einer Naturkatastrophe getroffen oder der Account gesperrt wird. AWS kann eine ganze Region abschalten, Microsoft einen Account binnen Stunden sperren, ein Rechenzentrumbrand tagelang andauern — in solchen Szenarien ist die Off-Site-Kopie das einzige Bollwerk zwischen Geschäftskontinuität und Insolvenz. Die "1" in der 3-2-1-Regel ist nicht verhandelbar.
Viertes Problem: unverschlüsselte Backups. Eine Backup-Datei ist eine vollständige Kopie Ihrer Produktionsdatenbank — also jeder Kundendatensatz, jede Kreditkartenspur, jeder Passwort-Hash und jede interne E-Mail liegt in einem einzigen tar.gz. Wird diese Datei gestohlen, ist eine Verletzung eine Verletzung; DSGVO und KVKK verzeihen Ihnen nicht, nur weil es ein Backup war. Alle Backups müssen sowohl at-rest (AES-256) als auch in-transit (TLS 1.3) verschlüsselt sein, mit Schlüsseln in einem vom Backup-System getrennten KMS — sonst ist das Backup eine Angriffsfläche, keine Verteidigung.
Fünftes Problem: keine Immutability. Moderne Ransomware verschlüsselt nicht nur die Produktion — der Angreifer landet zuerst im Backup-System, löscht oder invalidiert die letzten drei Monate Backups und verschlüsselt erst dann die Produktion. Wenn Backup-Accounts dasselbe Verzeichnis, dasselbe VPN und dasselbe SSO wie die Produktion nutzen, findet Ransomware sie. Lösung: WORM-Speicher (Write-once-read-many), S3 Object Lock, ein Veeam Hardened Repository, eine Air-Gapped-Offline-Kopie — kurz: eine Schicht, in der Löschen selbst mit Admin-Credentials mathematisch unmöglich ist.
Eine Restore-Zeitleiste, eine Ransomware-Bereinigungssimulation und ein RPO/RTO-Vergleichspanel — sie machen Entscheidungen nach dem Katastrophenfall im Voraus messbar.
Stündliche Snapshots + tägliche Vollbackups + wöchentliche Konsolidierung + monatliches Archiv. Restore-Punkt sekundengenau wählbar.
Verschlüsselte Daten → Restore aus unveränderlichem Backup → saubere Daten mit grünem Haken markiert.
Sehen Sie den Unterschied zwischen "kein Backup" und unserer Architektur auf einen Blick.
Eine Stunde Datenverlust = Hunderte Bestellungen, Tausende Lagerbewegungen, gestörte Zahlungsabstimmung.
Die Wiederherstellung eines einzelnen Mandanten darf nie die ganze Tabelle erfordern.
Patientenakten müssen jahrelang revisionssicher gespeichert werden; jeder Verlust ist DSGVO/HIPAA-Verletzung.
BaFin-, BDDK-, SEC-Datensätze müssen jahrelang unverändert vorgehalten werden.
Verlorene Design-Dateien, Video-Projekte oder Code-Repos bedeuten Einzelgespräche mit jedem Kunden.
Petabyte Rohmaterial, nicht reproduzierbares historisches Material — dedizierte Architektur nötig.
Geht eine einzige Controller-Konfiguration verloren, steht die Linie stundenlang still.
Diplome, Transkripte und Anwesenheit müssen lückenlos, dauerhaft und revisionssicher sein.
Von der Strategie bis zum Runbook, zehn Schichten in einem Paket — keine ausgelassen, keine aufgebläht.
Business-Impact-Analyse, Asset-Inventar, RPO/RTO-Matrix, vertraglich fixierte Ziele.
Physische oder virtuelle Backup-Appliance vor Ort für schnellste Restores.
Asynchrone/synchrone Replikation in ein anderes Rechenzentrum oder eine Cloud-Region.
Lifecycle-gesteuerte, kostenoptimierte Backups auf S3, Blob, GCS.
S3 Object Lock, Wasabi Compliance, Veeam Hardened — die unlöschbare Schicht.
PostgreSQL WAL, MySQL Binlog, MongoDB Oplog, MSSQL Transaction Log.
VSS, fsfreeze, Pre-/Post-Hooks für schreibkonsistente Disk-Images.
Periodische Sandbox-Restores + Integritätsprüfung + Bericht.
Schritt für Schritt — wer macht was, wer freigibt, wer protokolliert.
Trigger → Isolation → Forensik → Restore → forensisch sauberes Image.
Welches System ist wie kritisch, akzeptabler Datenverlust und Wiederherstellungsfenster; vollständige Business-Impact-Analyse.
Drei Kopien, zwei Medien, ein Off-Site; Immutability + Verschlüsselung + Zugriffsmodell dokumentiert.
On-Site-Appliance + Cloud-Account + Netz-Isolation + Monitoring + Alerting in Betrieb.
Stündlicher/täglicher/wöchentlicher/monatlicher Zyklus; AES-256 at-rest, TLS in-transit, separate Keys im KMS.
Restores mit echten Szenarien; gemessene RPO/RTO werden mit Vertragszielen verglichen; Abweichungen behoben.
Backup-Erfolg, Storage-Trend, Restore-Zeit auf Dashboards; monatlicher Bericht + jährliche Architekturrevision.
Wir verkaufen kein einzelnes Werkzeug für sich. Wir entwerfen Ihre Architektur, begründen, welches Werkzeug in welche Schicht gehört, und zeigen die Gesamtbetriebskosten transparent.
Shop mit 250k SKU Freitag 03:14 verschlüsselt; Voll-Restore aus unveränderlicher Wasabi-Kopie in 38 Minuten — kein Bestellverlust.
Entwickler löschte eine Produktionstabelle; PostgreSQL PITR lieferte einen vollständig konsistenten Restore in 4 Minuten.
Klinik bestand ihr 7-Jahres-PHI-Audit; mathematischer Nachweis der Vollständigkeit im unveränderlichen Archiv.
Notebook eines Senior-Designers gestohlen; 2TB Kundendaten waren stündlich per Restic off-site.
Roh-Archiv eines Senders getiered; aktives S3 + Glacier Deep Archive senkten Jahreskosten um 63%.
AWS eu-central-1 Outage; automatisches DNS- + DB-Failover nach eu-west-1 in 11 Minuten, keine Kunden-Downtime.
Nein, ein Snapshot allein ist kein Backup. Ein Snapshot ist eine "Momentaufnahme" einer Festplatte oder eines Volumes, und die überwiegende Mehrheit lebt auf demselben Speichersystem — oft sogar auf derselben Disk — wie die Produktivdaten. Wenn die Produktivdaten verloren gehen, ist der Snapshot also auch weg. Hardwaredefekte, Speicherkorruption, Ransomware oder Adminfehler treffen den Snapshot mit. Snapshots sind eine hervorragende erste Schicht für sehr schnelle Restores (Sekunden zurück in der Zeit), aber für ein echtes Backup muss der Snapshot auf ein separates System, unter einer separaten Identität, idealerweise in einer separaten Geografie kopiert werden. In unserer Architektur ist ein Snapshot immer eine Stufe — gefolgt von einem Off-Site-Backup, einem unveränderlichen Archiv und einer Disaster-Recovery-Replikation.
Die 3-2-1-Regel ist die in der Branche bewährte Mindest-Backup-Strategie: drei (3) Kopien der Daten, auf zwei (2) verschiedenen Medientypen, mit einer (1) Kopie off-site. Eine der drei Kopien ist die Produktion selbst, zwei sind Backups — wenn ein Backup korrupt ist, ist das andere noch da. Zwei Medientypen schützen vor systemischen Ausfällen einer einzelnen Technologie (z.B. alle SSDs fallen wegen eines Firmware-Bugs aus): Disk + Tape, Disk + Object-Storage, NAS + Cloud. Die Off-Site-Kopie schützt vor Feuer, Flut, Diebstahl, Regional-Outage oder Account-Sperre — eine Kopie im selben Gebäude oder derselben Stadt zählt nicht als off-site. Die moderne Erweiterung lautet "3-2-1-1-0": eine Kopie muss unveränderlich sein (1) und Restore-Tests müssen null (0) Fehler zeigen.
Nur bei korrekt entworfenem Setup. Moderne Ransomware sitzt wochenlang im Netzwerk bevor sie die Produktion verschlüsselt — sie entdeckt das Backup-System und löscht oder invalidiert bestehende Backups, danach verschlüsselt sie die Produktion und es bleibt nichts zum Wiederherstellen. Backup-Accounts müssen daher unabhängig vom Produktions-Directory, vom Produktions-SSO und sogar vom Produktions-Netzwerk sein. Die Lösung ist WORM-Speicher (Write-Once-Read-Many): S3 Object Lock im Compliance-Modus, Wasabi Compliance, Veeam Hardened Repository, Air-Gapped Tape. Auf diesen Schichten ist Löschen selbst mit Admin-Rechten mathematisch unmöglich — die Daten sind für die Aufbewahrungsdauer "eingefroren". Jeder unserer Kunden hat mindestens eine WORM-Schicht, und das Ransomware-Recovery-Playbook wird per Übung verifiziert.
Mindestens vierteljährlich, monatlich bei kritischen Systemen, in regulierten Umgebungen wöchentlich automatisiert. Ein Test-Restore ist der einzige Beweis, dass Ihre Backup-Architektur tatsächlich funktioniert — ein grünes "OK" im Log reicht nicht. Eine vollständige Übung umfasst Restore in eine isolierte Sandbox, Hochfahren der Anwendung, Prüfung der Datenbankintegrität und Checksummen, Vergleich der gemessenen RPO/RTO mit den vertraglichen Zielen. Automatisierte Tests erzeugen nach jedem Backup ein "Instant Recovery"-Image, führen intelligente Scans aus und melden die Ergebnisse. Wir führen für jeden Kunden sowohl wöchentliche automatisierte Verifikation als auch vierteljährliche manuelle Übungen durch; Ergebnisse werden in einem signierten Bericht gespeichert — nützlich für Audits, Versicherungen und Vertragsverlängerungen.
Nicht bei korrektem Design, extrem teuer ohne. Kosten haben drei Hauptachsen: Speicher (pro GB pro Monat), Egress (Download beim Restore), API-Aufrufe (pro Dateioperation berechnet). Der naive Ansatz "alles täglich voll auf S3" kann jährlich zehntausende Dollar kosten. Der richtige Ansatz ist getiered: letzte 14 Tage S3 Standard, letzte 90 Tage S3 Standard-IA, letztes Jahr S3 Glacier Instant, älter Glacier Deep Archive — gleiche Daten, Kosten unterscheiden sich um Faktor 10-20. Mit Lifecycle-Policies, Kompression, Deduplikation und Incremental-Forever-Strategie liegen die Cloud-Backup-Kosten eines typischen Kunden im niedrigen dreistelligen Dollar-Bereich pro Monat. Ihre Restore-Muster zu kennen ist der Schlüssel zur Dimensionierung; Glacier Deep ist wunderbar bei einem Restore pro Jahr und ruinös bei fünf Restores pro Tag.
RPO (Recovery Point Objective) beantwortet "wie viel Datenverlust akzeptieren wir", RTO (Recovery Time Objective) "wie schnell müssen wir wieder online sein". Beide Zahlen ergeben sich aus einer Business-Impact-Analyse: Wenn das System eine Stunde ausfällt, ein Tag Daten verloren geht — wie hoch ist der reale Schaden bei Umsatz, Kundenvertrauen und Regulatorik? Im E-Commerce zwingt der stündliche Umsatz das RTO meist in Minutenbereiche; ein bestellannehmendes System mit 1 Std. RTO ist viel zu lang. Ein internes CRM kann gut mit 8 Std. RTO leben. Für RPO: wie viele Minuten Geschäftsaktivität können Sie verlieren? Stündliche Snapshots setzen RPO auf 60 Min., Transaction-Log-Replikation auf Sekunden. Diese Ziele sind vertraglich fixiert und werden bei jeder Übung neu gemessen — sie sind Geschäftsentscheidungen, keine willkürlichen Zahlen.
Ja, unsere Architektur ist vollständig mit DSGVO, KVKK, ISO 27001 Anhang A.12.3, SOC 2 CC9 und PCI-DSS 9.5/12.10 ausgerichtet. Das heißt: alle Backups verschlüsselt at-rest (AES-256) und in-transit (TLS 1.3); Schlüssel in einem KMS (AWS KMS, Azure Key Vault, HSM), getrennt vom Backup-System autorisiert; Aufbewahrungsfristen entsprechen gesetzlichen Anforderungen mit nachweisbarer Löschung bei Überschreitung; Verfahren für "Recht auf Vergessen" mit Backup-Suche und selektiver Anonymisierung; wählbarer Datenstandort (EU/Türkei); jeder Zugriff, jeder Restore und jede Konfigurationsänderung in einem unveränderlichen Audit-Log. Das Audit-Readiness-Paket liefert Architekturdiagramme, Policy-Dokumente, RACI-Matrix und die letzten Übungsberichte — jede Frage eines Prüfers hat eine vorbereitete Antwort.
Ja, wir übernehmen Ihre bestehende Veeam- (oder Rubrik-, Cohesity-, Commvault-, Acronis-)Installation as-is; Ihre Lizenz bleibt, die Hardware bleibt. In der ersten Woche führen wir ein vollständiges Audit durch: aktuelle Backup-Erfolgsquote, letzte Restore-Daten, Retention-Policy, Immutability-Status, Zugriffsmodell, Schlüsselverwaltung, Monitoring und Alarme — alles dokumentiert, Risiken als rot/gelb/grün gemeldet. In den folgenden 30 Tagen wird die Architektur überprüft und bei Bedarf werden neue Schichten im Brücken-Modus hinzugefügt (alt + neu parallel); es werden keine Daten verschoben, sondern neue Backup-Ziele ergänzt. Am Ende des dritten Monats läuft eine vollständige Restore-Übung und die Baseline wird abgenommen. Wir haben zertifizierte Veeam-VMCE- und Rubrik-RCSA-Ingenieure im Haus; ein Anbieterwechsel ist nicht nötig — wir bringen korrekte Konfiguration und operative Disziplin.
In einem kostenlosen 30-minütigen Gespräch prüfen wir gemeinsam Ihren Backup-Status: RPO/RTO-Ziele, Immutability-Lücken, letztes Test-Restore-Datum und konkrete Schritte für die nächsten 90 Tage — als schriftlicher Bericht.
