From: nospam@needed.invalid   
      
   On Wed, 9/3/2025 3:05 AM, Jeff Layman wrote:   
   > On 02/09/2025 23:46, Lawrence D’Oliveiro wrote:   
   >> On Tue, 2 Sep 2025 16:26:18 +0100, Jeff Layman wrote:   
   >>   
   >>> ... but when I plugged in the USB stick and tried "Restore" it   
   >>> reported that there were no backups! I thought the whole point of   
   >>> having a backup is that it would be easy to restore to a new HD if   
   >>> the old one had failed.   
   >>   
   >> This is why you need to test your backup system by doing an actual   
   >> restore. Without that, you don’t actually have a backup system.   
   >   
   > I agree. When I started using Deja Dup (not "Deja vu"!!!) I tried a restore   
   to a temporary folder on the hard drive and it worked perfectly. I've since   
   tried restoring the odd file and folder just to check. All went without   
   problem. Out of interest, I    
   just tried the same thing on my current laptop with the backup I created   
   yesterday. Deja Dup found the backup on the USB stick immediately, and asked   
   what I wanted restored and where. I created a folder called "Restorecheck" and   
   "restored" a folder to it    
   without problem.   
   >   
   > So when I run Deja Dup on the other laptop, why does it not see the backup   
   on the USB stick?   
   >   
      
   A quick Google   
      
       “Backup Failed”: Could not restore '~/.cache/deja-dup/metadata'   
      
   Maybe have a look in there and see what "metadata" exists, per laptop ?   
      
   Perhaps it cheats, checks the metadata, then it sniffs some storage identifier   
   on the USB stick   
   and realizes the USB stick has been mounted on the system before.   
      
   The other laptop, might require a brute-force search to find such things.   
      
   On Windows, we would use Process Monitor, and CreateFile/ReadFile/WriteFile   
   of a program execution session would be recorded for us. On Linux   
   this might be "strace" or "truss", and what is recorded there, is mostly   
   path execution without a lot of other event types being recorded. (At one time,   
   the recorded paths had string length limitations, and software had to be   
   staged in a way that the pathname would not be too long.) Back in   
   my Unix days, this was frequently sufficient to develop a breadcrumb and   
   a theory, how a program worked. But over the years, such traces have so   
   much noise in them, it's a needle in a haystack. We would sometimes use   
   this on X11 applications, to see what order they were evaluating potential   
   preference files. There might be thirty "file not found" entries, which   
   is the program methodically checking for preferences. Such an approach does   
   not work well on multi-process executables -- an strace on Firefox might   
   not be tracing the process that is doing something naughty. When programs   
   like that were invented, multi-process and named pipes were not exactly   
   what they were designed for.   
      
   Debuggers can also give access to such information, but having a lightweight   
   tracer is just so much easier (no learning curve).   
      
   *******   
      
   https://man.archlinux.org/man/duplicity.1.en   
      
      --metadata-sync-mode mode   
       This option defaults to 'partial', but you can set it to 'full'   
      
       Use 'partial' to avoid syncing metadata for backup chains that   
       you are not going to use. This saves time when restoring for the   
       first time, and lets you restore an old backup that was encrypted   
       with a different passphrase by supplying only the target passphrase.   
      
       Use 'full' to sync metadata for all backup chains on the remote.   
      
   That implies there is some sort of expectation in terms of   
   what Master, restores what Slave ? Maybe you weren't supposed   
   to take the USB stick over there ?   
      
   This seems to be hiding the details   
      
       https://apps.gnome.org/DejaDup/   
      
          "Back up to the cloud, a network server, or a local drive"   
      
   Perhaps not all options, have the same restore capabilities ?   
   Maybe your NAS would be a good staging area (a consistent identifier   
   on both machines), but then I'm not sure how the remote machine   
   gets a copy of the metadata from the first machine.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)