Back in September of last year, I wrote in Bacula: 6 months on that cloud backups required part.0 in order to be recognized for automatic part retrieval.

While this was mostly accurate, the critical file is actually part.1. As such, when referencing my own blog post when trimming my bacula storage, I deleted the wrong file, leaving my "volumes" without labels, and thus rendering automatic part retrieval inoperative.

To remedy this, I needed to sync the part.1 files back into my local cache. As I'm using an S3-style storage mechanism for my remotes, I decided to use Rclone to bring the files back.

The command looks like this (this is the safe version that doesn't copy, hence -n, remove that when you're satisfied it's good to go):

rclone sync -n --no-update-modtime s3-server-ref:s3-bucket local --include "part.1"

Breaking this command down:

• Use the rclone command
• sync subcommand will synchronize from source to destination
• --no-update-modtime attempts to leave the modification time the same
• s3-server-ref is a reference to an Rclone server created with rclone config
• s3-bucket is the bucket (or path) of the source
• local is the path to the local destination
• --include "part.1" is a filter that only copies the specific filename

Running the version as a dry run (-n) results in (partial results):

2021/10/05 10:06:56 NOTICE: Vol-0998/part.1: Not copying as --dry-run
2021/10/05 10:06:56 NOTICE: Vol-1101/part.1: Not copying as --dry-run
2021/10/05 10:06:56 NOTICE: Vol-1105/part.1: Not copying as --dry-run
2021/10/05 10:06:56 NOTICE: Vol-1106/part.1: Not copying as --dry-run
2021/10/05 10:06:56 NOTICE: Vol-1110/part.1: Not copying as --dry-run
2021/10/05 10:06:56 NOTICE: Vol-0999/part.1: Not copying as --dry-run

which indicates that each of these files would be copied if this had not been a dry run.

Re-run the command removing -n and you should get the desired results.