Größe von Datenbestand ermitteln/schätzen zur Verwendung mit dd

[Piktogramm]

ctime ist immer wecklig und wird zum Problem beim Kopieren, Backup/Restore und eben dem Umzug auf neue Blockdevices. Normalerweise wäre der dringende Rat, davon abzukommen, dass (cr)times so wichtig sind, dass man sie behalten muss.

fstrim auf sda ist sinnlos, dd liest leere Blöcke und schreibt leere Blöcke. Allenfalls bringt fstrim etwas auf sdb nach dem Kopieren, falls sdb eine SSD oder HDD mit Shingled Recording ist.



An sich:
0. /dev/sda bzw. alle Partitionen davon aushängen
1. dd if=/dev/sda of=/dev/sdb status=progress
2. mit parted (oder grafisch gparted) die Partition auf sdb erweitern
3. Rechner aus, SDA physisch abklemmen, Booten

Da SDB bzw. die Partitionen darauf die selben UUIDs haben, sollte das Mounting über /etc/fstab automagisch klappen. Schön isses nicht, aber an sich habe ich das Wochenende so ähnlich ein degradiertes mdadm Raid1 auf neue, größere HDDs umgezogen.

 

[foofoobar]

2.
Das überschreibt die ungenutzten Blöcke der ehemaligen sda1-Partition (also der Kopie davon auf sdb1) mit Nullen, so dass dieser Speicher wieder nutzbar ist.

Aber nur auf SSDs, bei zukünftigen Speicher kann das Verhalten komplett anders sein.
Klassischer Fall von impliziter Annahme, und eine Garantie für Probleme in der Zukunft.

ctime ist immer wecklig und wird zum Problem beim Kopieren, Backup/Restore und eben dem Umzug auf neue Blockdevices. Normalerweise wäre der dringende Rat, davon abzukommen, dass (cr)times so wichtig sind, dass man sie behalten muss.

Warum das so wichtig darüber schweigt sich der TO weiterhin aus.