Correct, this is about uploads migration.
The S3 access credentials are present in the restored database so there is no need to require these to be in an environment variable as well.
Providing the environment variables yield a failure as well
Restoring uploads, this may take a while...
Checking if db8015 already migrated...
200 of 206 uploads are not migrated to S3. S3 migration failed for db 'db8015'.
5 posts are not remapped to new S3 upload URL. S3 migration failed for db 'db8015'.
No posts require rebaking
Migrating uploads to S3 for 'db8015'...
Uploading files to S3...
- Listing local files
=> 21 files
- Listing S3 files
. => 16 files
- Syncing files to S3
Updating the URLs in the database...
Removing old optimized images...
Flagging all posts containing lightboxes for rebake...
5 posts were flagged for a rebake
EXCEPTION: 183 of 206 uploads are not migrated to S3. S3 migration failed for db 'db8015'.
No idea why this is failing.
Most uploads were at s3, so the “200 of 206 uploads are not migrated to S3” and “183 of 206 uploads are not migrated to S3” are incorrect. The amount of 21 local files is correct, and there are approximately 200 uploads in s3 (could be 206 as well). I do not recognize any of the other numbers (183, 16).
No idea why the restore process is trying to move more uploads to s3 either? It should just take the local images from the backup and leave the uploads in s3 alone? Or am I overlooking something?
In the end I ended up hacking the
enable_s3_uploads setting in the database dump to false, but that caused everything to be remapped back to local. And since there were a few images still local, it took a lot of work to figure out which ones needed to be mapped back to s3 and which one should not.
This is all on 2.4.0 beta11.