isolating appwrite containers from their data

I want to be able to restore appwrite wholesale should something go awry. At the very least, the mariadb needs to be stored somewhere outside the /var/lib/docker directory. What else needs to be mapped to separate storage? It should be so that I could blow away all the containers (that is blow away /var/lib/docker), recompose with a configured .env file and appwrite would just reconnect to its restored data.

See:

1. https://appwrite.io/docs/production#backups
2. https://youtube.com/watch?v=lM5yZEPtlvg

thanks for this info. I believe to raid protect my data, I need to put /var/lib/docker/volumes on the raid. This is where everything is stored.

I made /var/lib/docker/volumes a zfs filesystem and was able to restore it from a zfs snapshot with no trouble.

one thing to note is that everything under /var/lib/docker has to be zfs for this to work. I was able to create a fresh system and simply swap in /var/lib/docker/volumes from another system and it immediately worked. I assume it would also work if everything were btrfs, too.

I just tried another test and it's failing. The database containers won't start up.

@mauricev What you want is store all the data separately from appwrite, true?

In such case I think it's going to be better to install the MariaDB server outside the appwrite container and then connect it to Appwrite by setting the corresponding variable in the docker compose file

Note that raid ≠ backups.

Raid is not a guarantee that in case something goes wrong you will be able to recover all data

In fact if something goes wrong you will get everything deleted/corrupted/etc from both the original and the raid copy. Raid is not a backup as said, It's for I'm case your physical server/machine disk stops working. I'm such case you can recover everything quickly from the other raid copy

I certainly don't want to have mariadb be separated. That deviates from out of the box configuraton. What I learned is that you can't easily do mounts inside the docker directory. The trick is to make an /etc/docker/daemon.json file and give it an alternate location for /var/lib/docker like so { "data-root": "/spool/docker" } spool/docker is a zfs filesystem

I just tested this by taking a snapshot, making some changes, stopping docker, reverting the snapshot, restarting docker. And everything reverted completely unaware that I pulled the rug right from under it.

Thinks it's a really bad idea to put mariadb db file on zfs. Search how it works 😉

Follow Steven links and backup your data, or use mariaDB cloud service, wich leverage backup/Snapshot/restore for you

I trust zfs for all storage 100%.

I don't know anything about zfs, but if this is like a snapshot of the disk, it can be dangerous in the case where what's on disk is mid transaction/write/etc. Then, when you restore, you end up with a corrupted database

Also snapshot are not backups, and the should not replace backups, so it's important having backups and if possible following 3 2 1 method in the case such data is really important (3 copies in 2 places, 1 offline/off-site)

db file isn't storage like image. It can works for sure, but you need many fine tuning and need to really understand how zfs works for maintenance. It can quickyl corrupt your data if you don't know what you do

Isn't the point of InnoDB tables, transactions, and ACID compliance to prevent this sort of thing from ever happening?