Backupstrategien und Programme für einen Linux-Server (KMU)
Hallo Zusammen,
ich habe schon etwas gesucht, bin aber noch nicht ganz so sicher. Darum möchte ich die Fage gerne hier nochmal stellen:
Es geht darum für ein kleines Unternehmen einen neuen Server aufzusetzen. Das Betriebssystem ist jetzt noch nicht festgelegt. Es kann somit ein Linux (Debian / Ubuntu) oder ein Windows werden. Der Server wird keine Verbindung zum Internet besitzen. Die Clients sind soweit Windows 7 /10.
Folgende Dienste sollen auf dem System laufen:
Ab jetzt beschreib ich mal meine Ideen und bitte um Kommentierung bzw. Kritisierung
Backupmedien und Idee:
Vorgehensweise:
Meine Fragen an euch:
Danke für eure Meinung
Viele Grüße
tuhpon
ich habe schon etwas gesucht, bin aber noch nicht ganz so sicher. Darum möchte ich die Fage gerne hier nochmal stellen:
Es geht darum für ein kleines Unternehmen einen neuen Server aufzusetzen. Das Betriebssystem ist jetzt noch nicht festgelegt. Es kann somit ein Linux (Debian / Ubuntu) oder ein Windows werden. Der Server wird keine Verbindung zum Internet besitzen. Die Clients sind soweit Windows 7 /10.
Folgende Dienste sollen auf dem System laufen:
- Datenfreigabe (Samba)
- Confluence Wiki
- DB für das Wiki (vorraussichtlich PostgreSQL)
- Webserver (apache) mit PHP + DB
- Git-Server (GitLab) (hier wird auch ein DB benötigt werden)
Ab jetzt beschreib ich mal meine Ideen und bitte um Kommentierung bzw. Kritisierung
- Es sollte ein hotbackup möglich sein
Backupmedien und Idee:
- Mehre externe Festplatten, pro Wochentag eine, welche somit 1x pro Woche überschrieben werden
- Update sollte incrementell durch geführt werden (Somit nur die Differenz seit dem letzten mal).
- Somit hab ich Backups für eine Woche
Vorgehensweise:
- von den Datenbanken ein Dump erstellen (Gibts hier auch inkrementelle Möglichkeiten?)
- Ordner (Samba, www, und Ordner für die DB-Dumps) via rsync auf die Platten spielen
- Das ganze in ein Skript packen
- Start des Skripts: Hier hätte ich folgende Ideen: entweder über eine Weboberfläche oder durch das Einstecken der USB-Platten (Hier muss ich mich noch einlesen, wie ich das als Trigger nutzten kann) starten.
Meine Fragen an euch:
- Was haltet ihr von dem Konzept?
- Was fehlt? Wo sind Schwachstellen?
- Gibt es hierzu fertige Software? (uu auch eine mit WEB-GUI?)
- Sehe ich das soweit richtig, dass es prinzipell auf rsync und dump hinausläuft?
Danke für eure Meinung
Viele Grüße
tuhpon
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 369888
Url: https://administrator.de/contentid/369888
Ausgedruckt am: 24.11.2024 um 15:11 Uhr
18 Kommentare
Neuester Kommentar
Hallo Tuhpon,
wie realisierst du das " der Server hat keine Verbindung zum Internet" - haben die Clients (wieviele?) Zugriff darauf? Wenn ja, gibt es eine Trennung? Was, wenn das Wiki auch von Unterwegs zugreifbar sein soll...?
Wie ist die Anforderung so weit gestreut? Warum Linux, wenn pur Windowsclients im Einsatz sind?
Ich denke, das Backup ist derzeit dein kleinstes Problem - mit welchem Fachwissen gehst du an die Sache heran?
Für eine ordentliche Konzeptionierung/Umsetzung darfst du dich gerne an mich per PN wenden.
VG
wie realisierst du das " der Server hat keine Verbindung zum Internet" - haben die Clients (wieviele?) Zugriff darauf? Wenn ja, gibt es eine Trennung? Was, wenn das Wiki auch von Unterwegs zugreifbar sein soll...?
Wie ist die Anforderung so weit gestreut? Warum Linux, wenn pur Windowsclients im Einsatz sind?
Ich denke, das Backup ist derzeit dein kleinstes Problem - mit welchem Fachwissen gehst du an die Sache heran?
Für eine ordentliche Konzeptionierung/Umsetzung darfst du dich gerne an mich per PN wenden.
VG
Moin,
wie ist denn dein Budget? Grundsätzlich würde ich den/die produktiven Server nicht auf ein Blech installieren, sondern als VM. Darunter dann Hyper-V oder VMWare, je nach Geschmack, und zum Sichern Veeam. Da alles lässt sich dann Prima skalieren falls die Firma mal wächst und erfüllt nebenbei noch alle deine Anforderungen.
lg,
Slainte
wie ist denn dein Budget? Grundsätzlich würde ich den/die produktiven Server nicht auf ein Blech installieren, sondern als VM. Darunter dann Hyper-V oder VMWare, je nach Geschmack, und zum Sichern Veeam. Da alles lässt sich dann Prima skalieren falls die Firma mal wächst und erfüllt nebenbei noch alle deine Anforderungen.
lg,
Slainte
Moin @tuhpon,
dein Ansatz ist veraltet und sehr fehleranfällig.
Du solltest dich an den Vorschlag von @SlainteMhath halten.
dein Ansatz ist veraltet und sehr fehleranfällig.
Du solltest dich an den Vorschlag von @SlainteMhath halten.
Zitat von @tuhpon:
Somit wäre meine Frage, ob für den "Spielzeug-Server" eine Virtualisierung nicht etwas Überdimensioniert ist.
Sehe ich das falsch? Wäre eine Virtualisierung immer noch interessant?
Virtualisierung ist State of the Art. Es gibt nur noch ganz wenige Szenarien, wo man keine Virtualisierung einsetzt. Durch die Virtualisierung entkoppelst du dein System von der Hardware, was eine Wiederherstellung oder einen Umzug auf neue Hardware enorm vereinfacht. Darüber hinaus bekommt man das Thema Backup leichter in den Griff.Somit wäre meine Frage, ob für den "Spielzeug-Server" eine Virtualisierung nicht etwas Überdimensioniert ist.
Sehe ich das falsch? Wäre eine Virtualisierung immer noch interessant?
Mein Vorschlag:
Setze einen Hyper-V auf, darauf eine Windows-VM als DC - kannst du in das vorhandene Netzt mit einhängen, eine VM als File und DB-Server und eine weitere VM als Linux für dein Confluence - Datenablage auf der Windows-VM. Und schon hast du eine saubere, skalierbare Lösung.
BTW: Server ohne Internet geht gar nicht: Heutzutage installiert man Sicherheitsupdates!
Gruß
Moin
Bereits seit 15+ Jahren stelle ich Windows-Blech-Server auf anderer Hardware wieder her.
Da gibt es keinen Geschwindigkeitsvorteil bei einer Virtualisierung und der Wechsel der Hardware ist mit den richtigen Sicherungslösungen auch kein Problem.
eine weitere VM als Mailserver
und noch eine VM für den WSUS
dann noch extra Hardware für den Backupserver
Beim TO geht's um 3-4 Mitarbeiter.
Es gibt - nach dem, was der TO bisher geschrieben hat - keinen Grund, hier nicht ein normales Serverblech hinzustellen und dort dann einen Linux- oder Windows-Server zu betreiben.
Meine Empfehlung:
normale Server-Hardware (bspw. HP ML30 Gen9) - Ausstattung nach Bedarf
Server-BS (Linux oder Windows Server 2016)
Als Sicherungslösung empfehle ich Veritas System Recovery Server oder Linux Edition
Das Sicherungsziel kann bspw. ein NAS und ein Wechseldatenträger sein (Extra-Sicherung außer Haus)
Zitat von @Kraemer:
Genau, aber wenn ich genau einen Server benötige, bzw. der TO sogar mit einem NAS zurechtkäme, ist das ein Szenario, wo Virtualisierung alles komplizierter macht.Zitat von @tuhpon:
Somit wäre meine Frage, ob für den "Spielzeug-Server" eine Virtualisierung nicht etwas Überdimensioniert ist.
Sehe ich das falsch? Wäre eine Virtualisierung immer noch interessant?
Virtualisierung ist State of the Art. Es gibt nur noch ganz wenige Szenarien, wo man keine Virtualisierung einsetzt.Somit wäre meine Frage, ob für den "Spielzeug-Server" eine Virtualisierung nicht etwas Überdimensioniert ist.
Sehe ich das falsch? Wäre eine Virtualisierung immer noch interessant?
Durch die Virtualisierung entkoppelst du dein System von der Hardware, was eine Wiederherstellung oder einen Umzug auf neue Hardware enorm vereinfacht. Darüber hinaus bekommt man das Thema Backup leichter in den Griff.
Sorry, aber das ist Unsinn. Backup wird dadurch nicht leichter, sonders anders.Bereits seit 15+ Jahren stelle ich Windows-Blech-Server auf anderer Hardware wieder her.
Da gibt es keinen Geschwindigkeitsvorteil bei einer Virtualisierung und der Wechsel der Hardware ist mit den richtigen Sicherungslösungen auch kein Problem.
Mein Vorschlag:
Setze einen Hyper-V auf, darauf eine Windows-VM als DC - kannst du in das vorhandene Netzt mit einhängen, eine VM als File und DB-Server und eine weitere VM als Linux für dein Confluence - Datenablage auf der Windows-VM. Und schon hast du eine saubere, skalierbare Lösung.
klarSetze einen Hyper-V auf, darauf eine Windows-VM als DC - kannst du in das vorhandene Netzt mit einhängen, eine VM als File und DB-Server und eine weitere VM als Linux für dein Confluence - Datenablage auf der Windows-VM. Und schon hast du eine saubere, skalierbare Lösung.
eine weitere VM als Mailserver
und noch eine VM für den WSUS
dann noch extra Hardware für den Backupserver
Beim TO geht's um 3-4 Mitarbeiter.
Es gibt - nach dem, was der TO bisher geschrieben hat - keinen Grund, hier nicht ein normales Serverblech hinzustellen und dort dann einen Linux- oder Windows-Server zu betreiben.
Meine Empfehlung:
normale Server-Hardware (bspw. HP ML30 Gen9) - Ausstattung nach Bedarf
Server-BS (Linux oder Windows Server 2016)
Als Sicherungslösung empfehle ich Veritas System Recovery Server oder Linux Edition
Das Sicherungsziel kann bspw. ein NAS und ein Wechseldatenträger sein (Extra-Sicherung außer Haus)
BTW: Server ohne Internet geht gar nicht: Heutzutage installiert man Sicherheitsupdates!
Geht alles - es gibt für Windows bspw. WSUSOffline, was selbst von einer USB-HDD aus das System updatet.
Hallo goscho,
das Konzept alles auf einen Server macht es also einfacher? Puh, dann danke ich Gott für VIrtualisierungslösungen, in denen ich bei der Arbeit an ServerA nicht alle Benutzer zum Urlaub verdonnern muss.
Abgesehen davon, wer kennt noch den SBS und was er bisweilen anstellte? (@Thomas, kein Bashing, ich mochte das Ding damals auch).
Die Sache ist daher eher eine Frage, des, wer kann es kompetent einrichten, aber grundsätzlich kann man sich auf beide Arten einen Stock in die Speichen legen.
@goscho, das mag schon stimmen, wenn man es richtig macht ist eine Wiederherstellung einer VM allerdings wesentlich einfacher. Sowie bei Hardwareaustausch kann es im laufenden Betrieb ohne Downtime geschehen.
Aufgrund der Systematik wette ich allerdings, dass das System innerhalb der Laufzeit ans Internet angeschlossen werden soll. Ist auf jeden Fall, als extern noch eine public Cloud vollzumüllen.
VG
das Konzept alles auf einen Server macht es also einfacher? Puh, dann danke ich Gott für VIrtualisierungslösungen, in denen ich bei der Arbeit an ServerA nicht alle Benutzer zum Urlaub verdonnern muss.
Abgesehen davon, wer kennt noch den SBS und was er bisweilen anstellte? (@Thomas, kein Bashing, ich mochte das Ding damals auch).
Die Sache ist daher eher eine Frage, des, wer kann es kompetent einrichten, aber grundsätzlich kann man sich auf beide Arten einen Stock in die Speichen legen.
@goscho, das mag schon stimmen, wenn man es richtig macht ist eine Wiederherstellung einer VM allerdings wesentlich einfacher. Sowie bei Hardwareaustausch kann es im laufenden Betrieb ohne Downtime geschehen.
Aufgrund der Systematik wette ich allerdings, dass das System innerhalb der Laufzeit ans Internet angeschlossen werden soll. Ist auf jeden Fall, als extern noch eine public Cloud vollzumüllen.
VG
Moin,
Nun ja, wenn du es wirklich so umsetzt, ist das durchaus ausreichend für deine Anforderungen, auch wenn der ein oder andere, die gewiss regelmäßig mit kleineren Bastellösungen wie dieser zu tun haben, der Meinung sind dass du doch lieber eine 08/15 Lösung nehmen sollst, oder sie dir sogar verkaufen wollen.
Die wichtige Frage ist halt, kriegst du es zusammengestrickt (Ein bisschen Software installieren, ein backup script schreiben,…). Wenn du das kannst, sehe ich ehrlich gesagt keine größeren Probleme.
Natürlich haben individuelle Setups dann auch individuelle Probleme, sprich wenn du dir irgendwie extern hilfe holst, kann es auch mal etwas teurer werden, zumindest wenn es dringend ist. Wenn du es aber richtig aufziehst und dein Backup und restore so klappen wie geplant, sehe ich da keine all zu großen Probleme auf die zukommen.
Und für die kleinen Hilfen gibt es LUG (Linux User Groups), Foren oder IRC und Matrix Channel wo man zumindest Rat findet und ggf. entsprechende Dokumentationen. Englisch sollte allerdings durchaus drin sein, sonst wird es etwas umständlich.
Naja, du meinst der Server soll nicht online. Das ist unter Linux auch kein Problem, du kannst dir für diverse Distros die Updates + Software Repositories per Post auf DVD zuschicken lassen. Empfehlen würde ich das allerdings nicht. Nicht nur ist es unnötig teuer und belastet die Umwelt, es erhöht deine Sicherheit auch nur eingeschränkt, wenn deine Firewall halbwegs richtig konfiguriert ist.
Einfach online gehen lassen und entsprechende updates regelmäßig von Hand(! zumindest auf den meisten Distros) durchführen. Skalieren wird halt etwas umständlich, wenn du es direkt auf Blech machst, aber ist auch kein Ding der Unmöglichkeit. kommt halt ein zweites Blech her, backup von Service A einspielen migrieren, fertig. Geht halt nicht ohne downtime, aber wenn eine Webseite mal 10 minuten nicht erreichbar ist, sollte das auch kein Beinbruch sein.
Ich bin der Meinung zumindest für Dinge wie GitLab, Samba-Freigaben und Co schon GUI lösungen gesehen zu haben, allerdings empfehle ich dir gerade in so einem Setup es dann doch einfach selbst zu bauen. Mit Docker ist das nicht all zu kompliziert GitLab, Confluence und Co aufzusetzen. Deine Backupscripts werden dadurch minimal komplizierter, aber sollte auch kein Problem sein. Und wenn du es gemacht hast, weißt du was wo läuft, was die Dinge sehr viel einfacher macht, als einfach alles von eine magisch GUI installieren zu lassen. Denn den GUI setup während einer Downtime erst mal selbst zu rekonstruieren nur um dann nach X Stunden festzustellen, dass die einen Typo in einem config template hatten, will man tatsächlich vermeiden.
Wenn es um Backups geht, ja. Wenn du das alles noch auf XFS machst, kannst du mit xfsdump auch konsistente Backups ziehen (auch inkrementell). Dazu solltest du natürlich deine entsprechenden DB und Nutzdaten auf das gleiche Volume packen. Das ist aber tatsächlich mit Docker ziemlich einfach, wenn du Bind-mounts nutzt. (Womit ich dir hiermit alle notwendigen Schlagworte geliefert habe ;))
Nicht zuletzt solltest du natürlich nochmal einen (kompletten,) separaten Datenbank dump ziehen womit du dann auf die sichere Seite bist.
Alles in allem, kann das also was werden, wenn du dir da noch einiges aneignest
Einfach erst mal ein bisschen ausprobieren und mal ein bis 2 Wochen testlauf machen, inklusive test wie man recovered, upgrades und ähnliches macht, bevor du es wirklich live nimmst, aber wenn das klappt und du dafür eine entsprechende Dokumentation angelegt hast, sehe ich keine größeren Probleme in deinem Setup.
Gruß
Chris
Was haltet ihr von dem Konzept?
Nun ja, wenn du es wirklich so umsetzt, ist das durchaus ausreichend für deine Anforderungen, auch wenn der ein oder andere, die gewiss regelmäßig mit kleineren Bastellösungen wie dieser zu tun haben, der Meinung sind dass du doch lieber eine 08/15 Lösung nehmen sollst, oder sie dir sogar verkaufen wollen.
Die wichtige Frage ist halt, kriegst du es zusammengestrickt (Ein bisschen Software installieren, ein backup script schreiben,…). Wenn du das kannst, sehe ich ehrlich gesagt keine größeren Probleme.
Natürlich haben individuelle Setups dann auch individuelle Probleme, sprich wenn du dir irgendwie extern hilfe holst, kann es auch mal etwas teurer werden, zumindest wenn es dringend ist. Wenn du es aber richtig aufziehst und dein Backup und restore so klappen wie geplant, sehe ich da keine all zu großen Probleme auf die zukommen.
Und für die kleinen Hilfen gibt es LUG (Linux User Groups), Foren oder IRC und Matrix Channel wo man zumindest Rat findet und ggf. entsprechende Dokumentationen. Englisch sollte allerdings durchaus drin sein, sonst wird es etwas umständlich.
Was fehlt? Wo sind Schwachstellen?
Naja, du meinst der Server soll nicht online. Das ist unter Linux auch kein Problem, du kannst dir für diverse Distros die Updates + Software Repositories per Post auf DVD zuschicken lassen. Empfehlen würde ich das allerdings nicht. Nicht nur ist es unnötig teuer und belastet die Umwelt, es erhöht deine Sicherheit auch nur eingeschränkt, wenn deine Firewall halbwegs richtig konfiguriert ist.
Einfach online gehen lassen und entsprechende updates regelmäßig von Hand(! zumindest auf den meisten Distros) durchführen. Skalieren wird halt etwas umständlich, wenn du es direkt auf Blech machst, aber ist auch kein Ding der Unmöglichkeit. kommt halt ein zweites Blech her, backup von Service A einspielen migrieren, fertig. Geht halt nicht ohne downtime, aber wenn eine Webseite mal 10 minuten nicht erreichbar ist, sollte das auch kein Beinbruch sein.
Gibt es hierzu fertige Software? (uu auch eine mit WEB-GUI?)
Ich bin der Meinung zumindest für Dinge wie GitLab, Samba-Freigaben und Co schon GUI lösungen gesehen zu haben, allerdings empfehle ich dir gerade in so einem Setup es dann doch einfach selbst zu bauen. Mit Docker ist das nicht all zu kompliziert GitLab, Confluence und Co aufzusetzen. Deine Backupscripts werden dadurch minimal komplizierter, aber sollte auch kein Problem sein. Und wenn du es gemacht hast, weißt du was wo läuft, was die Dinge sehr viel einfacher macht, als einfach alles von eine magisch GUI installieren zu lassen. Denn den GUI setup während einer Downtime erst mal selbst zu rekonstruieren nur um dann nach X Stunden festzustellen, dass die einen Typo in einem config template hatten, will man tatsächlich vermeiden.
Sehe ich das soweit richtig, dass es prinzipell auf rsync und dump hinausläuft?
Wenn es um Backups geht, ja. Wenn du das alles noch auf XFS machst, kannst du mit xfsdump auch konsistente Backups ziehen (auch inkrementell). Dazu solltest du natürlich deine entsprechenden DB und Nutzdaten auf das gleiche Volume packen. Das ist aber tatsächlich mit Docker ziemlich einfach, wenn du Bind-mounts nutzt. (Womit ich dir hiermit alle notwendigen Schlagworte geliefert habe ;))
Nicht zuletzt solltest du natürlich nochmal einen (kompletten,) separaten Datenbank dump ziehen womit du dann auf die sichere Seite bist.
Alles in allem, kann das also was werden, wenn du dir da noch einiges aneignest
Einfach erst mal ein bisschen ausprobieren und mal ein bis 2 Wochen testlauf machen, inklusive test wie man recovered, upgrades und ähnliches macht, bevor du es wirklich live nimmst, aber wenn das klappt und du dafür eine entsprechende Dokumentation angelegt hast, sehe ich keine größeren Probleme in deinem Setup.
Gruß
Chris
Zitat von @certifiedit.net:
Hallo goscho,
das Konzept alles auf einen Server macht es also einfacher? Puh, dann danke ich Gott für VIrtualisierungslösungen, in denen ich bei der Arbeit an ServerA nicht alle Benutzer zum Urlaub verdonnern muss.
Lies bitte nochmal nach, wie viele User es beim TO gibt:Hallo goscho,
das Konzept alles auf einen Server macht es also einfacher? Puh, dann danke ich Gott für VIrtualisierungslösungen, in denen ich bei der Arbeit an ServerA nicht alle Benutzer zum Urlaub verdonnern muss.
3-4 und diese haben insgesamt 10-15 PCs
Abgesehen davon, wer kennt noch den SBS und was er bisweilen anstellte? (@Thomas, kein Bashing, ich mochte das Ding damals auch).
Ich betreue noch sehr viele SBS2011 bei meinen kleinen Kunden. Es sind auch virtualisierte dabei.Die Sache ist daher eher eine Frage, des, wer kann es kompetent einrichten, aber grundsätzlich kann man sich auf beide Arten einen Stock in die Speichen legen.
Mir musst du das kaum erklären.Ich habe in meinem Kleinstunternehmen mehr Server (8; 5 davon als VMs) als aktive User (3).
@goscho, das mag schon stimmen, wenn man es richtig macht ist eine Wiederherstellung einer VM allerdings wesentlich einfacher. Sowie bei Hardwareaustausch kann es im laufenden Betrieb ohne Downtime geschehen.
Wenn man was richtig macht?Man kann auch Ausfallsicherheit dazu kaufen.
Es ist alles eine Frage der Verhältnismäßigkeit.
Aufgrund der Systematik wette ich allerdings, dass das System innerhalb der Laufzeit ans Internet angeschlossen werden soll. Ist auf jeden Fall, als extern noch eine public Cloud vollzumüllen.
Warum, wenn der TO folgendes schreibt:Es gibt zwei physikalisch getrennte Netze; eines für das Inet und ein Firmeninternes mit Zugriff auf den Server.
Es gibt auch heute noch Szenarien, in welchen bestimmte Geräte keinen Internetzugang haben sollen.Wir sollten das respektieren und nicht mit Totschlagargumenten dagegen anquatschen.
Selbst wenn es irgendwann mal so sein sollte, dass der Server alle seine Daten über irgend eine Wolke austauschen soll, so kann das auch später eingerichtet werden.
Also du rätst Ihm: klatscht alles auf einen Server ohne(!) Virtualisierung, damit alle 10-15 PCs bei einer Wartung an Teilbetriebsmenge X (wie kommt man auf die 10-15 Anzahl?) still stehen? Solide geplant.
Wenn man die Planung und Konfiguration richtig macht. Wenn man da irgendwas zusammenbastelt kann auch das einfache Verschieben einer VM zu einer Herkulesaufgabe werden.
Ich betreue auch noch den einen oder anderen SBS2011 - alle virtualisiert. Aber die, die ich von dritten (Kunden und anderen Systemhäusern übernahm) waren schlimm verwurstelt. Eine klare Trennung der Systeme hilft natürlich auch beim Upgrade.
Ich sehe hier kein Totschlagargument(?!), ich hinterfrage aber den Grund. Du kannst seine Aussagen respektieren (übrigens sehe ich kein "nicht respektieren" meinerseits) und ihm die Hände streicheln, das beantwortet aber nicht seine Frage, was man davon hält. Vielleicht hast du den Eingangspost einfach nicht (so weit) gelesen.
Wenn man die Planung und Konfiguration richtig macht. Wenn man da irgendwas zusammenbastelt kann auch das einfache Verschieben einer VM zu einer Herkulesaufgabe werden.
Ich betreue auch noch den einen oder anderen SBS2011 - alle virtualisiert. Aber die, die ich von dritten (Kunden und anderen Systemhäusern übernahm) waren schlimm verwurstelt. Eine klare Trennung der Systeme hilft natürlich auch beim Upgrade.
Ich sehe hier kein Totschlagargument(?!), ich hinterfrage aber den Grund. Du kannst seine Aussagen respektieren (übrigens sehe ich kein "nicht respektieren" meinerseits) und ihm die Hände streicheln, das beantwortet aber nicht seine Frage, was man davon hält. Vielleicht hast du den Eingangspost einfach nicht (so weit) gelesen.
Zitat von @certifiedit.net:
Also du rätst Ihm: klatscht alles auf einen Server ohne(!) Virtualisierung,
damit alle 10-15 PCs bei einer Wartung an Teilbetriebsmenge X (wie kommt man auf die 10-15 Anzahl?) still stehen? Solide geplant.
Ja, denn ich höre auch zu (in diesem Fall lese auch):Also du rätst Ihm: klatscht alles auf einen Server ohne(!) Virtualisierung,
damit alle 10-15 PCs bei einer Wartung an Teilbetriebsmenge X (wie kommt man auf die 10-15 Anzahl?) still stehen? Solide geplant.
Zitat von @tuhpon:
Mitarbeiter sind es 3 - 4; Clients sind es 10 - 15. Das sind Arbeits- und Mess- bzw. Testrechner.
Mitarbeiter sind es 3 - 4; Clients sind es 10 - 15. Das sind Arbeits- und Mess- bzw. Testrechner.
Du verkaufst auch jemanden, der einen Kombi oder kleinen Transporter braucht, weil er gelegentlich größere Sachen transportiert, gleich mal einen 40-Tonner mit Hänger, ohne zu fragen, ob er/sie den überhaupt fahren kann.
Ich sehe hier kein Totschlagargument(?!), ich hinterfrage aber den Grund. Du kannst seine Aussagen respektieren (übrigens sehe ich kein "nicht respektieren" meinerseits) und ihm die Hände streicheln, das beantwortet aber nicht seine Frage, was man davon hält. Vielleicht hast du den Eingangspost einfach nicht (so weit) gelesen.
Es ging ihm eigentlich nur um das Backup und sein Konzept.
Einzig Chris @sheogarath ging darauf richtig ein.
Slainte (Veeam) und ich (Veritas System Recovery) haben wenigstens noch Vorschläge zum Thema Backup gemacht.
Von den anderen Antworten würde ich gern deinen 1. Kommentar auszugsweise zitieren:
Zitat von @certifiedit.net:
Ich denke, das Backup ist derzeit dein kleinstes Problem - mit welchem Fachwissen gehst du an die Sache heran?
Ich denke, das Backup ist derzeit dein kleinstes Problem - mit welchem Fachwissen gehst du an die Sache heran?
Zitat von @goscho:
Sorry, aber das ist Unsinn. Backup wird dadurch nicht leichter, sonders anders.
Bereits seit 15+ Jahren stelle ich Windows-Blech-Server auf anderer Hardware wieder her.
Da gibt es keinen Geschwindigkeitsvorteil bei einer Virtualisierung und der Wechsel der Hardware ist mit den richtigen Sicherungslösungen auch kein Problem.
Mein Vorschlag an dich: Geh mal auf eine Fortbildung! Dann hätten wir hier einen weniger, der 80er-Jahre-Lowbudget-Strategien verteidigt.Sorry, aber das ist Unsinn. Backup wird dadurch nicht leichter, sonders anders.
Bereits seit 15+ Jahren stelle ich Windows-Blech-Server auf anderer Hardware wieder her.
Da gibt es keinen Geschwindigkeitsvorteil bei einer Virtualisierung und der Wechsel der Hardware ist mit den richtigen Sicherungslösungen auch kein Problem.
Das was der TO beschrieben hat ist eine Frickellösung die üblicherweise von Firmen umgesetzt werden, die entweder
- einen übereifrigen Mitarbeiter haben, welcher dem Chef mal zeigen will, wie man Geld spart
- von einer IT-Schrauberbude betreut werden, deren einzige Fortbildung aus der aktuellen Computerbild kommt und vor Angst einen Auftrag nicht zu bekommen, jeden auch nur erdenklichen Mist umsetzen. Hauptsache billig.
Ernsthaft: Ich finde es gut, das der TO hier nach einer professionellen Meinung fragt. Keiner hat ihm gesagt das er blöd ist! Dafür wurde ihm aufgezeigt, was an seinen Überlegungen nicht zu Ende gedacht ist.
Und dann kommt wieder einer, der unbedingt den Beschützer spielen muss. Es hat ihn zwar keiner drum gebeten, mit der Problemstellung hat er sich auch nicht wirklich auseinander gesetzt aber er kann Abends friedlich ins Bett gehen und ist sich sicher: Den Pros habe ich es heute aber gezeigt.
Und jetzt fehlt nur noch ein neuer Thread wo darüber gejammert wird, dass hier alle so gemein sind...
Moin,
Joa, tatsächlich würde ich das tun. Wenn der Strom ausfällt ist man auch nicht besser dran. Also von daher muss man eh auch mal ein paar Minuten, ja vielleicht sogar eine oder zwei Stunden ohne Rechner auskommen. Davon abgesehen reden wir hier von einem Samba share, confluence, einem Wiki, einer (vermutlich internen) Webseite und einem Gitlab. Ganz im Ernst, sowas darf im worst case sogar mal einen ganzen Tag ausfallen und es sollte nicht die Existenz des Betriebs bedrohen, sonst gibt es ganz andere Probleme.
Und ja, Virtualisierung ist toll, aber in dem Fall schlicht nicht zwangsläufig notwendig. Es scheint sich um einen einzelnen physicalischen Server zu handeln, alles was Virtualisierung hier bringt ist zusätzliche load und *vielleicht* eine bisschen bessere kontrolle über die system load.
Snapshots und Co machen auf Virtualisierung erst dann wirklich Spaß, wenn man mit externem storage arbeitet und sicherheitstechnisch ist der Zugewinn nun auch nicht übertrieben groß.
Du lieferst gerade selbst ein Argument, dass gegen Virtualisierung in solch einem trivialen Setup spricht, aber dazu später mehr.
Mhm, das ist alles schön und gut, aber ich sehe da eher das Grundproblem SBS. Den hier beschrieben setup würde ich nicht mal auf Windows laufen lassen wollen. Und unter Ubuntu sowas zu migrieren oder aktualiseren ist wirklich kein Hexenwerk. Denn das ist im Grunde alles fertig gescripted und es gibt nur marginale Debugging tasks, die zwar auch mal ihre Zeit dauern können, aber hier findet man Hilfe in der entsprechenden community.
Naja, was hier als "Totschlagargument" gewertet wurde, war die Grundaussage: "Vergiss es, lass den Profi ran und dann wird das auch."
Und so nett gemeint der Vorschlag auch war, sind wir mal ehrlich, systemhäuser lieben Standardlösungen. Warum? Weil die Wartung überall nahezu identisch ist, man auf die gleichen Probleme stößt, usw.. Es ist einfach billiger. Für das Systemhaus, für den Kunden, für alle, richtig?
Naja, nicht ganz. Im hier beschrieben Setup sehe ich Potential. Und zwar Potential jemanden dazu zu befähigen seinen Setup auch selbst zu maintainen und wenn er das selbst kann, und vielleicht sogar upgrades am Wochenende macht weil er Spaß dran hat, sind downtimes gar kein so großes Problem mehr.
Und hier wird es natürlich unattraktiv für das Systemhaus, denn die bezahlt man in der Regel ja pro Einsatzstunde. Ja, individuelle Setups brauchen oft etwas mehr Zeit und Liebe, um sie am laufen zu halten, aber wenn man diese Zeit nicht übermäßig Teuer bezahlen muss, ist das manchmal einfach günstiger
Aber genug von diesem ganzen Unsinn und zurück zum Thema ;)
And den TO noch einen Hinweis: Wenn du XFS nimmst, bau dir ein LVM drunter (sollte dein Installer während der Partitionierung können) und fang mit kleinen volumes an. Empfehlung: 50GB. XFS kann im live betrieb wachsen, aber niemals schrumpfen, sprich wenn du irgendwann knapp mit Speicher bist, kann es haarig werden. Also kleine logische Volumes die man nach Bedarf wachsen lassen kann, die Befehle dafür findest du in entsprechenden Online tutorials, ist kein Hexenwerk ;)
Edit: Kleiner zusätzlicher Hinweis: Wenn du auf einem einzelnen Blech läufst, schau dass du einen Wartungsvertrag für deine Hardware hast, der entsprechend zeitnah (möglichst <24h) und vor Ort stattfindet.
@goscho danke für die Blumen ;)
In diesem Sinne
Gruß
Chris
Zitat von @certifiedit.net:
Also du rätst Ihm: klatscht alles auf einen Server ohne(!) Virtualisierung, damit alle 10-15 PCs bei einer Wartung an Teilbetriebsmenge X (wie kommt man auf die 10-15 Anzahl?) still stehen? Solide geplant.
Also du rätst Ihm: klatscht alles auf einen Server ohne(!) Virtualisierung, damit alle 10-15 PCs bei einer Wartung an Teilbetriebsmenge X (wie kommt man auf die 10-15 Anzahl?) still stehen? Solide geplant.
Joa, tatsächlich würde ich das tun. Wenn der Strom ausfällt ist man auch nicht besser dran. Also von daher muss man eh auch mal ein paar Minuten, ja vielleicht sogar eine oder zwei Stunden ohne Rechner auskommen. Davon abgesehen reden wir hier von einem Samba share, confluence, einem Wiki, einer (vermutlich internen) Webseite und einem Gitlab. Ganz im Ernst, sowas darf im worst case sogar mal einen ganzen Tag ausfallen und es sollte nicht die Existenz des Betriebs bedrohen, sonst gibt es ganz andere Probleme.
Und ja, Virtualisierung ist toll, aber in dem Fall schlicht nicht zwangsläufig notwendig. Es scheint sich um einen einzelnen physicalischen Server zu handeln, alles was Virtualisierung hier bringt ist zusätzliche load und *vielleicht* eine bisschen bessere kontrolle über die system load.
Snapshots und Co machen auf Virtualisierung erst dann wirklich Spaß, wenn man mit externem storage arbeitet und sicherheitstechnisch ist der Zugewinn nun auch nicht übertrieben groß.
Wenn man die Planung und Konfiguration richtig macht. Wenn man da irgendwas zusammenbastelt kann auch das einfache Verschieben einer VM zu einer Herkulesaufgabe werden.
Du lieferst gerade selbst ein Argument, dass gegen Virtualisierung in solch einem trivialen Setup spricht, aber dazu später mehr.
Ich betreue auch noch den einen oder anderen SBS2011 - alle virtualisiert. Aber die, die ich von dritten (Kunden und anderen Systemhäusern übernahm) waren schlimm verwurstelt. Eine klare Trennung der Systeme hilft natürlich auch beim Upgrade.
Mhm, das ist alles schön und gut, aber ich sehe da eher das Grundproblem SBS. Den hier beschrieben setup würde ich nicht mal auf Windows laufen lassen wollen. Und unter Ubuntu sowas zu migrieren oder aktualiseren ist wirklich kein Hexenwerk. Denn das ist im Grunde alles fertig gescripted und es gibt nur marginale Debugging tasks, die zwar auch mal ihre Zeit dauern können, aber hier findet man Hilfe in der entsprechenden community.
Ich sehe hier kein Totschlagargument(?!), ich hinterfrage aber den Grund. Du kannst seine Aussagen respektieren (übrigens sehe ich kein "nicht respektieren" meinerseits) und ihm die Hände streicheln, das beantwortet aber nicht seine Frage, was man davon hält. Vielleicht hast du den Eingangspost einfach nicht (so weit) gelesen.
Naja, was hier als "Totschlagargument" gewertet wurde, war die Grundaussage: "Vergiss es, lass den Profi ran und dann wird das auch."
Und so nett gemeint der Vorschlag auch war, sind wir mal ehrlich, systemhäuser lieben Standardlösungen. Warum? Weil die Wartung überall nahezu identisch ist, man auf die gleichen Probleme stößt, usw.. Es ist einfach billiger. Für das Systemhaus, für den Kunden, für alle, richtig?
Naja, nicht ganz. Im hier beschrieben Setup sehe ich Potential. Und zwar Potential jemanden dazu zu befähigen seinen Setup auch selbst zu maintainen und wenn er das selbst kann, und vielleicht sogar upgrades am Wochenende macht weil er Spaß dran hat, sind downtimes gar kein so großes Problem mehr.
Und hier wird es natürlich unattraktiv für das Systemhaus, denn die bezahlt man in der Regel ja pro Einsatzstunde. Ja, individuelle Setups brauchen oft etwas mehr Zeit und Liebe, um sie am laufen zu halten, aber wenn man diese Zeit nicht übermäßig Teuer bezahlen muss, ist das manchmal einfach günstiger
Aber genug von diesem ganzen Unsinn und zurück zum Thema ;)
And den TO noch einen Hinweis: Wenn du XFS nimmst, bau dir ein LVM drunter (sollte dein Installer während der Partitionierung können) und fang mit kleinen volumes an. Empfehlung: 50GB. XFS kann im live betrieb wachsen, aber niemals schrumpfen, sprich wenn du irgendwann knapp mit Speicher bist, kann es haarig werden. Also kleine logische Volumes die man nach Bedarf wachsen lassen kann, die Befehle dafür findest du in entsprechenden Online tutorials, ist kein Hexenwerk ;)
Edit: Kleiner zusätzlicher Hinweis: Wenn du auf einem einzelnen Blech läufst, schau dass du einen Wartungsvertrag für deine Hardware hast, der entsprechend zeitnah (möglichst <24h) und vor Ort stattfindet.
@goscho danke für die Blumen ;)
In diesem Sinne
Gruß
Chris
Zitat von @Kraemer:
Mein Vorschlag an dich: Geh mal auf eine Fortbildung! Dann hätten wir hier einen weniger, der 80er-Jahre-Lowbudget-Strategien verteidigt.
In den 80-er hatte ich wirklich noch Lowbudget, war ich doch ein Teenie in der DDR. Mein Vorschlag an dich: Geh mal auf eine Fortbildung! Dann hätten wir hier einen weniger, der 80er-Jahre-Lowbudget-Strategien verteidigt.
Das was der TO beschrieben hat ist eine Frickellösung die üblicherweise von Firmen umgesetzt werden, die entweder
- einen übereifrigen Mitarbeiter haben, welcher dem Chef mal zeigen will, wie man Geld spart
- von einer IT-Schrauberbude betreut werden, deren einzige Fortbildung aus der aktuellen Computerbild kommt und vor Angst einen Auftrag nicht zu bekommen, jeden auch nur erdenklichen Mist umsetzen. Hauptsache billig.
Peng, der saß. - einen übereifrigen Mitarbeiter haben, welcher dem Chef mal zeigen will, wie man Geld spart
- von einer IT-Schrauberbude betreut werden, deren einzige Fortbildung aus der aktuellen Computerbild kommt und vor Angst einen Auftrag nicht zu bekommen, jeden auch nur erdenklichen Mist umsetzen. Hauptsache billig.
Was soll man von Leuten halten, die solche Sachen von sich geben:
Zitat von @Kraemer:
BTW: Server ohne Internet geht gar nicht: Heutzutage installiert man Sicherheitsupdates!
Als könnten Sicherheitsupdates nur mit direkter Internetanbindung eingespielt werden.BTW: Server ohne Internet geht gar nicht: Heutzutage installiert man Sicherheitsupdates!
An dieser Stelle disqualifizierst du dich selbst und es erübrigt sich eigentlich jedes weitere Wort zu deinen Kommentaren
aber ich kann nicht anders:
Ernsthaft: Ich finde es gut, das der TO hier nach einer professionellen Meinung fragt.
Und warum antwortest gerade du ihm dann?Du bist doch mit keiner Silbe auf sein Anliegen eingegangen. Ich würde mal sagen, weil du das Anliegen nicht verstanden hast.
Lies dir einfach auch mal den Eröffnungspost und die weiteren Erläuterungen des TO durch.
Lesen bildet. ;)
Und jetzt fehlt nur noch ein neuer Thread wo darüber gejammert wird, dass hier alle so gemein sind...
Anscheinend hast du noch nie einen Kommentar von mir gelesen.Achja, ich vergaß, das mit dem Lesen war nicht wirklich deine Stärke.
Dein Vorhaben lässt sich doch auf potenter Syno/QNAP-Hardware oder als Selbstbau NAS mit FreeNAS/napp-it mit OmniOS/OMV lösen.
ZFS und btrfs könntest auch noch auf die Lektüreliste setzen. Können Bhyve/KVM & qemu bzw. Docker, Datensicherung geht easy über rsync / ZFS send / oder via Plugins nach S3 / Glacier / Cloud deiner Wahl / externe HDD, etc.
Bei 3-4 Mitarbeitern und 10-15 Clients würde ich keine 4 stelligen Beträge für Betriebssysteme / Sicherungssoftware ausgeben.
Gilt natürlich nicht bei einer Expandierung / Vergrößerung.
ZFS und btrfs könntest auch noch auf die Lektüreliste setzen. Können Bhyve/KVM & qemu bzw. Docker, Datensicherung geht easy über rsync / ZFS send / oder via Plugins nach S3 / Glacier / Cloud deiner Wahl / externe HDD, etc.
Bei 3-4 Mitarbeitern und 10-15 Clients würde ich keine 4 stelligen Beträge für Betriebssysteme / Sicherungssoftware ausgeben.
Gilt natürlich nicht bei einer Expandierung / Vergrößerung.