Uniti Core backup

Streaming Audio
1

My Core starts a daily backup process automatically at 03:00 in the night (to a NAS). I check regularly my NAS whether new music has been backed up, which is always the case. However, recently I corrected metadata of a digitized CD stored in /Downloads. The filenames did not change, only the album title in these file’s metadata, and thus the time stamp of the files.

To my surprise the Core apparently only checks whether filenames exist in the backup, and not their time stamps, as my updated files are not ending up in the backup. This is a serious flaw/shortcoming in my opinion. Has anyone observed this phenomenon as well?

If I copy the updated files by hand to my NAS, does the backup then remain intact? (probably if the restore routine only reads/copies files, but I do not know how Naim designed this functionality; if a database is involved I may destroy my backup, right?).

My firmware version is up to date, i.e. 2.5.5 (4007).

1 Like
2

I would have thought backup, specifically incremental backup, should identify any file changes, preferably by checksum comparison, and copy any identified files to the backup device/destination.

If it’s not doing this it’s not really backup is it?

One for Naim tech to respond to……

ATB, J

3

That is a bit of a concern if that’s the case. I’ve never noticed, but then hadn’t checked either…(plus my first couple of months with the Core were occupied and plagued by a Restart issue, now finally resolved with an upcoming firmware release). I’ll have to have a play and test if the same happens…

I guess, as it’s the Downloads folder, the Core may not be scrutinising the content in the same way it does the MQ folder, which also contain the additional ‘external’ metadata files etc within each album….But then that doesn’t make sense in a way, as the Core has to look into the contents of the Download folder for building the database for browsing etc….I guess an edit on metadata when embedded in the files would have virtually no effect on file size – perhaps the Core just isn’t seeing that…?! But as you say…Time stamps!

But surely the Core is checking more than the file names ahead of incremental backups – would be madness if not…

I have wondered about the robustness of the Core’s own backups…Not much info seems to be given about them. I presume they are just part of the Linux OS. Nice and convenient, but they need to be 100% – and not all OS backups always are. (If you look up DigiLloyd and Mac Performance, you’ll find many an article and example of Apple’s Finder making poor and incomplete backups…I actually use his suite of software to check critical backups, which writes hidden hashtags into the source content, which is then checked on the copied version…) ….There was also a thread here a short time ago where someone discovered the backed up files were of a slightly smaller size than the originals stored on the Core – although this could be due to viewing the files across different OS platforms or protocols etc: viewing the Core’s files would be via SMB whereas the copies would be native Windows/Mac…

One thing you could do, and is something I plan to implement as an additional backup safeguard, is to run a separate ‘external’ backup routine….Using something like CCC (Carbon Copy Cloner – Mac only, but there’s plenty of similar for Windows) you could schedule a backup from the Core’s folders (mounted on the Mac) and incrementally back up to an attached USB drive or better still the NAS….At least with something like that, having used CCC for many years, I’d have fairly sound confidence in the state of the incremental backups.
Of course, the Core wouldn’t recognise those backups as it’s own in the event of needing to do a restore – but as it’s the Downloads folder, you kind of have that situation anyway and can manually put the content back there……

But I agree with @Osiris , would be good to have some additional info from Naim regarding the backups. I’m actually in contact with Support the last few weeks whilst the issue with my Core was resolved – I’ll see if I can tack on another question!

SC

4

We use a NAS as our Core Music Store.

Incremental backup to cloud taken care of by Synology. Faultless.

1 Like
5

Exactly. Or what I’ll be doing, is using Hyper Backup to regularly sync to my 2nd NAS….

As I said, only issue with these alternative/additional backups is that the Core wouldn’t recognise them for an automated restore….but easy to work around.

SC

1 Like
6

When we were experimenting with SQ tests via Core disk, NAS, SPDIF, ethernet etc. we simply pointed the Core at the already existing area on the NAS holding Core rips.

The Core is happy to rebuild the index from the content. So if we lost our NAS we’d build a new one, pull down from cloud and then point the Core at the new store.

Are backups different - are they somehow tied to an individual Core device?

7

Yes, when you set up a Core Backup and format the external USB drive, it automatically names it with a unique name (seems to be random each time you do this) …this is then obviously held in the Core database somewhere and known to that Core for backup and restore use….
If you plug in an ‘old’ backup, the Core will indicate that it doesn’t belong to the current Music Store – but you can override this and tell it to use it and assign it to the Core….
What I haven’t yet tried and seen what differences there are, is a Core back up to a NAS share (obviously this skips the formatting stage also) ….

1 Like
8

“Are backups different - are they somehow tied to an individual Core device?”

If that turns out to be correct, it’s just as bad as the original ‘file name’ issue - again, not a real backup…. at least in IT terms.

ATB, J

9

The backups are specific to the particular Core. I think this is all part of how they can do differential backups.

If you install a new internal HDD or SSD then you can “restore” using the backup and it’s back as it was.

You can also “import” a backup, in which case the files will take up residence on the new HDD quite happily, but not necessarily in the Music/MQ folder (may be in the Downloads folder instead).

10

Unless you have made metadata corrections in files which have already been backed up. Those changes are likely to be lost… (see first message of this topic).

11

OK, I’ve just had a play around with this…

It’s NOT happening for me i.e the Core backup seems to be correctly identifying and backing up re-tagged files in the Downloads folder…

