flashback

I might have to just try and grab the data not copied (it's only 50-100gb that hadn't backed up by the time it started failing) by booting it back up, as I don't have another PC to fire up - only laptops.

TerraMaster support isn't responding and as Amazon just fulfills for them, they can't provide a straight replacement and will only refund. The price has gone up by £183, which is rather annoying. I think I may need to look at alternative replacements. In the meantime, what's the best way for me to recover the data from the drives that Unraid was managing? Put them into a USB caddy, and then is there a way to read in Windows or will I need to boot up into a Linux live environment or similar due to XFS?

Thanks all - it's shutdown, so I'll deal with the joy that is Amazon for a replacement of the unit.

I had a recent kernel hang and as I'm not able to physically able to get to the device for a few days, stumbled across this as a way of initial investigation. Great tool, thanks! [16.11.2025 04:34:40 GMT] /usr/bin/memtester 28G 2 ============================================================================================= The detailed error output is enabled, watch this panel for any occurring errors. FAILURE: possible bad address line at offset 0x000000036eef1328. FAILURE: 0xffffffffff7fffff != 0xfffffbffff7fffff at offset 0x00000000fb7b35d8. What is interesting is the timing of this, I installed this new NAS a month ago in my comms room downstairs and it's been running fine. On Wednesday I moved it up to my loft as my sparky came and extended my network up there - it's cooler up there (although at idle the system runs at 18-25 degrees C and the drives around the same), but also the power socket has a max limit of 5A. Hanging off the power socket are the UPS (Eaton 3S850B 3S Gen2 Desktop UPS Uninterruptible Power Supply (510W/850VA)) which connects my 2.5GbE switch and then this NAS. Is this just a red herring and just coincidental timing? In the meantime, should I just power off the NAS till I get back and raise a warranty replacement request in the meantime? Then there's the question around the timing of the relocation, is it possible the lower temps and/or the power running to it are what's maybe caused the issue. If so, a warranty replacement may not help and the same issue might reoccur if it's either temp or power that is/has caused the issue.

I thought I might do what I could as much as possible before I get back, and triggered an online memtest of 29G out of the 32G RAM, results as follows: [16.11.2025 04:34:40 GMT] /usr/bin/memtester 28G 2 ============================================================================================= memtester version 4.6.0 (64-bit) adapted for use on Unraid installations Copyright (C) 2001-2020 Charles Cazabon Copyright (C) 2024 desertwitch (modifications for Unraid) THIS PROGRAM IS PROVIDED AS IS AND WITHOUT ANY WARRANTIES It is licensed under GNU General Public License Version 2 pagesize is 4096 pagesizemask is 0xfffffffffffff000 want 28672MB (30064771072 bytes) got 28672MB (30064771072 bytes), trying mlock ...locked. Loop 1/2: Stuck Address : Testing... ok Random Value : Testing... ok Compare XOR : Testing... ok Compare SUB : Testing... ok Compare MUL : Testing... ok Compare DIV : Testing... ok Compare OR : Testing... ok Compare AND : Testing... ok Sequential Increment : Testing... ok Solid Bits : Testing... ok Block Sequential : Testing... ok Checkerboard : Testing... ok Bit Spread : Testing... ok Bit Flip : Testing... ok Walking Ones : Testing... ok Walking Zeroes : Testing... ok 8-bit Writes : Testing... ok 16-bit Writes : Testing... ok Loop 2/2: Stuck Address : Testing... failed Random Value : Testing... ok Compare XOR : Testing... ok Compare SUB : Testing... ok Compare MUL : Testing... ok Compare DIV : Testing... ok Compare OR : Testing... ok Compare AND : Testing... ok Sequential Increment : Testing... ok Solid Bits : Testing... ok Block Sequential : Testing... ok Checkerboard : Testing... ok Bit Spread : Testing... ok Bit Flip : Testing... failed Walking Ones : Testing... ok Walking Zeroes : Testing... ok 8-bit Writes : Testing... ok 16-bit Writes : Testing... ok Done. ============================================================================================= [16.11.2025 07:16:21 GMT] The operation has finished with errors. [16.11.2025 07:16:21 GMT] Code: 6 - Error during Stuck Address Test + Other Test(s). And: [16.11.2025 04:34:40 GMT] /usr/bin/memtester 28G 2 ============================================================================================= The detailed error output is enabled, watch this panel for any occurring errors. FAILURE: possible bad address line at offset 0x000000036eef1328. FAILURE: 0xffffffffff7fffff != 0xfffffbffff7fffff at offset 0x00000000fb7b35d8. What is interesting is the timing of this, I installed this a month ago in my comms room downstairs and it's been running fine. On Wednesday I moved it up to my loft as my sparky came and extended my network up there - it's cooler up there (although at idle the system runs at 18-25 degrees C and the drives around the same), but also the power socket has a max limit of 5A. Hanging off the power socket are the UPS (Eaton 3S850B 3S Gen2 Desktop UPS Uninterruptible Power Supply (510W/850VA)) which connects my 2.5GbE switch and then this NAS. Red herring and just coincidental timing? In the meantime, should I just power off the NAS till I get back do you think and raise a warranty replacement request in the meantime? Then there's the question around the timing of the relocation, is it possible the lower temps and/or the power running to it are what's maybe caused the issue.

