Windows 10/11 für Lexware - auf DS920+, DS1621+ oder kleinem Rechner?

[NSFH]

Die Anfordrungen an die VM für Lexware sind gar nicht so hoch, weil da nur schlicht eine DB betrieben wird, keine Grafik GUI etc. Auch die Anwendungssoftware verbleibt auf den Clients. Das ganze dann unter WinServer2019 läuft auf einem Kern in der xs+ aber mit einem SSD Raid1!
Der Zugriff auf den WinServer zu Wartungszecken erfolgt per Remote Konsole. Hier merkt man den einen Kern, könnte flüssiger laufen, stört aber nicht wirklich.
Ich denke eine DS mit AMD CPU, 2 Kerne für die VM, mindestens 16GB RAM plus SSD reichen!

 

[sugarDaddy]

@gaerti Super Aufschlüsselung!
@NSFH Ja, gehe auch von nem Lexware-Server ohne GUI aus, schön dass Du es bestätigst. Grade deswegen würde ich sogar vermuten dass es auf ner DS920+ liefe, mit der Einschränkung dass spätestens 4 gleichzeitige Berichtsabfragen (großer Zufall) dann doch spürbar sein könnten.

Da mir das aber zu heikel ist, spricht alles für eine DS1621+. Da ist dann vielleicht sogar ein bisschen Spiel für eine weitere Software/GUI drin.

 

[NSFH]

eine 920+ ist nicht prickelnd im Bereich VM! Zumal du WinServer2019 dfarauf lassen lassen musst. Von daher lieber auf eine AMD CPU setzen! Je nach dem wieviele HDs du benötigst evtl 6Bay nehmen und die VM auf 2 kleinen 120GB SSD im Raid1 laufen lassen. Dazu MINDESTENS 16GB RAM nur für die VM!

 

[sugarDaddy]

Es ist ohnehin angedacht mit 2 WD Red 1 TB SSDs im SHR zu starten und sukzessive zu erweitern (also für die gesamte NAS mit DSM, Packages und Docker). Braucht es dann noch ein dedicated SSD-volume/pool für die VM? Hab das mit den SSDs immer so verstanden, dass die Leute HDDs für Speicher nutzen, und VM-SSDs daneben für höhere VM-Geschwindigkeiten einsetzen.

 

[Georgius]

Nein, brauchst keinen extra Pool.

 

[NSFH]

Brauchst nur mehr Speicherplatz. Die VM muss eine feste Grösse haben, die du im Nachgang nicht mehr verändern kannst. 90-100GB sollte sie schon gross sein.
Die Exportdatei der VM (Installationssicherung, nicht snapshot) incl WinServer2019 und LexwarePremium hat eine Grösse von 23GB. Der Export kann aber in einem beliebigen Bereich des SHR gespeichert werden. Nimmst du dann noch Snapshots dazu verlierst du für den Betrieb der VM incl Backups ca 150GB Speicherplatz.

 

[sugarDaddy]

@NSFH Den Speicherverbrauch werde ich jetzt nochmal testen. Ist ja auf der DS216+II der Selbe. Die Größe des Exports kann ich natürlich ablesen. Allerdings finde ich nicht, wo er die Snapshots ablegt (pool, volume, folder) bzw. welchen Speicherplatz sie einnehmen (muss vorher/nachher testen).

Super Infos soweit von allen Beteilligten, danke! Und falls mich jemand noch netterweise auf einen Faux-Pas hinweisen möchte, hier nochmal mein geplantes Setup nach aktuellem Stand:

• Hardware (mal zwei, weil off-site für Backups via VPN und Diskstation-Ersatz-onDemand)
  • DS1621+ AMD 6-Bay
  • +16 GB (ECC von speicher.de D4ECSO-2666-16G; ein zweiter Riegel wenn nötig)
  • 2x1 TB WD Red NAS SSD im SHR (Datenmenge initial eher gering; muss aber nochmal durchrechnen)
