Full backup ( RAW ) and restore to a different HDD

Help Section
1

Full backup ( RAW ) and restore to a different HDD failed because the UUID of the new HDD is other. The system start up but does not find the partition that is related to the UUID of the source HDD. How to solve? Thanks in advance!

2

Are you using the UUID(s) in /etc/fstab? NomadBSD’s standard partitions use GPT labels (on a HDD installation), and UFS labels on
live media, so it’s independent of the underlying disk.

3

Hello mk1, how are you?

I just assumed that would be the problem (UUID), because I used Macrium Reflect to create a disk image (source) in sector-by-sector mode, the backup was done perfectly and very fast. Macrium Reflect did the restoration of NomadBSD on the new disk, the disk went up beautifully, but already close to entering the system it aborted informing not having found a partition. So I figured Freebsd would enumerate the partitions with their UUIDs.
Do you happen to know any LIVE backup application that supports UFS file system and can restore the image to a different HDD?

Thanks again,
Marcelo

MR
MR750×612 141 KB

Hello my friend!

After a long search I found the only backup application with GUI interface capable of recognizing, manipulating, backing up only data from each NomadBSD partition and restoring correctly to any HDD.

1629940918103647246324979819064
16299409181036472463249798190644016×3008 2.21 MB

4

16299550543127353327582376886192
162995505431273533275823768861924016×3008 1.43 MB

Hi mk1, how are you?

In according information :+1: I need to disable TRIM on the new HDD as it doesn’t support TRIM. I need to do this by logging in via Single User right?
Could you please confirm that the command is this # tunefs -t disable
Is that why the system didn’t climb on the new HDD? For security I disabled the SATA controller where the SSD is connected so there is no collision between the two disks because I’m booting from USB.

Thank you very much!
Marcelo

After disable TRIM

16299901881408727911274669079059
162999018814087279112746690790594016×3008 1.5 MB

16299903500926608787039366035828
162999035009266087870393660358284016×3008 1.17 MB

5

I don’t know that tool, and don’t know what it exactly does. Telling from the error messages, I’d guess this is not a 1:1 copy. The label information is missing. If you used the good ol’ dd(1) to make a 1:1 copy of the disk, there should be no problem.

It’s just a warning, and doesn’t matter.

6

So I already disabled TRIM for dealing with HDD, but the system doesn’t go up, it aborts with unknown error 3. That’s why I imagined the UUID issue. Please see the Photo above.
Any help is very welcome!
Best wishes,
Marcelo

7

As I said:

The UUID doesn’t matter unless you use it in /etc/fstab instead of a label. If the HDD/SSD changes, the UUID changes, and therefore those fstab entries using UUIDs become invalid, and must be adjusted. But NomadBSD standard partitions use labels, not UUIDs.

8

I would use dd to clone a disk:

Let’s say you boot NomadBSD from a thumb drive (da0), and da1 is the system you want to clone, and da2 is the target disk, then:

# dd if=/dev/da1 of=/dev/da2 bs=4m conv=sync

This would make a 1:1 copy of da1, and write it to da2.

9

Thanks! But I would like to save a NomadBSD backup, for example NomadBSD.img so that I can restore to another HDD if my current one gets damaged.
I don’t want to clone the HDD, I just want a full disk image to save for security.
Thanks again,
Marcelo

10

Easy:

# dd if=/dev/da1 of=nomadbsd_backup.img bs=4m

:slight_smile:

11

Cool, friend! Thanks! And to extend the /home partition with the free GB’s?