Local Storage #299
Replies: 2 comments
|
That actually looks pretty handy for small projects where setting up a full DB feels like overkill. I like the idea of keeping things lightweight and simple instead of adding unnecessary complexity early on. Could be really useful for prototyping or local tools. |
|
Hey @SerhiiZahuba — thanks for the question! You also opened #322 with the same topic, so I’ve answered there in detail and will keep the conversation in the issue from now on. Short answer: yes, for now the full local free space is needed. The current flow writes the dump to a local working directory, compresses it locally, and only then streams the archive to the remote volume. So for a 700–800 GB database you do need roughly that much free disk on the host running Databasement (less after compression, but plan for the uncompressed dump + compressed archive existing simultaneously during the compress step). Closing this discussion in favor of #322. |
Uh oh!
There was an error while loading. Please reload this page.
Hi, I have a question about how backups are handled internally in Databasement.
From the documentation, it looks like Databasement first creates a full local dump file, then compresses it, and only after that uploads it to the selected storage backend such as S3, SFTP, or FTP.
Is that correct?
My main concern is disk space for large databases. For example, if I need to back up a database of around 700-800 GB, does the server running the Databasement Docker container need enough local free space to hold the full dump, and possibly also the compressed file at the same time before upload finishes?
In other words:
Does Databasement always stage the backup locally first?
Is upload to remote storage streamed, or only started after the full local backup is created?
What amount of temporary local disk space would you recommend for very large databases?
Thanks.
All reactions