Skip to main content

When a file will not copy

A replication job can report that a file failed. This page is about what that means, why nobody can tell you the reason, and the one thing that fixes it.

Backblaze does not say why​

Not to this app, not through its interface for other software, and not in its own web console. A failed file carries a mark saying it failed and nothing else.

There is one exception, and it is worth knowing because it is the commonest cause: when an account passes a cap, Backblaze sends an email. Check that email, and check Caps and Alerts in the Backblaze web console for both the account you are copying from and the account you are copying to.

Bucketree checks the other causes Backblaze names, and tells you what it found: whether the keys can still read and write, whether one bucket has Object Lock switched on and the other does not, whether any file is encrypted with your own key, and whether a large upload was left unfinished.

A failed file is never tried again​

This is the part that surprises people, and it is the reason this page exists.

The mark belongs to that version of the file, not to the job. Nothing ever re-reads a version once it has failed. So none of the following will help:

  • waiting, however long
  • fixing the cap or the permission that caused it
  • pausing and resuming the job
  • removing the job and setting up a new one

The last one is worth stating plainly, because it sounds like it ought to work and Backblaze's own documentation says it does. It does not.

What does fix it: a new version​

Backblaze judges a new version afresh. Upload the file again and it copies normally, usually within minutes.

Bucketree can do that for you without downloading anything. On a job with failures, press Fix These Files. It asks Backblaze to build a new version of each file from the file's own bytes, inside Backblaze, so nothing passes through your Mac, nothing is charged for download, and the contents cannot change on the way. The modification time and the rest of the file's information are carried across.

The new version becomes the current one, and the version that failed moves into version history.

The old versions​

By default they stay. That means the bucket stores both until you remove them, which the wizard tells you before it starts.

You can choose to delete them as part of the same operation. The files themselves are not affected: the new version is built from the old version's own bytes, so the two are identical, and what goes is a superseded entry in version history.

What it will not do​

A file encrypted with your own key cannot be copied inside Backblaze, and could not be replicated either. Those are skipped and named.

Older versions that failed​

A job can show failed versions while no current file is missing. That means an older version of a file failed to copy at some point, and the current version of the same file is safely at the destination.

Nothing is missing, and there is nothing to do. Those versions cannot be tried again and can only be removed, which Clearing what a bucket stores but does not show does.