A super techy friend suggested I use Duplicati to handle my backups. Based on reviews I read online, I thought it would meet my needs of simply backing up my D drive (my data) to another HDD (I know I can backup to my cloud service). I created three backup types (1) Complete, (2) Pictures, and (3) Test. The first two were scheduled for a later date. The third was for 4 files, a mix of docx and jpeg. I chose “Run Now” and the process bar indicates it is backing up. Each time I have run this backup, it tells me there is an error and to “Please Run Repair”. I have searched the program and this forum for how to run the repair. There are many threads with “Please Run Repair” in them, but none seem to be asking how. What have I missed?
Any thoughts, ideas, suggestions, etc., are appreciated.
Thank you Pectojin. I found it yesterday using your instructions and ended up deleting because it could not repair. I created another Test backup using the same four files (files that are not corrupted and were not in use or changed) and the program ran successfully.
I think I put the task somewhere here… *looks through giant pile of stuff to do*
In all seriousness, I don’t see any reason not to implement this idea, so I will make a pull request this week if no one beats me to it. It’s a minor change too.
Running on Windows, I swapped from a standard install to running as a service. Exported the config then reimported it to the Run as a Service version. I then enabled VSS backup.
This caused the next backup to flag up umpty thousand files “not recorded in local storage”.
I saw the above error message asking to run a repair, but there is no repair button.
Is this button supposed to appear in the current beta?
If I installed a Canary the dog would probably eat it. So I stick to the Beta.
I’ve moved two “standard backups” across to a “Run as a Service” and “turned on snapshot \ VSS”. One or both of these steps causes the database to need to be repaired\rebuilt.
So I’ll have to say it is nice to see when things go crunch that repair and recovery work well.
It is when things go wrong that you find out how well software is written.
It sounds like when you did your initial standard-to-service shift you either didn’t use the imported job’s Database page to point to the old .sqlite file OR rename the existing file to whatever name the imported job was using.
When importing a job it automatically gets assigned a new .sqlite file name so you don’t risk running two jobs pointing at the same file. Though it might not hurt to add a feature that says “Hey, we noticed you just imported this job - if it’s replacing an old job that won’t be run anymore, point us to the old database and we’ll move it over to the new job.”
Ah - so nothing repaired, it just brought a few settings over to the newly created backup?
I have a few more I wanted to change. Is there a help page as to how to do this correctly? I had assumed “Export” from one followed by going to the service based backup and “Add Backup / Import from a File” would have been enough.
There’s a Windows focused guide (see below) but it can be generally applied to Linux & MacOS as well (just different paths and processes for stopping/starting services/daemons).
If you’ve already used it (or look through it now) and find it lacking / confusing please feel free to offer some suggestions on how to make it easier to use. One of the drawbacks of getting to know software well enough to try and write a How-To is that it because easy to skip steps that seem “obvious” or to forget to include things that have become second nature.
Exporting a job will indeed export the settings for the job (though you may need to re-enter passphrases and re-authorize some cloud destinations). What it won’t do (at least as of 2.0.3.9) is is bring over any GLOBAL settings or the existing sqlite database.
When the new job is created it gets a “fresh” database so the Repair you did was really to sync the remote file info into the local database - but yes, it was essentially a database Recreate.
Really the only thing you could have done “better” would have been to manually bring the sqlite database file over to the new backup at which point the Repair shouldn’t have been necessary.
I am going to keep note of my experiences. I can certainly see a few holes based on the “obvious” stuff that you know as the developers.
Little things like moving the database when swapping to the service based version. Maybe a message appearing on screen say - “Oi, dappy, did ya remember to bring the database over?”. Never would have occurred to me that anything other than the export file would be needed.
I am also seeing hiccups in backup over the LAN to an SMB share. Backups are running, tell me they were successful but “missed some files”, yet when I look in the backup folder there is nothing there. I’ll look closer at that and build up some feedback. I want to give you some polish from the “Dumb User” world.
Oh - and thanks for that link. That isn’t the one I initially found and have now see other tips in that thread that are useful.
