I am setting up Duplicati for a friend to backup to a Minio store I am running. Most of the backup is (not very compressible) photos. I started this backup from hist location, but the transport is so slow that the initial backup is going to take forever.
Given my use of a S3-compatible backend, would it be possible to instead create a backup that writes to a local disk, take the disk to the server where the Minio backend runs and just copy it in place?
Yes, that’s possible. After the backup is completed, copy all Duplicati files to the new location and before the next scheduled backup starts, edit the backup job and point to the new location. When the next backup starts, Duplicati will find all expected files in the new backup location and will continue backing up to the new backend.
Depending on how comfortable you are with file browsing in S3 buckets you might want to use the Duplicati GUI destination test feature to create the folder into which the seeded files can then be placed.
Digging out an old post, but it looks like it confirms my needs.
I have done an initial backup from my PC to a second PC using Duplicati. That destination PC was just using a Windows File Share.
Now I am going to pull that hard disk out, scrap the PC, put the disk into a caddy, attach it to the back of a router.
So, if I understand this correctly, literally all I need to do is change ONE value in Duplicati and all will continue as before. Just change the \\pcname\share to \\router\newshare and all will be well.
I am hoping there won’t be too much of a speed difference \ time lost by swapping from a chunky old PC to a router. There will be a saving in power costs and desk space which is important in this case so I don’t mind it if it takes a bit longer.
(BTW - if an admin is reading this the “reply by email” option bounces back with errors. Complaining about “relaying denied”)
Aah, people are looking at the badges page! Excellent! Never mind @JonMikelV’s stance on badges. He does a huuuuge amount of work here and of course no badge can pay for that. But for ordinary users, badges may well be a motivating factor
But I think you have a point that perhaps discourse should hide email related badges when email is not activated. Will raise it on meta.discourse.org.