I would also do a dd. But I am thinking of a user who is not comfortable with such a thing. Of course, if they can't grok dd, then perhaps they should not be having any confidence in some friendly GUI app. That is part of my asking: what tools are reliable and, I now add, novice friendly? On Mon, Oct 16, 2023 at 3:39 PM bent fender wrote:

Mon, 16 Oct 2023 14:17:45 +0200 Roger Oberholtzer :

...

If, as part of a disaster recovery system, you wanted to make a copy of your openSUSE OS disk, what are the best programs to use? I guess as part of this there is the discussion of what might need to be changed if the image is on another disk (/etc/fstab) for example).

How about rescuezilla?

-- Roger Oberholtzer

My 2 cents says when push comes to shove you would want bare bones commands and no YSOA (Yet Some Other App) to do the honors.

dd, hands-on and hands down.

yes, fstab & grubwork 4 sure.

-- Roger Oberholtzer

Am 16.10.23 um 15:39 schrieb bent fender:

Mon, 16 Oct 2023 14:17:45 +0200 Roger Oberholtzer :

...

If, as part of a disaster recovery system, you wanted to make a copy of your openSUSE OS disk, what are the best programs to use? I guess as part of this there is the discussion of what might need to be changed if the image is on another disk (/etc/fstab) for example).

How about rescuezilla?

-- Roger Oberholtzer

My 2 cents says when push comes to shove you would want bare bones commands and no YSOA (Yet Some Other App) to do the honors.

dd, hands-on and hands down.

