18.12.2019

10490

Meinung gefragt: Backups auf NAS

Hallo zusammen,

ich wollte mal fragen wie ihr zum Thema Backups auf einem NAS (Synology, Qnap, ...) steht. Bisher hatten wir einen Server dafür abgestellt, aber dieser hat nun so viele Jahre auf dem Buckel, dass ein weiterer Betrieb einfach nicht mehr vertretbar ist. Das Sicherungsziel bot bislang SSH, SMB und iSCSI an für die verschiedenen Bedürfnisse. Das soll nach Möglichkeit auch so bleiben. Nun bieten die NAS heutzutage sowas auch an und nun stellt sich die Frage, ob es sinnvoll und sicher ist das im Unternehmen zu nutzen.

Gruß aus Köln

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 526776

Url: https://administrator.de/contentid/526776

Ausgedruckt am: 23.11.2024 um 01:11 Uhr

31 Kommentare

Neuester Kommentar

Hallo,

kommt darauf an.
An ein NAS ein TAPE Drive zu hängen ist sicher nicht einfach und bei mir läuft auf dem Backupserver eine zentrale Sicherungssoftware drauf.
Ich konfiguriere nicht pro Server einen eigenständigen Task.

Hi,
grundsätzlich ist ein "echtes" NAS auch nichts weiter als ein ganz ordinärer Servercomputer. Seine Hard- und Software ist nach 10 Jahren genauso alt und "unvertretbar", wie die eines "echten" Servers. Insofern würde ich das nicht in den Vergleich stellen.
Sicherer wird es allein durch die Verwendung eines "echten" NAS nicht. Aber so ein NAS ist für Backup ganz praktisch, weil es nicht selten für genau solche Anwendungszwecke spezialisiert ist.

E.

Und wenn man das NAS dann noch nachts auf ein anderes NAS spiegelt dann macht es die Backups auch recht sicher !

Sowas noch mit einem "Server" zu machen ist heute wirklich nicht mehr ganz "State of the art"...

Moin,

wir sichern alle Daten aller Server per Veeam zuerst auf das NAS und erstellen im Anschluß eine Kopie auf Tape. Das Tape-Laufwerk hängt am Veeam-Server (Wir müssen Monatssicherungen für 10 Jahre aufbewahren).
Unser NAS (Synology RS815+) hat ca. 10TB Speicherplatz. Das reicht für unsere Bedürfnisse. Du kannst die Teile aber mit zusätzlichen Modulen erweitern, sollte das nicht ausreichen. Angebunden ist das Ganze mit 4x1GBit. Die inkrementellen Sicherungen sind meist in ca. 20min durch (~30GB).

Gruß

Looser

Hallo.

Als Sicherungs-Ziel ist so ein NAS, wie schon geschrieben, sehr praktisch.

Haben bei unseren Standorten auch immer ein NAS als Sicherungs-Instanz in der Kette.

Mit Veeam lassen sich durch die Option "Backup Copy Job" prima die VM auf so ein Gerät kontinuierlich sichern.

Das macht in jedem Fall Sinn, bevor man anfängt eine kleine Server-Kaskade zu errichten für eben genau diesen Zweck.

Gruß
Radiogugu

Zitat von @Looser27:

[...] Angebunden ist das Ganze mit 4x1GBit. Die inkrementellen Sicherungen sind meist in ca. 20min durch (~30GB).

Gruß

Looser

Kleine Frage am Rande: Hast du es mal mit 1*1Gbit versucht? Ich habe mich mal aus einem anderen Grund mit dem Syno Support rumschlagen dürfen und dort wurde behauptet, die Appliance mag das nicht, wenn alle 4 Ports im gleichen Netz hängen. Aber vielleicht hatte der Supporter auch nur nen schlechten Tag. Jedenfalls habe ich mal ausführlich alle Ethernet Varianten Speed und Stabilitätsmäßig durchgetestet. Ergebnis: Mehr als einen Port braucht man nicht. Man hat keinerlei Speed Vorteil und muss sich auch nicht mit irgendwelchen seltsamen DNS/Interface Settings rumschlagen. Ich sicher so ca. 90GB in 50min. Auf 10G brauche ich 40min. Bottleneck ist da einfach VEEAM selbst.

Hallo,

bei der Beantwortung der Frage muß man wohl 2 Aufgaben trennen:

