Externe SSD gesucht.

Die Anschlussfrage wäre, ob das Mainboard überhaupt eine Erweiterungskarte mit 4x64 Gbps unterstützen könnte.
Laut MSI B550 Tomahawk Infosheet wohl eher nicht.
Korrekt, solange Du eine Grafikkarte sinnvoll benutzen willst, also in dem oberen vollbeschalteten PEG-Steckplatz mit 16x Lanes, bleibt bei Deinem Board lediglich der untere 3.0x4 Steckplatz, also 1x32Gbps, wo Du genau EINE PCIe/NVMe-SSD direkt benutzen kannst.
würden PCIe 4.0 Karten mit hohen Schreibgeschwindigkeiten (wie z.B. meine
Samsung 980 PRO NVMe M.2 SSD, 2 TB, PCIe 4.0, 7.000 MB/s Lesen, 5.000 MB/s Schreiben) allerdings von der Steckkarte ausgebremst werden
Absolut richtig, jedoch weniger "von der Steckkarte", sondern viel mehr von dem MB-Slot selbst - werden auf maximale Geschwindigkeiten der PCIe3.0x4 Schnittstelle, im Klartext: 980Pro bringt dann ca. 3500-3600 MB/s maximal sequentiell, was aber nicht arg tragisch ist (bei Deiner Anwendung mit vielen kleinen Dateien sind das vielleicht 10-20% Verlust).
Deswegen hatte ich überlegt, ob so eine von dir genannte Erweiterungskarte mal nützlich werden könnte.
In deinem Geizhals Screenshot sind meine beiden M2 Steckplätze belegt, PCIe 4.0 x16 nutzt die Graka, womit die Adapterkarte

4 Port M.2 NVME SSD To PCIE X16 Host Controller Expansion Card 4X32Gbps​

dann am PCIe 3.0 x16 (x4) Port hängen würde.
Natürlich wäre kaum nützlich - jede M.2-NVMe-SSD nutzt 4x Lanes und in einem "PCIe 3.0 x16 (x4) Port" würde natürlich auch nur eine SSD funktionieren, sprich: in so einem 4xSSD-zu-16-Lanes-Adapter würde nur der erste Steckplatz funktionieren und genauso kannst Du einen einfacheren und günstigeren Adapter für EINE SSD dort einsetzen, z.B.:
Würde halt auch maximal 3.0x4 bringen (wegen dem Slot, obwohl der Adapter an sich 4.0 kann), aber, wie schon gesagt, ist das nicht arg tragisch und Deine aktuell beste Möglichkeit eine weitere NVMe-SSD anzuschließen.
x4 da ist dann Schluss bei 3,9 GBs, ....
Brutto "auf dem Papier" 3,9 GB/s, netto grob 3,5 GB/s
..., dann geh doch lieber über Typ USB-C 10 GBs
Schön wäre es, sogar USB4 kann maximal ~4GB/s und kommende USB4v2 maximal 8GB/s...
Und wenn Du 10 Gbps gemeint hast, dann siehe in meinem Post weiter oben: Post #3, mit 10Gbps@USB kommt man maximal auf 1GB/s.
 
Bei dieser Art des Kopierens werden nur die veränderten Daten kopiert. Es werden aber alle Veränderungen über Datumsstempel / Dateigrößen erkannt, korrekt?
robocopy vergleicht Dateinamen und Dateiattribute (dazu gehören auch alle Zeitstempel). Wenn alles identisch --> überspringen, wenn irgendwas abweichend --> überschreiben mit neuer Datei.
Das einzige was robocopy nicht erkennen würde ist, wenn innerhalb einer Datei ein ungewollter Fehler auftritt, etwa ein gekipptes Bit, da keine Prüfsummen erstellt/verglichen werden. Bedeutet "kaputte" Dateien, Übertragungsfehler usw. kann robocopy nicht erkennen.
Was hier wahrscheinlich nicht klappt ist das Löschen von Dateien im Backup, die auf dem eigentlich Datenträger entfernt wurden.
Doch, natürlich - das ist der "/mir" befehl hinter robocopy.
Das Zielverzeichnis wird nach dem Befehl eine exakte Kopie des Quellverzeichnisses sein. Alle Date(ie)n, die im Ziel zusätzlich vorhanden waren werden gelöscht - daher auch die Pfade im Befehl vorher genau prüfen!
Alle diese Vorgänge werden in der Logdatei aufgeschrieben (wenn du meine Befehlszeile oben benutzt).

Du kannst es ja einfach mal mit nem Testverzeichnis und dummy-Dateien ausprobieren. ;-)
 
Ich habe das gerade gelesen, das Mit der Pcikarte kannste vergessen.

∙ 1x PCIe 4.0/ 3.0 x16 slot (PCI_E1)*
∙ 1x PCIe 3.0 x16 slot (PCI_E3), supports x4 speed**
∙ 2x PCIe 3.0 x1 slots
* The supported specification depends on installed processor.
** When installing devices in M.2_2, PCI_E2 & PCI_E3 slots at the same time,
PCI_E3 slot will be unavailable, and M2_2 slot only supports PCIe x2. Please
refer to page 29 for details
Brutto "auf dem Papier" 3,9 GB/s, netto grob 3,5 GB/s

Schön wäre es, sogar USB4 kann maximal ~4GB/s und kommende USB4v2 maximal 8GB/s...
Und wenn Du 10 Gbps gemeint hast, dann siehe in meinem Post weiter oben: Post #3, mit 10Gbps@USB kommt man maximal auf 1GB/s.
Ok, ich danke dir für die Information, bei GEN2 sind das sogar 1200 MB/s.
 
