Meta tags:
description=Setting up regular backups (optional, but not really);

Headings (most frequently used words):

backing, up, your, server, overview, failure, modes, application, secrets, postgresql, user, uploaded, files, redis, sponsored, by,

Text of the page (most frequently used words):
the (29), and (15), mastodon (13), backing (13), your (13), admin (13), you (11), are (10), #server (10), redis (8), will (8), for (7), postgresql (7), with (7), data (7), using (6), #failure (6), application (6), database (6), uploaded (5), files (5), that (5), secrets (5), api (5), only (4), need (4), stored (4), user (4), backups (4), accounts (4), setting (4), instance (4), profile (4), account (4), oauth (4), file (3), make (3), storage (3), such (3), use (3), corruption (3), from (3), hard (3), disk (3), drive (3), machine (3), but (3), lose (3), posts (3), overview (3), search (3), preferences (3), apps (3), reports (3), new (3), source (2), this (2), regularly (2), then (2), directory (2), public (2), object (2), responsible (2), hardware (2), streaming (2), other (2), goes (2), back (2), they (2), env (2), production (2), best (2), not (2), same (2), list (2), media (2), moving (2), stop (2), working (2), two (2), push (2), all (2), error (2), documentation (2), modes (2), optional (2), notificationpolicy (2), filter (2), report (2), quote (2), domainblock (2), notifications (2), trends (2), collections (2), domain_blocks (2), tokens (2), security (2), environment (2), implementing (2), installing (2), features (2), configuring (2), running (2), imprint, view, blog, join, sponsored, last, updated, november, 2025, also, available, 简体中文, improve, page, easy, writes, which, copy, var, lib, dump, rdb, local, copies, sizeable, where, default, system, external, provider, amazon, google, cloud, wasabi, don, worry, about, those, respective, companies, handling, failures, high, availability, setups, possible, hot, replication, have, second, always, date, ready, switched, over, down, risk, power, cuts, botched, schema, migrations, reason, occasionally, making, backup, recommended, pg_dumpall, pg_dump, easiest, since, never, change, store, somewhere, safe, called, off, site, ones, itself, hosted, fire, explodes, won, much, losing, almost, harmless, irrecoverable, contents, sidekiq, queues, scheduled, retries, previously, failed, jobs, home, feeds, can, regenerated, tootctl, avatars, headers, attachments, work, forward, some, functions, users, logged, out, factor, authentication, become, unavailable, web, subscriptions, stores, most, important, loss, result, complete, including, their, followers, there, types, people, general, may, guard, human, software, wrongful, deletion, particular, piece, former, type, considered, equivalent, things, backed, order, importance, any, real, world, should, sure, regular, really, webpushsubscription, translation, token, termsofservice, tag, suggestion, statussource, statusedit, status, shallowtag, shallowquote, scheduledstatus, rule, role, relationshipseveranceevent, relationship, reaction, quoteapproval, privacypolicy, previewcardauthor, previewcard, poll, notificationrequest, notificationfallback, notification, mediaattachment, marker, identityproof, filterstatus, filterresult, filterkeyword, featuredtag, featureapproval, familiarfollowers, extendeddescription, customemoji, conversation, context, collectionwithaccounts, collectionitem, collection, asyncrefresh, appeal, annualreport, announcement, measure, ipblock, emaildomainblock, domainallow, dimension, cohort, canonicalemailblock, accountwarning, entities, markers, lists, conversations, timelines, scheduled_statuses, polls, statuses, proofs, oembed, custom_emojis, announcements, health, grouped, async_refreshes, emails, annual, retention, measures, ip_blocks, email_domain_blocks, domain_allows, dimensions, canonical_email_blocks, tags, suggestions, mutes, followed_tags, follow_requests, filters, featured_tags, favourites, endorsements, bookmarks, blocks, methods, rate, limits, scopes, guidelines, practices, datetime, formats, rest, bearcaps, microformats, webfinger, activitypub, spec, compliance, design, reference, creating, themes, css, styling, state, management, components, frontend, guide, issues, disclosure, routes, code, structure, dev, technical, contributing, libraries, implementations, logging, obtaining, client, app, access, playing, getting, started, developing, roles, webhooks, index, troubleshooting, errors, moderation, actions, scaling, migrating, upgrading, release, cli, single, sign, captcha, onion, services, full, text, preparing, own, official, ios, android, leaving, externally, more, settings, set, promoting, yourself, others, dealing, unwanted, content, quoting, network, posting, signing, what,

