Create a clone on a device (SD card) instead of an image possible with shrink-backup?

[framps]

As far as I understand in case the current OS fails I have to restore the backup image created with shrink-backup on a device (for example a SD card), replace the broken SD card on the system and reboot. THis requires some experience how to restore the backup image and needs some time.

Would be much easier and shortens the outage time just to have a cold standby SD card handy which was
created by shrink-backup.

Think about a 7/24 system @home which fails and the system operator is on a business trip. If there exists a cold standby SD card you only have to replace the failed SD card with the cold standby SD card and the system is up and running again easily.

[UnconnectedBedna]

You will need to do the same thing you did when you originally installed the system.

Using shrink-backup to write an img was something I lightly touched on and actually had a scrtipt for a short while on the testing branch, but I dropped the idea because skrink-backup suddenly became way more than what intended to be:
shrink-backup is a very fast utility for backing up your SBC:s into minimal bootable img files for easy restore with autoexpansion at boot.

The backup image is also NOT a clone, it's a bootable img backup created from the running system.

Would be much easier and shortens the outage time just to have a cold standby SD card handy which was
created by shrink-backup.

If you want to achieve above, I suggest writing a simple script that writes the img to the sd-card using dd after a backup is made, could be controlled by a systemd timer for example. (or just run dd directly from a systemd service controlled by a timer that runs after shrink-backup has made an img)

Another way is to use something like ddrescue instead of shrink-backup to create a clone of the running system directly to a device. But the speed of shrink-backup is obv lost this way.

Or simply just write the backed up img the same way as when you installed.

If the idea is that you want to be able to write to a /dev instead of to an img file using shrink-backup it is not possible.
Shrink-backup relies on the initial dd to create partition table, partitions and boot sector. The only thing the script does is resize the root partition after the initial dd, then format it and rsync files.
Having the script using a dev directly instead of an img file brings the script outside the scope of it being a fast tool to create bootable img files.
You can use it in combination like I suggested earlier, but using it to directly write to a dev is not possible and would require a massive change of code to make something like that possible.

Please see:
Order of operations - img creation
Order of operations - img update

What could be done from the side of shrink-backup in this case is to create a wiki entry for a workflow achieving what you want.

The wiki for this project is under utilized, I am working on stuff to include in it, but things take time.
This is an idea I will keep in my mind though and possibly create an entry. (I actually don't know if anybody can change the wiki on this github, feel free to create a page if you can/want)

Edit
Now I think anybody can edit the wiki, not only collaborators, I hope I don't regret that... 😅

[framps]

The backup image is also NOT a clone, it's a bootable img backup created from the running system.

Looks like we have a different understanding of backup and clone :-) If a backup is an image backup and not just some data backup it's a clone for me. What's the difference of a clone and a backup for you?

Another way is to use something like ddrescue instead of shrink-backup to create a clone of the running system directly to a device.

I used ddrescue already but only for data recovery of a broken SD card. But then I also could just use dd.

If the idea is that you want to be able to write to a /dev instead of to an img file using shrink-backup it is not possible.

Yes, that's what rpi-clone is able to do and there a lot of folks using rpi-clone. But I agree, as a workaround a simple script can call shrink-backup followed by a dd call and then you have your cold backup. Maybe you document this workaround somewhere.

You can use it in combination like I suggested earlier, but using it to directly write to a dev is not possible and would require a massive change of code to make something like that possible.

I see. Same for raspiBackup. I created a branch and modified raspiBackup and it was able to create a clone immediately on a device. But the support doesn't fit into the design so I finally also abandoned the clone support. But that's why I'm interested in any backup tools which clone - and in my wording shrink-backup is a clone tool :-)

Please see:

If I have some spare time I'll check your code ;-)

What could be done from the side of shrink-backup in this case is to create a wiki entry for a workflow achieving what you want.

👍

[framps]

Now I think anybody can edit the wiki, not only collaborators, I hope I don't regret that... 😅

I wish you good luck. But I frankly wouldn't open a wiki for the whole world ...

[UnconnectedBedna]

Looks like we have a different understanding of backup and clone :-) If a backup is an image backup and not just some data backup it's a clone for me. What's the difference of a clone and a backup for you?

For me and anybody else:
A clone is exactly what it sounds like, a complete clone bit for bit, while a backup is just making sure the DATA (could be located anywhere on the backup, not bit for bit clone) is included. The difference is massive!
A backup can be a clone, but can also be a copy.
shrink-backup is a copy backup, not a clone backup.

dd an entire device while not in use = a clone
rsync an entire filesystem != clone

As an example with shrink backup:
The boot part is CLONED bit for bit when you create a a backup.
If the script would not do that, for example some armbian devices would NEVER boot, because they use MBR and have no boot partition, and no rsync in the universe would ever clone data outside of the filesystem where boot data is located (outside and before the filesystem).
After it is done with dd, it switches over to using rsync for the rest of the device.

In subsequent backups this data is not touched (data before and outside the filesystem), ever. Only a synchronization of the FILESYSTEMS on the device is done, ie a copy.

I used ddrescue already but only for data recovery of a broken SD card. But then I also could just use dd.

I just mentioned ddrescue because it CAN deal better with mounted storage that you clone compared to "normal" dd.

Maybe you document this workaround somewhere.

I do not, because it is outside the scope of what shrink-backup is.
The wiki however can cover anything, not just shrink-backup, that is why I offered it for you to create something if you want. :)

But that's why I'm interested in any backup tools which clone - and in my wording shrink-backup is a clone tool :-)

It is not, and you def should stop calling copies clones.
A clone is a clone, a copy is a copy, and shrink-backup will always be a copy, never a clone.
You can think of copies as twin siblings. They look the same, they sound the same, but they are not EXACTLY the same, only a CLONE would.

But I frankly wouldn't open a wiki for the whole world ...

That IS what a wiki IS, for anybody, ie the community to edit. Otherwise it would just be documentation, not a wiki.
From wikipedia about wiki:

A wiki is a type of website that lets anyone create and change its pages. The word is sometimes used in Internet slang to mean Wikipedia. Wiki is short for WikiWikiWeb. Wikiwiki is a word from the Hawaiian language, meaning "fast" or "speed".[1][2]

If I have some spare time I'll check your code ;-)

It's not a link to code, it is links to bullet lists of the scripts workflow.

🙂