Zentrales baremetal recovery von developer workstations auf dedizierten Backupserver

ThomasH

Experte
Thread Starter
Mitglied seit
06.10.2014
Beiträge
208
Hallo,

habe hier schon im Softwareforum gesucht, aber fand dort nichts äquivalentes und poste es lieber hier im Workstation Forum.

Ehe ich nun anfange eine eigene Lösung zu skripten, hat evtl. jemand etwas brauchbares im Einsatz:

Gesucht ist ein
zentrales baremetal recovery für developer workstations auf dedizierten Backupserver, die cryptolocker fest ist. D.h., keine Fileshares etc.
Gerne auch etwas, was Geld kostet, nur keine Abo-Modelle ;-).
Gesichert werden soll alles, am besten per VSS (inkrementelle Sicherung). Komprimierung muss nicht sein.
Ein nice to have, wäre ein nicht properitäres Sicherungsformat, was man im Notfall auf USB Disk spielen kann und mit WinPE direkt zurückladen kann.

Edit: Reine Windows Lösung brauche ich ..

Getestet habe ich Veeam Backup und Recovery Community Edition,
was leider auf einigen der zu sicherenden Workstation mehrfach mitten in der Sicherung in einem BSOD endetet.
Sieht man sich das dortige Supportforum an, dann scheint diese Lösung nicht ganz frei von Problemen zu sein. ;-)

Ein Restore habe ich damit garnicht erst getestet.

Falls jemand etwas im Einsatz hat, wäre ein Link ganz toll.

Danke vorab
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich könnte nicht wirklich was negatives zum Veeam Agent sagen, abgesehen das die LocalDB mit einigen Produkten nicht so ganz zusammenspielt.

Wenn dir Veeam nicht zusagt, würde ich mal einfach auf Urbackup verweisen. Die Gui usw wirkt etwas angestaubt, aber ansonsten deckt es deine Anforderungen gänzlich ab (keine Shares, vss, vhd als Containerformat, zentrales Management,..)
 
Wir nehmen hier Aomei zum Sichern der Windows Rechner auf ein SMB Share. Zurückspielen kann man das direkt aus Windows oder via Windows PE (USB Stick kann man direkt aus Aomei anlegen).

Gesichert wird auf einen OmniOS ZFS Server. Dessen Snaps sind Ransomware sicher. Läuft ultraschnell und ist richtig angenehm zum Handhaben.
 
Ich danke Euch.
UrBackup werde ich mir mal ansehen, da OpenSource.

Veeam hat mir von der GUI sehr gefallen, aber ein BlueScreenOfDeath beim Sichern des Clients geht mal garnicht. Sichere ich die gleiche Workstation mit wbadmin läuft das sauber durch.
Beim Testen habe ich übrigens mal den Veeam Server gewechselt, da der alte zu wenig Disk Space hatte. Danach geht auf den Clients nichts mehr. Man muss dann händisch auf den Clients die Registry säubern. Dort hat sich noch der alte Server verewigt. LocalDB ist auch so ein Ding. Habe da mal SQL mäßig mit getracet, was da abgeht. Teilweise CPU spitzen von 20% durch die sqlserver.exe wegen der ständigen Abfragen. Das Supportforum ist voll von Problemen. Einige Leute sichern damit ihre Cluster und Oracle DBs. OMG.
 
Da es keinen Protest gab bei "Sicherung auf SMB Share", werfe ich mal "drive snapshot" in den Raum. Ist wirklich winzig, kann auf einem normalen Windows-Install-USB-Stick mit gespeichert und gestartet werden ohne installation und kostet nicht die Welt. Kann Verschlüsseln, Snapshots, Differentiell und Inkrementell. Hat einen recht brauchbaren Paramatersatzsatz um das ganze per Komandozeile zu steuerm. Die Backups können direkt mit dem gleichen kleinen Programm als Laufwerk eingebunden werden. Nur zum Sichern braucht es die registrierte Fassung. Restore läuft auch mit der unregistrierten Version.

