Days ago I deployed a Vaultwarden here and it felt good. At that time, I duplicated both machines and volumes that were originally only deployed in HKG to NRT for stability. But just now, I found that the data of the two Volumes is not in sync. If my requests lands on HKG, everything goes fine. But if it lands on NRT, it will return to the initial interface where I didn’t set up Vaultwarden in the first place.
Now I have confirmed the problem, but I don’t know what to do. I hope to delete the machines and volumes that are not synced by NRT on the basis of keeping the HKG’s, and create another machines and volumes located elsewhere (as long as it is not HKG), and keep it in sync with the current HKG configuration.
Is that possible? If yes, may there some kind hints? Thanks in advance!
Well, there does have same post arguing this problem, see https://community.fly.io/t/data-not-in-new-volume-after-using-fly-scale-count-2/18919/9, so I’m confused why “Always provision at least two volumes per app. Running an app with a single Machine and volume leaves you at risk for downtime and data loss.” is urged though data between two different volumes won’t be synced? Should I do it manually? But there is no applicable command I can perform.
“Fork” in this context is a one-time copy, not an ongoing connection, so the operation will have to be repeated (manually) every so often. And older spares will likewise need to be removed.
The NRT copy will not have a Machine attached; it will just be the data. That way, if something later happens to your HKG server, you will be able to restore from the rescue volume.
Alternatively, you can get a little more elegant with this by creating a separate application that just does rsync every hour, on a timer.
Both of these approaches assume that you’re ok with your Vaultwarden interface being down for a few hours (until you manually restore it) on rare occasions, .
Hope this helps a little!
Yes, Volumes are by far and away the most confusing aspect of the Fly.io platform. (Even users who have been here way longer than I have are taken by surprise sometimes.)
They’re really only “half” of what people have come to expect from a cloud environment; I expect that the passage you quoted will eventually be reworded to instead say “use Tigris, Supabase, LiteFS, or Tarsnap—unless you have a POSIX wizard hat”.
Thanks for your clarification, these really helps! Actually, I’m already learning how to rsync between apps and backup vault database. Your answers are truly enlightening.
.