Duplicacy seemingly ignoring Prune command parameters?

[boskev]

Hello, everyone.

A few weeks ago, the Fusion Drive on my iMac failed, and I decided to replace it with an SSD drive. Prior to this, I had scheduled a weekly Backup to BackBlaze of a ~250GB shared folder (which took about two days for the initial upload to complete, all without issue), and then a weekly Prune job to preserve only one of these weekly backups each month ( -keep 30:30 -a).

This routine worked very well, but when my repaired computer was returned to me, Duplicacy seemed to think that I needed to backup this entire large folder from scratch, and now I find myself in this endless loop where I cannot maintain a connection to my company’s server long enough to re-upload this 250GB folder to BackBlaze. My last successful update (i.e., incremental backup was on 11/6/2021) – everything since then has been a bunch of attempts that have timed out and failed to complete. What I’d like to do is just prune everything that’s occurred since 11/6/2021 and try again, hoping that Duplicacy will just try to upload the incremental changes again and not the entire folder. But the prune commands I keep sending to Duplicacy don’t seem to be pruning anything: I keep asking Duplicacy to delete a series of contiguous revisions, and when the Check results are returned, those very revisions still exist. I don’t really do anything too complicated with prune, so I feel as if I’m just doing something really stupid, making a beginner’s mistake. If anyone can offer any advice. It would be greatly appreciated.

Here’s the last Prune command I submitted: -r 43-47 -exhaustive -exclusive

I’ve tried this with and without the “-exhaustive” option. Thanks in advance

• Kevin

[gchen]

You need to add the id option to prune, that is, -id BNS-FDrive-B2.

[boskev]

@gchen

-id BNS-FDrive-B2.

And just like that, my problem is solved! Thank you so much, Gilbert.

Just for my own edification, why did I have to explicitly reference the Snapshot name when it’s the only Snapshot in that storage? It’s been a while since I’ve pruned just one revision, but I don’t recall having to do that before: -r seemed to be enough. Is there something different about this prune job?

[Droolio]

Good that you solved your prune issue, but just wondering… am not sure how a prune will help your next backup succeed? You still have the same amount of data to upload as before?

What I’d do in your situation is to exclude (or move out of the way) changed files, run a backup, and gradually include or move them back in.

But TBH, you shouldn’t have to do that anyway, as progressively you upload more and more chunks which won’t need uploading again - even if the incremental backup is aborted.

[boskev]

Hi, Droolio, and thank you for your reply. I’m not sure that I can explain why, but after I pruned all of those failed attempts (basically, rolling back my storage to where it was before my disk crashed), and then ran another backup/refresh attempt, it completed in 40 minutes – which is generally how long a weekly incremental refresh of that particular repository generally takes.

My disk failed mid-backup, and once it was replaced, Duplicacy seemed to want to start from scratch. But by deleting everything from that point forward, everything is now back to where it was, thankfully.

Again, I’m not sure if that’s “expected behavior,” but hey, I’ll take it!

Kevin

[Droolio]

@boskev

My disk failed mid-backup, and once it was replaced, Duplicacy seemed to want to start from scratch.

Aha! That may explain it… Hmm then what likely happened is the files became unavailable but Duplicacy completed an empty or mostly empty snapshot. Hence incremental backups having to re-chunk ‘new’ files.

Glad it’s now sorted.