Ich benutze das um meine Workstations täglich voll zu sichern. Das ganze via Taskplaner, einem Backupaccount und einer kleinen Batch. Montags Full-Backup, den Rest der Woche Differenz-Sicherung. Das Zugriffsproblem löse ich dadurch das die Backups unter dem anderen User auf den Fileserver gehen. Der Fileserver selbst wird aber vom Backupserver via Rsync ziehend gesichert. So ist kein direkter Zugriff auf die Backups möglich. Etwas unhandlich beim Recover, aber passiert ja nicht oft.
 
Zuletzt bearbeitet:
bei den SMB Shares besteht immer das Problem, dass cryptolocker da ran kann.
 
Ein anderes Protokoll (NFS, ftp, ssh, iSCSI etc) ist nur ein vordergründiger Ausweg, muss man dann doch hoffen, dass die Ransomware das übersieht. Ein wirklicher Schutz ist das nicht. Prinzipiell muss man dafür sorgen, dass im Fall der Fälle der Datenstand vor dem Befall sicher erhalten bleibt und dass die Ransomware selbst mit Admin-Rechten da nicht dran kann. Ein Windows SMB Server und Windows Schattenkopien sind da weniger geeignet. Ein ZFS SMB Server z.B. mit einem stündlichen Snapshot für die letzten Tage und täglichen Snapshot im letzten Monat oder Jahr etc sorgt immer dafür dass man den Datenstand vor einem Befall hat und dass dieser von der Ransomware auch als Windows Administrator nicht verschlüsselt/gelöscht werden kann.
 
Cryptolocker kommt aber nur an die Shares ran, auf die es in dem Userkontext zugreifen kann, unter dem es läuft.
Wir machen auch die Backups auf SMB Shares die aus ZFS NAS liegen. Wir haben das so eingerichtet, das alle Active Directory User maximal Lesezugriff auf diese Shares bekommen. Schreiben darf ausschließlich ein lokaler User der auf dem NAS eingerichtet ist. Die Shares für das Backup sind als nicht browsable und mit access based share enum eingerichtet.
 
Hi katzenhai,

das ist auch mein Ansatz, allerdings sehe ich dort die Schwachstelle, dass die Credentials für den "lokalen Workstation User mit RW Rechten" irgendwo hinterlegt werden müssen.
Habe da schon Ansätze gesehen, wo es die Leute in eine Batch im Klartext hatten. Auch wenn man die Credentials per Powershell setzt und holt, ist mir das nicht ganz geheuer.

Ich wollte das so regeln, dass ich mir auf dem Client und auf dem Server automatisch jeden Tag ein neues Kennwort generieren lasse, so in der Art wie es bei MSAs im AD gemacht wird. Die Shares wollte ich als hidden Shares anlegen und auch kein Filesharing aktivieren. Allerdings alles Windows.
Allerdings soll mein Sicherungsserver nicht im AD Mitglied sein.

Wie machst Du es mit den Credentials?
 
Zuletzt bearbeitet:
Ich werfe mal NFS in den Raum - Als NFS exportiert sollte doch auch keine Ransomware / Cryptolocker an die Backups kommen und du musst dir keine Gedanken über Credentials machen die eventuell irgendwo im Klartext liegen könnten :wink:
 
So wie gea vorgeschlagen hat, auf ZFS ablegen, Snapshots anlegen (die können nicht befallen werden) und fertig->be happy, go drink some beer
 
Wie machst Du es mit den Credentials?
Veeam macht das für mich ;-)
Der eigentliche Backupprozess läuft dort im Kontext Local System. Nur dieser User hat Zugriff auf die Creditential und Konfigurationen. Standardmäßig kann selbst der lokale Administrator nicht auf Dateien oder die Registry von local System zugreifen.
Spätestens wenn ein Prozess von Veeam beendet wird sollte die Netzwerküberwachung Alarm schreien.
 