something like this (only example, you must set it to your needs): cat /dev/zero > /mnt/nvme0n1p1/deleteme cat /dev/zero > /mnt/nvme0n1p2/deleteme (yes i know, much write operations on nvme not pretty good, for sdX never a problem and works also for more than 5 years 3-5 times a year on my nvme's) then DONE FROM A NOT MOUNTED DRIVE (example boot from "systemrescuecd") (or a second installed mimimal opensuse on a second drive -> there you could write nice shell script to backup automatic) dd if=/dev/nvme0n1 conv=noerror,sync |pv| pbzip2 -c > backup.img.bz2 or (if you know the size of the drive, and like to speed up the reading with bigger inputblocksize) dd ibs=1024 if=/dev/nvme0n1 conv=noerror,sync |pv -s 512110190592| pbzip2 -c > backup.img.bz2 or something with ddrescue such a backup will work without problems when bring it to a new drive, bigger or same size than the old. it could be that you have to adjust fstab, it depends how you have the drive names configured there. for this i like the sda nvme... design of names more than the exact "lkjasdl2123öljkölk" drive names. it will boot without problems from new drive if not the exact names are specified there.

yes, fstab & grubwork 4 sure.

simoN -- ========== www.becherer.de

On 2023-10-16 19:15, Bill Walsh wrote:

Jump on the internet. Order a clone box from China,

Insert source drive. Insert new drive of the same size or larger. Turn on. Push button. Go watch good movie. Done.

Provided you can remove the disk; on a laptop, that's not easy. And nowdays, they are M2. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

Hello, In the Message; Subject : Re: OS disk cloning Message-ID : <5e65a0c8-cc1a-40a9-8aff-4523256a9aa1@telefonica.net> Date & Time: Mon, 16 Oct 2023 16:50:46 +0200 [CER] == "Carlos E. R." has written: [...] CER> Or clonezilla. I don't have experience with any of them. I use CER> plain dd (or dd*rescue), or rsync. CER> Notice: if btrfs is on the root system, I can not handle it. I CER> don't know how. [...] I have been using an ext4 file system for a long time. But、I found this; https://dev.to/archerallstars/linux-opensuse-tumbleweed-review-in-2022-the-b... I noticed the following written in; zRAM AKA free RAM, and BTRFS transparent compression AKA free disk space, should be enabled by default I did BTRFS transparent compression described there.　 The question that boggled my mind was how to migrate the current Tumbleweed. When I asked Google, the only answer I got was "clean install of Tumbleweed". So I decided to investigate by installing tumleweed on my laptop with btrfs. The result was that the fstab looked quite different from the one in the ext4 case, but I found the structure of the system was the same as in the ext4 case, Then, I did as follows; 1. Backup of the current Tumbleweed to an external hard drive using rsync 2, Download a snapshot of Tumbleweed with the same kernel as the current Tumbleweed & clean install with btrfs. 3, Restore the backup Tumbleweed using rsync in overwrite mode (except /boot area) Since then, I haven't had any problems, and I occasionally get the backup to an external HDD with this script; #! /bin/sh rsync -av --delete /boot/ /bkup/boot rsync -av --delete /etc/ /bkup/etc rsync -av --delete /lib/ /bkup/lib rsync -av --delete /lib64/ /bkup/lib64 rsync -av --delete /opt/ /bkup/opt rsync -av --delete /root/ /bkup/root --exclude=.* rsync -av --delete /usr/ /bkup/usr --exclude='/local/tmp/' rsync -av --delete /var/ /bkup/var --exclude='/tmp/' Regards, --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Companies have come to view generative AI as a kind of monster that must be fed at all costs―even if it isn’t always clear what exactly that data is needed for or what those future AI systems might end up doing." -- Generative AI Is Making Companies Even More Thirsty for Your Data --

Hello, In the Message; Subject : Re: OS disk cloning Message-ID : <67beb350-da5f-40fa-b2d9-db85c434c83c@telefonica.net> Date & Time: Tue, 17 Oct 2023 07:51:31 +0200 [CER] == "Carlos E. R." has written: CER> [1 ] CER> [1.1 ] CER> On 2023-10-17 03:28, Masaru Nomiya wrote: CER> > Hello, CER> > CER> > In the Message; CER> > CER> > Subject : Re: OS disk cloning CER> > Message-ID : <5e65a0c8-cc1a-40a9-8aff-4523256a9aa1@telefonica.net> CER> > Date & Time: Mon, 16 Oct 2023 16:50:46 +0200 CER> > CER> > [CER] == "Carlos E. R." has written: CER> > CER> > [...] CER> > CER> Or clonezilla. I don't have experience with any of them. I use CER> > CER> plain dd (or dd*rescue), or rsync. CER> > CER> > CER> Notice: if btrfs is on the root system, I can not handle it. I CER> > CER> don't know how. CER> > [...] [...] CER> I don't like btrfs in root, simply because recovery⁽¹⁾ is so CER> complicated that I can not memorize and reproduce. At the time I CER> looked at it, there was no way to format a new btrfs with the CER> same structure as the machine you are going to clone r CER> restore. The only known way was to install openSUSE fresh. CER> (1) recovery in this context is cloning the system, or bare iron recovery, CER> reconstruction of a system from backup. As you can see from my quote, I am talking about migration to btrfs, not system cloning. MN> > I did BTRFS transparent compression described there.　 MN> > The question that boggled my mind was how to migrate the current MN> > Tumbleweed. CER> You can not. No published procedure AFAIK. As I mentioned before, I know there is no description of how to migrate from ext4 to btrfs. I would like to know why you say no. I myself don't dare to do anything that doesn't make sense. MN> > When I asked Google, the only answer I got was "clean install of MN> > Tumbleweed". So I decided to investigate by installing tumleweed on MN> > my laptop with btrfs. The result was that the fstab looked quite MN> > different from the one in the ext4 case, but I found the structure of MN> > the system was the same as in the ext4 case, MN> > MN> > Then, I did as follows; MN> > MN> > 1. Backup of the current Tumbleweed to an external hard drive using rsync MN> > MN> > 2, Download a snapshot of Tumbleweed with the same kernel as the MN> > current Tumbleweed & clean install with btrfs. MN> > MN> > 3, Restore the backup Tumbleweed using rsync in overwrite mode (except MN> > /boot area) CER> Yes, you can do that. I would perhaps have deleted all the files CER> of the fresh install prior to restoring the backup, except fstab. I can't understand why you say it can't be done above and then say it can be done here (I excluded fstab, of course). Could you explain it to me? Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Maddox hopes that empowering users to pick their own algorithms will get them to think more about what’s involved in making them. " -- Bluesky's Custom Algorithms Could Be the Future of Social Media --

Hello, In the Message; Subject : Re: OS disk cloning Message-ID : <226859cf-4223-47a4-b98b-18f188186e35@telefonica.net> Date & Time: Tue, 17 Oct 2023 08:47:08 +0200 [CER] == "Carlos E. R." has written: [...] CER> Well, it works, but it is not a "proper" procedure. It is install fresh, then CER> overwrite it. I can't understand what you mean. As I mentioned before, I did a clean install and overwrite restore, what's wrong with this? I've been using the "backup & restore" method a lot since before I migrated to btrfs, for serious software builds, installs & tests, and restore of backup after the test. CER> A proper procedure would be a script creating the proper volumes CER> and subvolumes or whatever, then a file with the fstab needed CER> entries, ready to populate but empty. We also need another script CER> to read the sctruture of an existing system in order to recreate CER> it later (backup or clone). I then migrated about 2 months ago and then tested the system, including bakcup & restore with btrfs. But I also keep a backup to go back to the original ext4 file system in case of problems. If there is a problem with the volume structure or the system structure, shouldn't something unusual be happening? Am I missing something? I don't think Linux is a loose system. CER> What you described is a "hack". Yes, I knew about it :-) I know it's a hack, that's why I uploaded my message. Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Companies have come to view generative AI as a kind of monster that must be fed at all costs―even if it isn’t always clear what exactly that data is needed for or what those future AI systems might end up doing." -- Generative AI Is Making Companies Even More Thirsty for Your Data --

Hello, In the Message; Subject : Re: OS disk cloning Message-ID : Date & Time: Tue, 17 Oct 2023 09:56:15 +0200 [CER] == "Carlos E. R." has written: [...] CER> That's the thing, a hack is not a proper procedure. CER> Yes, it works. Not your answer unless you tell me what exactly is the problem? In Linux, it is not uncommon to install it correctly and have it not work and have to hack it, i.e., it does not work as it is supposed to? Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "No Windows, no gains!" ... "Why, I am wrong?" -- Bill --

On 2023-10-17 10:45, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: OS disk cloning Message-ID : Date & Time: Tue, 17 Oct 2023 09:56:15 +0200

[CER] == "Carlos E. R." has written:

[...] CER> That's the thing, a hack is not a proper procedure.

CER> Yes, it works.

Not your answer unless you tell me what exactly is the problem?

In Linux, it is not uncommon to install it correctly and have it not work and have to hack it, i.e., it does not work as it is supposed to?

There is nothing wrong or bad. But a hack can not be proper, not kosher. I don't know how to explain it further, it is language issue. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

With all due respect the OP cited "disk cloning" which is not the same as migrating, or moving for that matter because in compuke a copy or a move is just the creation of something 'similar'. For what it's worth, MY definition of a a backup is "a created resource from which the original can be indistinguishably recovered WITHOUT the original source and without the system that was used to make the backup". dd isn't THAT difficult to use, as for btrsf I know nothing about it. Tue, 17 Oct 2023 18:55:45 +0900 Masaru Nomiya :

Hello,

In the Message;

Subject : Re: OS disk cloning Message-ID : <67beb350-da5f-40fa-b2d9-db85c434c83c@telefonica.net> Date & Time: Tue, 17 Oct 2023 07:51:31 +0200

[CER] == "Carlos E. R." has written:

[...] CER> You can not. No published procedure AFAIK. [...]

I had assumed it was unsupported by openSUSE, but upon further inspection, I found that the Japanese SUSE Linux Enterprise Server manual's

In the Storage Management Guide,

　　Offline migration from existing Ext2, Ext3, and Ext4 file systems.

is mentioned, and ubuntu and Synology provide the offline migration procedures. Reading these, I found that my way is fine.

Regards.

--- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Companies have come to view generative AI as a kind of monster that must be fed at all costs―even if it isn’t always clear what exactly that data is needed for or what those future AI systems might end up doing."

-- Generative AI Is Making Companies Even More Thirsty for Your Data --

Tue, 17 Oct 2023 21:47:55 +0900 Masaru Nomiya :

...

For what it's worth, MY definition of a a backup is "a created resource from which the original can be indistinguishably recovered WITHOUT the original source and without the system that was used to make the backup".

I'm sorry, but I can't understand what you are trying to say.

i.e. to make a backup completely independently of the system being backed up and to recreate it on demand completely independently of it or of the system used to make its backup ...something like this. It's like a spare car key, you don't wanna have to be in the car to be able make one or, once made, to have to use the grinder in order to open the car with it :-)

