26
Idee für smb?
wir haben etwa 13TB nutzdaten verteilt auf 2 vm's liegen, aktuell migriere ich die 2 vm's per dfs auf einen smb/vm.
Dauert ewiiiiiigkeiten *gähn*.
Hatte mal versucht das zeug direkt auf ein flashstorge zu legen, war ein total flop.
Wie macht ihr das? insbesondere Backup/Restore bei solchen Mengen kleiner Daten und niemand will was archivieren oder gar löschen..
Dauert ewiiiiiigkeiten *gähn*.
Hatte mal versucht das zeug direkt auf ein flashstorge zu legen, war ein total flop.
Wie macht ihr das? insbesondere Backup/Restore bei solchen Mengen kleiner Daten und niemand will was archivieren oder gar löschen..
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 94118164553
Url: https://administrator.de/contentid/94118164553
Printed on: April 27, 2024 at 18:04 o'clock
26 Comments
Latest comment
Moin,
ist halt ne Frage des Storage und der Anbindung. Worauf liegen die Daten? Was ist das Ziel? Wie sieht die Netzwerk Anbindung aus?
Und klar, viele kleine Daten brauchen viel länger als große zusammenhängende Dateien. Insbesondere auf alten Spindeln.
Ich denke du fährst da max 10G, oder?
Gruß
Spirit
ist halt ne Frage des Storage und der Anbindung. Worauf liegen die Daten? Was ist das Ziel? Wie sieht die Netzwerk Anbindung aus?
Und klar, viele kleine Daten brauchen viel länger als große zusammenhängende Dateien. Insbesondere auf alten Spindeln.
Ich denke du fährst da max 10G, oder?
Gruß
Spirit
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Zitat von @Spirit-of-Eli:
Moin,
ist halt ne Frage des Storage und der Anbindung. Worauf liegen die Daten? Was ist das Ziel? Wie sieht die Netzwerk Anbindung aus?
Und klar, viele kleine Daten brauchen viel länger als große zusammenhängende Dateien. Insbesondere auf alten Spindeln.
Ich denke du fährst da max 10G, oder?
Gruß
Spirit
Moin,
ist halt ne Frage des Storage und der Anbindung. Worauf liegen die Daten? Was ist das Ziel? Wie sieht die Netzwerk Anbindung aus?
Und klar, viele kleine Daten brauchen viel länger als große zusammenhängende Dateien. Insbesondere auf alten Spindeln.
Ich denke du fährst da max 10G, oder?
Gruß
Spirit
Servus,
die Daten liegen als vm auf flash Anbindung 100G. Das Ziel ist natürlich eine möglichst hohe verfügbarkeit sowie optimaler performance beim backup und recovery. >60% der Daten sind im KB bereich, furchtbar.
Zitat von @ElmerAcmeee:
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Zitat von @user217:
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Zitat von @ElmerAcmeee:
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Zitat von @Spirit-of-Eli:
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Zitat von @user217:
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Zitat von @ElmerAcmeee:
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
In der VM läuft ein 2016 Win Server. Kannst du mir das bitte näher erklären, davon hab ich noch nie gehört?
Zitat von @user217:
In der VM läuft ein 2016 Win Server. Kannst du mir das bitte näher erklären, davon hab ich noch nie gehört?
Zitat von @Spirit-of-Eli:
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Zitat von @user217:
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Zitat von @ElmerAcmeee:
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Moin,
genauso.
Wenn möglich die Filer VMs inhaltlich trennen. Aber wenn's nicht anders geht, wird so ein Filer auch mal paar TB groß.
Unser Storage macht Dedup. Dem ist es eh egal ob ein oder viele VMs.
Der Trend beim Backup geht Richtung Synthetic Full. Dies wäre dann also auch egal.
SMB direkt vom Storage > meine persönliche Erfahrung sagt: nein.
Für die Migration nutzte ich bislang immer Robocopy. Nach dem ersten Sync nur noch Deltas.
Von MS gibt es aber auch ein Tool dazu.
Gruß und viel Erfolg
Hallo,
ja dedup wäre in dem Fall top, hatten wir als spindel Lösung aber kann unser store aktuell nicht und werden ihn deshalb auch nicht rauswerfen.
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
In der VM läuft ein 2016 Win Server. Kannst du mir das bitte näher erklären, davon hab ich noch nie gehört?
Gibts alles nach einer kurzen suche.
https://www.windowspro.de/wolfgang-sommergut/daten-deduplizieren-windows ...
@user217
Moin,
wirklich effektiv an der Datenübertragung sehr vieler kleiner Dateien kann man nicht verbessern. Da helfen auch superschnelle Süds nicht, da das Daten-Handshake über die Leitung eben so viel Performance schluckt.
Eine Überlegung wert wäre ggf da eher, wenn es der Datenbestand erlaubt vieles als ISO-Dateien zusammenzufassen und nur noch Read-only anzubieten. So kann man viele kleine Dateien in eine große packen.
Kreuzberger
Moin,
wirklich effektiv an der Datenübertragung sehr vieler kleiner Dateien kann man nicht verbessern. Da helfen auch superschnelle Süds nicht, da das Daten-Handshake über die Leitung eben so viel Performance schluckt.
Eine Überlegung wert wäre ggf da eher, wenn es der Datenbestand erlaubt vieles als ISO-Dateien zusammenzufassen und nur noch Read-only anzubieten. So kann man viele kleine Dateien in eine große packen.
Kreuzberger
Zitat von @kreuzberger:
@user217
Moin,
wirklich effektiv an der Datenübertragung sehr vieler kleiner Dateien kann man nicht verbessern. Da helfen auch superschnelle Süds nicht, da das Daten-Handshake über die Leitung eben so viel Performance schluckt.
Eine Überlegung wert wäre ggf da eher, wenn es der Datenbestand erlaubt vieles als ISO-Dateien zusammenzufassen und nur noch Read-only anzubieten. So kann man viele kleine Dateien in eine große packen.
Kreuzberger
@user217
Moin,
wirklich effektiv an der Datenübertragung sehr vieler kleiner Dateien kann man nicht verbessern. Da helfen auch superschnelle Süds nicht, da das Daten-Handshake über die Leitung eben so viel Performance schluckt.
Eine Überlegung wert wäre ggf da eher, wenn es der Datenbestand erlaubt vieles als ISO-Dateien zusammenzufassen und nur noch Read-only anzubieten. So kann man viele kleine Dateien in eine große packen.
Kreuzberger
Du kannst auch anstatt .iso einige Ordner in ein .zip packen. Das hilft auch schon ungemein.
@Spirit-of-Eli
..im Prinzip auch das. Aber ein ISO hat den Vorteil, dass man es live mounten kann und so direkt als Laufwerk oder Pfad anhängen kann als Freigabe. Das geht per ZIP-Datei wohl eher nicht.
Kreuzberger
„Süds“ sollte SSDs heissen.
..im Prinzip auch das. Aber ein ISO hat den Vorteil, dass man es live mounten kann und so direkt als Laufwerk oder Pfad anhängen kann als Freigabe. Das geht per ZIP-Datei wohl eher nicht.
Kreuzberger
„Süds“ sollte SSDs heissen.
Ich dachte eher an die Übertragung.
Ich weiß nicht ob das mounten einer ISO den transfer der Dateien darin schneller macht. Wird die ISO dafür nicht auch erst über tragen?
Ich weiß nicht ob das mounten einer ISO den transfer der Dateien darin schneller macht. Wird die ISO dafür nicht auch erst über tragen?
@Spirit-of-Eli
das sind unterschiedliche Anwendungsideen.
Nur zum Übertragen ist die große ISO eben schneller als tausende Minidateien. Das ist klar.
Für den laufenden Betrieb und Zugriff auf die Minidateien, was auch immer das ist, haben wir damals auf Linux-Basis ISO-Dateien (Inhalt waren Schrift-Font-CDs) als Read-Only-Verzeichnis freigegeben. Das sah für die User so aus, als wäre es eine Server-Freigabe, Server-intern war es eine ISO-Datei.
Wie das mit Windows geht weiss ich leider nicht. Grundsätzlich war das aber aus ähnlichem Grund und eben praktisch. (GGf. weiss jemand hier, wie das mit Windows machbar wäre?)
Eine ISO als Freigabe kann aber eben nunmal nur als Read-Only freigegeben werden.
Kreuzberger
das sind unterschiedliche Anwendungsideen.
Nur zum Übertragen ist die große ISO eben schneller als tausende Minidateien. Das ist klar.
Für den laufenden Betrieb und Zugriff auf die Minidateien, was auch immer das ist, haben wir damals auf Linux-Basis ISO-Dateien (Inhalt waren Schrift-Font-CDs) als Read-Only-Verzeichnis freigegeben. Das sah für die User so aus, als wäre es eine Server-Freigabe, Server-intern war es eine ISO-Datei.
Wie das mit Windows geht weiss ich leider nicht. Grundsätzlich war das aber aus ähnlichem Grund und eben praktisch. (GGf. weiss jemand hier, wie das mit Windows machbar wäre?)
Eine ISO als Freigabe kann aber eben nunmal nur als Read-Only freigegeben werden.
Kreuzberger
1
Ja, Datenhygenie würde schon viel helfen. Wenn jeder User sein ungenutztes Zeug auch mal wieder löschen oder zumindest in ein archiv packen würde. Das ist schwer vermitellbar/umsetzbar.
Gibt es vielleicht irgendein Script/Tool was alles das älter als X ist zuverlässig archiviert und anschließend die Quelldaten löscht? Keine Kommandozeile für robocopy/7zip..
Aber selbst wenn befürchte ich dass das in Hose geht, glaub das ist reine Handarbeit.
Gibt es vielleicht irgendein Script/Tool was alles das älter als X ist zuverlässig archiviert und anschließend die Quelldaten löscht? Keine Kommandozeile für robocopy/7zip..
Aber selbst wenn befürchte ich dass das in Hose geht, glaub das ist reine Handarbeit.
@user217 da wird man wohl eine generelle Regel mit der Geschäftsleitung finden müssen, die du dann mit deren Rückendeckung durchsetzt.
Daten ab dem Alter YYYYMMTT lassen sich mit robocopy und anderen tools umsetzen .
Kreuzberger
Daten ab dem Alter YYYYMMTT lassen sich mit robocopy und anderen tools umsetzen .
Kreuzberger
Da gebe ich dir recht, ich hol mir was schriftliches und nehme ein dickes Archiv NAS auf das alle Daten älter 5 Jahre Änderungsdatum hinverschoben werden.
@user217 Logisch ist, dass diese Daten eben Imme rmehr werden. Das wird wie ich es verstanden habe nie aufhören. Erkläre der GF, dass es ein Technisches Problem ist, und dass das Problem wenn man nichts tut imemr größer wird von Jahr zu Jahr. Lösen kann man es eben dann mit einem Archivspeicher, der Extra mitläuft.
(Ich hatte so ein Problem mal mit einem eMail-Server, wo speziell ein Account über 50.000 Mails enthielt, die man ja ALLE ständig bräuchte.)
Kreuzberger
(Ich hatte so ein Problem mal mit einem eMail-Server, wo speziell ein Account über 50.000 Mails enthielt, die man ja ALLE ständig bräuchte.)
Kreuzberger
Entweder die Eigentümer der Daten machen das oder Vorschlaghammer. Alles andere ist sinnfrei.
Das beste wäre ein Rundmail mit der Anweisung benötigte Daten auf den neuen zu schieben, den alten noch X Zeit laufen zu lassen und nach ablauf dieser abzuschalten. Wenn jemand was braucht einschalten, ende.
Das beste wäre ein Rundmail mit der Anweisung benötigte Daten auf den neuen zu schieben, den alten noch X Zeit laufen zu lassen und nach ablauf dieser abzuschalten. Wenn jemand was braucht einschalten, ende.
1
@user217 Wenn man so einen Extra Archivspeicher hat, kann man den zb. ein Mal pro Jahr auffrischen und Daten aus dem Produktivbereich aussortieren. Bedeutet: Backup vom Archivspeicher nur ein Mal pro Jahr reicht.
Backup vom Produktivbereich ggf. täglich, aber dafür deutlich schneller.
Datensuche der User auf dem Produktivbereich wird ebenfalls deutlich minimiert und schneller.
Ich finde solche Vorgehensweise für alle deutlich entspannter.
Kreuzberger
Backup vom Produktivbereich ggf. täglich, aber dafür deutlich schneller.
Datensuche der User auf dem Produktivbereich wird ebenfalls deutlich minimiert und schneller.
Ich finde solche Vorgehensweise für alle deutlich entspannter.
Kreuzberger
@user217 ach ja, am ende gibt es bei Windows Server dann noch eine tolle „Zwangsmaßnahme“: das nennt sich „Kontingent".
Kreuzberger
Kreuzberger
Moin @user217:
kopierst du die Daten zufällig über den Windows Explorer?
Gruss Alex
Dauert ewiiiiiigkeiten *gähn*.
kopierst du die Daten zufällig über den Windows Explorer?
Gruss Alex
Zitat von @kreuzberger:
@user217 ach ja, am ende gibt es bei Windows Server dann noch eine tolle „Zwangsmaßnahme“: das nennt sich „Kontingent".
Kreuzberger
@user217 ach ja, am ende gibt es bei Windows Server dann noch eine tolle „Zwangsmaßnahme“: das nennt sich „Kontingent".
Kreuzberger
ich weiß, unmöglich umzusetzen. Drama
Zitat von @MysticFoxDE:
Moin @user217:
kopierst du die Daten zufällig über den Windows Explorer?
Gruss Alex
Moin @user217:
Dauert ewiiiiiigkeiten *gähn*.
kopierst du die Daten zufällig über den Windows Explorer?
Gruss Alex
um gottes willen
Hat Gott einen AD Account?
Kreuzberger
Kreuzberger
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Das ist gigantisch wieviel mal da sparen kann, danke nochmals für den Hinweis!
Zitat von @user217:
Das ist gigantisch wieviel mal da sparen kann, danke nochmals für den Hinweis!
Was läuft denn in der VM.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Mach doch da dedub. Du kannst ja sogar unter Windows prüfen wie hoch die Ersparnisse wäre.
Das ist gigantisch wieviel mal da sparen kann, danke nochmals für den Hinweis!
Denke aber daran, das hilft dir nix beim über tragen. Dadurch muss trotzdem alles mehrfach gesendet werden.
Klar, trotzdem 1 Klasse. Danke.