KluthR

Ich würde von Unraid grundsätzlich schonmal garnix direkt nach außen freigeben. Alle Prozesse in Unraid laufen als root (was ich nie verstanden habe). ich würde da mindestens ein Reverse Proxy (meinetwegen als docker container auf dem Unraid, npm) mit eigenem Login vorschalten. Persönlich ist bei mir ein wireguard nötig um an Unraid zu kommen.

No bug known. I have to check the debug log tomorrow.

You are right and you cannot exclude them for now.

Seems like an GitHub error. The plugin infos comes directly from GitHub repository.

No. The process just wasnt able to do a simple copy to the destination. A syslog from that time would be maybe more interesting.

If combined with reboot: nothing

Yes. Named volumes are not supported at this time.

Yes. Try the workaround script a few posts above Same. Try the script, save and try again

I work on a solution which splits the data into chunks. I could also patch the PHP settings on-the-fly but that seems a bit hacky to me. Could take a few more days If you want a workaround for now: Open a shell and run this command: curl -s https://raw.githubusercontent.com/Commifreak/unraid-appdata.backup/refs/heads/master/scripts/hotfix_php_max_input_vars.sh | bash This changes the php config. Run it again to undo the fix. Or reboot (fix is not permanent!)

Turns out its a default PHP-Limit of the setting max_input_vars. This is defaulted to 1000. and exactly after 1000 lines, the request gets cut off.

Structure needs cleaning. Filesystem check? No idea.

I would start htop, hit F6, to select by RAM, start backup and watch the ram being filled. The process with the most used ram is on top

Your previous screenshot shows the issue during backup: the oom-killer was kicking in. The ram was full resulting in killing docker (and system?) processes. Thats another issue you have to look at. Something is eating the ram during docker container starts?

Yea. Okay. We seem to hit a limit here. Let me think about possible solutions

I bet there is some config error. Please post your settings

Ive just released an update which includes a simple settings form debug mode. Open the AppdataBackup settings page Edit the URL by adding "?debugForm" to it. Hit enter Save the settings. A new window will appear with the form data generated BEFORE sending it to the server The page behind will post the received settings. Either compare it yourself or send me both for evaluation. I made a test with HUGE settings pages. But that worked for me. Also, if the data, sent to the server, is too big, the page stays blank. Maybe we can get some info with the debugForm mode.

The backup simply calls unraids method for creating flash backup. That weird.

That abnornal. Please try to create a backup via unraid

Which exact plugin name and version do you use? please make a screenshot from the config page.

The best I can do here: start with the basic things: share a whole log (or share via share debug log feature).

No. These issues does not belong to each other. how long does it take to make the server crash? Could you observe logs during backup until it happens?

this needs some more time on my side. It seems that information getting cut off during form submission. I made some tests with many dummy containers a few weeks ago but couldnt find any issue. Have to try again.

Not in the json. This can be huge without issues. maybe a limit for the web form? How many containers do you have?

Hm. Maybe. Double check your flash drive. Did you another normal reboot, just for fun? what are the file permissions on /boot/config/plugins/appdata.backup/config.json? sounds like it cant write the file. But it can read it. Open the global log terminal and see if anything gets logged when trying to save.

there are some crypt-command examples for encrypt tar.gz archives. I never did it on my end