9
Dateien MASSENWEISE umwuchten oder löschen
RAID Systeme umlagern
Suche Lösungsansätze für folgende Aufgabe:
Altes RAID-System 2TB - Windows 2003 Server - soll auf ein neues System mit 4TB umgezogen werden. ( Als einzige Verbindung zwischen den Systemen gibt es 1 GB-LAN
)
Dazu müssen 2TB an Bilddaten - 4Mio Dateien - in 25000 Ordnern auf das neue System kopiert werden.
Erschwerend kommt hinzu, dass sowohl die (Teil-)Ordnernamen als auch die Dateinamen mindestens 40 Stellen lang sind. ( Dämlich - aber Gott gegeben
)
d.h. in der root - dir /b > datei.txt ergibt eine Dateigrösse von > 1GB !!!
Frage1: Wie kann man MÖGLICHST SCHNELL die Dateien von S1 nach S2 kopieren?
Frage2: Wie kann man MÖGLICHST SCHNELL den Dateibaum löschen OHNE die Platten zu formatieren? ( Auf einem Teil des Systems wird noch gearbeitet )
Danke für Ideen.
Suche Lösungsansätze für folgende Aufgabe:
Altes RAID-System 2TB - Windows 2003 Server - soll auf ein neues System mit 4TB umgezogen werden. ( Als einzige Verbindung zwischen den Systemen gibt es 1 GB-LAN
)Dazu müssen 2TB an Bilddaten - 4Mio Dateien - in 25000 Ordnern auf das neue System kopiert werden.
Erschwerend kommt hinzu, dass sowohl die (Teil-)Ordnernamen als auch die Dateinamen mindestens 40 Stellen lang sind. ( Dämlich - aber Gott gegeben
)d.h. in der root - dir /b > datei.txt ergibt eine Dateigrösse von > 1GB !!!
Frage1: Wie kann man MÖGLICHST SCHNELL die Dateien von S1 nach S2 kopieren?
Frage2: Wie kann man MÖGLICHST SCHNELL den Dateibaum löschen OHNE die Platten zu formatieren? ( Auf einem Teil des Systems wird noch gearbeitet )
Danke für Ideen.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 47642
Url: https://administrator.de/forum/dateien-massenweise-umwuchten-oder-loeschen-47642.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
9 Kommentare
Neuester Kommentar
bei vielen kleinen dateien geht die kopiergeschwindigkeit über explorer bzw dateimanager arg in den keller, egal ob nun lan oder von platte zu platte.
das schnellste dürfte ein image der partition sein, z.b. mit acronis.
möglicherweise kann man auch mit einer replikationssoftware arbeiten, das ist zwar nicht schneller, kann aber im laufenden betrieb nebenbei gemacht werden. erster durchlauf replikation von allen dateien, danach ein zweiter durchlauf der nur noch die geänderten dateien kopiert.
zu frage 2:
da wird dir nur der klassische weg bleiben. wobei das löschen des dateibaums den betrieb nicht beeinträchtigen dürfte.
das schnellste dürfte ein image der partition sein, z.b. mit acronis.
möglicherweise kann man auch mit einer replikationssoftware arbeiten, das ist zwar nicht schneller, kann aber im laufenden betrieb nebenbei gemacht werden. erster durchlauf replikation von allen dateien, danach ein zweiter durchlauf der nur noch die geänderten dateien kopiert.
zu frage 2:
da wird dir nur der klassische weg bleiben. wobei das löschen des dateibaums den betrieb nicht beeinträchtigen dürfte.
Sehe ich teilweise auch so...
Also, wenn der Transfer echt nur über Netz geht, Total Commander nehmen.
Im Vergleich zum Win-Explorer geht das mit dem schneller.
Image, bäh, das is sicher eine Möglichkeit, halte ich bei dieser Dateimenge jedoch für unangemessen.
Was auch eine Möglichkeit wäre, sofern Hotswap...
Oder eben echt ein Sync-Tool...
Das mit dem Dateibaum, hm, da würde ich sagen, solltest Du Dich an das Forums-Mitglied Biber wenden, denn das Löschen kann in der Tat teilweise system-beeinträchtigend werden.
Besser wäre hier ein nettes Bätschelchen, das die Ordnerstruktur so nach und nach killt; sprich erst den einen Unterordner, dann den nächsten, etc...
Lonesome Walker
Also, wenn der Transfer echt nur über Netz geht, Total Commander nehmen.
Im Vergleich zum Win-Explorer geht das mit dem schneller.
Image, bäh, das is sicher eine Möglichkeit, halte ich bei dieser Dateimenge jedoch für unangemessen.
Was auch eine Möglichkeit wäre, sofern Hotswap...
Oder eben echt ein Sync-Tool...
Das mit dem Dateibaum, hm, da würde ich sagen, solltest Du Dich an das Forums-Mitglied Biber wenden, denn das Löschen kann in der Tat teilweise system-beeinträchtigend werden.
Besser wäre hier ein nettes Bätschelchen, das die Ordnerstruktur so nach und nach killt; sprich erst den einen Unterordner, dann den nächsten, etc...
Lonesome Walker
Danke.
hmmm ... Image: 2TB ist immer noch SEHR unhandlich.
Wo erstellen und wohin dann damit?
--
Hast du eine bestimmte Replikationssoftware im Sinn?
hmmm ... Image: 2TB ist immer noch SEHR unhandlich.
Wo erstellen und wohin dann damit?
--
Hast du eine bestimmte Replikationssoftware im Sinn?
ich hab gute erfahrungen mit vice versa pro 2 ( http://www.tgrmn.com ) gemacht. kann (fast) alles, ist einfach zu bedienen und kostet nicht viel. für deine anwendung dürfte interesant sein, das man prozesspriorität und die transferrate einstellen bzw. herunterregeln kann.
Moin bitrider,
ich würde versuchen, den Prozess soweit wie möglich zu parallelisieren, das heißt, ab einer gewissen "Tiefe" der vorhandenen Verzeichnisstruktur einzelne MOVE-Prozesse (also etwas mit wenig Overhead) zu starten.
Und vorher die "leere" Ordnerstruktur mit XCopy anlegen.
Ich denke, ein Dutzend Parallel-Bätche wird ein halbwegs zeitgemäßes System verkraften.
Beispiel: Wenn die Daten von einem Quellverzeichnis d:\Data nach \\neuServer\Altdaten sollen:
Dann würden in jedem vorhandenen Unterverzeichnis unter d:\data je ein MOVE-Prozess losgetreten werden... wenn in dieser zu wenig Unterzeichnisse sind, halt eine Ebene tiefer anfangen.
Vielleicht kannst Du mal kurz antesten, ob diese (theoretisch funktionierende) Strategie auch in der Praxis funktioniert.
Das Erzeugen der Ordnerstruktur kann ja nicht schaden... und ein paar MOVEs auch nicht...
Wenn das Prinzip funktioniert, lässt es sicher auch mit einer weiteren halben Zeile auf rekursive Abarbeitung der Verzeichnisstruktur aufbohren.
Das abschließende Löschen der leeren Verzeichnisse mit einer For/R-Anweisung und ggf. wieder gestarteten Parallel-Threads halte ich nicht für problematisch.
Ach, übrigens... wie groß wäre denn eine mit "dir /b A:d >ordner.txt" erzeugte Datei?
Gruß
Biber
ich würde versuchen, den Prozess soweit wie möglich zu parallelisieren, das heißt, ab einer gewissen "Tiefe" der vorhandenen Verzeichnisstruktur einzelne MOVE-Prozesse (also etwas mit wenig Overhead) zu starten.
Und vorher die "leere" Ordnerstruktur mit XCopy anlegen.
Ich denke, ein Dutzend Parallel-Bätche wird ein halbwegs zeitgemäßes System verkraften.
Beispiel: Wenn die Daten von einem Quellverzeichnis d:\Data nach \\neuServer\Altdaten sollen:
>Xcopy /s /T d:\data\*.* \\neuServer\Altdaten\
>for /d %i in (d:\data\*.*) do @for /d %j in ("%i\*.*") do Start /min Move /y "d:\data\%~nxj\*.*" "\\neuserver\Altdaten\%~nxj\" Vielleicht kannst Du mal kurz antesten, ob diese (theoretisch funktionierende) Strategie auch in der Praxis funktioniert.
Das Erzeugen der Ordnerstruktur kann ja nicht schaden... und ein paar MOVEs auch nicht...
Wenn das Prinzip funktioniert, lässt es sicher auch mit einer weiteren halben Zeile auf rekursive Abarbeitung der Verzeichnisstruktur aufbohren.
Das abschließende Löschen der leeren Verzeichnisse mit einer For/R-Anweisung und ggf. wieder gestarteten Parallel-Threads halte ich nicht für problematisch.
Ach, übrigens... wie groß wäre denn eine mit "dir /b A:d >ordner.txt" erzeugte Datei?
Gruß
Biber
Hallo Biber!
du bist offensichtlich auch ein FAN-DER-DOS-BOX
<grins> TIPPER haben immer andere Ansätze als MAUSER
JA!
So hab ich mir's auch vorgestellt.
hm - klingt nicht falsch; aber ich versteh nicht, warum's GUT ist?!
Jeder (x)copy macht eine Systemlast von 2-3%
... da gehen schon ein paaaar.
Beispiel: Wenn die Daten von einem
Quellverzeichnis d:\Data nach
\\neuServer\Altdaten sollen:
Dann würden in jedem vorhandenen
Unterverzeichnis unter d:\data je ein
MOVE-Prozess losgetreten werden... wenn in
dieser zu wenig Unterzeichnisse sind, halt
eine Ebene tiefer anfangen.
Vielleicht kannst Du mal kurz antesten, ob
diese (theoretisch funktionierende) Strategie
auch in der Praxis funktioniert.
Das Erzeugen der Ordnerstruktur kann ja
nicht schaden... und ein paar MOVEs auch
nicht...
Den echten transfer mit einem move zu machen ist ne coole Idee!
1,65MB
Meine erste Idee war, wie kann ich mehrere xcopys parallel laufen lassen.
Weil der stumpfe xcopy *.* ziel /s dauert ewig...
Dann hab ich mich geärgert weil
xcopy TEILVERZEICHNIS1\*.* ziel /s
gibt's nicht.
du bist offensichtlich auch ein FAN-DER-DOS-BOX
<grins> TIPPER haben immer andere Ansätze als MAUSER
ich würde versuchen, den Prozess soweit
wie möglich zu parallelisieren, das
heißt, ab einer gewissen
"Tiefe" der vorhandenen
Verzeichnisstruktur einzelne MOVE-Prozesse
(also etwas mit wenig Overhead) zu starten.
wie möglich zu parallelisieren, das
heißt, ab einer gewissen
"Tiefe" der vorhandenen
Verzeichnisstruktur einzelne MOVE-Prozesse
(also etwas mit wenig Overhead) zu starten.
JA!
So hab ich mir's auch vorgestellt.
Und vorher die "leere"
Ordnerstruktur mit XCopy anlegen.
Ordnerstruktur mit XCopy anlegen.
hm - klingt nicht falsch; aber ich versteh nicht, warum's GUT ist?!
Ich denke, ein Dutzend Parallel-Bätche
wird ein halbwegs zeitgemäßes
System verkraften.
wird ein halbwegs zeitgemäßes
System verkraften.
Jeder (x)copy macht eine Systemlast von 2-3%
... da gehen schon ein paaaar.
Beispiel: Wenn die Daten von einem
Quellverzeichnis d:\Data nach
\\neuServer\Altdaten sollen:
>Xcopy /s /T d:\data\*.*
> \\neuServer\Altdaten\
> >for /d %i in (d:\data\*.*) do @for /d %j
> in ("%i\*.*") do Start /min Move
> /y "d:\data\%~nxj\*.*"
> "\\neuserver\Altdaten\%~nxj\"
> Unterverzeichnis unter d:\data je ein
MOVE-Prozess losgetreten werden... wenn in
dieser zu wenig Unterzeichnisse sind, halt
eine Ebene tiefer anfangen.
Vielleicht kannst Du mal kurz antesten, ob
diese (theoretisch funktionierende) Strategie
auch in der Praxis funktioniert.
Das Erzeugen der Ordnerstruktur kann ja
nicht schaden... und ein paar MOVEs auch
nicht...
Wenn das Prinzip funktioniert, lässt es
sicher auch mit einer weiteren halben Zeile
auf rekursive Abarbeitung der
Verzeichnisstruktur aufbohren.
Das abschließende Löschen der
leeren Verzeichnisse mit einer
For/R-Anweisung und ggf. wieder gestarteten
Parallel-Threads halte ich nicht für
problematisch.
Ach, übrigens... wie groß
wäre denn eine mit "dir /b A:d
>ordner.txt" erzeugte Datei?
sicher auch mit einer weiteren halben Zeile
auf rekursive Abarbeitung der
Verzeichnisstruktur aufbohren.
Das abschließende Löschen der
leeren Verzeichnisse mit einer
For/R-Anweisung und ggf. wieder gestarteten
Parallel-Threads halte ich nicht für
problematisch.
Ach, übrigens... wie groß
wäre denn eine mit "dir /b A:d
>ordner.txt" erzeugte Datei?
1,65MB
Meine erste Idee war, wie kann ich mehrere xcopys parallel laufen lassen.
Weil der stumpfe xcopy *.* ziel /s dauert ewig...
Dann hab ich mich geärgert weil
xcopy TEILVERZEICHNIS1\*.* ziel /s
gibt's nicht.
Gruß
Biber
Biber
Moin!
Will mich ja in eure Batchschreiberei nicht einmischen, aber wollte mal so am Rande bemerken:
Wie sieht das mit der Übernahme der Verzwichnisberechigungen aus, sollen die mit auf den neuen Server übernommen werden? Wenn ja, dann würde ich robocopy aus dem Res.-Kit statt xcopy empfehlen.
my 5 ct.
Ralf
P.S: Allen einen guten Rutsch!
Will mich ja in eure Batchschreiberei nicht einmischen, aber wollte mal so am Rande bemerken:
Wie sieht das mit der Übernahme der Verzwichnisberechigungen aus, sollen die mit auf den neuen Server übernommen werden? Wenn ja, dann würde ich robocopy aus dem Res.-Kit statt xcopy empfehlen.
my 5 ct.
Ralf
P.S: Allen einen guten Rutsch!
Moin!
Will mich ja in eure Batchschreiberei nicht
einmischen, aber wollte mal so am Rande
bemerken:
Will mich ja in eure Batchschreiberei nicht
einmischen, aber wollte mal so am Rande
bemerken:
MachNur-MachNur
Bin für ALLES dankbar!Wie sieht das mit der Übernahme der
Verzwichnisberechigungen aus, sollen die mit
auf den neuen Server übernommen werden?
Verzwichnisberechigungen aus, sollen die mit
auf den neuen Server übernommen werden?
Berechtigungen klassisch... ALLE dürfen ALLES ...
Wenn ja, dann würde ich robocopy aus dem
Res.-Kit statt xcopy empfehlen.
Res.-Kit statt xcopy empfehlen.
In meiner Verzweiflung hab ich robocopy dann auch verwendet
Aber bis man die Parameter-Liste gelesen (und teilweise verstanden) hat, hat man nen weissen Bart
Also RICHTIG cool ist es nicht...
Und nachdem diese Aufgabe bei jedem von uns IMMER IMMER wieder kommt (vielleicht nicht in DEM Umfang) will ich da eine richtige Lösung !!!
Bisher finde ich den Parallelprozess-Gedanken immer noch am nettesten.
my 5 ct.
Ralf
P.S: Allen einen guten Rutsch!
Moin bitrider,
ich wollte auch nur meine Strategieüberlegungen loswerden, noch keine Patentlösung anbieten...
Zu Deinen Fragen:
Weil sich der MOVE-Befehl nur verwenden lässt, wenn denn das Zielverzeichnis schon da ist.
Zu n.o.b.o.d.y. /Ralfs Ergänzungen:
Wenn die Strategie denn Parallelisierung sein soll, wäre sicherlich
- der MOVE-Befehl der schlankeste. Aber auch der am wenigsten mächtigste - da geht weder Verzeichnisse anlegen noch Rechte übertragen noch rekursives Verzeichnisse-Abarbeiten.
- Robocopy wäre der komfortabelste Allrounder. Allerdings auch ein Klotz, der sich schlecht in einem Dutzend Parallelthreads starten lässt. Kennt aber auch ein /MOVE.
-XCopy wäre ein brauchbarer Kompromiss zwischen Funktionalität und Ressourcenfresserei - mit zwei Einschränkungen. Erstens ist XCopy einer der wenigen M$-Befehle, der dokumentierterweise den Fehler "Zu wenig Hauptspeicher zum Weitermachen" kennt. Und der kennt den Fehler nicht nur, sondern stürzt sich auch in der Tat bei größeren Datenmengen sehenden Auges in genau dieses Verderben. Zweitens hat XCopy alles mögliche an Parametern, aber eben keinen /Move oder /DeleteAfterCopy-Parameter.
Zwischen den drei Werkzeugen würde ich abwägen und - wie oben beschrieben - ich wäre dann zu der Strategie gekommen, die Verzeichnisstruktur mit "XCopy /T" anzulegen und das Verschieben mit dem MOVE-Befehl abzufackeln.
Falls es natürlich irgendwo ein Multi-Thread-Kopiertool gibt, das ähnlich wie ein Downloadmanager die Daten in Parallel-Prozessen kopiert, würde ich auch dieses nehmen. (Aber erfinden würde ich keins... bestenfalls Aufwand in 5 oder 6 Zeilen Batch stecken.)
@bitrider:
Hast Du denn mal einen kurzen Test gemacht, wie sich so ein "Multi-Thread-Kopieren" verhält?
Mir fehlen hier ein bisschen Deine TByte-großen Testdaten....
Gruß
Biber
ich wollte auch nur meine Strategieüberlegungen loswerden, noch keine Patentlösung anbieten...
Zu Deinen Fragen:
Und vorher die "leere" Ordnerstruktur mit XCopy anlegen.
hm - klingt nicht falsch; aber ich versteh nicht, warum's GUT ist?!Weil sich der MOVE-Befehl nur verwenden lässt, wenn denn das Zielverzeichnis schon da ist.
Zu n.o.b.o.d.y. /Ralfs Ergänzungen:
Wenn die Strategie denn Parallelisierung sein soll, wäre sicherlich
- der MOVE-Befehl der schlankeste. Aber auch der am wenigsten mächtigste - da geht weder Verzeichnisse anlegen noch Rechte übertragen noch rekursives Verzeichnisse-Abarbeiten.
- Robocopy wäre der komfortabelste Allrounder. Allerdings auch ein Klotz, der sich schlecht in einem Dutzend Parallelthreads starten lässt. Kennt aber auch ein /MOVE.
-XCopy wäre ein brauchbarer Kompromiss zwischen Funktionalität und Ressourcenfresserei - mit zwei Einschränkungen. Erstens ist XCopy einer der wenigen M$-Befehle, der dokumentierterweise den Fehler "Zu wenig Hauptspeicher zum Weitermachen" kennt. Und der kennt den Fehler nicht nur, sondern stürzt sich auch in der Tat bei größeren Datenmengen sehenden Auges in genau dieses Verderben. Zweitens hat XCopy alles mögliche an Parametern, aber eben keinen /Move oder /DeleteAfterCopy-Parameter.
Zwischen den drei Werkzeugen würde ich abwägen und - wie oben beschrieben - ich wäre dann zu der Strategie gekommen, die Verzeichnisstruktur mit "XCopy /T" anzulegen und das Verschieben mit dem MOVE-Befehl abzufackeln.
Falls es natürlich irgendwo ein Multi-Thread-Kopiertool gibt, das ähnlich wie ein Downloadmanager die Daten in Parallel-Prozessen kopiert, würde ich auch dieses nehmen. (Aber erfinden würde ich keins... bestenfalls Aufwand in 5 oder 6 Zeilen Batch stecken.)
@bitrider:
Hast Du denn mal einen kurzen Test gemacht, wie sich so ein "Multi-Thread-Kopieren" verhält?
Mir fehlen hier ein bisschen Deine TByte-großen Testdaten....
Gruß
Biber