1. Wenn du eine zentral Verwaltete Backup-Lösung (-Software) - zB: Veeam, Backup Exec - einsetzt, brauchst du einen Rechner (Server), auf dem diese Software mit ihrer Management-Funktion und der Datenbank läuft. Das muß in der Regel ei klassischer Rechner (Server) sein. Auf den NAS-Geräten kann man diese Backup-Lösungen in der Regel nicht installieren.

2. Zur Datenablage braucht ein Backup-System ein Storage. Warum soll das nicht ein NAS sein? Die sind heutzutage genauso gut wie ein klassischer Server mit internen Festplatten (und meistens besser scalierbar).

Ich nutze einen Server für Veeam, an dem über iSCSI ein NAS als Backup-Storage angebunden ist. Ein 2. NAS in einem anderen Brandabschnitt dient als 2. Stufe des Backups.

Jürgen

Kleine Frage am Rande: Hast du es mal mit 1*1Gbit versucht?

Nein. Ich habe sofort ein Team aus den 4 NICs gebildet und den Switch entsprechend konfiguriert. Läuft reibungslos.
Der hängt damit jeweils mit 2x1GBit an je einem Core.
Genau wie die anderen Server auch an jedem Core hängen. Somit wäre ein Core-Ausfall während der Sicherung kein Problem.

Zitat von @Looser27:

Kleine Frage am Rande: Hast du es mal mit 1*1Gbit versucht?

Ah ok. Dachte aus Performance Gründen.

Kommt halt wie so oft darauf an.
Wir haben einen dedizierten Backupserver am laufen. Darauf läuft dann Veeam B&R. Der Backupserver ist per SAS direkt mit dem zentralen SAN-Storage verbunden. An einem 2. SAS-Controller hängt dann die LTO5-Tape Library.
Damit schaffen wir einerseits über 400 MB/s bei Sicherung vom SAN und die Tape Library bekommt anschließend auch Ihren konstanten Datenstrom von ca. 125 MB/s.
Und auf 5 Jahre gerechnet sind die Kosten für den Backupserver auch vernachlässigbar. Da sehe ich keinen wirklichen Kostenvorteil zum Einsatz eines NAS von QNAP/Synology als Backupziel. Bekommt man überhaupt ein Qnap/Synology mit 5 Jahren NBD-Support!?

nutze eine Synology DS414 (4 Platten) mit Raid5 als primäres Backupziel (einfach nur ne Datei vom Backupexec in nen SMB share) und repliziere das Backup auf nen Glacier bei AWS als "doppelten Boden" und verwerfe dort jeweils das älteste von 5 Backups. Damit ersparen wir uns ein LTO Wechsler... bzw. ohne Wechsler muß irgendjemand Bänder tauschen und das wird immer mal wieder vergessen.

Die Festplatten von der Synology muß man gelegentlich mal lifecyceln, aber von Hitachi gibts ne 4 TB Enterprise Edition mit 7 Jahren Garantie, deshalb passiert das eher selten, aber ne fünfte Ersatz-HD liegt im Regal falls doch mal was ist.

Zitat von @GrueneSosseMitSpeck:
... verwerfe dort jeweils das älteste von 5 Backups. Damit ersparen wir uns ein LTO Wechsler... bzw. ohne Wechsler muß irgendjemand Bänder tauschen und das wird immer mal wieder vergessen.

Kommt halt immer auf das Backupkonzept bzw. die Anforderungen an. Wenn Euch 5 Backupsätze ausreichen ist das ja ok. Wir haben die Anforderung, dass wir jede Datei für 365 Tage taggenau wieder herstellen können. Wir kommen damit insgesamt auf 13 Monatsbandsätze á 5 Bänder = 65 LTO5-Bänder. Dazu kommen dann noch die Bänder für die tägliche B2D2T-Sicherung.
Und ja, Backup braucht Manpower!

Zahlt sich aber auch aus. Hatten noch nie ein Problem, was wir nicht dank unseres Backup lösen konnten!
Und wenn ich teilweise lese, wie vielen Firmen Ihre Daten inkl. kompletten Backup verschlüsselt wurde... Kann bei Tape nicht so einfach passieren.

365 Tage ?? Wow. Das höre ich so auch zum ersten Mal. 97TB nur an Tapes :D Wie viele passen denn zeitgleich in eure Tape Libary?

Zitat von @Ex0r2k16:

365 Tage ?? Wow. Das höre ich so auch zum ersten Mal. 97TB nur an Tapes :D Wie viele passen denn zeitgleich in eure Tape Libary?

Na ja,
die 365 Tage beziehen sich nur auf Fileserver.

