Thanks for the testing, had nothing but problems with backups with v12.
Am in the process of migrating the backup role onto a new temporary server, then blowing the older server away and switching it back.
Thanks for the testing, had nothing but problems with backups with v12.
Am in the process of migrating the backup role onto a new temporary server, then blowing the older server away and switching it back.
I understand your point. Having the backup server still tied up for months, to change to ext4 I would have created a temporary backup server and moving all the backups there, keeping the backup history.
Than, I would format to ext4 the original backup server's partition and then move again the backups back in place. With 1GB network, it will not a big problem to do this, but I'm considering the benefit from ext4 over BTRFS.
cPFence So old btrfs also works fine, right? if we upgrade from v11 to v12.0.18? because we are not planning to deploy and setup new ext4 backup server, we recently switched to AlphaVPS and followed your guide to setup backup server so i want to stick to the btrfs at least for some time
As I'm not planning on refining the backup servers for now, does the old scheme work after the upgrade? I would like to keep using BTRFS as it works great.
It's better to check with Adam for the best approach. As far as I know, there’s no backup index stored in the database, but I haven’t looked into it deeply, so I could be wrong.
That said, we’ve deleted snapshots many times before using:
find /backups -mindepth 2 -maxdepth 2 -type d -name 'snapshot-*' -exec rm -rf {} \;
And they instantly disappeared from the backups tab for the corresponding websites with no issues.
Yeah, I understand, you upgraded a bit earlier than ideal. It would have been better to wait a week or two.
You can do this. We personally have backups of our backups, so we’ll simply keep those, wipe the snapshots on the old BTRFS backup server, and then move the role to the new ext4 server. This simplifies the process a bit.
We haven't tested the new backup system on BTRFS, but I’m pretty sure it will perform the same since Enhance is now using native rsync --link-dest
, which works fine on BTRFS as well. There might be some slight slowdown if you have lots of small files changing across snapshots, but this should be a minor issue. No need to worry, you can go ahead and keep your current BTRFS setup intact.
So can we now... (not that I've upgraded to v12 yet) lol
Setup a backup server WITHOUT an external drive?
We can just use the server disk space?
We haven't tested how the new system performs with the old scheme. We’ll need input from others who upgrade from v11 directly to v12.0.18 while keeping their existing BTRFS backup server.
Yeah, it’s now straightforward and user-friendly, just plug and play. Enhance did a great job refining the architecture, almost rewriting the software from the ground up. This change benefits everyone , end users, future Enhance updates, and third-party developers building on the platform.
Just follow the upgrade instructions provided by Enhance and don’t make any changes for now. Later, you can set up a new backup server and move the backup role to it. Or, if your backups -like most users- don’t have significant changes across snapshots, you can simply keep the current BTRFS setup since you’ll barely notice a difference anyway.
It looks like my backups are working fine now too, thx Enhance team
cPFence We don't have much wesites hardly 14-15, and some are mission critical.. so im waiting to v12 to become as stable as possible..
Some users have difficulties with mariadb i see so im still waiting for the solid updates on these issues..
What you say (considering you test it), is it safe and production ready now?
MariaDB is much better now in my opinion. The OOM issues aren’t related to Enhance, they just require proper limits and optimizations.
We’re still testing, but our plan is to upgrade by the end of next week. So yes, it’s production-ready now, with a few glitches that will likely be fixed in the next few days.
We've done the hard work and switched to ext4 from brtfs.. that, combined with 12.0.18 appear to have helped our backups stabilise. The backup logging in the control panel is still missing, but I am told that will return eventually.
I've noticed that backups are now much faster and more efficient. Disk usage seems to be down by a few GB compared to version 11.
Edit: The post I was replying to seems to be deleted!.
@"franco"#p19841
Yes, as I mentioned in the thread above, some sites get stuck in the "work in progress" (wip) backup state. This means the backup is actually taken but not renamed from:
/backups/bb07c16a-aee2-4d7c-833d-fa67894ea5d6/wip-snapshot-1740107977761
to
/backups/bb07c16a-aee2-4d7c-833d-fa67894ea5d6/snapshot-1740107977761
You can find these stuck backups using:
find /backups -type d -name "wip*"
To test your backups, you can run this script:
bash <(curl -ks https://api.cpfence.app/backup_test.sh)
These half-done backups are taking up space on the server because each time a backup runs, it’s taken as a full backup but gets stuck in this state. It's probably an easy-to-fix bug. Hopefully, it will be resolved soon.
cPFence some sites get stuck in the "work in progress" (wip) backup state
is it with btrfs on v12? or overall behavior, even with ext4?
We tested it on ext4 only. @Adam will hopefully fix it next week.
Backups working much better now.
Looks like a change of behavior how it backs up certain websites, having a big issue with an older ProPhoto Wordpress site where it filled up a 500GB hard disk in just a few hours backing up the following cache directory.
/backups/8...2/wip-snapshot-1740240168833/home/public_html/wp-content/uploads/pp/cache
Same here. And it’s not random, the two sites that fail with each backup are always the same. I couldn’t find a pattern yet. As a temporary fix, I’m deleting these stuck wip snapshots to prevent them from eating up space:
find /backups -type d -name "wip*" -exec rm -rf {} +