How do I know a prune job completed successfully?

Support
,
#1

Today I ran

duplicacy -log prune -storage pcloud -keep 0:1800 -keep 7:180 -keep 1:90 -keep 30:365 -delete-only -threads 2 -exhaustive -all

via the web-ui and it went surprisingly fast. Too fast, tbh, considering how long other commands have been taking. The web-ui is confident that the job completed:

image

But when I look at the log, it doesn’t really convince me that this is the case:

Running prune command from /tmp/.duplicacy-web/repositories/localhost/all
Options: [-log prune -storage pcloud -keep 0:1800 -keep 7:180 -keep 1:90 -keep 30:365 -delete-only -threads 2 -exhaustive -all]
2020-10-06 16:24:53.030 INFO STORAGE_SET Storage set to webdav://<myusername>@webdav.pcloud.com/Backup/Duplicacy
2020-10-06 16:25:04.833 INFO RETENTION_POLICY Keep no snapshots older than 1800 days
2020-10-06 16:25:04.833 INFO RETENTION_POLICY Keep 1 snapshot every 7 day(s) if older than 180 day(s)
2020-10-06 16:25:04.833 INFO RETENTION_POLICY Keep 1 snapshot every 1 day(s) if older than 90 day(s)
2020-10-06 16:27:07.338 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/35' returned status code 403
2020-10-06 16:28:41.382 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/50' returned status code 403
2020-10-06 16:31:58.449 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/125' returned status code 403
2020-10-06 16:33:18.661 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/131' returned status code 403
2020-10-06 16:37:12.746 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/172' returned status code 403
2020-10-06 16:41:05.742 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/266' returned status code 403
2020-10-06 16:43:40.397 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/331' returned status code 403
2020-10-06 16:50:28.922 INFO WEBDAV_RETRY URL request 'GET snapshots/NAS/538' returned status code 403
2020-10-06 17:03:04.829 INFO WEBDAV_RETRY URL request 'GET snapshots/SERVER/108' returned status code 403
2020-10-06 17:07:00.782 INFO WEBDAV_RETRY URL request 'GET snapshots/SERVER/142' returned status code 403
2020-10-06 17:09:58.645 INFO WEBDAV_RETRY URL request 'GET snapshots/SERVER/175' returned status code 403
2020-10-06 17:12:25.416 INFO WEBDAV_RETRY URL request 'GET snapshots/SERVER/216' returned status code 403
2020-10-06 17:16:31.827 INFO WEBDAV_RETRY URL request 'GET snapshots/SERVER/278' returned status code 403
2020-10-06 17:28:23.723 INFO WEBDAV_RETRY URL request 'GET snapshots/PC_C/233' returned status code 403
2020-10-06 17:34:59.013 INFO WEBDAV_RETRY URL request 'GET snapshots/PC_C/464' returned status code 403
2020-10-06 17:46:12.649 INFO WEBDAV_RETRY URL request 'GET snapshots/ALPHA_C/78' returned status code 403
2020-10-06 17:50:17.519 INFO WEBDAV_RETRY URL request 'GET snapshots/ALPHA_C/133' returned status code 403
2020-10-06 17:55:11.969 INFO WEBDAV_RETRY URL request 'GET snapshots/ALPHA_C/195' returned status code 403
2020-10-06 17:56:29.909 INFO WEBDAV_RETRY URL request 'GET snapshots/ALPHA_C/214' returned status code 403
2020-10-06 18:01:43.017 INFO WEBDAV_RETRY URL request 'GET snapshots/PC_D/134' returned status code 403
2020-10-06 18:02:46.855 INFO WEBDAV_RETRY URL request 'GET snapshots/PC_D/173' returned status code 403
2020-10-06 18:11:29.818 INFO WEBDAV_RETRY URL request 'GET snapshots/PC_D/503' returned status code 403

Shouldn’t there be some more information in the log? Or did I just get used to looking at logs with the -d or -v flags and expect too much of an ordinary log?

How does the web-ui know that the job completed succesfully? Or does it? I realize it just says “Completed”, not “Completed successfully”… :thinking:

So one corrupted chunk can destroy all my backups?
#2

Completed means Completed successfully. If the job fails the job status would be Failed.

All those WEBDAV_RETRY messages are INFO level messages, which means they’re not errors. I don’t know why pcloud returned 403 in those cases, but the fact that there were no subsequent errors means retries were already successful and this is the evidence that pcloud servers sometimes acted up temporarily.

1 Like
#3

Excellent! That is good news!

I’m wondering, though: couldn’t the logs be a bit more user-friendly? For example, couldn’t duplicacy write something like prune command executed successfully before exiting? (Same here, BTW)

I would also like to see some basic summary of what it did. Like, how many snapshots and chunks it deleted/fozilized, resurrected… Perhaps the latter could be issued when -stats is used. As far as I can see, prune doesn’t have a -stats option, is that correct?

1 Like