For those wanting to give it a go, I'll send you guys private messages to not clog this thread with stuff that isn't relevant to others.
Thanks for tagging this convo in the other
thread,
@digitalpoint.
So, my main goal of getting this attachment content into CF is to make the site as fast as possible for my users, especially outside of US-EAST.
So, I'm am willing to give this a try. I probably need to manually migrate because of the number of objects I have stored. Can you fill me in a little more on what the file layout needs to be, I can preconfigure the buckets since that tends to take a while to copy? Besides splitting the buckets, what are the other changes to the layout of the filesystem? My main concern is that in 5 years we all move on from CF for some reason and need to be able to get back to "Standard" storage and then move to something else. My other plan, is to rclone to backup the bucket(s) back to linode's object storage to provide me a backup (and they also provide a 7 day rolling backup on top of that).
R2 is S3 compatible (for the most part, there are a few obscure calls that aren't yet implemented in R2, but for purposes of data migration and normal use, it's all there), so as long as there are tools for moving data around S3, there are tools that will work for R2 if you ever needed to get all your data off R2.
As far as getting R2 buckets "prepped" and moving data into them preemptively, the structure the add-on is using by default (I say default because technically someone could implement additional sub-folders or whatever else via the more traditional way of XenForo doing filesystems via config.php edits) is fairly simple:
One bucket can be used for
data, and another bucket can be used for
internal_data/attachments. For each bucket, data and internal_data is considered the "root". Objects should have the full path intact like so (this is a screenshot from a
data bucket):
For an
internal_data/attachments bucket, it's similar (note that "attachments" is still part of the path):
The reason we are keeping the attachments part intact in the path there (even though the whole bucket is just for the attachments folder) is in case someone wanted to use the same bucket for additional folders within internal_data (or all of internal_data), they don't need to reorganize things if making such a change.
If you look at the first screenshot, you'll notice that some avatars with .jpg extensions actually have mime-types of image/png. The reason for that is how XenForo works (it stores all avatars as .jpg even if they aren't
actually jpg). If you don't set an explicit mime-type when putting objects into R2, Cloudflare will analyze the contents of the file and assign the proper mime-type. So whatever migration tool you use, make sure it doesn't set it's own mime-type based on file extension as that could be problematic if Cloudflare is serving public objects with the wrong mime-type. Just something to be wary of sooner rather than finding out you've set the wrong mime-type on a zillion objects.
![[DigitalPoint] App for Cloudflare®](/community/data/resource_icons/8/8750.jpg?1692633961){kind=icon}