Wed, 18 Oct 2023 13:19:19 +0900 Masaru Nomiya :

Hello,

In the Message;

Subject : Re: OS disk cloning Message-ID : <20231017122236.ae217d445a0993eb6f2af2bf@trixtar.org> Date & Time: Tue, 17 Oct 2023 12:22:36 -0400

bent fender has written:

...

Tue, 17 Oct 2023 21:47:55 +0900 Masaru Nomiya :

[...]

...

...

I'm sorry, but I can't understand what you are trying to say.

...

i.e. to make a backup completely independently of the system being backed up and to recreate it on demand completely independently of it or of the system used to make its backup ...something like this.

...

It's like a spare car key, you don't wanna have to be in the car to be able make one or, once made, to have to use the grinder in order to open the car with it :-)

You seem to be suggesting that I use the dd command, no?

no, I'm not suggesting anything

I know what the dd command is, and I use it very occasionally.

I use the rsync command for routine backups for a reason, as you can see from the script I showed up before?

Or are you saying that the rsync command is system dependent?

I can't understand, at all.

I posted I think one reply to the OP, then some discussion followed about methods that are not cloning methods. So I threw in another post reinforcing my choice of dd as the best tool because recovery of the original made from the dd copy requires neither the original system (as in the case of windows methods) or even the foreign system from which the copy creation is executed. I can't word it any differently any more :-) If you have system-A which you want to clone you do not need to have it booted and it must not even be mounted. Then you use a booted system-B to execute the cloning with, and if you like then you may use system-C to X to recover the copy with.