• Software
  • ActiveDirectory für 20 PCs mit profile_dir auf NAS (davon 10 Office, davon 3 Lexware (Client))
  • Docker mit MSSQL für 20 PCs (davon 3 mit aufwendigen Queries/Reports dann und wann)
    • Ein Backup-Task exportiert MSSQL .baks/.diffs in ein shared-folder
  • Windows Server VM mit Lexware Financial Office Pro als Server
    • BackupLX macht automatische Backups der Lexware-Daten auf ein shared-folder
    • Snapshots der VM für lokal (Windows Updates & Stuff)
    • Kompletter Image Export für Replikation dann & wann
  • SnapshotReplication zur off-site-Replikation aller shared-folders
  • HyperBackup zum Backup von Settings und Daten
    • ActiveDirectory Settings
    • HyperBackup
    • USB Copy
    • Synology Application Service
    • Teils direktes Backup auf off-site, teils auf lokal wenn ich diese als Snapshots (replicated) haben möchte

Das Einzige wofür ich noch keine Lösung habe, ist dass nur wenn ich auf dem primären NAS die Snapshot-Replication auflöse, die shared-(replicated-)folders auf dem backup NAS ihr "read only" verlieren. Brennt mir aber der primäre NAS ab, kann ich auf Seiten des backup NAS nichts anderes tun, als sämtliche Daten in neue folders mit read&write zu kopieren.

 

[Synchrotron]

Ich würde mir mal Active Backup für Business anschauen. Vorteil: Pull-Backup, d.h. die Backup-DS wählt sich selbst auf die zu sichernde DS ein und zieht sich das Backup von dort.

Mit Versionierung ist es sogar egal, ob die Quell-DS verschlüsselt wurde. Da auf der Quell-DS keine Zugriffsdaten liegen, kann von dort auf die Backup-DS nicht zugegriffen werden.

HyperBackup kann nur Push, d.h. benötigt Zugangsdaten.

 

[sugarDaddy]

@Synchrotron Die Office-PCs haben nichts was es zu backupen lohnt. Aber Du meinst von NAS2 von NAS1 ziehen. Ginge auch, mit dem Vorteil der Zugangsdaten und des read only. Allerdings zöge ABB sich ja nicht die Snapshots des btrfs mit rüber? Im Zweifel würde ransomwared-rubbish gezogen und mein Backup überschrieben.
Wobei, zum Einen gibts sicher ne Art Retention-Policy. Zum anderen könnte ich ja vielleicht die Backups von ABB auf NAS2 mit Snapshots versionieren? Ich schaue mir das mal an. Danke.

 

[Synchrotron]

ABfB gibt es auf 2 Ebenen: Clients zu DS (das war hier nicht gemeint), DS zu DS.

Darum ging es hier. Wenn ein potenter Trojaner auf die Arbeits-DS kommt, wird er zuerst versuchen, die Backups zu finden und zu verschlüsseln ! Gute Backups sind versioniert, d.h. sie sichern immer die letzte Version einer Datei. Nur werden sie selbst angegriffen, nützt das nichts. Weil davon ausgegangen wird, dass man sich seine Backups selten anschaut, greift man die zuerst an.

Liegt auf der Backup-DS hingegen ein nicht angreifbares Backup, und auf der Quell-DS werden Dateien verschlüsselt, kann es sein, dass die verschlüsselten Dateien als Backup gezogen werden. Macht aber nichts, denn die vorherigen Versionen sind noch verfügbar, und können wiederhergestellt werden.

Der Vollständigkeit halber sei erwähnt, dass die Ransom-Kriminellen inzwischen auch versuchen, Daten zu stehlen. Im Fokus stehen dabei vor allem personenbezogene Daten, Kundendaten o.ä. Damit wird neben der Verschlüsselung versucht, zusätzlichen Druck aufzubauen.

Also am besten „sauber bleiben“.