EldonMcGuinness

I have this very issue. From time to time I have a router that is reset and when that happens I have to get to the unraid server in person and alt-ctrl-del to initiate a reboot. The router is setup to give the server a static IP and the server is setup to use a static ip as well, not sure what the issue is. Another issue is you can't login via cli as when you type in root you are not prompted for a password and the attempt times out after 60 seconds.

That all just depends on how your service can access the data. It is just an SQLite database file that resides on your thumb drive. If your service in question can read from the file, you're welcome to pull data right from there. As for a graph, I highly doubt I'll be adding anything of that nature as it just seems overkill. The point of this was just to get a running idea of how often your drives are awake or asleep. I'm not adverse to somebody proposing a pull request to add this feature though. 😉

Ahh true, still a valid solution for bitrot or other possible corruption issues of that nature that are more of a passive issue.

Well parity should be able to, and at least did for me, just fine. Consider this situation: You have 6 disks Disk 1 through 6 being found at /mnt/disk1 through /mnt/disk6. Parity checks are not set to correct the parity drive, meaning if a discrepancy is found one could still read the previous parity (checked?) version. This means is say /mnt/disk2/somefile.txt were to suffer from bitrot, overwriting, or really anything else (EDIT: Forgot parity is actively written, thanks @primeval_god) one can pull disk2 from the array and then access the parity (checked? is this the right term) version. Seems like a logical conclusion to me. Kinda like having a non-versioned backup. Assuming you have not overwritten the backup with bad data you could restore from it.

It occurred to me yesterday, while trying to restore a file that had somehow been corrupted, that it would be nice to be able to read from an emulated drive and try to recover the file without having to remove the drive from the array temporarily. In my case, I was able to get the file from the emulated drive, after removing the drive that contained the corrupted file, and it was indeed a proper file. Seems like this could be a quick first step for restoring a corrupted file locally before having to resort to pulling a remote backup. If mounting is not feasible, due to file system locks or something similar, perhaps a command could be included in unraid to be able to rebuild a particular file on a specific disk from the parity and the other disks. Something like below would be great. parity-restore /mnt/disk2/somefile.txt /mnt/user/somefile.txt.restored In practice this command would rebuid /mnt/disk2/somefile.txt from the parity disk as well as the other disks, save disk2 of course, and save it to /mnt/user/somefile.txt.restored. Any chance for this, unless there is already a way to do it.

Thanks for the heads up, I will put in the next update. I hope to have it out by this weekend.

Will do!

Is it happening after every reboot or only some reboots?

At the moment it does not, but the backend does, so it should just be a matter of building in the UI to capture the needed fields. If you're up for testing, file a bug on the github repo asking for it to be supported so I do not forget. New Backend Request

I wanted a better way to backup some of my local files to a cloud provider and did not want to have to rely on a container or VM to do so. To this end I have written a backup plugin that allows me to do so. At the moment it is just oAuth2 based, however, it uses rclone for a backend so I could add other destination types. The project is on GitHub in case you want to review the codebase. The plugin allows you to do 3 types of jobs: Backup - This copies files from the unraid server to the remote storage Archive - This moves files from the unraid server to the remote storage Sync - This is a bi-directional sync so changes on either side are replicated both ways In addition to this, it uses cron scheduling to automate calling of the backup commands. [ https://github.com/EldonMcGuinness/UnraidCloudBackup ] At this time the plugin is a beta, and I am looking for testers. As it currently sits, it allows you to hook connect to Dropbox, GoogleDrive, and Box. If you have another use case, and are willing to help test, let me know and I'll see what I can do on getting it in there. Below are images of the current interface. Do be aware, as oAuth2 does require a FQDN to connect and properly process callbacks, I did need to write a server-side client script, which I am hosting as a github page, to handle the handshake and requesting of tokens to give back to rclone. This too is on github for your review, since I know this might be a point of contention. If you are interested in testing, please let me know how it goes or if you need help installing the plugin. A link the the plg file is below: [ https://raw.githubusercontent.com/EldonMcGuinness/UnraidCloudBackup/master/CloudBackup.plg ] You will need to setup your own client id and secret, which is free, until I find out what all I need to do to open my generated client/secret it up for general use with the different providers. The callback URL you will want to use for your application/client is [ https://eldonmcguinness.github.io/UnraidCloudBackup/callback ], again, this does not log anything at all and the code base is on github as well. Plugin @ Github Auth Server @ Github

@kiwijunglist I would love to add this to the plug-in as well as a few other things, perhaps I will have some more time soon. At the risk of sounding like a mad capitalist, donations towards getting features added are always nice and will definitely help to move things along. If you're interested, you can do so on the github repo. @kiwijunglistI have moved away from manual polling and instead use the built-in polling that is part of unraid, this should not be an issue any longer. @fr500 I'm not sure on this one, I'm running the latest version and am not seeing this, additionally, I have other testers that have confirmed it is not happening to them either. Perhaps this is unique to your setup?

What version of Unraid are you running?

I'm not seeing that behavior, do be aware that this does use cookies to store the information. Perhaps you have cookies disabled? Try it in "in-private or incognito" mode with your browser and let me know what happens.

That is so odd, you are the second person that said that. I wonder if it is due to my script clashing/relying on anther script inadvertently. I will take a look. 👍 EDIT: This is indeed what was happening, this is fixed in the next build [2023.11.26-004] Also added dev support as of [2023.11.27-002]

I don't think so as this is a longitudinal average of queries. If I don't have the intervals logged then, when they are all counted up and divided, the averages would not be the same. The way I calculate it is a simple average: Without each interval I would not be able to take a quick sum and it likely would get more complicated for minimal gain. There is currently a show toggle that lets you hide it and it is cookie based so it should stick across sessions. I will have to look into this once I have an unassigned drive to test, unless someone would like to be my guineapig. In the case that you or someone else would, let me know and I'll setup a dev branch for you to test.