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
Mon, 16 Oct 2023 14:17:45 +0200 Roger Oberholtzer <roger.oberholtzer@gmail.com> :
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.
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 <ksusup@trixtar.org> wrote:
Mon, 16 Oct 2023 14:17:45 +0200 Roger Oberholtzer <roger.oberholtzer@gmail.com> :
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 16:05 schrieb Roger Oberholtzer:
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?
novice friendly: second boot drive with shellscript, my oldest user is 82 years old and is able to boot to second minimal (no graphical enviorement) opensuse and make the automatic dd backup :-)) simoN
On Mon, Oct 16, 2023 at 3:39 PM bent fender <ksusup@trixtar.org <mailto:ksusup@trixtar.org>> wrote:
Mon, 16 Oct 2023 14:17:45 +0200 Roger Oberholtzer <roger.oberholtzer@gmail.com <mailto:roger.oberholtzer@gmail.com>> :
> 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
-- HINWEIS: Wenn Sie diese "reintext" Mail mit Outlook oeffnen kann es sein, dass Outlook diese Mail nicht korrekt formatiert anzeigt. Das ist ein Fehler oder eine Misskonfiguration in Outlook. Informieren Sie ihren Systemadministrator. (von "Wenn... bis ... Systemadministrator." sind das hier 6 Zeilen.) (Zeilenumbruchzeichen ist HEX 0A) ========== B e c h e r e r GmbH Sondermaschinenbau Mauermattenstrasse 22 79183 Waldkirch Germany Tel.: (+49) (0)7681 3134 Fax: (+49) (0)7681 4378 Mail: info@becherer.de Web: www.becherer.de USt-ID-Nr.: DE 814912198 Registergericht: Freiburg HRB 701860 Geschaeftsfuehrer: Dipl.-Ing. (FH), EWE Simon H. Becherer Gerichtsstand / Sitz: Waldkirch Es gelten ausschliesslich unsere allgemeinen Liefer- und Zahlungsbedingungen / Einkaufsbedingungen: www.becherer.de/AGB
Am 16.10.23 um 15:39 schrieb bent fender:
Mon, 16 Oct 2023 14:17:45 +0200 Roger Oberholtzer <roger.oberholtzer@gmail.com> :
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
Am 16.10.23 um 14:17 schrieb 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?
My experience: Get a new disk/ssd, install suse fresh, simply copy from your backup HOME over the new one, finished. Later you can fine-tune the new installation with the help of your extensive documentation of you previously installed suse;-) Practised yesterday on a virtual tumbleweed, which will serve as my first test for slowroll.
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?
Or clonezilla. I don't have experience with any of them. I use plain dd (or dd*rescue), or rsync. Notice: if btrfs is on the root system, I can not handle it. I don't know how. For backups, I prepare laptops with an external boot disk; it contains a complete openSUSE system, plus a big data partition, encrypted, and using compressed btrfs. In it, there is a dd compressed image of the boot and system partittions, the table of partition data, and rsync of all, with a script of mine to do it. If the laptop contains windows, then a dd image of it all. The external disk has double the size of the internal disk, but in rotating rust. Not trivial to use, but not hard. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
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. -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title
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))
I have successfully multiple times cloned my OS to a new disk using Clonezilla live. Regarding automated backup of root filesystem (home is on a separate disk with different backup), I use timeshifht. It can do btrfs snapshots to a different device (I use another internal disk) or rsync snapshots. I use the latest and usually I just recover specific files after a clean install.
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." <robin.listas@telefonica.net> 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 --
On 2023-10-17 03:28, Masaru Nomiya wrote:
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." <robin.listas@telefonica.net> 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 don't like btrfs in root, simply because recovery⁽¹⁾ is so complicated that I can not memorize and reproduce. At the time I looked at it, there was no way to format a new btrfs with the same structure as the machine you are going to clone or restore. The only known way was to install openSUSE fresh. (1) recovery in this context is cloning the system, or bare iron recovery, reconstruction of a system from backup.
I did BTRFS transparent compression described there.
The question that boggled my mind was how to migrate the current Tumbleweed.
You can not. No published procedure AFAIK.
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)
Yes, you can do that. I would perhaps have deleted all the files of the fresh install prior to restoring the backup, except fstab.
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/'
-- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
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." <robin.listas@telefonica.net> has written: CER> [1 <multipart/mixed (7bit)>] CER> [1.1 <text/plain; UTF-8 (base64)>] 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." <robin.listas@telefonica.net> 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 --
On 2023-10-17 08:23, Masaru Nomiya wrote:
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." <robin.listas@telefonica.net> has written:
CER> [1 <multipart/mixed (7bit)>] CER> [1.1 <text/plain; UTF-8 (base64)>] 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." <robin.listas@telefonica.net> 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.
Yes.
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?
Well, it works, but it is not a "proper" procedure. It is install fresh, then overwrite it. A proper procedure would be a script creating the proper volumes and subvolumes or whatever, then a file with the fstab needed entries, ready to populate but empty. We also need another script to read the sctruture of an existing system in order to recreate it later (backup or clone). What you described is a "hack". Yes, I knew about it :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
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." <robin.listas@telefonica.net> 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 --
On 2023-10-17 09:51, Masaru Nomiya wrote:
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." <robin.listas@telefonica.net> 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.
...
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.
That's the thing, a hack is not a proper procedure. Yes, it works. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
Hello, In the Message; Subject : Re: OS disk cloning Message-ID : <de8eeb1b-63a4-45be-86ae-a26155de7371@telefonica.net> Date & Time: Tue, 17 Oct 2023 09:56:15 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> 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 --
My reason for wanting something that works with a novice (in this respect) is that a developer thought he would make a backup of his laptop hard disk. He is running Tumbleweed. For some reason he used clear linux to do this. After the backup seemed complete, he rebooted, but instead of getting in to Linux, he was in some odd Windows installer. I think there are things like that in the newer disk layouts. How he got there is a mystery. Seems grub never ran. Or so it has been reported. So I thought I would see if I could outline a safer approach. (BTW, we corrected his computer by running the Tumbleweed installer and selecting Update. Worked a charm.) I am in the camp of doing a clean install. All source code and tools are checked in to our source repository (subversion here. It fits our needs very well). It may take a little time. But at least I know what I have. And it happens so seldom. Like almost never. But the novice user is a different matter. Some really trust everything the read on the net. I would imagine that having a disk backup utility on the OS installer (the bootable ISO) could be a useful thing.Then people don't wander off using an unknown tool (to us - and not meaning bad) that may do changes a bit differently than we expect, based on how SUSE/openSUSE do things. I.e., no changes at all until you agree to them in a dialog that warns you that at that point something on the disk might be altered. On Tue, Oct 17, 2023 at 10:46 AM Masaru Nomiya <nomiya@lake.dti.ne.jp> wrote:
Hello,
In the Message;
Subject : Re: OS disk cloning Message-ID : <de8eeb1b-63a4-45be-86ae-a26155de7371@telefonica.net> Date & Time: Tue, 17 Oct 2023 09:56:15 +0200
[CER] == "Carlos E. R." <robin.listas@telefonica.net> 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 --
-- Roger Oberholtzer
On 2023-10-17 10:45, Masaru Nomiya wrote:
Hello,
In the Message;
Subject : Re: OS disk cloning Message-ID : <de8eeb1b-63a4-45be-86ae-a26155de7371@telefonica.net> Date & Time: Tue, 17 Oct 2023 09:56:15 +0200
[CER] == "Carlos E. R." <robin.listas@telefonica.net> 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))
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." <robin.listas@telefonica.net> 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 --
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 <nomiya@lake.dti.ne.jp> :
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." <robin.listas@telefonica.net> 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 --
Hello, In the Message; Subject : Re: OS disk cloning Message-ID : <20231017080316.8241c1783b699a51af2194a1@trixtar.org> Date & Time: Tue, 17 Oct 2023 08:03:16 -0400 bent fender <ksusup@trixtar.org> has written:
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'.
As I said to Carlos, I was only expressing my opinion on the part of Carlos's description of btrfs filesystem. I guess I started the thread the wrong way.
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.
dd isn't THAT difficult to use, as for btrsf I know nothing about it.
The btrfs has a useful tool called snapper, so there is no need to use dd or rsync. Best Regards & Good Night. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ "Bill! You married with Computer. Not with Me!" "No..., with money."
Tue, 17 Oct 2023 21:47:55 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
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 :-)
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 <ksusup@trixtar.org> has written:
Tue, 17 Oct 2023 21:47:55 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
[...]
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? 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. Regards. --- ┏━━┓彡 野宮 賢 mail-to: nomiya @ lake.dti.ne.jp ┃＼／彡 ┗━━┛ " Hassabis says that no one really knows for sure that AI will become a major danger. But he is certain that if progress continues at its current pace, there isn’t much time to develop safeguards. "I can see the kinds of things we're building into the Gemini series right, and we have no reason to believe that they won't work," he says." -- "Google DeepMind's CEO Says Its Next Algorithm Will Eclipse ChatGPT" --
Wed, 18 Oct 2023 13:19:19 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
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 <ksusup@trixtar.org> has written:
Tue, 17 Oct 2023 21:47:55 +0900 Masaru Nomiya <nomiya@lake.dti.ne.jp> :
[...]
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.
On Thu, Oct 19, 2023 at 1:15 AM bent fender <ksusup@trixtar.org> wrote:
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.
Exactly this. But I was looking for something a novice could do. And that includes the thing you boot into to run whatever command you need. The whole chain. I've decided that I'm going to make a bootable Leap image with kiwi that contains a couple potential packages to do this. And of course 'dd' will be one of them. I will then be certain that nothing unexpected is done to any disks found in the system. Which is what my user claims happened after using clear linux to do this. What I'm trying to figure out is where best to store the image. kiwi has some flexibility on how the ISO image (the one you boot with to do all this) fills the media it first boots on. So making a partition for those images is possible. -- Roger Oberholtzer
Le 16/10/2023 à 14:17, Roger Oberholtzer a écrit :
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?
don't now this one. I use clonezilla, with results from perfect to disaster... with it one can clone to disks of various sizes (target different from source) jdd -- c'est quoi, usenet? http://www.dodin.org/wiki/pmwiki.php?n=Usenet.Usenet
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/JF5UIEMX7BHPTR5BQR5BX4JL4E4LDPSR/> -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
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. <robin.listas@telefonica.net> 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
On 2023-10-20 08:28, Roger Oberholtzer wrote:
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.
Then the tool to use is dd or a variant. It could be clonezilla, but it seems that sometimes fails somewhat. 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. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
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 2023-10-20 12:51, 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 :-)
True, I forgot that. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" <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
Fri, 20 Oct 2023 20:45:07 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" <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
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 <ksusup@trixtar.org> wrote:
Fri, 20 Oct 2023 20:45:07 +0000 (UTC) Robert Webb via openSUSE Users <users@lists.opensuse.org> :
On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" <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-23 10:43, Roger Oberholtzer wrote:
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.
I do that in my script, but it is not polished. Not for newbies. -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.5 (Laicolasse))
On 2023-10-20 22:45, Robert Webb via openSUSE Users wrote:
On Fri, 20 Oct 2023 12:51:42 +0200, "jdd@dodin.org" <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 Fri, 20 Oct 2023 23:15:49 +0200, "Carlos E. R." <robin.listas@telefonica.net> 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" <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. -- Robert Webb
On 2023-10-21 08:29, Robert Webb via openSUSE Users wrote:
On Fri, 20 Oct 2023 23:15:49 +0200, "Carlos E. R." <robin.listas@telefonica.net> 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" <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))
On 10/20/23 01:28, Roger Oberholtzer wrote:
It is a byte-for-byte mirror image.
That is what those cloning boxes do. Copy one byte from source to target then copy another,, and another and so on. It has no idea what is on the source drive and doesn't care. -- In times of Tyranny and injustice when law oppresses the people, the outlaw takes his place in history. ~ · Robin Hood · 2010 · Screen Title
participants (10)
-
bent fender -
Bill Walsh -
Carlos E. R. -
jdd＠dodin.org -
Masaru Nomiya -
Peter McD -
Robert Webb -
Roger Oberholtzer -
Simon Becherer -
Stratos Zolotas