DietPi-Software | Clonezilla live backup

[cocoflan]

Just an idea maby no good!

Also version control on backup would be nice! like you have on déja dup!

found this also https://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/d55c4e6d6f/#0656/, clonezilla live like on a openmediavault system for arm based systems!

We have created a testing ARM64 release here: http://stevenshiau.org/clonezilla-live/arm/2.6.6-3/ Basically if your uboot supports uEFI boot, or your machine supports uEFI booting, you can unzip the clonezilla live zip file to a USB flash drive, which has a VFAT partition, then boot it. We have tested that in a Banana Pi, and Mikey Chang also put the result on youtube: https://www.youtube.com/watch?v=ea7_cYtNYsk Let us know the results if you test it.

Steven

To do like this, to get it working

https://forum.openmediavault.org/index.php?thread/13686-system-backup-clonezilla-option-failed/

1 - Remove clonezilla rm -f /etc/grub.d/42_clonezilla update-grub

2 - Manually download the clonezilla iso to /boot/ cd /boot wget http://gigenet.dl.osdn.jp/clonezilla/64590/clonezilla-live-2.4.5-23-i686.iso Edit /etc/grub.d/42_clonezilla for the version you downloaded update-grub

[MichaIng]

Many thanks for your suggestion.

Clonezilla generally is a great backup, clone and install tool, we use it for our x86_64 installer images. Also the server edition can be used to maintain multiple clients, e.g. backup, clone or reset a whole server farm.

Interesting that they have an ARM64 image. With this we could create SBC installer images to make install to internal eMMC chips easier, using the same method the we use for x86_64 installer images now. I had a different method in mind, but this one would be much faster to implement of course. Sadly there was no update for a year, I hope the experiment has not been abandoned.

If it can be seamlessly installed and removed as an additional boot option, we could add it as software option.

[robyscar]

@MichaIng another useful tool, under the same category of cloning / bkp, could be this :

• https://github.com/billw2/rpi-clone

more than once - at least for me - after an update of DietPi, my Rpi hangs and doesn't works anymore. Not DietPi's fault, but of course, i am using my system and adding/removing things.

Considering that DietPi is a DISTRO and not a closed system, i suppose that more than some users would be happy about the addition. Considering that Rpi is used let's say at least by 50-60% of Windows users (as i am), the use of the WSl/WSL2 can be useful.

Via a Debian Container for WSL, i am already capable to DD in remote my running DietPi. The issue is that, of course, we need also a minumum RUNLEVEL / maintenance mode active. SYSTEMCTL is quite a PITA (pain in the @$$), and not so easy to manage a proper running level 1, with SSHD, SUDO, NETWORKING and LOGIN ENABLED.

I am trying, but stucking in the lack of TTYAMA0 always working (as per your architecture choice as i have seen in other posts), that leaves me hanging after an INIT 1, to test the remote DD and/or RSYNC with nothing else running than basic services ... sorry WinZozz habit ... daemons

Ciao RS

[MichaIng]

rpi-clone is one of the cases where an implementation is basically overkill 😄. To use it:

bash -c "$(curl -sSfL https://raw.githubusercontent.com/billw2/rpi-clone/master/rpi-clone)"

Nothing we can do to enhance things. But there is a plan to integrate the feature into DietPi, originally with the aim to provide an installer image, that you can flash onto a USB drive, boot from there but install DietPi into an internal drive, or an eMMC module. But the same method can be used to clone any live system anywhere else.

SYSTEMCTL is quite a PITA (pain in the @$$), and not so easy to manage a proper running level 1, with SSHD, SUDO, NETWORKING and LOGIN ENABLED.

Probably it is that I never worked with runlevels (too young?), but I'd always do a regular boot and stop services which do imply constant disk writes. On DietPi:

dietpi-services stop

There is nothing else left running aside of SSH and, when installed, other remote connection servers, so sounds like what you want with runlevel 1.

I am trying, but stucking in the lack of TTYAMA0 always working

You want the serial console active (default) or you want to disable it? The console as well as the device itself can be toggled via dietpi-config > Advanced Options > Serial/UART. On RPi models with onboard WiFi + Bluetooth, /dev/ttyAMA0 is used by the Bluetooth device, so that needs to be disabled to be able to use it for other purposes:

/boot/dietpi/func/dietpi-set_hardware bluetooth disable
#reboot

But the mini UART /dev/ttyS0 can be used instead, which is also the primary UART and enabled by default on those models. It can be toggled as well via above dietpi-config menu.

[cocoflan]

And the use of some kind of recovery partition on new installation is this not an option?

[cocoflan]

https://www.linuxquestions.org/questions/linux-newbie-8/how-to-create-system-recovery-partition-in-linux-ubuntu-4175452606/

https://linuxsay.com/t/create-recovery-partition-in-linux-ubuntu/1626

https://unix.stackexchange.com/questions/73597/making-a-recovery-partition-in-embedded-linux

https://magpi.raspberrypi.org/articles/raspberry-pi-recovery-partition

https://github.com/rescuezilla/rescuezilla

just some info.

[robyscar]

Hi Mich, and tnx for your prompt reply. I agree with you: is overkilling and quite complex (for the avg user) that's why i was looking on the DietPi page, looking for future features

rpi-clone is one of the cases where an implementation is basically overkill 😄. To use it:

bash -c "$(curl -sSfL https://raw.githubusercontent.com/billw2/rpi-clone/master/rpi-clone)"

Let's hope you will roll out soon. As told, i use your DISTRO as i call it: a distro on which build my systems. Neat and manteined Rapsbian/Debian, installed at minimal, and then add my "lego" pieces

But the same method can be used to clone any live system anywhere else.

I wish you was right, unfortunately i came from the VIC20 / C64 generation. I have quite a lot of years on shoudelrs and few hairs on head. I just gave my years to WinZozz systems, 'cause Unix SysV was quite expensive to buy and run. My first distro was many years later a Slackware, then RedHat, then Centos, and now Debian. Is just that i have other "forma mentis" and the acrobatic system management made with N .target, Y.want and so on, is quite chaotic... and the time is limited to start from scratch learning things

Probably it is that I never worked with runlevels (too young?), but I'd always do a regular boot and stop services which do imply constant disk writes. On DietPi:

and this is OK (i have read your scripts and found it) for YOUR toolset. But as told, someone like me can use your distro and add things (is one of the things you say in the update/upgrade warnings). But i am aware the request is of topic: the natural reply from you could be : GET A LINUX MANUAL ;)

dietpi-services stop There is nothing else left running aside of SSH and, when installed, other remote connection servers, so sounds like what you want with runlevel 1.

BT was already disabled from the dietpi-config, now i have forced also with the $ you added. The goal is to have ALWAYS a serial TTY.

I am trying, but stucking in the lack of TTYAMA0 always working You want the serial console active (default) or you want to disable it? The console as well as the device itself can be toggled via dietpi-config > Advanced Options > Serial/UART. On RPi models with onboard WiFi + Bluetooth, /dev/ttyAMA0 is used by the Bluetooth device, so that needs to be disabled to be able to use it for other purposes:

/boot/dietpi/func/dietpi-set_hardware bluetooth disable
#reboot