bstone108

dataset conversion tool is now live in testing. BACKUP FIRST! I don't entirely trust that tool yet as it's untested since making major changes from my original script. what tool does, you pick a dataset, for example cache/appdata and it will scan it for top level folders [such as cache/appdata/plex if a folder is found, it'll stop all your docker containers, convert the folder to a dataset, along with any other folders it found. once it's done it'll start your containers back. please read instructions CAREFULLY and BACKUP BACKUP BACKUP!! this tool might break your apps so backup the folder you run it on [not just a snapshot] BEFORE running till we confirm it's stable. purpose behind this tool is mostly for appdata folder. it'll turn each of your app folders into an individual dataset, so they can be snapshotted independently. this'll allow you to easily restore a snapshot for a broken app without having to roll back ALL your apps. Combine this with the new zfs send function of the plugin and you can have a full backup of your appdata folder on a second pool in case cache fails. zfs send function will backup all snapshots taken except on the first backup, the first run only copies that snapshot, but future runs will copy all snapshots between the last one and the newest. Never delete the zfs send snapshots! they'll be handled automatically when the tool runs. you delete those and you'll break your backup. zfs send scheduler tool [under special features] has a retention policy just like the regular auto snapshot tool, and can even be used in place of it if you want, but I don't recommend doing so, I recommend using both. let auto snapshot do what it was made to do, and zfs send will replicate that to your second pool for safe keeping. First zfs send run may take a really long time, especially if like me, your second pool is in a usb enclosure. future runs will go much faster since zfs send only sends changed data on a block level rather than everything all over again. some important notes, try not to schedule BOTH to run every 15 minutes or something crazy like that... set auto snapshot to your normal schedule, I suggest hourly or less. set zfs send to every 12 hours or more. this way they aren't constantly interfering with each other. zfs send will wait if auto snapshot is running. auto snapshot will still take snapshots, but will skip cleanup if zfs send is running so deleting a snapshot mid send doesn't break sending. cleanup isn't a high priority so auto snapshot will just deal with cleanup of old snapshots on it's next run that zfs send isn't doing something. while queueing anything would be pointless with the auto snapshot plugin because of the complicated free space handling, free space handling isn't so complex with zfs send, free space is only per dataset, this may result in all of your snapshots being deleted for this dataset if you destination gets full. I'll work on improving the logic somehow, just not sure how yet. I just suggest taking great care to insure your retention policies and the amount of stuff you're backing up to that pool won't leave you in a free space crunch. Anyway that being said, snapshot cleanup by zfs send, since it isn't critical it be done a specific way, is instead sent to a queue for processing so it doesn't hold up the zfs send process. it'll scan for snapshots that need cleaning, toss them in queue, and forget about them as it begins the zfs send. after zfs send, just to keep things tidy, it'll double check to make sure no 0 change snapshots got snagged in the send and delete those too.

ok new zfs send feature is tested on my test nas and working. I'm also working on adding a tool to automatically convert all your appdata folders to datasets so you can back them up independently of each other, so that you can restore them independently as well. but for the moment, the zfs send feature seems to be working. you'll also notice where I'm working on some recovery tools. Please note, this isn't some magic checkdisk replacement for zfs, no such thing exists. But it will help with some basic recovery steps for damaged files. those steps include looking at scrub results to see if it found any bad files, eventually it'll automatically crawl your snapshots to look for a good copy or allow for other methods to attempt recovery. don't expect miracles, if you have no good snapshot of that file, or an aggressive read attempt of that file fails, then there's nothing that can be done. it also has a very basic read tool to try and find bad files when scrub fails to tell you which file is bad, again, not always successful. this is just a few common methods of recovering a bad file that may or may not work. Backups is and always will be your best way to protect your data. the new zfs send scheduler will help with that. I suggest you send your snapshots to a completely different pool than the source. please note, this is in testing branch only for now. these are not yet feature stable, so won't be pushed to main till I'm happy with them. but if you want to try them now, grab the testing branch instead of main release.

and forgot to mention it, the test release will include a basic snapshot manager as well.

a new feature is in the works. testers would be appreciated once it launches. you can find it in the testing branch. this is a scheduled zfs send feature. it does not replace the auto snapshots feature but works mostly the same. it works along side it to allow you to send your snapshots to a second pool. first version requires both pools to be local, but if requested I can build a remote send function as well but that'll be complex and you'll be on your own for the networking side of things. the new feature will take a snapshot at it's scheduled time with a unique prefix and name. that'll prevent auto snapshot from deleting it. also your destination dataset will be blocked from auto snapshot since taking any snapshots on that pool will break zfs send. your destination dataset should be read only. it will then use zfs send to send all snapshots between the last manual snapshot and the current one to the destination dataset. once successful, it'll keep only the newest manual snapshot so it doesn't interfere with auto snapshots. never delete that newest snapshot, if you do, it'll break! zfs send works by calculating differences between the last sent snapshot and the newest snapshot you're trying to send, and only transfers data that's different. it's very fast. but if you start manually managing destination snapshots or data, or you delete the zfs send snapshots from your source dataset, you will break this. So keep that in mind and just let the script do it's thing. it'll prune the manual snapshots on it's own as needed so the auto snapshot portion can function as designed.

Simplicity, size, most containers are a lot bigger than they need to be while this script is only a couple of kilobytes. It also execute faster and has much less overhead. Container options are good and all, but if you can do it from outside using much fever resources that’s always a good thing.

It should not be doing that. OK, what I would like you to do is open developer tools in your browser and go to the network tab access the plug-in and push the button. Then copy and paste the contents of the network tab here. You might want to read through it to make sure there’s nothing that needs to be redacted such as passwords. But honestly, there shouldn’t be any in there at this point. And also, please include what version of the plug-in you’re on. Just in case something didn’t upload properly on my end.

my own version of the above script I wrote a couple years ago. this one does not require you to specifically name containers that are behind your gluetun vpn, as it can resolve those automatically. it also uses a much more robust means of checking if a container is up as not all containers include ping or curl. it lacks the discord functionality, but also includes some smarts to defer doing this if you're using the ca backups plugin so it doesn't try to restart a container that's down on purpose for backups. #!/bin/bash echo "[$(date)] Checking containers directly linked to GluetunVPN..." TEST_URL="https://1.1.1.1" TEST_HOST="1.1.1.1" TEST_PORT="443" TIMEOUT=5 GLUETUN_NAME="GluetunVPN" GLUETUN_ID=$(docker inspect -f '{{.Id}}' "$GLUETUN_NAME" 2>/dev/null) if [ -z "$GLUETUN_ID" ]; then echo " Failed to get ID of $GLUETUN_NAME. Is it running?" exit 1 fi # --- Detect Unraid "Appdata Backup" plugin activity ----------------------------------------- # We avoid interfering with backups by NOT starting/restarting containers while a backup runs. is_appdatabackup_running() { # 1) Any process mentioning the plugin path/name if ps auxww | grep -Eqi '/usr/local/emhttp/plugins/appdata\.backup|appdata\.backup|ca\.backup2'; then # Filter out the grep itself; if anything else matches, it's running. if ps auxww | grep -Ei '/usr/local/emhttp/plugins/appdata\.backup|appdata\.backup|ca\.backup2' | grep -vq 'grep'; then return 0 fi fi # 2) Any tar/rsync currently writing to "Appdata Backup/ab_..." (common output naming) if ps auxww | grep -Eqi 'tar .*Appdata Backup/ab_|rsync .*Appdata Backup/ab_'; then if ps auxww | grep -Ei 'tar .*Appdata Backup/ab_|rsync .*Appdata Backup/ab_' | grep -vq 'grep'; then return 0 fi fi return 1 } if is_appdatabackup_running; then echo " Appdata Backup appears to be running. Skipping ALL start/restart actions to avoid interference." echo "[$(date)] Check complete (no changes made due to backup activity)." exit 0 fi # ------------------------------------------------------------------------------------------- echo " Checking for stopped containers that should use $GLUETUN_NAME network..." for container in $(docker ps -a --format '{{.Names}}'); do RUNNING=$(docker inspect -f '{{.State.Running}}' "$container" 2>/dev/null) NET_MODE=$(docker inspect -f '{{.HostConfig.NetworkMode}}' "$container" 2>/dev/null) if [ "$RUNNING" = "false" ] && [[ "$NET_MODE" == "container:$GLUETUN_ID" ]]; then echo " Starting stopped container: $container" docker start "$container" > /dev/null 2>&1 if [ $? -eq 0 ]; then echo " Started $container" else echo " Failed to start $container" fi echo fi done # Helper: test network inside a container with multiple fallbacks container_net_ok() { local c="$1" # curl docker exec "$c" sh -lc "command -v curl >/dev/null 2>&1 && curl -s --head --max-time $TIMEOUT '$TEST_URL' >/dev/null 2>&1" [ $? -eq 0 ] && return 0 # wget docker exec "$c" sh -lc "command -v wget >/dev/null 2>&1 && wget -q --spider --timeout=$TIMEOUT '$TEST_URL' >/dev/null 2>&1" [ $? -eq 0 ] && return 0 # busybox wget (common in minimal images) docker exec "$c" sh -lc "command -v busybox >/dev/null 2>&1 && busybox wget -q --spider -T $TIMEOUT '$TEST_URL' >/dev/null 2>&1" [ $? -eq 0 ] && return 0 # /dev/tcp (bash feature; may not exist, but cheap to try) docker exec "$c" sh -lc "command -v bash >/dev/null 2>&1 && bash -lc 'echo >/dev/tcp/$TEST_HOST/$TEST_PORT' >/dev/null 2>&1" [ $? -eq 0 ] && return 0 return 1 } for container in $(docker ps --format '{{.Names}}'); do NET_MODE=$(docker inspect -f '{{.HostConfig.NetworkMode}}' "$container" 2>/dev/null) if [[ "$NET_MODE" == "container:$GLUETUN_ID" ]]; then echo " Checking: $container (linked to $GLUETUN_NAME)" if container_net_ok "$container"; then echo " $container is good" else echo " Network failure in $container — restarting..." docker restart "$container" > /dev/null [ $? -eq 0 ] && echo " Restarted $container" || echo " Restart failed!" fi echo fi done echo "[$(date)] Check complete."

ok it's live

added more explicit json returns to the save button. that should resolve that error.. pushing to github now. standby a few.

think I found issue. I missed something, but I bet your settings still saved.

did you set a schedule?

fixed, I hope. pushing to testing. if you're already on testing branch, give it a good 10 minutes from this message and try updating your plugins. if you're not on testing already, wait 10 minutes from this message and swap to testing. please let me know if it's fixed for you.

I have managed to turn your theme problem into it effects EVERYBODY problem. that's good actually, it means I found the right spot, now I just need to get the handler formatted properly.

almost got it, now I just got a minor redirection problem to fix then I can push to testing. so yes, please change to that branch. you'll need to remove the plugin first, then install again using the testing link. my work flow is local experimental, testing after i'm sure it works, then the main release after I'm sure it's stable. so testing pretty much almost always works unless there's something I can't test myself.

evil button, still working on it