Add MySQL, MariaDB, PostgreSQL, SQLite support #24

altendorfme · 2025-11-16T02:34:39Z

I added MySQL, MariaDB, PostgreSQL, and SQLite as volume options, removed the files tab, and adjusted the listings.

I also had to add the client to the Dockefile to support dumping

I think this structure can still be improved; I don't know if volumes are a better place or if I should create a new Sources environment

nicotsx

Thank you @altendorfme this is a good first stab! I left you a few comments to review

nicotsx · 2025-11-16T10:01:17Z

app/client/components/create-volume-form.tsx

+		if (
+			formValues.backend === "nfs" ||
+			formValues.backend === "smb" ||
+			formValues.backend === "webdav" ||
+			formValues.backend === "mariadb" ||
+			formValues.backend === "mysql" ||
+			formValues.backend === "postgres"
+		) {


Maybe we could make this a constant ["nfs", "smb", ...] and here refactor to if SUPPORTS_CONNECTION.includes(formValues.backend) {} as this condition is becoming to big

nicotsx · 2025-11-16T10:03:18Z

app/schemas/volumes.ts

As SQLite is just a file, I'm wondering if it makes any sense to add it as a "volume". Users can simply use the local directory feature. I would remove it

nicotsx · 2025-11-16T10:06:22Z

app/server/modules/backups/backups.service.ts

-		const volumePath = getVolumePath(volume);
+		let backupPath: string;
+		let dumpFilePath: string | null = null;
+		const isDatabase = isDatabaseVolume(volume);
+
+		if (isDatabase) {
+			logger.info(`Creating database dump for volume ${volume.name}`);
+
+			const timestamp = Date.now();
+			dumpFilePath = getDumpFilePath(volume, timestamp);
+
+			try {
+				await executeDatabaseDump(volume.config as DatabaseConfig, dumpFilePath);
+				logger.info(`Database dump created at: ${dumpFilePath}`);
+			} catch (error) {
+				logger.error(`Failed to create database dump: ${toMessage(error)}`);
+				throw error;
+			}
+
+			backupPath = dumpFilePath;
+		} else {
+			backupPath = getVolumePath(volume);
+		}


I see this becoming hard to maintain if we ever add more types. Instead, I suggest you add a new abstract method in the xxx-backend.ts files for getVolumePath() and then here you. can simply call it the same way for all possible backends.

By doing this, you can get rid of all the 4 functions you have added in helpers.ts

nicotsx · 2025-11-16T10:10:41Z

app/server/utils/spawn.ts

-			resolve({
-				exitCode: -1,
-				stdout: stdoutData,
-				stderr: stderrData,
-			});
+			reject(error);


Why changing this? The whole purpose of the safeSpawn is to not throw and avoid needless try catches when using it

Sorry, this is the kind of change we make when some things break and we don't know why, haha!

nicotsx · 2025-11-16T10:11:30Z

app/server/utils/database-dump.ts

This should probably live in each respective backend file instead of a big everything helper

nicotsx · 2025-11-16T10:12:44Z

app/server/utils/spawn.ts

+		// Write stdin if provided
+		if (stdin && child.stdin) {
+			child.stdin.write(stdin);
+			child.stdin.end();
+		}


You don't seem to be using this at the moment. Could be useful but no need to clutter the code with it if we don't need it now

nicotsx · 2025-11-16T10:22:50Z

Dockerfile

+    mariadb-client \
+    mysql-client \
+    postgresql-client \


Bun ships with all 3 of these clients https://bun.com/docs/runtime/sql could you explore if it is possible to replace the usage of those clients with a direct connection from javascript and running a raw query for dumping?

Hum! I'll try it, I didn't know about this route!

I was reading the comparisons, and the native clients have full support for tables, views, triggers, procedures, and functions, and the backup process is safer and more stable for long processing times.

altendorfme · 2025-11-16T20:48:11Z

I removed SQLite support.
I reverted some tests
And I created a new method for volumepath

CLAassistant · 2025-11-18T18:39:23Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

nicotsx · 2025-11-18T19:04:53Z

Will merge this asap! Looks great

nicotsx · 2025-11-20T21:37:14Z

Hello @altendorfme

The more I tested the implementation the more I started thinking that maybe we are not the right tool to integrate Database backups. For a few reasons mainly:

Databases are not real “volumes” and we are adding weird code branches to make up for this. We have to run dump executions or “hooks” before backups and after for cleaning up
Since we create a new dump and back it up each time this goes a bit against the restic philosophy of incremental deduped backups
The frontend functionality like volume size, file explorer, “mounted” status, file inclusions/exclusions make little sense and we are also writing code branches to hide these parts to the user.
We increase the image size significantly with multiple clients that the user might not need

Overall I think this complexifies the code too much while the user could simply run dump executions from a script on the host and backup that folder with Zerobyte.

What do you think? I'm sorry you've probably spent some time here

altendorfme · 2025-11-20T21:47:19Z

To avoid this conflict with volumes, could I handle and separate them in an environment called Source or Database?

nicotsx · 2025-11-20T22:14:18Z

I think we should maybe start a discussion and check with the community how this feature would be used. This way we make sure that we get the implementation right from the get go

I'll start a thread tomorrow (it's late here) and ping you

