As I experiment with different b2.connections values to get optimal throughput when using restic 0.12.0 to backup to Backblaze B2, I wonder whether there is any risk whatsoever in aborting a backup with Ctrl+C? Subsequently, I used restic rebuild-index to correct errors found by restic check – is this correct/advised procedure, or could something go wrong when rebuilding the indices?
I am aware that when aborting backups there will be some unreferenced pack files, and that those are no problem for restic. But I wonder: Could such abortion of restic leave behind any incomplete or partial files on the remote repo, which restic could see as corrupted – say, eg, a partial pack file without header? And, could this be worsened by rebuild-index, check or others?
To B2, no, this is not possible. B2 is “object storage” which requires a full and complete upload before any data is reflected in the bucket (same with S3). This is in contrast to other storage protocols like SFTP where it is possible for a file to be partially written. With object storage like S3 and B2, the upload either successfully completes in its entirety, or no file is created. (Except with “large file” or “multipart” uploads, there can be an in-progress multipart upload record, but this doesn’t appear like a file until it is completed. Restic does not need these anyway since the packs are not large enough to warrant using multipart uploading.)
And even if this did happen, prune can determine when a pack file was partially written and will automatically delete them, provided the rest of the rest of the repository looks undamaged.
Yes. rebuild-index is going to include the data in the unused packs in the index, so that backups can deduplicate against it. (This is the mechanism by which backups can be “resumed” – the client will dedupe data it’s already uploaded, even if that data is not referenced by any snapshot yet.)
No, there just isn’t sufficient information in this thread to determine what the issue is, if there even is one. I don’t think your original post even includes the supposed error message from restic check. If the output was “pack xyz not referenced in any index,” that’s not an error.
Right, so that’s more of a notice/warning and doesn’t indicate that there is actually any problem. A pack file not referenced in an index is just evidence of an interrupted backup and causes no harm at all. A future prune would clean up the extra pack if it never becomes referenced by a snapshot. rebuild-index is not necessary in this case.