Leistung 05 · Betreuung und Störungsbehebung, Tag und Nacht
Managed Services für Ihre Server und Anwendungen, aus Straßburg, Tag und Nacht.
Durchgehende Überwachung, Sicherheitsupdates, geprüfte Backups und menschliche Rufbereitschaft bei Störungen. Wenn nachts etwas ausfällt, werden wir geweckt.
Erstgespräch kostenlos.
Was Managed Services abdecken und was nicht
Wir betreiben Server und Anwendungen: Ihre eigenen oder die von uns geschriebenen. Keine Büroarbeitsplätze, keine Drucker, keine Bürosoftware. Den vertraglichen Rahmen regelt der Anhang unserer AGB zur Aufrechterhaltung des Betriebs.
- 01
Geschäftskritische Anwendungen. Ein Ausfall kostet viel Umsatz oder schadet dem Ruf. Sie brauchen eine gemessene Verfügbarkeit, keine erhoffte.
- 02
Teams ohne Rufbereitschaft. Nachts und am Wochenende haben Sie niemanden. Wir übernehmen die Wache, Ihre Entwickler bleiben beim Produkt.
- 03
Anforderungen an die Betriebskontinuität. Sie müssen einen Notfall-Wiederherstellungsplan, Backups und Wiederherstellungszeiten nachweisen. Wir richten sie ein, testen sie und liefern Ihnen die Messwerte dazu.
Für wen es nicht passt
Die Verwaltung eines Bestands an Arbeitsplatzrechnern, Bürolizenzen oder des Firmen-E-Mail-Systems: Dafür ist ein Dienstleister für Arbeitsplatz-IT besser geeignet.
„Zuverlässig“ lässt sich messen.
Mehr dazu im Blog: was „zuverlässig“ wirklich bedeutet.
Eine Anwendung, auf die es ankommt, darf nicht vom Glück abhängen. Wir betreiben sie durchgehend: Sonden, die sie einmal pro Minute testen, Sicherheitsupdates, die Maschine für Maschine nachverfolgt werden, zentral gesammelte und ausgewertete Protokolle und menschliche Rufbereitschaft bei Störungen. Wenn etwas aus dem Ruder läuft, antwortet ein Mensch, kein Anrufbeantworter.
Gemeinsam legen wir konkrete Ziele fest: die akzeptable Wiederanlaufzeit, den tolerierbaren Datenverlust, die Reaktions- und Wiederherstellungszeit je nach Kritikalität und einen Notfall-Wiederherstellungsplan, den wir testen, statt ihn zu versprechen.
Jeden Monat sagt Ihnen ein Bericht, was passiert ist, was wir getan haben und was noch zu erledigen ist. Die Zahlen auf dieser Seite stammen daraus: Es sind unsere Instrumente, nicht unsere Argumente.
Im Betrieb abgedeckt
- Durchgehende Überwachung, eine Messung pro Minute
- Sicherheitsupdates, auf jeder Maschine nachverfolgt
- Jede Nacht Backups, automatisch geprüft
- Zentral gesammelte Protokolle, für die Analyse aufbewahrt
- Menschliche Rufbereitschaft bei kritischen Störungen
- Monatlicher Bericht: Störungen, Verfügbarkeit, Maßnahmen
Drei Stufen, ein Ziel
Drei Stufen, im Angebot im Detail beschrieben. Sie wählen für jede Anwendung die Stufe, die ihrer Kritikalität entspricht; der monatliche Bericht ist in allen drei enthalten.
- 01
Essential: Überwachung, Backups und Sicherheitsupdates zu Geschäftszeiten. Die Grundlage: Nichts bleibt unbemerkt.
- 02
Standard: Überwachung Tag und Nacht, Alarme, die jemanden wecken, vertraglich zugesagte Reaktions- und Wiederherstellungszeiten.
- 03
Premium: Verstärkte Rufbereitschaft, getesteter Notfall-Wiederherstellungsplan, kurze Wiederanlaufzeiten und Vorrang bei Einsätzen.
Wer nachts antwortet
Ein Alarm weckt einen von uns beiden, der Ihre Anwendung kennt, weil er sie geschrieben hat oder hostet. Kein Callcenter, kein Ticket, das auf den Morgen wartet.
Unsere Messwerte im Detail
Jede Zahl nennt ihr Instrument, ihr Messfenster und ihre Berechnungsweise. So können Sie die Messung wiederholen oder uns widerlegen. Die Fallstudien zu unserer Infrastruktur und zu unserer Auslieferungskette beschreiben, was sie erzeugt.
- Ihre Anwendungläuft auf unseren Servern, die wir selbst administrieren
- Zugangspunktder Datenverkehr ist verschlüsselt, alles andere wird blockiert
- Abgeschottetes Netzkein Rechner ist von außen direkt erreichbar
- Server in Frankreichdrei getrennte Rechenzentren, in Straßburg, Roubaix und Gravelines
- Verschlüsseltes Backupeine Kopie jede Nacht, geprüft, an einem zweiten Standort
- Überwachung Tag und Nachtwir sehen die Störung vor Ihnen, und wir werden geweckt
| Messwert | Wert | Instrument | Methode | Datum |
|---|---|---|---|---|
| Durchschnittliche Verfügbarkeit der Websites, die wir hosten | 99,89 % | Interne Überwachung mit Uptime Kuma (HTTP-Sonden, eine Messung pro Minute) | Durchschnitt der 9 HTTP-Sonden der öffentlichen Websites auf dedizierten Maschinen, über die gleitenden 30 Tage bis zum 4. September 2026, 23:45 Uhr UTC. Berechnung: Zeit im Zustand „verfügbar“ im Verhältnis zur beobachteten Zeit, je Sonde, dann ungewichteter Durchschnitt. | 5. Sept. 2026 |
| Verfügbarkeit unserer eigenen Website, www.sanfytech.com | 99,91 % | Interne Überwachung mit Uptime Kuma (HTTP-Sonde, eine Messung pro Minute) | Öffentliche HTTP-Sonde von www.sanfytech.com, gleitende 30 Tage bis zum 4. September 2026, 23:45 Uhr UTC: 43.143 Messungen „verfügbar“ gegenüber 37 Messungen „nicht verfügbar“. | 5. Sept. 2026 |
| Durchschnittliche Verfügbarkeit über 90 Tage der Websites, die seit mindestens 90 Tagen überwacht werden | 99,74 % | Interne Überwachung mit Uptime Kuma (HTTP-Sonden, eine Messung pro Minute) | Durchschnitt der 5 Website-Sonden, deren Verlauf tatsächlich 90 Tage abdeckt, gleitendes Zeitfenster bis zum 4. September 2026, 23:45 Uhr UTC. Später in Betrieb genommene Websites sind ausgeschlossen: Wir ergänzen ein kurzes Zeitfenster nicht durch eine Hochrechnung. | 5. Sept. 2026 |
| Aktive Überwachungssonden im Bestand | 58 | Interne Überwachung mit Uptime Kuma | Bestandsaufnahme der Monitore am 5. September 2026: 62 aktive Monitore, davon 4 reine Anzeigegruppen, also 58 echte Sonden (HTTP, Ping, TCP-Port und Backup-Kontrollen). | 5. Sept. 2026 |
| Maschinen, deren Logs in Echtzeit an das SIEM gehen | 40 | SIEM Wazuh (interne Verwaltungskonsole) | Erfassung der Agenten beim Wazuh-Manager am 5. September 2026: 40 Agenten, alle im Zustand „aktiv“, also 39 administrierte Maschinen plus der SIEM-Server selbst. | 5. Sept. 2026 |
| Maschinen, deren Sicherheitsupdates verfolgt werden | 39 | Patch-Verwaltung PatchMon (interne Konsole) | Bestandsaufnahme der registrierten Hosts am 5. September 2026: 39 Hosts, alle im Zustand „aktiv“ und alle mit einem Bericht in den vorangegangenen 24 Stunden. | 5. Sept. 2026 |
| Häufigkeit der Backups der gehosteten Maschinen | 1 pro Tag | Backup-Planer des Virtualisierungsclusters | Tägliche Aufgabe um 20 Uhr UTC (22 Uhr Pariser Zeit) für alle Gäste des Clusters, im Snapshot-Modus. Drei Maschinen mit besonderem Profil haben eine eigene wöchentliche Aufgabe. Stand der geltenden Konfiguration am 5. September 2026. | 5. Sept. 2026 |
| Erfolgreich abgeschlossene Backups in den letzten sieben Tagen | 322 von 322 | Dedizierter Backup-Server (Proxmox Backup Server) | Aufgabenprotokoll des Backup-Servers zwischen dem 28. August 2026, 23:48 Uhr UTC, und dem 4. September 2026, 23:48 Uhr UTC: 322 Backup-Aufgaben, 322 ohne Fehler abgeschlossen, keine fehlgeschlagen. | 5. Sept. 2026 |
| Integritätsprüfungen der Backups in den letzten sieben Tagen | 7 von 7 | Dedizierter Backup-Server (Proxmox Backup Server) | Ein Backup, das nie geprüft wurde, ist kein Backup. Tägliche Prüfaufgabe um 4 Uhr UTC für noch nie kontrollierte Snapshots, ergänzt durch eine monatliche vollständige Prüfung aller Snapshots, die älter als 30 Tage sind. Im Zeitfenster vom 28. August 2026 bis 4. September 2026: 7 Prüfungen, alle ohne Fehler. | 5. Sept. 2026 |
| Aufbewahrte Wiederherstellungstiefe für die gehosteten Maschinen | 7 tägliche, 2 wöchentliche, 1 monatliches | Dedizierter Backup-Server (Proxmox Backup Server) | Am 5. September 2026 geltende Löschregeln für den Speicherbereich des gehosteten Bestands: 7 tägliche, 2 wöchentliche und 1 monatliches Backup werden aufbewahrt. Für Infrastrukturmaschinen außerhalb des Clusters sind es bis zu 30 tägliche, 12 wöchentliche und 12 monatliche. | 5. Sept. 2026 |
| Getrennte Standorte mit einer Kopie der Backups | 2 Standorte | Dedizierter Backup-Server und sein Spiegel außerhalb des Hosting-Anbieters | Primäre Kopie auf einem dedizierten Backup-Server in einem vierten Rechenzentrum, in Deutschland; zweite Kopie jede Nacht (5:30 und 6 Uhr UTC) auf einen Spiegel in Frankreich außerhalb des Hosting-Anbieters kopiert. Der Spiegel holt die Daten selbst ab: Der primäre Server hat keinerlei Zugang zu ihm. Zustand geprüft am 5. September 2026, 1,4 TB repliziert. | 5. Sept. 2026 |
| Verschlüsselung der Backups | An der Quelle verschlüsselt | Speicherkonfiguration des Virtualisierungsclusters | Die Daten werden auf dem Ursprungsrechner verschlüsselt, bevor sie übertragen werden: Der Backup-Server erhält nur verschlüsselte Blöcke. Vorhandensein eines hinterlegten Schlüssels auf dem Speicherbereich des gehosteten Bestands, geprüft am 5. September 2026 (Fingerabdruck erfasst, Schlüssel nie offengelegt). | 5. Sept. 2026 |
| OVHcloud-Rechenzentren, in denen unsere Hypervisoren stehen | 3 in Frankreich | Öffentliche OVHcloud-API (Datenblatt der dedizierten Server) | Feld „datacenter“ der drei dedizierten Server, abgefragt am 5. September 2026: sbg3 (Straßburg), rbx8 (Roubaix), gra2 (Gravelines). Drei getrennte Standorte, alle in Frankreich. | 5. Sept. 2026 |
| Rechenzentrum, in dem der Backup-Server steht | 1 in Deutschland | Öffentliche OVHcloud-API (Datenblatt des dedizierten Backup-Servers) | Feld „datacenter“ des Backup-Servers, abgefragt am 5. September 2026: lim3 (Limburg, Deutschland). Standort getrennt von den Hypervisoren, Daten innerhalb der Europäischen Union. | 5. Sept. 2026 |
| Auf dem Cluster gehostete virtuelle Maschinen und Container | 37 | Virtualisierungscluster (Bestand der Gäste) | Erfassung am 5. September 2026: 37 aktive Gäste, davon 29 Container und 8 virtuelle Maschinen, verteilt auf die drei Hypervisoren. | 5. Sept. 2026 |
Durchschnittliche Verfügbarkeit der Websites, die wir hosten99,89 %
- Instrument
- Interne Überwachung mit Uptime Kuma (HTTP-Sonden, eine Messung pro Minute)
- Methode
- Durchschnitt der 9 HTTP-Sonden der öffentlichen Websites auf dedizierten Maschinen, über die gleitenden 30 Tage bis zum 4. September 2026, 23:45 Uhr UTC. Berechnung: Zeit im Zustand „verfügbar“ im Verhältnis zur beobachteten Zeit, je Sonde, dann ungewichteter Durchschnitt.
- Datum
- 5. September 2026
Verfügbarkeit unserer eigenen Website, www.sanfytech.com99,91 %
- Instrument
- Interne Überwachung mit Uptime Kuma (HTTP-Sonde, eine Messung pro Minute)
- Methode
- Öffentliche HTTP-Sonde von www.sanfytech.com, gleitende 30 Tage bis zum 4. September 2026, 23:45 Uhr UTC: 43.143 Messungen „verfügbar“ gegenüber 37 Messungen „nicht verfügbar“.
- Datum
- 5. September 2026
Durchschnittliche Verfügbarkeit über 90 Tage der Websites, die seit mindestens 90 Tagen überwacht werden99,74 %
- Instrument
- Interne Überwachung mit Uptime Kuma (HTTP-Sonden, eine Messung pro Minute)
- Methode
- Durchschnitt der 5 Website-Sonden, deren Verlauf tatsächlich 90 Tage abdeckt, gleitendes Zeitfenster bis zum 4. September 2026, 23:45 Uhr UTC. Später in Betrieb genommene Websites sind ausgeschlossen: Wir ergänzen ein kurzes Zeitfenster nicht durch eine Hochrechnung.
- Datum
- 5. September 2026
Aktive Überwachungssonden im Bestand58
- Instrument
- Interne Überwachung mit Uptime Kuma
- Methode
- Bestandsaufnahme der Monitore am 5. September 2026: 62 aktive Monitore, davon 4 reine Anzeigegruppen, also 58 echte Sonden (HTTP, Ping, TCP-Port und Backup-Kontrollen).
- Datum
- 5. September 2026
Maschinen, deren Logs in Echtzeit an das SIEM gehen40
- Instrument
- SIEM Wazuh (interne Verwaltungskonsole)
- Methode
- Erfassung der Agenten beim Wazuh-Manager am 5. September 2026: 40 Agenten, alle im Zustand „aktiv“, also 39 administrierte Maschinen plus der SIEM-Server selbst.
- Datum
- 5. September 2026
Maschinen, deren Sicherheitsupdates verfolgt werden39
- Instrument
- Patch-Verwaltung PatchMon (interne Konsole)
- Methode
- Bestandsaufnahme der registrierten Hosts am 5. September 2026: 39 Hosts, alle im Zustand „aktiv“ und alle mit einem Bericht in den vorangegangenen 24 Stunden.
- Datum
- 5. September 2026
Häufigkeit der Backups der gehosteten Maschinen1 pro Tag
- Instrument
- Backup-Planer des Virtualisierungsclusters
- Methode
- Tägliche Aufgabe um 20 Uhr UTC (22 Uhr Pariser Zeit) für alle Gäste des Clusters, im Snapshot-Modus. Drei Maschinen mit besonderem Profil haben eine eigene wöchentliche Aufgabe. Stand der geltenden Konfiguration am 5. September 2026.
- Datum
- 5. September 2026
Erfolgreich abgeschlossene Backups in den letzten sieben Tagen322 von 322
- Instrument
- Dedizierter Backup-Server (Proxmox Backup Server)
- Methode
- Aufgabenprotokoll des Backup-Servers zwischen dem 28. August 2026, 23:48 Uhr UTC, und dem 4. September 2026, 23:48 Uhr UTC: 322 Backup-Aufgaben, 322 ohne Fehler abgeschlossen, keine fehlgeschlagen.
- Datum
- 5. September 2026
Integritätsprüfungen der Backups in den letzten sieben Tagen7 von 7
- Instrument
- Dedizierter Backup-Server (Proxmox Backup Server)
- Methode
- Ein Backup, das nie geprüft wurde, ist kein Backup. Tägliche Prüfaufgabe um 4 Uhr UTC für noch nie kontrollierte Snapshots, ergänzt durch eine monatliche vollständige Prüfung aller Snapshots, die älter als 30 Tage sind. Im Zeitfenster vom 28. August 2026 bis 4. September 2026: 7 Prüfungen, alle ohne Fehler.
- Datum
- 5. September 2026
Aufbewahrte Wiederherstellungstiefe für die gehosteten Maschinen7 tägliche, 2 wöchentliche, 1 monatliches
- Instrument
- Dedizierter Backup-Server (Proxmox Backup Server)
- Methode
- Am 5. September 2026 geltende Löschregeln für den Speicherbereich des gehosteten Bestands: 7 tägliche, 2 wöchentliche und 1 monatliches Backup werden aufbewahrt. Für Infrastrukturmaschinen außerhalb des Clusters sind es bis zu 30 tägliche, 12 wöchentliche und 12 monatliche.
- Datum
- 5. September 2026
Getrennte Standorte mit einer Kopie der Backups2 Standorte
- Instrument
- Dedizierter Backup-Server und sein Spiegel außerhalb des Hosting-Anbieters
- Methode
- Primäre Kopie auf einem dedizierten Backup-Server in einem vierten Rechenzentrum, in Deutschland; zweite Kopie jede Nacht (5:30 und 6 Uhr UTC) auf einen Spiegel in Frankreich außerhalb des Hosting-Anbieters kopiert. Der Spiegel holt die Daten selbst ab: Der primäre Server hat keinerlei Zugang zu ihm. Zustand geprüft am 5. September 2026, 1,4 TB repliziert.
- Datum
- 5. September 2026
Verschlüsselung der BackupsAn der Quelle verschlüsselt
- Instrument
- Speicherkonfiguration des Virtualisierungsclusters
- Methode
- Die Daten werden auf dem Ursprungsrechner verschlüsselt, bevor sie übertragen werden: Der Backup-Server erhält nur verschlüsselte Blöcke. Vorhandensein eines hinterlegten Schlüssels auf dem Speicherbereich des gehosteten Bestands, geprüft am 5. September 2026 (Fingerabdruck erfasst, Schlüssel nie offengelegt).
- Datum
- 5. September 2026
OVHcloud-Rechenzentren, in denen unsere Hypervisoren stehen3 in Frankreich
- Instrument
- Öffentliche OVHcloud-API (Datenblatt der dedizierten Server)
- Methode
- Feld „datacenter“ der drei dedizierten Server, abgefragt am 5. September 2026: sbg3 (Straßburg), rbx8 (Roubaix), gra2 (Gravelines). Drei getrennte Standorte, alle in Frankreich.
- Datum
- 5. September 2026
Rechenzentrum, in dem der Backup-Server steht1 in Deutschland
- Instrument
- Öffentliche OVHcloud-API (Datenblatt des dedizierten Backup-Servers)
- Methode
- Feld „datacenter“ des Backup-Servers, abgefragt am 5. September 2026: lim3 (Limburg, Deutschland). Standort getrennt von den Hypervisoren, Daten innerhalb der Europäischen Union.
- Datum
- 5. September 2026
Auf dem Cluster gehostete virtuelle Maschinen und Container37
- Instrument
- Virtualisierungscluster (Bestand der Gäste)
- Methode
- Erfassung am 5. September 2026: 37 aktive Gäste, davon 29 Container und 8 virtuelle Maschinen, verteilt auf die drei Hypervisoren.
- Datum
- 5. September 2026
Messwerte vom 5. September 2026.
Vor der nächsten Störung
Zur Vorbereitung im Blog: was ein Notfall-Wiederherstellungsplan wirklich enthält.
Was passiert, wenn um drei Uhr morgens ein Alarm eingeht?
Die Sonde benachrichtigt uns, einer von uns meldet sich an, stellt den Dienst wieder her und schreibt Ihnen, was passiert ist. Je nach gewählter Stufe ist die Reaktionszeit vertraglich zugesagt.
Was enthält der monatliche Bericht?
Die Störungen des Monats, die von den Sonden gemessene Verfügbarkeit, die eingespielten Sicherheitsupdates, die geprüften Backups und unsere Empfehlungen. Dieselben Zahlen wie die hier veröffentlichten.
Wie wähle ich die Stufe?
Nach der Kritikalität: was eine Stunde Ausfall kostet, und zu welcher Uhrzeit. Eine interne Anwendung, die tagsüber genutzt wird, ist oft mit Essential gut bedient; eine Website, die nachts Zahlungen annimmt, braucht Standard oder Premium. Wir entscheiden das mit Ihnen in der Konzeptphase.
Fristen, Angebote, Eigentum am Code, Vertragsende: Die Antworten finden Sie in den häufigen Fragen.
Auf Angebot. Richtpreise stehen auf der Preisseite, zusammen mit dem, was ein Budget beeinflusst.
Vor der nächsten Störung
Wer antwortet, wenn Ihre Anwendung ausfällt?
Beschreiben Sie uns, was Sie heute betreiben. Wir sagen Ihnen, was wir überwachen, was wir übernehmen und zu welchem Preis.
Antwort binnen 24 Stunden an Werktagen, von einem der beiden Gründer.