Veeam macht das für mich ;-)
Der eigentliche Backupprozess läuft dort im Kontext Local System. Nur dieser User hat Zugriff auf die Creditential und Konfigurationen. Standardmäßig kann selbst der lokale Administrator nicht auf Dateien oder die Registry von local System zugreifen.
Spätestens wenn ein Prozess von Veeam beendet wird sollte die Netzwerküberwachung Alarm schreien.

ja veeam erledigt das. Die Credentials werden beim win client dort in der local sql db abgelegt (ich hoffe mal verschlüsselt). Aber der veeamInstallerService hat ohnehin alle Rechte.
Das KW fürs veam login steht in der reg (keine Ahnung ob es im Klartext ist, ich habe eine andere "Lücke" genutzt, um in die SQL DB zu kommen). Du kommst via named pipe mit sqlcmd rein. Die ändern zwar den namen der named pipe bei jedem neustart, aber das kann man alles ermitteln.

- - - Updated - - -

@All
sorry Ich bin ein DAU. Habe das oben mal ergänzt. Das ganze ist ein reines Windows Netz (Außenstelle) und dort sind keine Admins, die UNIX Kenntnisse haben und auf den Sicherungsserver muss später auch noch eine Backuplösung für die Exchange365 Postfächer drauf, wo mir Veeam vorschwebt. Ein NAS soll da nicht auch noch hin ..
 
Ich werfe mal NFS in den Raum - Als NFS exportiert sollte doch auch keine Ransomware / Cryptolocker an die Backups kommen und du musst dir keine Gedanken über Credentials machen die eventuell irgendwo im Klartext liegen könnten :wink:

Dann muss er aber einen NFS Client installieren damit er sein Backup speichern kann. Ab dem Zeitpunkt ist es egal, schreiben kann ich auf smb und nfs Shares. Je nach Export muss ich mir wegen der Credentials dann tatsächlich keine Gedanken mehr machen, es darf dann eh jeder drauf schreiben ;)

- - - Updated - - -

@All
sorry Ich bin ein DAU. Habe das oben mal ergänzt. Das ganze ist ein reines Windows Netz (Außenstelle) und dort sind keine Admins, die UNIX Kenntnisse haben und auf den Sicherungsserver muss später auch noch eine Backuplösung für die Exchange365 Postfächer drauf, wo mir Veeam vorschwebt. Ein NAS soll da nicht auch noch hin ..

Gibt es einen speziellen Grund warum die Exchange Backups in einer Außenstelle liegen?
 
Dann muss er aber einen NFS Client installieren damit er sein Backup speichern kann. Ab dem Zeitpunkt ist es egal, schreiben kann ich auf smb und nfs Shares. Je nach Export muss ich mir wegen der Credentials dann tatsächlich keine Gedanken mehr machen, es darf dann eh jeder drauf schreiben ;)

- - - Updated - - -


Gibt es einen speziellen Grund warum die Exchange Backups in einer Außenstelle liegen?

Nein gibt es nicht. Ursprünglich wollte ich alles mal komplett mit Veeam auf einem Server machen.
 
Ich danke Euch.
UrBackup werde ich mir mal ansehen, da OpenSource.

Veeam hat mir von der GUI sehr gefallen, aber ein BlueScreenOfDeath beim Sichern des Clients geht mal garnicht. Sichere ich die gleiche Workstation mit wbadmin läuft das sauber durch.
Beim Testen habe ich übrigens mal den Veeam Server gewechselt, da der alte zu wenig Disk Space hatte. Danach geht auf den Clients nichts mehr. Man muss dann händisch auf den Clients die Registry säubern. Dort hat sich noch der alte Server verewigt. LocalDB ist auch so ein Ding. Habe da mal SQL mäßig mit getracet, was da abgeht. Teilweise CPU spitzen von 20% durch die sqlserver.exe wegen der ständigen Abfragen. Das Supportforum ist voll von Problemen. Einige Leute sichern damit ihre Cluster und Oracle DBs. OMG.

Poste das mal auf Veeam Community Forums. Da sind auch die Veeam-Leute aktiv. BSOD geht definitiv nicht und vielleicht gibts da den passenden Fix für dich oder du hast einen nennenswerten Bug gefunden ;-)
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh