ubuntuusers.de

Hallo,

folgendes Problem: Habe mir eine externe 12 TB SATA HDD mit Docking Station gekauft und über USB 3.0 angeschlossen. Diese will ich künftig für meine Sicherungen (v.a. Back in Time) nutzen. Nach anfänglichen technischen Problemen (Partitionstabelle nicht gefunden, E-/A-Fehler beim Kopieren der alten BiT Sicherungen) habe ich mittels GParted die Partitionstabelle neu erstellen lassen und über den gesamten Plattenplatz eine Ext4-Partition erstellt. Hierhin habe ich meine alten BiT-Snapshots von meiner alten 3TB SATA HDD (USB) kopiert (sudo cp -rapPv /media/mikeff/LINUX_Ext3/Back_in_time → /media/mikeff/BACKDSK/backintime/). Aufgrund der Datenmenge habe ich die Snapshots einzeln kopiert, was dann auch ohne Fehler gelang (insgesamt 8 Monatssicherungen). Ich stellte allerdings fest, dass der Platz auf der neuen HDD inflationär schrumpfte, was eigentlich nicht sein kann, weil es ja 1:1 Kopien von einem LW auf das andere sind. So ist das Verzeichnis 'Backintime' auf der alten HDD mit 2.929.764 Objekten 1,3 TB groß, während es auf der neuen HDD mit 2.929.759 Objekten 6,3 TB groß ist, also fast den dreifachen Platz belegt. Reservierten Speicherplatz mit sudo tune2fs -m von 5% auf 1% reduziert. Dass es am unterschiedlichen Darteiformat liegt (ext3 vs ext4) konnte ich mir nicht so recht vorstellen, also habe ich beide Platten mal mit fdisk -l anschauen lassen. Am auffälligsten ist hierbei der Eintrag E/A-Größe (minimal/optimal), hier die Ausgabe beider Tests:

Festplatte /dev/sdb: 10,94 TiB, 12000138625024 Bytes, 2929721344 Sektoren
Festplattenmodell:                 
Einheiten: Sektoren von 1 * 4096 = 4096 Bytes
Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 33550336 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0xa86caaac

Gerät      Boot Anfang       Ende   Sektoren Größe Kn Typ
/dev/sdb1          256 2929721343 2929721088 10,9T 83 Linux


Festplatte /dev/sdc: 2,75 TiB, 3000592982016 Bytes, 732566646 Sektoren
Festplattenmodell: 2105            
Einheiten: Sektoren von 1 * 4096 = 4096 Bytes
Sektorgröße (logisch/physikalisch): 4096 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 939C6D31-CE70-40D9-BA7E-012B45E2F8AD

Gerät      Anfang      Ende  Sektoren Größe Typ
/dev/sdc1     256 732566527 732566272  2,7T Linux-Dateisystem

Ich vermute mal, dass das des Rätsels Lösung ist. Nur - wie kann man das ändern? Letztlich könnte ich natürlich auf der neuen HDD wieder eine Part Tab neu erstellen und eine Ext4 Partition anlegen, nur würde ich gerne verstehen, wie das kommt und vermeiden dass das tagelange Kopieren umsonst war.

Danke und Gruß

Das sieht "seltsam" aus ... 😎

Festplatte /dev/sdb: 10,94 TiB,
Festplattenbezeichnungstyp: dos

12TB sind eine Hausnummer, hebe dein System auf "heutige" Technik. (22.04, ext3 weg, GPT)

hakel2022 Ja, das fiel mir auch auf. Dachte aber es ist ja nur das Label. Vermutlich dadurch, dass ich die Partition mit GParted erstellt habe, aber nicht von der live DVD sondern vom System, welches damals (April 2020) ja noch nicht mit GPT sondern unter bios installiert wurde. Ein Systemupdate wird demnächst erfolgen, wenn 24.04 LTS rauskommt. Bin faul und ein LTS - Anhänger 😊

Gparted kann die Partitionstabelle von Platten unabhängig von der vom installierten System einrichten.

Hier hättest du dann GPT wählen können. Jetzt halt nachholen und alles nochmal schreiben.

22.04 ist auch eine LTS. Ich nutze die Zwischenversionen, Release Upgrade dauert inzwischen 15 Minuten. 👍

Durch die kleinen Sprünge sind die Nacharbeiten gering, und man bleibt in Übung. Das ist natürlich Geschmackssache!

Die Tools unter Linux haben oft durchaus Verbesserungspotential.

22.04 ist nicht gut, daher ist eine Neuinstallation mit 24.04 in deinem Fall sicher die bessere Idee. Prüfe, ob dein System noch mit Gnome klar komm in all seiner Pracht!

Gparted kann die Partitionstabelle von Platten unabhängig

Hat der TS ja auch, aber ich weiß gar nicht wie das klappt bei ihm! So etwas darf doch gar nicht sein ...

Hallo linubie,

DOS kann maximal 2TB verwalten .....

Gruss Lidux

linubie schrieb:

Aufgrund der Datenmenge habe ich die Snapshots einzeln kopiert, was dann auch ohne Fehler gelang (insgesamt 8 Monatssicherungen). Ich stellte allerdings fest, dass der Platz auf der neuen HDD inflationär schrumpfte, was eigentlich nicht sein kann, weil es ja 1:1 Kopien von einem LW auf das andere sind.

Sind es eben nicht, wenn du die Snapshots einzeln kopierst.

BiT übernimmt unveränderte Dateien mittels Hardlinks in den neuen Snapshot. Das heißt, die Daten sind physisch nur einmal auf der Platte und werden von mehreren Stellen des Inhaltsverzeichnisses aus verlinkt. Das hat die angenehme Folge, dass man alte Snapshots bedenkenlos löschen kann – solange mindestens noch ein Hardlink existiert, bleiben die Daten erhalten.

Du hast nun die Ordner einzeln kopiert, was jedesmal eine neue physische Kopie jeder (auch unveränderten) Datei erzeugt hat.

--ks

Lidux schrieb:

Hallo linubie,

DOS kann maximal 2TB verwalten .....

Nicht wenn die Blockgröße mehr als 512 ist.

Lidux schrieb:

DOS kann maximal 2TB verwalten .....

Ja ist mir inzwischen bekannt, deshalb habe ich neulich meine interne 4TB ssd mit gdisk auf GPT umgestellt, was übrigens recht problemlos geklappt hat. Die Screenshots die ich anhänge, zeigen was ich meine, wenn Du Dir die Größen anschaust.

Kreuzschnabel schrieb:

linubie schrieb:

...Ich stellte allerdings fest, dass der Platz auf der neuen HDD inflationär schrumpfte, was eigentlich nicht sein kann, weil es ja 1:1 Kopien von einem LW auf das andere sind.

Sind es eben nicht, wenn du die Snapshots einzeln kopierst.

BiT übernimmt unveränderte Dateien mittels Hardlinks in den neuen Snapshot. Das heißt, die Daten sind physisch nur einmal auf der Platte und werden von mehreren Stellen des Inhaltsverzeichnisses aus verlinkt. Das hat die angenehme Folge, dass man alte Snapshots bedenkenlos löschen kann – solange mindestens noch ein Hardlink existiert, bleiben die Daten erhalten.

Du hast nun die Ordner einzeln kopiert, was jedesmal eine neue physische Kopie jeder (auch unveränderten) Datei erzeugt hat.

So etwas in der Art hatte ich tatsächlich schon im Verdacht, dachte aber durch die Option P (groß) im Befehlsaufruf könnte man das verhindern. Allerdings steht in der Beschreibung nur bzgl Symbolischer Links. Vermutlich ist das jedoch ein Problem wenn man BiT Snapshots kopiert. Unabhängig davon werde ich die GPT nochmal neu erstellen so wie es DJKuhpisse und hakel2022 es ja auch schon vorgeschlagen haben und es dann nochmal versuchen, indem ich das gesamte BIT Verzeichnis auf einmal kopiere. Dann wird man weitersehen. Jedenfalls Danke schon mal bis hier

Wenn du einen Ordner kopierst, hat die Software praktisch keine Möglichkeit zu merken, dass etwas, das für sie wie eine normale Datei aussieht, a) bitgleich zu einer bereits vorhandenen Datei ist und b) von einer anderen Stelle im Index bereits verlinkt wurde. (Also es ginge sicher, wäre aber sehr aufwendig und zeitintensiv.)

Ein Hardlink ist keine „Umleitung“ wie ein Symlink. Ein Hardlink ist das Normalste der Welt. Jede Datei hat mindestens einen Hardlink in den Index. Ein zusätzlicher Hardlink, wie BiT ihn einbaut, ist genau das, was die Erstinstanz bereits hat, ein weiteres Mal. Die Software kann nicht mal erkennen, welcher der Hardlinks der „originale“ ist.

Nehmen wir an, Datei X an Speicheradresse 4321 ist per Hardlink in Ordner 1 und Ordner 2 vorhanden. Beim Kopieren von Ordner 1 fordert der Kopierprozess vom Datenträger Datei X an. An welcher Speicheradresse die liegt, interessiert den Kopierprozess nicht, dass muss nur die Festplatte selbst wissen. Sie liefert die Datei gemäß Bestellung aus und fertig. Wenn du nun Ordner 2 kopierst, wird wieder Datei X angefordert, die da drin ist. Dass die Festplatte diese Datei schon mal von derselben Speicheradresse geholt hat, weiß der Kopierprozess nicht. Für ihn sieht das genauso aus wie eine zusätzliche Kopie der Datei X, die du in Ordner 2 bewusst neu angelegt hast.

--ks

kreuzschnabel Verstehe, Danke. Hm, und wenn man das gesamte BiT VZ bitweise kopieren (quasi klonen) würde, ohne den Umweg über die Dateiverwaltung in der FAT? Also sorry wenn das doof klingt und nicht dass ich jetzt auf Anhieb wüsste wie das geht, ich glaube aber ich weiß noch, dass es Tools gibt, die das können. Alte Versionen von Acronis glaub ich konnten das. Linux hat sowas glaub ich auch in den Bordmitteln (dd?)

EDIT: Sorry, ist Quatsch, fiel mir gerade ein. Wie soll dann die Dateiverwaltung wissen, an welcher Stelle welche Datei abgelegt ist? Ginge also nur wenn man gleichzeitig die FAT editiert

Ja, mit dd erzeugst du eine echte 1:1-Kopie der gesamten Partition. Dabei geht auch die Formatierung deiner neuen Platte flöten. dd kennt keine Dateisysteme oder so was, es schreibt stur Bit für Bit ab.

--ks

Ich werds jetzt so versuchen: nachdem die alte Sicherungsdisk ja bereits mit GPT eingerichtet ist, werde ich auf der neuen (größeren) nochmals mit GParted eine GPT erstellen. Dann mit GParted die gesamte Partition kopieren, auf der sich das BiT-Verzeichnis befindet (bequemer als mit dd). Dann alle Daten außer BiT löschen, Dateiformat in Ext4 konvertieren und die Partition anschließend auf den gesamten Plattenplatz erweitern. Das ist vermutlich die einfachste und praktikabelste Lösung.