DANgerous25

Old thread, but seeing as I've just figured out how to do this for myself I'm posting in case it's useful for anyone else. Basically Nextcloud doesn't give you an easy to use backup solution, however I've read that the NextCloud-AIO instance does. I just have regular NextCloud. According to the documentation here, it says that you should copy the installation and the database, and later use these to restore. My use case is to copy and encrypt that data to cloud storage, in my case DropBox. The basic steps are: 1. Get rclone installed on your Unraid instance 2. Configure rclone for your chosen cloud provider (in my case, DropBox) and set up the remote rclone destination 3. [Optional] Use rclone to encrypt your remote cloud destination 4. Install the "User Scripts" plugin in Unraid in case you don't already have it 5. Use my script below with your appropriate modifications as a "User Script". 6. Run the copy script manually for the first time (it will take a long time depending on your NC install size, network etc.) 7. Once your initial copy is done, enable scheduler (I've set my to daily) using "User Scripts" in unraid. 8. That's it! Note that I haven't tried a restore, and I'm not too fussed about it because I know I can get my data in the worst case scenario. I'm not too bothered about the rest of my NC install. #!/bin/bash # Script to backup NextCloud installation to DropBox # v1.0 22nd June 2024 - Initial # Check if previous run worked, abort otherwise echo Checking for existing lock file ... if [ -f /tmp/nc_backup.lock ] ; then /usr/local/emhttp/webGui/scripts/notify -e "NextCloudBackup" -s "NC Daily Backup" -d "Finished" -i "ERROR" -m "The NexCloud backup script FAILED" echo ERROR: Lock file exists, likely that a previous run failed. Aborting! exit 1 fi # Create lock file while the script works echo Creating new lock file ... touch /tmp/nc_backup.lock # Perform the backup while in maintenance mode echo Putting NextCloud in maintenance mode ... docker exec nextcloud occ maintenance:mode --on # dump the database echo Dumping the database ... docker exec mariadb mysqldump --single-transaction -u mydatabasename -mypassword nextcloud > /tmp/nextcloud-sqlbkp_`date +"%Y%m%d"`.bak # copy the database echo Deleting any existing database files from the remote cloud storage ... rclone delete NextCloudBackupEncrypted:daily_db echo Copying the dumped database ... rclone copy /tmp/nextcloud-sqlbkp_`date +"%Y%m%d"`.bak NextCloudBackupEncrypted:daily_db/ echo Cleaning up dumped database ... rm /tmp/nextcloud-sqlbkp_`date +"%Y%m%d"`.bak # sync all other files echo Syncing NextCloud installation ... rclone sync --transfers 12 --tpslimit 12 /mnt/user/nextcloud/ NextCloudBackupEncrypted:daily/ echo Turning off maintenance mode ... docker exec nextcloud occ maintenance:mode --off # Remove the lock when all done echo Removing lock file for next run ... rm /tmp/nc_backup.lock # Finished /usr/local/emhttp/webGui/scripts/notify -e "NextCloudBackup" -s "NC Daily Backup" -d "Finished" -i "normal" -m "The NextCloud backup script SUCCEEDED" exit 0

Yes exactly. The only thing to change is the data directory of the second container when you set it up. When you restore your backup, restore it to that 2nd data directory. (Otherwise you will restore over your existing instance which may result in data loss if you saved anything in your vault since your backup).

My setup is only a single user, so I can’t answer conclusively. However, I don’t see why it shouldn’t work for all of your users, because all it is doing is essentially making a clone of your installation. Best bet is to test it for yourself (as in the worst case scenario it will be good for you to know it does work and how to do it!).

I know this is an old post but hopefully the question is still relevant to someone! Well, it was to me yesterday... I can confirm that this method works. I tested it by: Running the OP's script to backup my VaultWarden container to a cloud service, Then I created a second VaultWarden container (pointing it to a different data directory), Stopped the container, From the command line I copied back from the cloud service to overwrite the files in the new data directory, Then fired up the 2nd container And finally tested it by logging in and checking my settings and vault contents. Boom, I essentially have a duplicate working VaultWarden.

I can't explain why, but I'm not seeing this issue any more. I've done a few upgrades but can't say which if any have fixed. Currently on Unraid 6.12.4, pfSense 23.05.1-RELEASE, haproxy-devel 0.62_13 (on pfSense), Brave browser 1.58.131, MacOS Sonoma 14.0. Hope the rest of you can sort this out somehow!

I finally regained physical access to my device. Reboot fixed the issue. I've no idea how/why this happened.

Thanks for the response. Yes I have the root password, but I get connection refused by SSH before being asked for it. If I try to enter the root password via WebGUI then the authentication succceeds but then I am met with the "no space left" error. # ssh [email protected] -p 22 ssh: Connection to [email protected]:22 exited: Connect failed: Connection refused ^ not my real IP above. No matter which port I specify, or if I omit the -p parameter, I get the same error.

Hi all, I'm currently in a different country to my server hence physical access right now is impossible. When I attempt to log in to the WebGUI remotely I get the following errors. If I try to SSH on the default SSH port I get "connection refused". I can't remember if that's because I never enabled SSH access or if I changed the port (unlikely because I would have kept a secure note with the port number). I'm sure it's not a firewall issue as I can log into a machine on the same network and can ping my Unraid server successfully. Warning: session_write_close(): write failed: No space left on device (28) in /usr/local/emhttp/plugins/dynamix/include/.login.php on line 218 Warning: session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php) in /usr/local/emhttp/plugins/dynamix/include/.login.php on line 218 Warning: Cannot modify header information - headers already sent by (output started at /usr/local/emhttp/plugins/dynamix/include/.login.php:218) in /usr/local/emhttp/plugins/dynamix/include/.login.php on line 222 Questions: Assuming no physical access, and with no SSH is there any way I can reboot the box? (not sure if that will even help...) Logging into "MyServers" if I try to access the WebGUI that way, it attempts to use a local server address which doesn't DNS resolve as I am not on my home network. I don't have VPN. Is there any way I can change the IP it tries to use, I can't see any account settings that might help. For example the URL it attempts to use is myservername.local instead of an IP address (Again not sure if that will even help). If there is nothing I can do without physical access, any idea what I can do when I return home and regain access? Will a reboot fix? If not, how can I access - right now the box doesn't have a keyboard and screen attached but that can be arranged if necessary. And the million dollar question, why is this happening in the first place? I assume it means there is no space on my Unraid USB key, as my array has TBs of free space. Once I'm in somehow, I'll need to get to the bottom of it to fix. Thanks in advance for any help.

FWIW, I also use HAproxy on PFSense to get to my Unraid GUI using myhost.mydomain.com. I get the same problem. If I connect directly using the server's IP, then no issue at all. Very strange (and frustrating).

Thanks for the great plugin. I believe I may have found a bug that is not too serious, or maybe I did something wrong. I am using version 2020.02.20 of the plugin on Unraid 6.9.22 beta. I created a second config (in addition to "default") which I used for a few days. I then decided to delete the config, which I did using the "Manage Configs" tab, "Remove configs" button. The config was then removed from the GUI pages. However I kept getting Unraid notifications that the vmbackup plugin failed for the config that I removed. I checked my crontab and saw that the entry for my deleted config is still in there. No harm done because it just fails to run the cron entry as the config no longer exists. For now I've commented out the entry. Hence unless I did something wrong, I believe that this version might not remove the cron entry when deleting configs. Let me know if you need any more info on this.

I solved this myself by adding a "Peer DNS server" [like google DNS] in the advanced config. For some reason local DNS forwarding just doesn't work with my setup.

Thanks for the excellent guide. Indeed I was up and running within minutes. Sorry if this is really a stupid question, but I am pretty clueless! I've set up Wireguard exactly as per the guide as type "Remote tunneled access". It's working, and I can connect in remotely and access hosts on my LAN. However my internet access doesn't work from my client devices while I'm connected to the VPN. Is there a setting somewhere I've missed or something I need to do? My Unraid server has internet access locally at least, so not sure why it doesn't work when I'm connected via VPN. I have a hunch that this might be something to do with "local tunnel network pool" and adding a static route somewhere, as in the advanced settings it says "Remark: docker containers on custom networks need static routing 10.253.0.0/24 to 10.10.10.5" which are my tunnel pool and server IP respectively. But I don't know how or where to do this. Thanks a lot for your help.

Hi all, first post but felt compelled given the amount of great community info out there that has helped me. I spent many, many hours trying to solve this issue and finally did. My setup: Ryzen 3950X, RTX 2080 Super. Tried and didn't work: * Clean install using UEFI boot, vanilla setup without editing XML or adding any parameters * With UEFI boot, adding "vfio-pci.ids=10de:1e81,10de:10f8,10de:1ad8,10de:1ad9" to the syslinux configuration (Main -> Syslinux, device IDs are the x4 nvidia device IDs derived from Tools -> System Devices), editing the xml to add multifunction='on' and aligning the bus/slot/function parameters for all four devices, re-install nvidia drivers in Win10 Eventually I got it to work by: * Doing all of the above, but changing to legacy bios boot, then in Windows remove the nvidia display adapter from device manager (having previously updated the driver from the web), then re-scan hardware -> hey presto, no error 43. Conclusion: Don't give up in Windows just because you get error 43, there is almost certainly mileage in updating the nvidia driver from the web and then removing/re-adding in device manager. However, this only worked for me once I'd configured all the passthrough in xml and set boot mode to legacy. It would not work without all of those actions completed. I hope this helps someone, and I'd like to thank all of the posters above and Space Invader 1 for his great videos that helped me to have some basic understanding of what needed to be done here.