I do not think the btrfs thing applies. I am looking to do a complete disk clone. The partition table and all partitions. Everything. It is not an incremental backup or a periodic sync. It is a byte-for-byte mirror image. The only thing I could expect is that the UUID for the disk might change and then require an update of that in /etc/fstab. I'm not sure about that. But it is possible. On Thu, Oct 19, 2023 at 4:42 PM Carlos E. R. wrote:

On 2023-10-16 14:17, Roger Oberholtzer wrote:

...

If, as part of a disaster recovery system, you wanted to make a copy of your openSUSE OS disk, what are the best programs to use? I guess as part of this there is the discussion of what might need to be changed if the image is on another disk (/etc/fstab) for example).

How about rescuezilla?

About btrfs, you should read this thread:

< https://lists.opensuse.org/archives/list/support@lists.opensuse.org/message/...

...

-- Cheers / Saludos,

Carlos E. R.

(from openSUSE 15.5 (Laicolasse))

-- Roger Oberholtzer

Le 20/10/2023 à 10:57, Carlos E. R. a écrit :

If the destination is the same disk size, dd is straight forward, just copy all. It will not change uuids, that's for some later postprocess.

be warned that similar disks may not have exact same number of sectors/size (specially hdd versus ssd), if the target is even a little smaller than the source, the result may be bad (or not, the worst is not always mandatory :-) jdd -- c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet

On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" wrote:

Le 20/10/2023 à 10:57, Carlos E. R. a écrit :

...

If the destination is the same disk size, dd is straight forward, just copy all. It will not change uuids, that's for some later postprocess.

be warned that similar disks may not have exact same number of sectors/size (specially hdd versus ssd), if the target is even a little smaller than the source, the result may be bad (or not, the worst is not always mandatory :-)

That's why you should always leave a little empty space after the last partition on the disk. -- Robert Webb

If I used dd, I would probably compress the file as it is read. But obviously watching that dd does not complain when writing it's data would be a good thing. Surely any proper disk cloning tool would do the same. And perhaps provide a checksum of the data do potentioal later corruption can be detected. In the example of kiwi, it computes a checksum of the image it will write to an OEM disk, and after it later writes that image to a new OEM disk, it will check that the written disk image has the same checksum. I would expect that any decent backup/restore program must do the same. On Fri, Oct 20, 2023 at 10:52 PM bent fender wrote:

