Summary of goal: I want all the versions in my backups, and I want to clone all the versions to another machine.
Details of goal: I have two backup locations. For simplicity I’ll call them A and B. Recently backup location A died when its hard drive died. Fortunately backup B lives on as its hard drive is good. B has hundreds of backup versions. I bought a new hard drive, and I want to clone B back to A and keep all the versions.
I tried and failed to clone once already. I tired to copy all backup files from B to A. Then I created a new A backup whose settings exactly matched the old A backup settings (settings created via an export .json file). When I ran A’s backup job, it found missing files and a repair option was needed. But A completed, and now I’m at 1 version on the new backup, I don’t have my versions.
Is there a better approach to clone the backup? Should I clone the local database too?
I think this is an important question. The database is very much tied to its destination.
Copying all destination files needs either copying its database, or recreate by Repair.
If you mean you looked inside the file, as opposed to letting Duplicati read for new job,
then you might have been using the old A database which knows nothing about B files.
Repair “fixes” things by deleting files the database thinks are extra, i.e. it doesn’t know.
If this is wrong, and you have B files, count dlist files. Each one represents a version.
Would that not be similar case when a user looses everything and all that they have is the backup (but nothing to start from)?
So - if backup B is copied to location A and then a new backup is created to location A - providing just location and password - will the system not be able to pick up from there? Since A=B then A and B should be identical.
I was under impression that copy of the DB is preserved at the backup location (but I may be wrong).
It’s not, and it could be a long upload for even a tiny change, as whole DB would be needed.
If you’re trying to get back in business (not just restore), do Repair to recreate the database.
The other thing not stored is the configuration (much smaller), so Export To File and secure.
No. If you still have the old A database, all its information will no longer match and there will be missing files that the database says should be there, and “extra” files the database thinks should not. It never saw them.
If you deleted the old A database, then the new database knows no files to be missing, but does find extras.
The database describes the backup files, and backup files are checked against database. They’re in a pair.
I have a backup with hundreds of versions.
I want to copy it to a different location to have another backup with hundreds of versions, and not a new one.
Then I want to use both the backups, not the second one in place of the first one.
As in backup to two destinations from one source computer? You’ll need two jobs, each with its own database and destination files. Clone the destination, export the job, import to clone the config, change its name, its destination, and maybe other things too. You’ll get a new database path. Copy the old database to the path. DB won’t be there from the new job until backup runs, but you get there first. After that, these clone jobs run independently as two backups.