Wie kam das Thema überhaupt von einer externen Backup-SSD auf interne PCIe-M.2 Adaper?
Intern und Backup ist für mich per se Humbug.

Das einzige was robocopy nicht erkennen würde ist, wenn innerhalb einer Datei ein ungewollter Fehler auftritt, etwa ein gekipptes Bit, da keine Prüfsummen erstellt/verglichen werden.
Es mag so langsam abdriften aber weißt du ob "verify on" mit robocopy funktioniert? Das findet man ja in so manchem Suchergebnis aber scheinbar weiß doch niemand, ob das wirklich funktioniert.
 
Es mag so langsam abdriften aber weißt du ob "verify on" mit robocopy funktioniert? Das findet man ja in so manchem Suchergebnis aber scheinbar weiß doch niemand, ob das wirklich funktioniert.
Der Befehl funktioniert, macht aber nicht das, was viele glauben/erwarten (weil der gleichnamige Befehl aus DOS-Zeiten was anderes macht). ;-)

verify on ist KEIN CRC-Check und erkennt keine Bitflips oder ähnliches. Die Funktion nutzt nur die übliche Fehlerkorrektur der ganzen verwendeten Standards um zu erkennen wenn was (grob) schiefgelaufen ist - das, was ein normaler Explorer-Kopiervorgang auch tun würde ("Kopieren fehlgeschlagen"-Meldung kennt vielleicht der eine oder andere oder das mehrfache Leseversuchen wenn was nicht funktioniert wie geplant... manch einer kennt noch die elenden dadurch hoch und runterdrehenden CD/DVD-Laufwerke...).

Ein echtes verify im Sinne von die kopierte Datei nopchmals einlesen und bit für bit mit dem Original vergleichen ist das nicht - dass das nicht passieren kann sieht man schon alleine daran, dass robocopy zwischen PCIe-SSDs mit mehreren GB/s Daten schieben kann ohne nennenswert CPU-Last zu generieren. Müsste die CPU Daten abgleichen oder Prüfsummen raushauen in der Geschwindigkeit würden auch neue CPUs ganz schön schwitzen.
 
Zuletzt bearbeitet:
Der Befehl funktioniert, macht aber nicht das, was viele glauben/erwarten (weil der gleichnamige Befehl aus DOS-Zeiten was anderes macht). ;-)

verify on ist KEIN CRC-Check und erkennt keine Bitflips oder ähnliches. Die Funktion nutzt nur die übliche Fehlerkorrektur der ganzen verwendeten Standards um zu erkennen wenn was (grob) schiefgelaufen ist - das, was ein normaler Explorer-Kopiervorgang auch tun würde ("Kopieren fehlgeschlagen"-Meldung kennt vielleicht der eine oder andere oder das mehrfache Leseversuchen wenn was nicht funktioniert wie geplant... manch einer kennt noch die elenden dadurch hoch und runterdrehenden CD/DVD-Laufwerke...).

Ein echtes verify im Sinne von die kopierte Datei nopchmals einlesen und bit für bit mit dem Original vergleichen ist das nicht - dass das nicht passieren kann sieht man schon alleine daran, dass robocopy zwischen PCIe-SSDs mit mehreren GB/s Daten schieben kann ohne nennenswert CPU-Last zu generieren. Müsste die CPU Daten abgleichen oder Prüfsummen raushauen in der Geschwindigkeit würden auch neue CPUs ganz schön schwitzen.
Nochmal ein Nachtrag zu Robocopy:
Inzwischen habe ich ein paar Versuche gestartet, die waren auch teilweise erfolgreich. Komischerweise habe ich aber noch Probleme damit, ganze Laufwerke zu kopieren:
Code:

@echo off

Robocopy "D:\Alt" G:\D /MIR

echo Robocopy liefert folgendes Ergebnis: %errorlevel%

pause

Wenn ich als Quelle nun "D:\" verwende, dann bekomme ich die Fehlermeldung, dass kein Zielverzeichnis(!) angegeben wurde.

Ich könnte jetzt natürlich viele Batchdateien für alle Ordner unter D: erstellen, aber ich gehe stark davon aus, dass ich hier nur irgendwas beachten muss und es dann doch geht.

Anbei auch nochmal ein Danke an alle für die vielen Beiträge. Immer wieder schön etwas neues zu lernen!
 
Robocopy kann iirc keine ganzen Partitionen sondern nur Ordner (man korrigiere mich wenn ich mich irre).

Du brauchst aber keine mehreren Bauchdateien, du kannst in eine auch mehrere Zeilen untereinander schreiben - das ist ja grade der Sinn von Batch bzw CMD. ;-)

robocopy E:\1 M:\DATA\1 /mir
robocopy E:\2 M:\DATA\2 /mir
robocopy E:\3 M:\DATA\3 /mir

Usw.
 
Danke für die flotte Antwort. Dann doch der kleine Workaround. Damit werde ich mir ein passendes Skript schreiben und beim nächsten Backup nutzen
 
Wenn ich als Quelle nun "D:\" verwende, dann bekomme ich die Fehlermeldung, dass kein Zielverzeichnis(!) angegeben wurde.
Ohne Anführungszeichen funktioniert es bei mir.

Aber:
Wenn Daten aus dem Stammverzeichnis eines Geräts kopiert werden, übernimmt das Zielverzeichnis während des Kopiervorgangs das Attribut „verborgen“.

Mein Test mit
robocopy f:\ e:\backup /mir
bestätigt es. e:\backup ist so nicht sichtbar.

ein folgendes
attrib -h -s e:\backup
scheint zu funktionieren.

attrib entfernt hier die System und Versteckt Attribute.


Das mit /A-:SH hat bei mir nicht funktioniert.
 
Zurück