Bei Datenbanken macht das ja auch irgendwie keinen echten Sinn.
Und die letzten 30 Tage liegen ja ohnehin direkt auf dem Backupserver. Damit sind weit über 90% aller Restores eh abgedeckt. Wir hatten schon diverse Fälle bei denen sich die lange Vorhaltedauer ausgezahlt hat.
Ist ein 16'er Tape-Autoloader. Effektiv bleiben 15 Slots frei, da in einem Slot das Cleaning-Tape sitzt. Und es sind fast alle Tapes im externen Bankschließfach. Einmal im Monat wird dann jeweils ein Monatssatz wieder getauscht. Der Platz in der Library reicht aus um die jeweilige Tages- und Monatssicherung gleichzeitig vorzuhalten.

Ich würde es auf Festplatten sichern. Weil wenn ein nas im System ist und das System befallen wir ist meistens der nas auch befallen

Natürlich erstellst du extra eine Freigabe für den User Backup, den du nur bei veeam im Backup Ziel einträgst.

Sobald du diese Freigabe direkt in Windows mountest hast du natürlich verloren.

Ich sichere die Daten folgendermaßen:
Daily Prio 1 und Prio 2 auf EMC bzw. Dell DataDomain per Snapshot vom Storage Unity 300 in der Nacht
Daraus wird dann „weekly - monthly- yearly“ erstellt, diese verbleiben auf der DataDomain und werden nächtlich zusätzlich per CopyJob auf ein QNAP NAS in einen separaten Brandabschnitt transferiert.
Das Ganze erfolgt soweit über eine Veeam-VM in einem VMware-Cluster mit 3 Hosts.
„weekly - monthly -yearly“ wird wöchentlich (5 Wochen vorgehalten) und monatlich für ein Jahr auf Tape geschrieben und im Bankschließfach aufgehoben. Die Jahresbänder werden in einem anderen Schließfach für 10 Jahre aufgehoben.

Zusätzlich existiert ein dedizierter Veeam-Proxy (separater Server), der halbstündliche crashkonsistente Snapshots aller wichtiger VMs anlegt und diese auf eigenen Festplatten im Hardware-Server für 72 Stunden vorhält.

Transaktionprotokolle der SQL-Server sichere ich alle 15 Minuten mit IPERIUS Backup auf RDX-Laufwerke.

"Ich würde es auf Festplatten sichern. Weil wenn ein nas im System ist und das System befallen wir ist meistens der nas auch befallen"

Vorausgesetzt, dass nicht PC und Server/NAS gleichzeitig Sicherheitslücken besitzen, braucht man das eigentlich nicht. Wenn zB auf dem PC ein SMB oder FTP Server läuft und man mit einem Login ohne Schreibrechte arbeitet. Auf die Art kann das NAS mit diesem Login alle PCs sichern und die PCs wiederum besitzen keinen Login vom NAS. Das NAS kann man dann natürlich immer noch zusätzlich sichern zB mit einem NAS an einem anderen Standort, das vom lokalen NAS auch nur einen Account mit Leserechten kennt. Allerdings schützt das nicht vor menschlichem Versagen (zB falsche Konfiguration) oder falls der Admin seine jeweiligen Zugänge nicht sauber trennt. Da wären externe HDDs oder Tapes nach wie vor die beste Option.

Zitat von @marcgutt:
Allerdings schützt das nicht vor menschlichem Versagen (zB falsche Konfiguration) oder falls der Admin seine jeweiligen Zugänge nicht sauber trennt. Da wären externe HDDs oder Tapes nach wie vor die beste Option.

Leider zeigen die aktuellen Vorfälle um Emotet, dass hier offenbar einiges im Argen liegt. Sei es aus mangelnder Kompetenz/Sorglosigkeit diverser Admins oder weil Emotet bzw. die Macher dahinter es doch irgendwie schaffen an die Credentials des Backup-Storage heranzukommen.
Eine Verschlüsselung von Servern/Clients im Netzwerk ist sicherlich extrem ärgerlich, wenn aber auch die Backups des Unternehmens verschlüsselt wurden, kann so etwas schnell die Existenz des ganzen Unternehmens bedrohen.
Von daher ist ein regelmäßiges Offline-Backup m.E. einfach unerläßlich.

Moin,

Ich finde es auf der einen Seite schon interessant, aber andererseits auch schon sehr bedenklich, wie hier Backups erzeugt werden.