sebwieser · 2026-01-28T13:04:37Z

Hello @altendorfme

The more I tested the implementation the more I started thinking that maybe we are not the right tool to integrate Database backups. For a few reasons mainly:

Databases are not real “volumes” and we are adding weird code branches to make up for this. We have to run dump executions or “hooks” before backups and after for cleaning up

Since we create a new dump and back it up each time this goes a bit against the restic philosophy of incremental deduped backups

The frontend functionality like volume size, file explorer, “mounted” status, file inclusions/exclusions make little sense and we are also writing code branches to hide these parts to the user.

We increase the image size significantly with multiple clients that the user might not need

Overall I think this complexifies the code too much while the user could simply run dump executions from a script on the host and backup that folder with Zerobyte.

What do you think? I'm sorry you've probably spent some time here

Hi @nicotsx, excuse me for jumping in. Speaking from a PostgreSQL perspective at least, your instincts are correct.
You will run into multiple issues trying to backup databases in the same way you do regular files.
Incremental backups with Restic will be done on a file level, meaning if a single database page changes, Restic will copy the whole database file. On a busy database, that could quickly start looking like a full backup.

Furthermore, it's common to restore databases to an exact point in time, which means you should make sure to back up WAL files as well in a consistent way, otherwise you're risking data loss or corruption.
Postgres has its own ecosystem of tools (pgBackRest, Barman) for creating consistent backups. PgBackrest is capable of creating proper database incremental backups on a block level.

If you'd like to cover database backups with Zerobyte, I'd always suggest going native.

I haven't been using SQLite much, but before backing it up, I'd make sure there are no writers to the file.

add mysql, mariadb, postgresql, sqlite volumes support

eb28667

nicotsx requested changes Nov 16, 2025

View reviewed changes

nicotsx reviewed Nov 16, 2025

View reviewed changes

altendorfme added 5 commits November 16, 2025 16:48

update for constant

0b6f64e

remove sqlite

0efe57b

cleanup

b333489

revert spawn

ff16c69

new abstract method for volumepath

14dadc8

Repository owner deleted a comment from CLAassistant Nov 18, 2025

altendorfme and others added 2 commits November 20, 2025 18:27

Merge branch 'main' into sql-support

b334c7c

Merge branch 'main' into sql-support

f6e2178

Add MySQL, MariaDB, PostgreSQL, SQLite support #24

Are you sure you want to change the base?

Add MySQL, MariaDB, PostgreSQL, SQLite support #24

Uh oh!

Conversation

altendorfme commented Nov 16, 2025

Uh oh!

nicotsx left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

altendorfme commented Nov 16, 2025

Uh oh!

CLAassistant commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nicotsx commented Nov 18, 2025

Uh oh!

nicotsx commented Nov 20, 2025

Uh oh!

altendorfme commented Nov 20, 2025

Uh oh!

nicotsx commented Nov 20, 2025

Uh oh!

sebwieser commented Jan 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

CLAassistant commented Nov 18, 2025 •

edited

Loading