Fri, 20 Oct 2023 20:45:07 +0000 (UTC) Robert Webb via openSUSE Users :

...

On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" wrote:

...

Le 20/10/2023 à 10:57, Carlos E. R. a écrit :

...

If the destination is the same disk size, dd is straight forward, just copy all. It will not change uuids, that's for some later postprocess.

be warned that similar disks may not have exact same number of sectors/size (specially hdd versus ssd), if the target is even a little smaller than the source, the result may be bad (or not, the worst is not always mandatory :-)

That's why you should always leave a little empty space after the last partition on the disk. -- Robert Webb

I never clone entire disks but IF I did I would want the same make and model and size. As for partitions I make them all exactly the same size so I can clone any one of them to any other on all disks. The data partitions , those I back up with rsync.

Disk /dev/sda: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: Samsung SSD 860 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 2CB71AC7-D2DB-4B81-A559-02802643D197

Device Start End Sectors Size Type /dev/sda1 2048 209717247 209715200 100G Linux filesystem /dev/sda2 209717248 419432447 209715200 100G Linux filesystem /dev/sda3 419432448 629147647 209715200 100G Linux filesystem /dev/sda4 629147648 838862847 209715200 100G Linux filesystem /dev/sda5 838862848 1048578047 209715200 100G Linux filesystem /dev/sda6 1048578048 1258293247 209715200 100G Linux filesystem /dev/sda7 1258293248 1468008447 209715200 100G Linux filesystem /dev/sda8 1468008448 1677723647 209715200 100G Linux filesystem /dev/sda9 1677723648 1887438847 209715200 100G Linux filesystem /dev/sda10 1887438848 1889535999 2097152 1G BIOS boot /dev/sda11 1889536000 1897924607 8388608 4G Linux swap /dev/sda12 1897924608 1906313215 8388608 4G Linux swap /dev/sda13 1906313216 1914701823 8388608 4G Linux swap /dev/sda14 1914701824 1923090431 8388608 4G Linux swap /dev/sda15 1923090432 1931479039 8388608 4G Linux swap /dev/sda16 1931479040 1939867647 8388608 4G Linux swap /dev/sda17 1939867648 1948256255 8388608 4G Linux swap

-- Roger Oberholtzer

On 2023-10-20 22:45, Robert Webb via openSUSE Users wrote:

On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" wrote:

...

Le 20/10/2023 à 10:57, Carlos E. R. a écrit :

...

If the destination is the same disk size, dd is straight forward, just copy all. It will not change uuids, that's for some later postprocess.

be warned that similar disks may not have exact same number of sectors/size (specially hdd versus ssd), if the target is even a little smaller than the source, the result may be bad (or not, the worst is not always mandatory :-)

That's why you should always leave a little empty space after the last partition on the disk.

That doesn't help in case of different (logical) sector size. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))

On 2023-10-21 08:29, Robert Webb via openSUSE Users wrote:

On Fri, 20 Oct 2023 23:15:49 +0200, "Carlos E. R." wrote:

...

On 2023-10-20 22:45, Robert Webb via openSUSE Users wrote:

...

   On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" wrote:

...

Le 20/10/2023 à 10:57, Carlos E. R. a écrit :

...

If the destination is the same disk size, dd is straight forward, just copy all. It will not change uuids, that's for some later postprocess.

be warned that similar disks may not have exact same number of sectors/size (specially hdd versus ssd), if the target is even a little smaller than the source, the result may be bad (or not, the worst is not always mandatory :-)

That's why you should always leave a little empty space after the last partition on the disk.

That doesn't help in case of different (logical) sector size.

I think it doesn't matter, as long as the partition sizes, and offsets, are multiples of the sector size, whatever it is.  I have written ISO images to USB thumb drives, optical disks (2K sector size), and harddisks without worrying about the sector size.  That is cloning of bit images.

Yes, logical sector size matters when cloning disks or partitions. The partitions have structures that map file names into sector numbers. If the sectors change size, the mapping is totally off. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))