I can only do that from the boot menu, can't I? If so, it'll need to wait till I'm back in town so I can physically access the machine...

I can change settings via the GUI now, so that's working after the reboot. I ran the syslog though ChatGPT as well as having a skim myself, which came out with the following: Category Severity Notes ACPI BIOS Errors Medium Fix with BIOS update if available Memory Controller (EDAC) Error Medium–High Run memory test; monitor ECC events NVMe Missing SUBNQN Low Common, usually harmless PCI Resource Mapping Warning Low–Medium Likely harmless; BIOS update may help If I start my array now (as I have it set to manual after reboot), I should uncheck write corrections to parity, as a safety measure, right? Or should I not try and start the array yet?

Rebooted, syslog and diagnostics attached. fwlonnas01-diagnostics-20251115-0759.zipsyslog20251115.zip

I ran powerdown, which it noted is deprecated but it started the process (like I had also tried from the GUI). That seems to do the same, whereby it says it is rebooting........ but doesn't actually reboot. Looks like I'll need to physically reboot via the power button. Note: I checked /mnt/disk1 and /mnt/disk2 and both seemed to display the data OK using ls -lah. :/mnt# powerdown -r powerdown: /usr/local/sbin/powerdown has been deprecated Broadcast message from root@NAS01 (pts/0) (Sat Nov 15 07:50:38 2025): The system is going down for reboot NOW!

If my array is stuck in the stopping state (been 12 hours now since I tried to stop it), am I at risk of data loss if I force a reboot? :~# grep -E '^(mdState|fsState)=' /var/local/emhttp/var.ini mdState="STARTED" fsState="Stopping"

OK, should I just run "/sbin/reboot" from the command line or "powerdown -r"? Searching the forum gave multiple viewpoints. Note that the array is still 'stuck': NAS01:~# grep -E '^(mdState|fsState)=' /var/local/emhttp/var.ini mdState="STARTED" fsState="Stopping"

Thanks, I suspected as much as I saw some kernel messages in there. I'm trying to do a pre-reboot dump of diagnostics, it's been running a few minutes now - I assume it shouldn't take that long and therefore may not be able to be grabbed pre-reboot then? I've attached the ZIP it's generated so far, there also seems to be one generated earlier today which I've also attached. For the force reboot, do I need to just shutdown -r via terminal, or physical reset it using the NAS power button? fwlonnas01-diagnostics-20251020-1252.zip fwlonnas01-diagnostics-20251020-2004.zip

Attached. NAS01syslog.zip

That's done, where's the best place to upload? It's 1.3mb so PasteBin fails (512kb limit).

I'm able to SSH on to the server and the web UI works, but everything else seems to time out. I can't access files etc. across the network, and if I try and trigger any commands via the GUI they just time out as well. Reboot, same. Stop array, same. I couldn't see anything obvious in /var/log/syslog that indicated any issues. Running top doesn't show anything with high mem or CPU usage, but some of the cores keep spiking/staying at 100% utilisation. Are there any logs I can provide to work out what might be going on here? Is there a way I can force the array offline in a 'safe' manner and then trigger a reboot perhaps? Any other thoughts as to how I should approach this? root@NAS01:~# tail /var/log/syslog Nov 14 16:06:46 NAS01 emhttpd: Sync filesystems... Nov 14 16:06:46 NAS01 emhttpd: shcmd (214519): sync Nov 14 16:06:47 NAS01 sshd-session[2206811]: Postponed keyboard-interactive/pam for root from 192.168.0.132 port 58796 ssh2 [preauth] Nov 14 16:06:47 NAS01 sshd-session[2206811]: Accepted keyboard-interactive/pam for root from 192.168.0.132 port 58796 ssh2 Nov 14 16:06:47 NAS01 sshd-session[2206811]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Nov 14 16:06:47 NAS01 elogind-daemon[1785]: New session 2 of user root. Nov 14 16:06:47 NAS01 sshd-session[2206811]: User child is on pid 2207105 Nov 14 16:06:47 NAS01 sshd-session[2207105]: Starting session: shell on pts/0 for root from 192.168.0.132 port 58796 id 0 Nov 14 16:09:28 NAS01 nginx: 2025/11/14 16:09:28 [error] 6488#6488: *17943 upstream timed out (110: Connection timed out) while reading upstream, client: 192.168.0.132, server: , request: "POST /update.htm HTTP/2.0", upstream: "http://unix:/var/run/emhttpd.socket:/update.htm", host: "nas01.local", referrer: "https://nas01.local/Main" Nov 14 16:14:28 NAS01 nginx: 2025/11/14 16:14:28 [error] 6488#6488: *17943 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.0.132, server: , request: "POST /update.htm HTTP/2.0", upstream: "http://unix:/var/run/emhttpd.socket/update.htm", host: "nas01.local", referrer: "https://nas01.local/Settings/DiskSettings"

