KillianLarcher @ KillianLarcher @lemmy.world

帖子

4

评论

13

加入于

3 mo. ago

Thanks for the feedback! Feel free to open issues for these ideas. A PR for SECRET_FILE support would be very welcome.

Thanks for adding Portabase to OpenAltFinder! I missed your message earlier, but I appreciate it.

Yes, this is one of the common use cases.

You can back up version X and perform the migration to version Y. If anything goes wrong during the migration, you can simply restore version X from the initial backup (you will, of course, need to downgrade to the original database version before restoring).

Thanks! PostgreSQL is well supported (it was the first database implemented). Feel free to open an issue on GitHub if you want to suggest any improvements.

Hi, Portabase handles database backup and restoration. It does not manage the migration process, so it depends on the type of database and whether migration is handled automatically or not.

Do you document the manual restore process for those?

No, we haven’t documented it yet, but that’s a good idea. I’ll add it to the backlog, and we’ll work on it soon!

Hi,

1. The agent need to be on the same network as your database. You can either include the agent in the same Docker Compose setup or create a Docker network to link them. I’m not sure what you mean by 'persist across restarts.' Can you clarify? However, it works perfectly fine with databases running in Docker.
2. For Redis and Valkey, hot restores are unfortunately not supported. You need to stop the services and perform some manual operations. This limitation is why backups are mainly useful for disaster recovery rather than live rollback.

Feel free to ask any other questions or clarification if needed.

Okay, yeah, I see. Unraid Community Apps is probably closer to something like Proxmox VE Scripts. Dokploy and Coolify are more like libraries of templates for Docker services.

Currently, the backup process is logical. Incremental backups are not implemented yet, as supporting them across multiple database systems (PostgreSQL, MariaDB, MongoDB, etc.) would require significant development effort.

The system relies on the database’s native tools when possible, such as pg_dump for PostgreSQL or mongodump for MongoDB. Table-level backups are not currently supported, but could be introduced in the future if there is enough demand.

I wasn’t aware of this. I’ll take a look! Is it similar to Dokploy or Coolify?

Thanks for sharing your use case. To be transparent, we didn’t consider automation when we created the local file config, but it’s indeed the perfect use case for this mode of operation. In any case, we’ll keep the current behaviour to avoid breaking changes. This will be introduced as an additional feature.

I’ll keep you updated on this. And yes, remote backups are one of our key differences compared to other systems: the agent-based architecture enables operations across multiple networks without requiring SSH tunnels or exposing databases publicly.

Hi @morethanevil@lemmy.fedifriends.social, We’ve received similar feedback from other users, so we are currently working on it. However, this requires changes to some internal processes, as the system was not initially designed this way. Thanks for the feedback!