Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!
-
@nebulon Yup that's it! Good to see it was already a scheduled task.
By the way, today my database filled up and I was no longer able to access my Mastodon app. (using Digital Ocean) I increased my droplet size, but that didn't seem to help as the database is in a docker image(?). Seems there wasn't a way to resize that image to use more space.
So my app is stuck is a state of database failing to connect because space is maxed out.
-
@MikeHuntington databases are provided as services to the apps on Cloudron. They run in their own container. Did the database run out of disk space (by default those are stored in /home/yellowtent/...) or did it run out of memory? For the latter you can adjust the memory limit in the services view.
-
@nebulon It ran out of diskspace after running mastodon for about 24 hours (with federation relays added)
-
@MikeHuntington in such cases go through the checklist at https://docs.cloudron.io/troubleshooting/#recovery-after-disk-full
-
@nebulon Thank you for that link! Is if possible to have my database run on a different server than the one cloudron is running on? Also is AWS S3 an option?
I know I can edit Mastodon's .env file directly but will Cloudron support that?
I think that'll help with diskspace a ton as well.
-
@MikeHuntington If you check out Cloudron's Mastodon forum there are a few discussions about how to use software like S3, Minio, Object Storage. It will def work.
EDIT: I just restarted my Owncast instance and set it up to use my Minio instance in just a few minutes. Once you get your head around how it all works, it's super smooth and do-able. -
@MikeHuntington True, and eventually I'll implement those commands to run automatically, but I imagine that someone who is surprised and frustrated by a rapidly-filling-up server won't have the tech skills, inclination or time to run those regularly anyway.
A win for Cloudron would be to offer a combined federation app - Mastodon + Scaleway, where the Mastodon instance also generates a user, Access Key ID and Secret Access Key which the user could then plug into a Scaleway Object Storage bucket (or there could be a drop-own menu offering S3, Scaleway or Minio), and also set the .env.production settings correctly. I realize doing that is relatively simple if you've done it before, but otherwise it could prove to be a barrier.
-
@robi said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
rcloneis a swiss army tool for connecting/mounting to remote storage and more.So if you have a deep store in GDrive, B2, Scaleway, Dropbox, etc you can connect them to your apps data/cache dirs.
Thanks for this very sweet knowledge! rclone has a (currently experimental) GUI (Graphical User Interface) which appears in the web browser. If Cloudron try supporting this, I hope they make use of it.
There are some lovely things rclone can interact with, apparently. I notice that rclone can help with internet archive:
-
@scooke said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
@MikeHuntington True, and eventually I'll implement those commands to run automatically, but I imagine that someone who is surprised and frustrated by a rapidly-filling-up server won't have the tech skills, inclination or time to run those regularly anyway.
A win for Cloudron would be to offer a combined federation app - Mastodon + Scaleway, where the Mastodon instance also generates a user, Access Key ID and Secret Access Key which the user could then plug into a Scaleway Object Storage bucket (or there could be a drop-own menu offering S3, Scaleway or Minio), and also set the .env.production settings correctly. I realize doing that is relatively simple if you've done it before, but otherwise it could prove to be a barrier.
This is a great idea and could remove a lot of friction for people wanting to self-host in the Fediverse.
-
@LoudLemur said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
A win for Cloudron would be to offer a combined federation app - Mastodon + Scaleway, where the Mastodon instance also generates a user, Access Key ID and Secret Access Key which the user could then plug into a Scaleway Object Storage bucket
+1 I'm too scared to run Mastodon on my server due to it eating all the disk. This would help.
-
@Sam_uk said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
I'm too scared to run Mastodon on my server due to it eating all the disk. This would help.
Could just spin up a new VPS for it (that's what I did, and switfly ran out of space! But then increased the size...)
And/ or just immediately go an set-up some storage elsewhere as a Volume and set-up the app to use that volume as the data storage directory as per https://docs.cloudron.io/apps/#data-directory
-
@jdaviescoates said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
@Sam_uk said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
I'm too scared to run Mastodon on my server due to it eating all the disk. This would help.
Could just spin up a new VPS for it (that's what I did, and switfly ran out of space! But then increased the size...)
And/ or just immediately go an set-up some storage elsewhere as a Volume and set-up the app to use that volume as the data storage directory as per https://docs.cloudron.io/apps/#data-directory
People like you make this place the brilliant community it is! Thanks.
-
@scooke said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
A win for Cloudron would be to offer a combined federation app - Mastodon + Scaleway, where the Mastodon instance also generates a user, Access Key ID and Secret Access Key which the user could then plug into a Scaleway Object Storage bucket (or there could be a drop-own menu offering S3, Scaleway or Minio), and also set the .env.production settings correctly. I realize doing that is relatively simple if you've done it before, but otherwise it could prove to be a barrier.
+1 something like that would be great because I've just gone to create a bucket on Scaleway (easy enough), but now I'm at a loss as to how I actually connect that to a volume. Which type of mount point should I use for the Volume?
-
@jdaviescoates you'd have to do that through rclone manually. Cloudron only supports S3 as a backup target, not App volumes.
-
G girish referenced this topic on
-
C chetbaker referenced this topic on
-
So I've been running into this exact issue really soon after hosting an instance with ~30 users for a few weeks. I'm now trying to migrate media files to an S3 storage, in my case it's a Linode Object Storage.
I've found this awesome guide which makes things pretty clear, but there's a question that came up when I read through it. In the section about configuring the bucket it says:
Also, these instructions are specific to manual deployments, you may need to modify paths slightly for docker or other automatic deployments.
Just to make sure, and please excuse if this question seems kinda inane, but: How exactly do I migrate my media files via Cloudron? Do I do it via the server console (Linode) or the Cloudron terminal? Is there anything extra I need to be aware of, any instructions that differ from this GitHub page?
Just trying to make sure I don't break everything while trying to migrate to external media storage. Please be patient.
-
@dxciBel I might be wrong, and I hope I am for your sake, but when you change storage systems I think you will basically be starting over. There is a way to move buckets if origin and destination are both already S3. For me, even though I was one user on my own instance, at the time the amount of data I had stored was huge, so I just called it a loss, changed to Minio, and let the instance slowly repopulate all the data it needed. The one thing I did do was SAVE all my own images, headers, icons, etc., for my instance.
In the process of writing this I did find these:
https://stanislas.blog/2018/05/moving-mastodon-media-files-to-wasabi-object-storage/
- the author recommends AGAINST Wasabi, but you want to read about the tools to move data from a regular storage to S3 using aws-cli. Almost halfway down there is this command which is what you want, and which you'll (obviously) have to adjust for your use-case:aws s3 sync public/system/ s3://my-bucket/ --endpoint-url=https://s3.wasabisys.com. "aws" is the command, "s3" is an option, "public/system" refers to where the data currently is, in your cloudron image, and "s3://my-bucket" is your Minio instance. I guess the last bit you need to include; if it doesn't work initially tweak the endpoint a few times, like remove the https...not sure how that it will go, but, it looks straightforward.Here are a few more. I suggest reading all of them before embarking on your journey:
https://github.com/cybrespace/cybrespace-meta/blob/master/s3.md
https://chrishubbs.com/2022/11/19/hosting-a-mastodon-instance-moving-asset-storage-to-s3/ -
@scooke said in Running a federated Mastodon instance will take up ALOT of space and RAM - be prepared!:
Almost halfway down there is this command which is what you want, and which you'll (obviously) have to adjust for your use-case: aws s3 sync public/system/ s3://my-bucket/ --endpoint-url=https://s3.wasabisys.com. "aws" is the command, "s3" is an option, "public/system" refers to where the data currently is, in your cloudron image, and "s3://my-bucket" is your Minio instance. I guess the last bit you need to include; if it doesn't work initially tweak the endpoint a few times, like remove the https...not sure how that it will go, but, it looks straightforward.
Yeah, I've not attempted moving files but it's obviously possible.
She also this guide that has similar command to above.
https://thomas-leister.de/en/mastodon-s3-media-storage/
Indeed in their set-up they not only move stuff over but also do some clever nginx stuff to serve files locally if they exist and if not to fetch from S3 and cache locally.
