Replies: 1 comment
|
Restic is great for simple use cases but it has problems when the data becomes big and there's high volume. Restic copies can become dirty since you start to backup files at T0 but at T1 a critical file changes then the whole data becomes corrupted. That being said, all databases have a way to natively backup and restore the database using docker so it's safer to keep using native tools and specific backup procedures for each database. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Temps has a very nice backup functionality, but I can't help but feel like it's reinventing (or at least reimplementing) a very complicated topic that a lot of people have thought about for a very long time.
Thoughts on leveraging something like https://github.com/restic/restic/ to broker the backups? Restic talks to s3-compatible backends, and builds in compression, deduplication, and strong encryption out of the box. It also supports FUSE-mountable recovery points and pruning old checkpoints. It could simplify a lot of the backup code that's already in temps.sh and it's a well-maintained battle-tested solution imho.
I'm using restic right now in my home-baked (no control panel) environments and it's really quite good.
All reactions