On Sat, Jul 3, 2021 at 10:18 AM Ger van Dijck <ger.vandijck@xxxxxxxxx> wrote: > > Hi Fedora , > > > Thanks to George N. Withe 111 , Bob Marcom, Erik P. Olsen and Klaus > Peter Schrage. > > I did install rpmshere-release with dnf : Runs fine. > > > I did install clonezilla-2.3.1-1.noarch.rpm with dnf and got following > message :Nothing provides drbl-partimage >=0.6.7 needed by clonezilla > -2.3.1-1 noarch. > > Nothing provides mkswap-uuid needed by > clonezilla-2.3.1-1.noarch. > > So , What now ? Hmm, I'm not finding clonezilla in Fedora repositories, or in RPM Fusion. And at https://clonezilla.org/downloads.php I'm not finding it packaged for rhel/centos/fedora. And 2.7.2 is current at clonezilla.org, so I'm not sure about the provenance of clonezilla-2.3.1-1.noarch.rpm but I suspect it's a stale package given the version. I'm not sure what to recommend without knowing the use case. For generic use case, sync or backup, I'd use something either rsync or borg based. I tend to consider block based backups (dd, ddrescue, dd_rescue) pretty much for scraping, i.e. for emergencies and recovery operations where you must have an identical copy. That's usually not what you want for a backup. Btrfs is compatible with the above options but adds some unique capabilities of its own: * snapshot send+receive Makes an essentially identical copy of a snapshot. There are advantages (immediately accessible just by mounting the file system; full checksumming; simpler incrementals management) if you use Btrfs for the destination file system, but it is possible to use 'btrfs send -f' to create a file on any file system. But that file must be "received" on a Btrfs file system to navigate it. * seed+sprout Setting the "seed" flag on a Btrfs file system makes it read-only. Mount it, and 'btrfs device add' a 2nd device, followed by 'btrfs device remove' the 1st device, and it will kick off replication at a block group level. The copy is identical in every meaningful way, but the new destination device can be any size. Of course, it needs to be at least as large as the data usage on the seed. [1] -- Chris Murphy [1] Sorta :) Once the 2nd device is added, you are allowed to delete things you don't want replicated. They are retained on the read-only seed, but are not replicated when you remove the seed. This might all seem a bit confusing but it's all a direct function of copy-on-write. The "delete" is just writing an updated portion of the file system tree that lacks references for the files/dirs you've deleted, and this updated portion of the tree is only written to the 2nd device (all writes get directed to this 2nd device because the 1st device, the "seed" is read only). There's more but if I don't stop here even I will get confused. The feature is quite nuanced and powerful, including even stacked seed devices. Considering devices could be loop mounted files, it's perhaps an underrated feature so far. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
