It’s great that all my posts live on my own PDS, except that it is now a single point of failure. Is there a way to setup a secondary PDS as a mirror, that can take requests should the primary PDS go offline?
3 Likes
There have been some thoughts along those lines here:
It’d be a matter of replicating your PDS’s database and maybe file / S3 storage ( if you aren’t using S3 for blobs ), and then having some sort of fail-over mechanism.
It’s not that far fetched, but nothing available for it right now I think. It’d also be possible for someone to make a highly-available implementation of a PDS with the failover features built-in.
We will most-likely end up doing something like that for Roomy eventually as we make a scaleable, highly-available hosting solution for our own PDS implementation.
4 Likes
this is more-or-less the idea of nostr tbh
1 Like
Failover pds works if it’s effectively the same pds, it’s kinda down to if the data is fully replicated and available. We’ve got autoscaling to handle load but are restricting by the SQLite file access, if it were on something like Postgres it would be significantly easier. Now if you want to failover to a totally different pds you’d also need to update the plc doc to migrate so would need to own a recovery key to do the signing yourself.
2 Likes
@baileytownsend.dev is working on data mirroring on mobile devices:
2 Likes
I think a mirrored PDS is pretty interesting and a cool thing to think on.
I think for PDS administrators it makes sense. But does feel like a lot of upkeep and I think personally keeping good backups and recovering from it that way may be a better solution of time vs effort vs money. But I know it’s a thing lots of folks would like to see.
I think for end users it’s already baked into the protocol with adversial migrations and backups. Just may not be as accessible to everyday users as what I am hoping a mobile app would give. PDS MOOver backups does this currently for public data (although it runs every 2 hrs, not instant 1:1) and does do the migrations, but it does not always feel as seamless as it could be that I hope to get from an app.
*these are just my thoughts on it. Def more than one way to tackle things like this. But I think atproto’s strength is not so much high availability, but the ability to recreate if needed.
3 Likes
For what it’s worth, I also realized recently-ish that subscribing to the firehose is enough to efficiently relicate your public repo in realtime. But that doesn’t handle things like keys and private preferences, etc.
How do you backup the PDS data? Is there any recommended path that is most suitable/preferable to do for a PDS? Or does this not matter?
Asking because I havent setup backups yet for my own PDS.
Right now all i have is snapshot level backups of my server. i’m thinking maybe rsync the /pds directory to another host for starters.