Absolutely! I'd already using the Unassigned Devices plugin, which works well for mounting the shares from the Synology NAS in r/o mode. It sounds like that's the next thing to do on my list, investigate how to spin up a Docker container for one that does not show up in CA e.g., https://bahmni.atlassian.net/wiki/spaces/BAH/pages/3117744129/Getting+Started+Quickly+with+Bahmni+on+Docker

Ok, I ended up using rsync -avhP and that reseeded things with the correct date/timestamp, although it seemed to actually copy the data again when it did it rather than just update the timestamp on the file. I think if I add --delete-delay that will then remove files on the backup destination (Synology) from the source (Unraid) anything that has been deleted on the Unraid data share. I should probably mention as well, I've been running mine using screen - which I added via a non-CA route. Any debate on why you prefer tmux over screen for doing simple 1 line commands like this?

Yes, when I did the initial sync from my older Synology to my new Unraid box, I used rsync. 2.5GbE on either side meant it handled the 10TB of data in reasonably good fashion. I thought I had made it clear in my original post, but I'm not coming at this completely fresh and have tried a lot of things in the background. Given rclone doesn't function as nicely, I think I'm still going to backup OneDrive and Dropbox using Cloud Sync on the Synology. Again, given the lack of simple reporting and scheduling on the Unraid side, it seems I'm better to also use Active Backup for Business on the Synology side and pull the data down that way to backup. The new Unraid box is primary and it will be backing up to the older Synology NAS it replaced.

Thanks for your comments, my 2nd post clarified that I have resolved the issue/query I had with the 'rclone' official Docker container that's available via CA. Having had a look at it, it feels like using Cloud Sync on my Synology target is going to be nicer to use. Did you have any thoughts on why my rsync command isn't keeping the original timestamp on the files/folders? When I did the initial sync from my Synology to Unraid, I used the following command, but note that the date/time stamp on the files was set as the time of the sync, rather than retaining their original date/time stamp. rsync -r --info=progress2 --info=name0 --delete-delay --size-only "/mnt/remotes/SOURCE" "/mnt/user/data/DESTINATION" Would using -a (archive) or -X (preserve extended attributes) fix that?

Bump

I'm clear on this item now, as it says Container Path: /config/rclone so in that case I'd just create /mnt/user/rclone/config and set that, ditto for Container Path: /data I'd set that to /mnt/user/rclone/data. Does anyone have thoughts on the strategies above taking into account the pros/cons of each?

Thanks - I was looking at doing the same. I guess the benefit of ABB vs Hyper Backup is being able to add Unraid as a file server, rather than for the HB option having to mount the NFS/SMB shares into a folder/share on the Syno side first? When adding it as a file server, why did you choose SMB server over rsync server?

Just to clarify, Hyper Backup is slightly different to ABB!

OK, it looks like it has created it - it's just a 3 minute or so lag to do so. Alright........ now that is sorted, do I have to manually delete the 3 backups I had run to the Unraid device, now that I've set the target to a new place? Or is it smart enough to do its version control and auto clean them up (I have it set to 14 and 7).

I initially had the backup set to dump in a local folder on my Unraid server, but have now updated it to dump straight to a remote target (mounted using Unassigned Devices). What I can't work out, is why when the backup runs locally it creates backup.log and config.json: root@NAS01:/mnt/user/data/Backup/ab_20251109_040001# ls -lah total 879M drwxr-x--- 1 nobody users 138 Nov 9 04:03 ./ drwxrwxrwx 1 username users 128 Nov 9 04:00 ../ -rw-r----- 1 nobody users 743 Nov 9 04:03 backup.log -rw-r----- 1 nobody users 1006 Nov 9 04:03 config.json -rw-r----- 1 nobody users 879M Nov 9 04:00 nas01-v7.2.0-flash-backup-20251109-0400.zip But when I have the target set as the remote device, it only puts the data and not the backup.log and config.json file? root@NAS01:/mnt/remotes/NAS02.LAN_Backup/ab_20251109_065248# ls -lah total 879M drwxrwxrwx 2 nobody users 0 Nov 9 06:53 ./ drwxrwxrwx 2 nobody users 0 Nov 9 06:52 ../ -rwxrwxrwx 1 nobody users 879M Nov 9 06:53 nas01-v7.2.0-flash-backup-20251109-0652.zip*