Als erstes sollte man sich überlegen, wozu Backups gemacht werden, diese dienen nur dazu im Falle der Fälle Daten retten zu können.
Diese Daten können ein Unternehmen in vielen Fällen vor dem "Aus" retten.
Wenn in eine Firma eingebrochen und die Hardware gestohlen wird, so denkt sich der Einbrecher doch nicht "ach bin ich mal freundlich und lass eine Kopie der Daten vor Ort", nein dann ist alles was nicht Off-Side ist unwiederbringlich weg.
Auch wird ein Feuer nicht einen Bogen um die Daten machen.

Das führt dazu, dass man sich wirklich Gedanken über ein Backupkonstrukt machen sollte und es nicht nur lapidar nebenbei laufen lässt.

Als erstes hilft es hierzu eine lokales Backup auf ein schnelles Medium zu schreiben. Hier kann dir ein NAS sehr gute Dienste leisten.
ABER im Falle von Crypto-Trojanern und des erwähnten Einbrechers/ Brandes ist häufig auch dies betroffen.

Da hilft nur eine Offline Kopie, welche an einen anderen Ort gelagert wird.

Backup to Tape ist daher immer noch sehr aktuell ( Tapes sind langlebig, relativ robust und einfach zu handeln), aber das Tapemanagement ist immer wieder ein Prozess, welcher in Firmen scheitert.
Nicht nur der Wechsel wird vergessen, auch habe ich bereits erlebt, dass die Bänder in einem Brandschutztresor gelagert wurden. So weit so gut, dieser Tresor verfügte jedoch über ein elektronisches Schließsystem, welches über den Magnetismus auf die Bänder Einfluss nahm und diese somit löschte.

Hier kommt dann wieder die Cloud ins Spiel, aber selbst wenn man seine Daten einem ausländischen Konzern anvertrauen möchte ( Man bedenke den Cloud-Act, nach diesem ist egal wo die Daten gespeichert werden, es interessiert nur der Sitz des betreibenden Unternehmens ) sind hier immer wieder viele versteckte Kosten enthalten. Amazon lässt sich die PUT und GET bezahlen, drosselt die Geschwindigkeit und im Glacier kommen bei einem Restore enorme Kosten auf das eh schon gebeutelte Unternehmen zum.

Da ich mich über eine lange Zeit mit dem Thema beschäftigt habe fand ich per Zufall das Produkt "DOCKS by PingUs" .
Die Daten liegen bei einem deutschen Unternehmen, die Rechenzentren sind in Deutschland und die Kosten sind mehr als einfach gehalten ( keinerlei Berechnung des Traffic etc, sondern nur das wirklich genutzte Volumen).
Ein Backup hierher wird On-Prem dedupliziert, somit sing schon mal das Datenvolumen. Ein initiales Backup geschieht, auf Wunsch, über ein Mobiles S3-Storage, um die Datenleitung zu schonen.
Auch werden die Daten bereits auf Nutzerseite verschlüsselt und der Anbieter hat keinen Zugriff auf diesen Key, somit können diese selbst wenn sie wollen nichts mit den Daten anfangen.

Das Produkt ist kompatibel zu Veeam, nativ mit QNap und Synology anbindbar und im Bereich Veritas Backup Exec sogar zertifiziert ( Support via Veritas ).

Heißt kurz gesagt, bitte nehmt nicht nur ein NAS.

Bei Fragen kannst du dich gerne melden.

Liebe Grüße
Markus

So weit so gut, dieser Tresor verfügte jedoch über ein elektronisches Schließsystem, welches über den Magnetismus auf die Bänder Einfluss nahm und diese somit löschte.

Für solche Anforderungen gibt es feuerfeste Tresore mit DIS Zulassung. Diese sind explizit zur Lagerung von Disketten und anderen "Magnet"-Medien.

Gruß

Looser

Jupp, man dadurch bleibt halt nur weiter die Fehlerquelle Mensch.
Hab leider schon zu oft erlebt, dass das Tapemanagement nicht funktioniert

Gruß
Markus

Wir haben 2 physikalische HP Proliant als Hyper-V Hosts am laufen auf denen jeweils bereits Redundanzen eingerichtet sind:
Raid 10 (4x 600GB SAS in Server A & 4x 500 GB SAS in Server B), Replikation für Fileserver VM, 2x DC mit AD, DNS, DHCP, 2x Exchange mit DAG.

An den Servern hängt jeweils auch eine externe USB Platte für das abendliche WBADMIN dran (Altbestände aus früherer Backup-Lösung).