Text of the page (random words):
backing up your server mastodon documentation what is mastodon using mastodon signing up for an account setting up your profile posting to your profile using the network features quoting other posts dealing with unwanted content promoting yourself and others set your preferences more settings using mastodon externally moving or leaving accounts official ios and android apps running your own server running mastodon preparing your machine installing from source configuring your environment configuring full text search installing optional features object storage onion services captcha single sign on setting up your new instance using the admin cli upgrading to a new release backing up your server migrating to a new machine scaling up your server moderation actions troubleshooting errors database index corruption webhooks roles developing mastodon apps getting started with the api playing with public data obtaining client app access logging in with an account libraries and implementations implementing quote posts implementing collections contributing to mastodon technical overview setting up a dev environment code structure routes security issues and responsible disclosure frontend guide components state management css and styling creating themes design tokens reference spec compliance activitypub webfinger security microformats oauth bearcaps rest api datetime formats guidelines and best practices oauth tokens oauth scopes rate limits api methods accounts blocks bookmarks domain_blocks endorsements favourites featured_tags filters follow_requests followed_tags mutes preferences reports suggestions tags admin accounts canonical_email_blocks dimensions domain_allows domain_blocks email_domain_blocks ip_blocks measures reports retention trends annual reports apps emails oauth async_refreshes collections grouped notifications health instance announcements custom_emojis directory trends notifications push oembed profile proofs search statuses media polls scheduled_statuses timelines conversations lists markers streaming api entities account accountwarning admin account admin canonicalemailblock admin cohort admin dimension admin domainallow admin domainblock admin emaildomainblock admin ip admin ipblock admin measure admin report announcement annualreport appeal application asyncrefresh collection collectionitem collectionwithaccounts context conversation customemoji domainblock error extendeddescription familiarfollowers featureapproval featuredtag filter filterkeyword filterresult filterstatus identityproof instance list marker mediaattachment notification notificationfallback notificationpolicy notificationrequest poll preferences previewcard previewcardauthor privacypolicy profile quote quoteapproval reaction relationship relationshipseveranceevent report role rule scheduledstatus search shallowquote shallowtag status statusedit statussource suggestion tag termsofservice token translation v1 filter v1 instance v1 notificationpolicy webpushsubscription backing up your server setting up regular backups optional but not really overview failure modes backing up application secrets backing up postgresql backing up user uploaded files backing up redis for any real world use you should make sure to regularly back up your mastodon server overview things that need to be backed up in order of importance postgresql database application secrets from the env production file or equivalent user uploaded files redis database failure modes there are two failure types that people in general may guard for the failure of the hardware such as data corruption on the disk and human and software error such as wrongful deletion of a particular piece of data in this documentation only the former type is considered mastodon stores all the most important data in the postgresql database the loss of the postgresql database will result in the complete failure of the server including all the accounts their posts and followers if you lose application secrets some functions of mastodon will stop working for your users they will be logged out two factor authentication will become unavailable and web push api subscriptions will stop working if you lose user uploaded files you will lose avatars headers and media attachments but mastodon will work moving forward losing the redis database is almost harmless the only irrecoverable data will be the contents of the sidekiq queues and scheduled retries of previously failed jobs the home and list feeds are stored in redis but can be regenerated with tootctl the best backups are so called off site backups i e ones that are not stored on the same machine as mastodon itself if the server you are hosted on goes on fire and the hard disk drive explodes backups stored on that same hard drive won t be of much use backing up application secrets application secrets are the easiest to back up since they never change you only need to store env production somewhere safe backing up postgresql postgresql is at risk of data corruption from power cuts hard disk drive failure and botched schema migrations for that reason occasionally making a backup with pg_dump or pg_dumpall is recommended for high availability setups it is possible to use hot streaming replication to have a second postgresql server with always up to date data ready to be switched over to if the other server goes down backing up user uploaded files if you are using an external object storage provider such as amazon s3 google cloud or wasabi then you don t need to worry about backing those up the respective companies are responsible for handling hardware failures if you are using local file storage then it s up to you to make copies of the sizeable public system directory where uploaded files are stored by default backing up redis backing up redis is easy redis regularly writes to var lib redis dump rdb which is the only file you need to make a copy of last updated november 21 2025 improve this page also available in 简体中文 sponsored by join mastodon blog view source cc by sa 4 0 imprint