I’m trying to setup an efficient and secure environment for my two (raspberry pi 4) servers, and have a few questions I haven’t really got a clear answer on by reading and reading (and reading).
My setup:
Two servers (A and B), running LXD 5.8, with btrfs storage pool.
They both have the same containers, but server A is “responsible” for running one subset (subset X) of the containers, and server B a different subset (subset Y).
I.e. only about half of the containers are running on each of the servers. This is to have quick redundancy ready if needed.
My idea of backup routine:
Server A gets all the containers in subset Y from server B, using the lxc copy command Server B gets all the containers in subset X from server A, using the lxc copy command
Server A then exports all containers to a backup drive (dir), including the ones from server B (which are now up-to-date) using lxc export, with –optimized-storage
I also export the needed init parameters using lxc init --dump > backup_file to make sure I can setup a fresh instance of lxd if needed.
The exports are then synched to an offsite location (this is out of scope for these questions).
Questions:
Do I need to create a snapshot if each container before doint lxc copy?
Do I need to stop the containers before doing lxc copy (and/or before creating snapshot above?)
Is anything missing for me to setup a new environment in case of SSD failure?
So, I have a follow-up question here. I have now copied all containers A->B and B->A according to the scheme in the initial post. And this might be more of a btrfs question, but I don’t get this:
root@hallonpaj:/mnt# btrfs filesystem du -s /mnt/btrfs-lxd/containers
Total Exclusive Set shared Filename
83.41GiB 83.41GiB 24.00KiB /mnt/btrfs-lxd/containers
vs
root@argon:~# btrfs filesystem du -s /mnt/btrfs-lxd/containers
Total Exclusive Set shared Filename
83.18GiB 45.28GiB 3.82GiB /mnt/btrfs-lxd/containers
The “exclusive” part differs quite a lot, and affects the space actually used on the disks.
Is this expected, and can anything be done to mitigate this difference?
It is expected, since you were copying data from one system to another. Do notice how on “argon” you have several gigs worth of shared data, but on “hallonpaj” you have mere 24KiB of shared data; on the system with several gigs worth of shared data, the data has been at least partially deduplicated, ie. some data-blocks are shared by multiple containers, for example.
Btrfs doesn’t do automatic online-deduplication, because that is a very heavy task, but if this really bothers you, you can use some 3rd-party tool to deduplicate your data – duperemove is pretty easy to use. See Deduplication - btrfs Wiki
With the above in mind, deduplication is only a temporary solution, because every time you copy containers around, you’ll end up with duplicated blocks. A more effective solution could be to e.g. use compression; just remember to use zstd1 (ie. in fstab the options would include compress=zstd:1) as the default is zlib, which is a lot slower, but achieves the same compression ratio. You can still dedup as well, if you feel like it, but I personally wouldn’t bother.