From: nospam@needed.invalid   
      
   On Sun, 2/15/2026 11:04 PM, Gordon wrote:   
   > On 2026-02-13, Alan K  wrote:   
   >> On 2/13/2026 8:14 AM, occam wrote:   
   >>> I'm currently transitioning from Windows to Linux Mint (under dual   
   >>> boot). Before I abandon Win10 for good I want to be sure I am able do   
   >>> everything in LM that I normally do under Win10.   
   >>>   
   >>> Is there an LM way of backing up /synchronising my data files onto an   
   >>> external drive? My favourite Windows program is SyncBack, which allows   
   >>> the synching of the two drives (i.e. incremental backup) without the   
   >>> need for a full backup every time. It shows me which files are to be   
   >>> deleted, which are to be updated and which are new files to be   
   >>> transferred - displayed in an easy-to-follow screen.   
   >>>   
   >>> Thanks for any pointers.   
   >>>   
   >>>   
   >> I keep windows 11 and dual boot, and since I have a perpetual license for   
   Acronis,   
   >> I use it to backup my Linux partition.  It's worked for me for years.  It's   
   also only the   
   >> 2020 version.   
   >>   
   >> Do you question your process?  Have to verified it works?   
   >> Like blowing out your entire docs folder and then trying to restore it?   
   >   
   > Are you able to restore the backup to a temp/partition disk?   
   >   
   >> Heck if it works fine.   
   >   
   > But what if it does not and its the only copy you have?   
   >   
   >>   
   >> I may try SyncBack and see how it works.  I currently use mint's backup   
   tool.   
   >> It's a bit quirky to get setup but I do now and I make daily backups with   
   it. But this only   
   >> makes snapshot tar files.  Good for the OOPS conditions.   
   >   
   > Not if it will not restore.   
   >   
   >> I also use rsync to do some mirroring now and then.  It's very easy to   
   script   
   >> since it's basically 'cp'.  rsync source dest.  You just add the needed   
   flags.   
      
   Your responses suggests a quite-unreliable storage model in your mind.   
   I have had bad blocks -- but on a refurb computer and its included disk.   
   Just not on the disks I use for backups.   
      
   The beauty of the Acronis or Macrium or even (heaven forbid) the Ghost,   
   was that they could mount the output image, like the .tib or .mrimg as   
   a FUSE-like file system.   
      
   For example, right now, I can back up C: to .mrimg, mount it as K: ,   
   turn off the permissions on K: and visit places I would normally not   
   be able to go. K: is read-only and you cannot damage the .mrimg .   
   And the .mrimg has some kind of primitive repair capability (implying   
   hashes at some level), but I've not had a demonstration of this.   
   I suppose I could experimentally damage a .mrimg and see if it recovers.   
   It would likely be easier to just read the manual.   
      
      [Picture] Use the "Download Original" button if the picture is fuzzy   
      
       https://i.postimg.cc/4ybV99x7/Macrium-mounter.gif   
      
   Does the product have limits ? Yes. When it backs up an EXT4, you cannot   
   mount the EXT4 without some other third party help (at a minimum). The GUIDs   
   of partitions are similarly NOT going to be changed on a restore for those.   
   While EXT4 does use smart backup (only blocks with data are output),   
   it cannot do the demo in the picture. But it's still a backup and   
   it is still a "protection against failed hard drive" capability.   
   I can back up a multiboot disk, and have the entire thing restored   
   without a stitch of work. No slaving over a command line. No solving   
   puzzles with BLKID and so on.   
      
   I have had "bad" Verifies, but it was caused by bad RAM on the   
   source computer, in the hard drive buffer pool area. And fortunately   
   (purely by accident), the Verify just happened to cover the   
   section that was causing the corruption. Not all failures ("my   
   computer not being a computer") are detected by hashing schemes.   
   But that failure was in just the right place, for the Verify   
   to catch it.   
      
   While a backup system could use PAR2 blocks, it's unlikely any   
   commercial operation will resort to that, because "it's not mathematically   
   robust". People use PAR2 every day, but I don't know what the properties   
   of such are at the moment (whether PAR2 failures-to-repair still happen).   
      
   The ultimate protection is to use two disk drives, and put   
   snapshots on both of them. (And run Verify on both, before   
   putting the disks away.)   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)