My test: I pointed Metadatics on the Mac at the mounted Downloads folder of my Core. I selected an album and then changed a track title tag (NOT its file name) and appended ‘TEST’ to the track title…Saved the change. I then waited a few minutes for the Core to update itself – sure enough the track title changed when viewing the album in the App, reflecting the tag change. I then connected my normal USB external backup drive. Triggered a backup and noted that 2 new files were being backed up – I would presume this would be the particular track/file and the overall related metadata file for the album. I then removed the backup drive and plugged back into a Mac – looking at the relevant files in the backup folder, sure enough the time stamps reflected the recent change. To confirm yet further, I then pointed Metadatics at these files to confirm the tags and sure enough they were the changed version with the ‘TEST’ track name tag.
I then repeated the whole process again – changing the same track file on the Core back to its original title…reattached the backup drive, backed up, and reconfirmed the now later time stamped files were indeed on the backup version – they were.

So from what I can see and experience, the Core IS backing up correctly from the Downloads folder, even files that are altered in a minor way re tagging….

How are you making you tagging adjustments – are you sure the tag changes are indeed being saved…?

Only thing I will add, is since doing this, I now seem to have the oft reported Recycle Bin appearing in my backup drive – I never had that before, I’m pretty sure.

Note: My core is on a RC version of the firmware (2.5.6) which Naim loaded for me to correct another issue, but as far as I’m aware this wouldn’t be making any difference to the backup issue you are reporting….

SC

1 Like
12

Thanks a lot for thoroughly checking!

What I did is pretty much the same you did. I pointed Kid3 on my Debian GNU/Linux laptop at the mounted Downloads folder on my Core and corrected a mistake in the album name for all 6 tracks of the album, filenames remained the same. The correction was successful (confirmed in the Naim app on my iPad). The time stamp of the files on the Core do reflect the change.

After these corrections I copied two new albums of the same artist to the Core. The next day I checked my backup and noticed that the new albums were backed up, while the album with metadata corrections was not (files still had their original timestamps of before my corrections).

The only difference I see now is that you connected your backup drive via USB, while my backup drive is SMB/CIFS connected. I do have an off-site USB backup drive (for a monthly backup). I can repeat your test in the weekend and check whether the backup to my USB drive will happen as expected. To be continued.

13

I brought my off-site USB-3 backup drive home and did the following test:

  • Uploaded a freshly ripped CD (1 folder with 6 .wav files, provided with metadata (ID3v2.3.0) with Kid3)
  • Made a backup to my USB-3 backup drive via the Core menu (Settings - Manage Music - Backup Music - Backup Now etc.)
  • Checked the backup by mounting the USB-3 drive on my GNU/Linux laptop → backup correct
  • Made a change in ID3’s Title field of all 6 .wav files on my Core
  • Made a change in the filename of only 1 .wav file on my Core
  • Made a backup to my USB-3 backup drive again

Next I checked the backup again and had to conclude that only the file with changed filename has been backed up. The original file has been moved to the Recycle Bin.

The other 5 .wav files, thus the ones with a metadata change, without filename change were NOT backed up.

I am afraid I have to update my firmware to RC version 2.5.6 as well. I will contact Naim for further help.

14

I updated my firmware to version 2.5.6. This did not solve the issue unfortunately. Just sent an email to Naim and asked for help.

15

I’m contemplating options for my own music library currently it’s just in iTunes/Apple Music app, I only use it for stuff not on qobuz. Why have a nas and a core I’ve been trying to decide between the two or maybe something else like Innuos. I’m considering a nas so that I can also back up other media
/photos/computer files so I’m just wondering what the core does better that you have both?

16

We have a Synology DS220 NAS. I ripped 3000+ CDs via DBPoweramp, all verified via AccurateRip. Discs are RAID, redundancy. Cloud backup to Google cloud, automatically runs each night. Asset on NAS, customised browsing tree, easy access to music. Sounded great into 272 (although improved by Cisco switch), All perfect. Works great with NDX2 into nDAC, no switch required as no SQ improvement with decoupled transport/DAC.

Our NAS also has areas for non music files, also backed up to cloud,

SWMBO wanted a “push to rip” solution for HER CD collection. Likes naim. She went halves on a Core via the trade in deal for UnitiServe, with usual dealer discount.

I have then actually ripped all her CDs, mixture of Core and DBPoweramp :laughing: Not sure she could even operate the Core.

We don’t even have a disk in our Core. It uses our NAS as music store, so any rips automatically get backed up to cloud and served via Asset.

Synology NAS into NDX2 as transport sounds same over ethernet as Core. SPDIF into NDX2 from Core sounds same as ethernet.

The Core is a complete waste of money for us. Same SQ rips can be achieved for far far less. Plus the software on the Core is very poor. Asset is a far better and more flexible uPNP server, and Synology offers RAID and far better backup options (such as incremental Cloud backup).

Summary - don’t waste your money on a Core unless SWMBO demands it.

There are Innuos options with far better software and functionality for far less cost.

If you’ve got technical ability to rip CDs and shift onto a NAS then that can be done for a fraction of the price of a Core.

I love naim boxes, as my profile will attest, but the Core is simply vastly overpriced and underfeatured.

Don’t get a Core, get a NAS with Asset if you can rip. If you want a ripper get one of the popular and cheaper options.

Use the money saved to add that nDAC you’ve been looking for - that will bring far more joy to your life than a Core.

2 Likes
17

I highly prefer to backup the internal HDD to an external one, BUT from my laptop with a sync program (I use SyncBackfree) so it respects and KEEP original time and date.

18

For what it’s worth…

In my experiments with drives, when I first received my Core, I found it to sound much better with a drive inserted inside the unit. For example, I tried a usb drive by itself and the music was dull, lacking in verve. When an internal drive was installed the usb came back to life.

I don’t know if this may apply for you as I use local streaming only, no nas involved.

19

We tried with and without an internal drive. Sounded exactly the same as far as we could tell.

We’ve settled on using NAS with Asset as primary source. Core is only used as a ripper, and once we get through the last box of CDs it will likely sit gathering dust!

20

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