Weiterhin haben wir eine Synology (RS815+) mit 4x 4TB im Raid 5 mit weiteren Diensten - u.A. Backup Ziel und Active Backup für Business und Hyper Backup:
a) Die Exchange, SQL und Fileserver sichern über Sicherungsoperator Account (PST Export, SQL Export, und Robocopy) auf ein Zugriffsziel auf der NAS auf dem kein anderer User (auch nicht Domänen Admins) Zugriff hat. (täglich)

b) Ein WBADMIN Hyper-V Backup (über Script mit Versionskontrolle sowie Logging und Email Benachrichtigung) für die VMs läuft am Wochenende und Speichert auf die Synology Rackstation in einer separaten Freigabe. (wöchentlich)

c) Weiterhin holt sich die Synology über Active Backup für Business nochmalig die Daten des Fileservers, des SQL Exports sowie die Exchange PSTs. (wöchentlich 2x)

d) Neu seit einigen Monaten ist die Möglichkeit von Active Business Backup dass neben VMware auch Windows Server 2016 Hyper-V VMs direkt gesichert werden können. (noch nicht implementiert weil unsere Hyper-V Hosts noch Windows 2012 sind)

Als weitere Stufe haben wir nochmal eine weitere Synology Diskstation in einem Nebengebäude in einem separaten VLAN, welche sich einmal die Woche automatisch einschaltet um die Daten der Rackstation zu sichern und danach automatisch heruntergefahren wird. (wöchentlich)

Ich finde die NAS Lösung bequem und ich bin der Meinung, dass durch die leicht implementierbaren unterschiedlichen (redundanten) Sicherungswege die Sicherheit des Backups erhöht wird. Zugegeben ist ein Plus bei uns auch das Nebengebäude in dem man innerhalb des Intranets und VLAN ein weiteres Backup-Ziel vorhalten kann.

Von daher ist ein regelmäßiges Offline-Backup m.E. einfach unerläßlich.

In beiden Fällen ist menschliches Versagen möglich. Entweder man geht schlampig mit seinen Zugangsdaten um oder beim Erstellen / der Lagerung der Tapes werden Fehler gemacht.

Ich favorisiere das zweite Off-site NAS mit 2-Faktor-Authentifizierung, da es ohne mein Zutun läuft. Dort kann ich mich mangels Fernwartung auch nur lokal anmelden und es ist nicht durchgehend an, sondern nur bei der Abholung des Backups (wie lange hängt natürlich von Upload ab). Ich erhalte beim Abschluss eine E-Mail und dann schaltet es sich ab. Dank Verschlüsselung ist ein Diebstahl auch irrelevant.

Die Kosten sind hier extNAS + extUSV + Beteiligung am Internetanschluss eines Dritten (inkl Strom) + Router zur Kaskadierung vom bestehenden Netz. Mit diesem wurde auch vertraglich vereinbart die Bandbreite nur teilweise zu nutzen. Die USV setze ich ein, damit ich nicht nach jedem Stromausfall hin muss um die Laufwerke zu entschlüsseln.

Von diesem Disaster-Backup kann man übrigens noch ein Disaster-Disaster-Backup per Google G-Suite Drive erstellen. Das sind max 50 € pro Monat für unendlich Speicherplatz (inoffiziell geht's auch mit einem Account = 10 €). Und wer Angst hat, dass das NAS inkl den Zugangsdaten des Drive ausgelesen wird, der kann das Backup-Verzeichnis einfach mit einem weiteren G-Suite Account teilen und der kopiert es regelmäßig in ein eigenes Unterverzeichnis. Dann hätte man sogar ein Disaster-Disaster-Disaster-Backup ^^

Allerdings ist so ein Konzept natürlich nur mit einem Upload realisierbar, der zur Datenmenge passt. Das alleine macht für viele Standorte Tapes alternativlos. Willkommen im Internet-Entwicklungsland.

Willkommen im Internet-Entwicklungsland.

Toll, dass Du Deine Daten mit der ganzen Welt und sämtlichen Geheimdiensten via Cloud teilen willst.
Es gibt allerdings Branchen, in denen dürfen die Daten das Haus nicht verlassen.

Zitat von @Looser27:

Willkommen im Internet-Entwicklungsland.

Toll, dass Du Deine Daten mit der ganzen Welt und sämtlichen Geheimdiensten via Cloud teilen willst.
Es gibt allerdings Branchen, in denen dürfen die Daten das Haus nicht verlassen.

Warum ist es eigentlich so beliebt sich einen Punkt rauszuziehen und daraus ein globales Totschlagargument zu basteln. Ich sagte nicht ohne Grund "Disaster-Disaster-Backup". Wer die Cloud meiden möchte, arbeitet eben nur mit extNAS1, extNAS2, usw.

Aber trotzdem mal zu deinem Argument. Natürlich verschlüsselt man die Daten lokal, bevor man sie in die Cloud schiebt. Laut WikiLeaks Dokumenten gilt AES 256 als sicher:
https://crypto.stackexchange.com/a/53499/41422

Wenn nun einzelne Branchen trotzdem eine Speicherung in der Cloud verbieten, dann macht man das eben nicht.

Toll, dass Du Deine Daten mit der ganzen Welt und sämtlichen Geheimdiensten via Cloud teilen willst.
Es gibt allerdings Branchen, in denen dürfen die Daten das Haus nicht verlassen.

Naja, es gibt auch DSGVO-Konforme Anbieter, welche selbst von Behörden genutzt werden dürfen.
Google, Amazon und Microsoft gehören nicht dazu ;)

