Force a Backup Still failing

Support
1

This is a continuation of previous post that was never resolved

Roon is on a 10i7 NUC / ROCK 32 Gb RAM 4tB internal SSD , Control is from a Windows 10 PC or a 12.9 iPad Pro

I have “EVERY DAY AT 14:00 KEEP 20 BU” set and that works . The folder specified is on the Windows PC via a share.

The auto - scheduled back up works fine BUT when I try to Force a Backup the PC loses connection with the NUC and the process fails

I set up an empty folder on a local USB drive in the NUC and tried again it gets this far

image
image922×163 7.62 KB

2

Hi @Mike_O_Neill,

Thank you for the post. We’ll keep notes here, but pick up the trail from this thread: Has something gone wrong with Backup? and your more recent reports elsewhere on Community.

We have an open investigation into this issue, please stand by and we’ll respond with our current status as soon as we can sync internally.

3

Thanks , it came to light as I had a suspect db corruption and needed a BU to restore, it was a mess of note but I finally managed to restore successfully but it reminded me when i tried a manual BU it failed as described in the original thread.

Schedule BU is still working fine , but not where a PC remote app is open ….

5

Hi @Mike_O_Neill,

Development has requested you take the following steps at your convenience to help us pin this down:

  1. Open Roon on the PC and Force a Backup to reproduce the failure
  2. Then, on the same PC, use the directions found here to find the folder named “Roon” → “Logs,” compress it (.zip), and upload to our File Uploader

We suspect this issue has a GUI-related component, so we need to capture logs from the Roon client rather than the server.

Thank you!

6

Guess what ? On the face of it I have changed nothing to the basic setup, no restarts etc . Just 2 new albums added.

I just went to the Settings> Backups>Schedule BU and used Force a BU and it worked !!

BUT I had changed the destination folder to a local (to the NUC) USB Drive maybe that’s it.

I have now reverted to the previous config which is a target folder on the Main PC set as a Share MainPC/00 - Backups/Roon. This too is working albeit much slower.

Is it a better practice to use a local USB or a network share ? I have always assumed no difference.

I’ll send the logs anyway if that helps ?

The only other change I made while investigating was to remove 1 album (MP3 as it happens) and 2 x JPG from the library as they were indicated as “Skipped Files”

( For info : I keep all my BackUps in one place - 00 - Backups so that I can easily copy that folder to BU the BU’s)

7

We’re glad your backups are working again. It is strange that this is what solved it. We’ll keep this thread open a bit longer just in case the problem returns.

You’re correct. We have users who use either successfully.

8

As a technical person too , I need to understand what I did to fix it , in my opinion NOTHING !!

9

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

10

Maybe need to re-open that thread , just tried a manual forced back up and

image

Just like before …
Manual backup of any type starts the Snapshot then throws this error . It is exactly the same as before. For Some strange reason it stopped happening for a day or so ???

Need to restart server via wed admin to proceed, the server seems to crash.

NUC 10i7 , Ethernet connected , Remote is either Windows 10 (Ethernet) or iOS (wI fI) botH react the same

Logs show …

09/29 11:04:30 Warn: AddTopLevel: win_backup_in_progress(100)
09/29 11:04:33 Warn: [remoting/remotingprotocolv2] timed out
09/29 11:04:33 Trace: [remoting/remotebrokerv2] [Roon Optimized Core Kit] Connection dropped: Id: 672faa1a-579a-49a6-b23b-879760c37d80 Name: Roon Optimized Core Kit: 192.168.1.169 tcp=9331 tcpv2=9332, http=9330, inet=False, timestamp=2024/09/29 09:01:44
09/29 11:04:33 Trace: [remoting/remotebrokerv2] [Roon Optimized Core Kit] disconnect(hard=False)
09/29 11:04:33 Trace: [remoting/remotebrokerv2] [Roon Optimized Core Kit] Connected => Connecting
09/29 11:04:34 Trace: [remoting/distributedbroker] 1 connected brokers -> 0 connected brokers, refreshing
09/29 11:04:34 Debug: [easyhttp] [21] POST to https://api.roonlabs.net/discovery/1/query returned after 262 ms, status code: 200, request body size: 74 B
09/29 11:04:35 Debug: [easyhttp] [20] POST to https://api.roonlabs.net/discovery/1/query returned after 758 ms, status code: 200, request body size: 140 B
09/29 11:04:36 Warn: AddTopLevel: resuming_connection(237)
09/29 11:04:44 Debug: [easyhttp] [22] POST to https://api.roonlabs.net/device-map/1/register returned after 276 ms, status code: 200, request body size: 1 KB
09/29 11:04:44 Trace: [devicemap] device map updated
09/29 11:04:44 Info: [stats] 2102730mb Virtual, 561mb Physical, 72mb Managed, 1101 Handles, 52 Threads
09/29 11:04:49 Debug: [windowpos] saving pos=M1007|39|974|1047 because closing window
12

Done and topics merged.

13

Hi @Mike_O_Neill,

Please open Roon on both the Windows and iOS remotes at your convenience so requested logsets can upload to our servers. Thanks!

14

Server rebooted , Remote open on Windows 10 and on iOS

I am not sure how long iOS will stay open , as it keeps getting put to sleep. That said almost all failure occur on the Windows 10 PC.

just a thought the C drive is quite low in free space , around 22 gb wil that have any impact . I am guessing no since the BU is processed on the Server.

15

Hey @Mike_O_Neill,

Thanks for sharing your report! After chatting with our development team, we’re curious - what happens if you try it out again, but this time let the backup process longer (even if it appears that Roon Server disconnects), and let me know if it eventually succeeds. :+1:

16

Yes , the connection fails and then comes back, presumably a start instruction goes to ROCK and then everything happens on the NUC , the Windows Remote app isn’t reporting progress.

A manual Force BU worked fine back to the Windows PC as destination.

17

Hey @Mike_O_Neill,

Got it, thanks for confirming the backup succeeds after a brief interruption. We’ll bring this information back to our development team for further investigation. I hope to have more information to share soon!