After purchasing pCloud for my backups, I came to realize that the API is extremely flaky. After every conceivable setting I could find in rclone and restic not working with pCloud I decided to build a REST server that would fix the repo on the fly. Truth be told, an agent did the work. I just steered
I have tested it the past couple of days with my own backups and everything seems to be working fine.
The logs look something like the following:
2026/09/09 07:00:46.597243 pcloud-repair-server 72775be listening on 0.0.0.0:8080, remote root pcloud:restic (max-retries=3, debug=false)
2026/09/09 08:04:14.101086 [info] SAVE pcloud:restic/myrepo/data/f3/f3e170caa645cc1fc5a71ead27a8de61cb65de8d7b6bafcace4745c801234567 [req 00377] initial attempt: wrote 17266469 bytes but pCloud still shows it missing - retrying fresh (copyto=16s verify=5m9s)
2026/09/09 08:04:39.607240 [info] SAVE pcloud:restic/myrepo/data/f3/f3e170caa645cc1fc5a71ead27a8de61cb65de8d7b6bafcace4745c801234567 [req 00377] retry 1/3: verified OK (17266469 bytes, total 5m50s)
I hope all the people who bought the life time subscription to their storage only to find out they could not use it for their backups, now have a solution.
I don’t know pCloud in particular but when I read your post I think this: you don’t do backup to do backups. You do them so you can restore right when you really need to. So you need a service as reliable as possible and not one where you’re always uncertain.
But even if you are certain - make sure you test restores regularily or at least restic check --read-data(-subset).
A backup is nothing without a regular test restore. I agree. The problem is pCloud has a dreadful API that basically validates a write when it’s not the case. The tool just checks the pack that is written is identical to what is expected and if not, deletes it and sends the pack again.
I don’t see why you assumed I thought it would replace a test restore or a repo check?
pcloud’s been flaky for me with rclone too. the verify-on-write approach makes sense if the api lies about completes.
i’d still run restic check --read-data-subset 5% on a schedule against that path so a silent bad pack does not sit there. curious how often your repair server actually rewrites vs first-try ok.
I’ve backed up about 200G and had about 20 retries
2026/09/09 08:04:14.101086 [info] SAVE pcloud:restic/myrepo/data/f3/f3e170ca... [req 00377] initial attempt: wrote 17266469 bytes but pCloud still shows it missing - retrying fresh (copyto=16s verify=5m9s)
2026/09/09 08:04:39.607240 [info] SAVE pcloud:restic/myrepo/data/f3/f3e170ca... [req 00377] retry 1/3: verified OK (17266469 bytes, total 5m50s)
2026/09/09 08:09:59.997904 [info] SAVE pcloud:restic/myrepo/data/ed/ed31418d... [req 00429] initial attempt: wrote 16931861 bytes but pCloud still shows it missing - retrying fresh (copyto=22s verify=5m14s)
2026/09/09 08:10:45.393161 [info] SAVE pcloud:restic/myrepo/data/ed/ed31418d... [req 00429] retry 1/3: verified OK (16931861 bytes, total 6m22s)
Again, I am not saying it’s a substitute for checking your repo. I’m saying it’s a fix to a flaky API. I check a percentage of my repo after each backup as well as doing monthly test restores.
The tool is only there to avoid having a corrupted backup.