Warum ist es eigentlich so beliebt sich einen Punkt rauszuziehen und daraus ein globales Totschlagargument zu basteln.

Weil viele auf die sinnfreien Aussagen von MS und anderen Anbietern reinfallen und sich denken die Rechenzentren stehen ja in Deutschland, dann passt das schon.

Zitat von @Moko-Slc:

Warum ist es eigentlich so beliebt sich einen Punkt rauszuziehen und daraus ein globales Totschlagargument zu basteln.

Weil viele auf die sinnfreien Aussagen von MS und anderen Anbietern reinfallen und sich denken die Rechenzentren stehen ja in Deutschland, dann passt das schon.

Ich kenne jetzt nicht die Aussagen dieser Anbieter, aber selbst die DSGVO enthält ja Ausnahmen wie §34 3a):

Die Benachrichtigung der betroffenen Person gemäß Absatz 1 ist nicht erforderlich, wenn ... Daten für alle Personen, die nicht zum Zugang zu den personenbezogenen Daten befugt sind, unzugänglich gemacht werden, etwa durch Verschlüsselung,

Ich halte es rechtlich außerdem noch für offen ob verschlüsselte personenbezogene Daten überhaupt noch personenbezogene Daten darstellen:
https://www.voelker-gruppe.com/stuttgart/verschluesselte_daten_personenb ...

Und wenn sie das nicht sind, kann man sie speichern wo man will. Meine Cloud steht übrigens bei Hetzner (also Deutschland), da mir das Thema auch zu heiß ist.

Aber für mich klingt das eigentlich einleuchtend, denn sonst müsste man wirklich jeden erfassen, der auch nur in die Nähe eines Rechners oder einer Datenverbindung kommt und jeden über jeden informieren: "Hallo Herr Müller, danke für ihre E-Mail. Leider habe ich diese mobil abgerufen und damit kommen bis zu 10.000 Personen im Umkreis von Mobilfunkmast X-719 in Frage, die diese Mail entschlüsseln konnten." Oder (per Einschreiben versteht sich): "Erst nach dem Versand meiner E-Mail-Antwort stellte ich fest, dass ein Rechenknoten mangels Double-Paid-Vereinbarung mit der Telekom den günstigeren interkontinentalen Routing-Weg über die USA wählte. Es ist daher nicht auzuschließen, dass ausländische Unternehmen oder Behörden die verschlüsselte E-Mail und damit Ihre E-Mail-Adresse kopiert haben und irgendwann entschlüsseln".

Eine Verschlüsselung, die laut dem aktuellen Stand der Technik als sicher gilt, muss einfach ausreichen, sonst kann man auch wieder die Schreibmaschine rausholen. Aber wir sind mittlerweile deutlich vom Thema abgekommen ;)

Danke für die Antworten. Da hatte ich einiges zu lesen.

Die Backups laufen und liefen nicht nur auf dem einen Backupserver. Das Heraustragen in einen anderen Brandabschnitt/Tresor ist hier zum Glück kein Thema. Wir stellen derzeit vieles um und so kam auch Proxmox als Virtualisierung zum Einsatz, was wir sehr schätzen. Die Proxmoxe sichern eben auf dem Server. Jeder hat sein eigenes Konto dort, dass man nicht gleich alles hat, wenn man auf einem Proxmox gelandet ist. Es ging jetzt eben nur darum einen neuen Backupserver anzuschaffen. Dennoch interessant wie lesen wie andere das machen. Man muss ja immer über den Tellerrand hinaus schauen.

Danke, eure Meinungen waren interessant und hilfreich.