Reconnecting Unitiserve to back-up

Have you tried to create a new backup job? Can you see the shares you are using for backup on the nas? 

Claus

Yes - I have tried the pc app and the web interface. I can see the share but when I try and set it up as a share it says it has to be empty (which kind of defeats the purpose of a backup!). 

It only has to be empty so that the Serve can take over the rights of the drive. Once it has done so back-ups will populate that share. You also cannot have a recycle bin set up on that share, as lots of NAS devices seem to have as a default option. 

So if you make a new public share with no recycle bin, let's just call it 'NaimBackup', and then add it as a back-up within desktop client this should work perfectly. 

So, does that mean I copy the existing back-up copies into the new back-up share, once that is set up, and restore from there?

I may try some experiments and report back.

Do you need to restore a previous backup, or just to be able to make backups for the future? If you just wan the backup scheduled Again I would just run an entire backup to the new share and then make the usual daily incremental backup afterwards.

Claus

The 'new' UnitiServe cannot use the 'old' backup.  This is because, at the error message states, when creating a new backup, the backup destination must be empty.  And you do need to create a new backup task, as your UnitiServe is, essentially, new.  Perhaps Naim by logging into your system can do a work-around, but the generic advice would be to create a new backup.

I kind of think that the whole point of a backup on another device is that if the hard drive of the US fails then you can restore the backup to the new drive. It's not much use, is it, if the US won't recognize the existing populated back-up!!

Actually it's a bit more complicated.  I didn't get into the full detail to avoid muddying the water. 

When they replaced the HD Naim were able to copy most but not all the music from the old to the new drive. So I can do as you suggest and just re-rip the lost albums. However, the slight complicating factor is that I let MediaMonkey on my PC include the back-up directory in its library and I did a fair bit of work sorting out the tags and artwork which I now stand to lose.  

The backup can be used to restore . . . I thought you were trying to use it as a backup destination for additional / continued backups.

Can n-Serve (or the DTC; not sure if you use OS X or Windows) see your backup folder on your network at all?  What you want to do is to connect to it first as a share.  Can you get that far?  If not, it's a network issue to sort out first.

(Naim will sort all of this out for you by the way.)

Bart - yes.  I can see the share from the web interface and the (Windows) DTC.  It won't let me use it as a new back-up, because it is expecting it to be empty.  Naim say that it won't recognise it as the old back-up because it is linked to the old disk drive that was replaced.

Maybe as you suggest I can restore from share, but to be honest I didn't try that, assuming that it needed to be identified as the back-up first. 

But in any case, what I am now doing is moving the albums into a new back-up share.  That is an overnight job.  When the old share is empty I will try linking to it as a back-up, and then moving albums back, and see if that works.

I previously contacted Naim, and they said they need to have remote access to my PC - which is fine except during their working hours I am at work myself away from my home set-up. 

Martin - there is a thread here that describes how to restore from a backup.  You mount the old backup as a Share . . . then promote it to a Store . . . then can copy over to the main Store on your Userve hdd (I think this is right).  But what's not right is mounting the old backup as a backup again; that's not how it works if you want to restore.

So the fact that it won't let you mount the old backup as a backup again is the software working as intended!

Thanks - took a look at that thread, but I am getting an error when I try to promote the old back-up to a share.  I think I will abandon self-help on this, and wait till I get a chance to call Naim support and let them loose on my PC.

I've worked with Phil Harris logging in to my home system and if it can be fixed, he'll fix it quickly!  We are lucky to have this sort of support!!

I thought I'd report back on how I did on this.

I did get in touch with Naim support.  They rather took the position, in not many more words, that since I had messed with the files, the back-up was broken and I'd have to start from scratch.  Which is completely understandable, albeit a little disappointing.

But as it happened what I described in my note from 25th May worked (after I left it a day)- that is - copy the music out of the folder, relink to it as a back-up, and then copy it back in.  The differential back-ups started working happily, building on the previously backed up files.

I reported back to Naim, who told me that that was fine, but the restores wouldn't work

So I started trying to restore one of the backed up files that I has 'edited' using MediaMonkey to the download folder, and that worked (as I hoped and expected it would).  Then I tried restoring the file 'properly', which involved moving it into a 'Share' folder on my NAS, then promoting it to a 'Store'.   That worked too.

So - great news for me - I didn't have to recreate the MediaMonkey metadata and the back-up/restores work.

Meanwhile I'd asked Naim for a bit more explanation and they said  "We rip as untagged WAVs or tagged FLACS, in addition we hold a separate database files for each album too … editing the files manually will mean that they and the database files no longer tie up and will therefore almost certainly not restore back correctly should you need to do so."

So I took a closer look at what was going on.  The simple answer for the most part is that MediaMonkey doesn't appear to mess with the WAV files nor the Naim generated metadata files - it keeps its own metadata in it's own database.  

However, there is a facility in MediaMonkey to 'synchronise tags', and this does go back into the WAV files and change things like titles to align these to the metadata.  I tried restoring a file edited in such a way, and that worked too. 

You can see metadata in plain text if you look at the WAV file using notepad.  I'm guessing Naim is using a RIFF format, which includes an INFO chunk.  But reading up about this, it seems that the treatment of this is inconsistent between applications, which would be one reason to be wary of making such changes.  Meanwhile, I suspect that having created the WAV file, the Unitiserve doesn't use it for meta data, just relying on its own database files. 

Anyway - my own conclusion is that I am safe to carry on as I am, but I will avoid synchronising tags to avoid any possible future problems.

I hope this is useful to anyone like me who is using other music management software alongside the Unitiserve!

Martin, can you provide some more details as to what you're using Media Monkey to change / edit?

Um - well .... background was that I had something like 60,000 tracks mostly MP3 with various levels of compression, and also Apple Lossless.  They were a mess of inconstant labels, missing album art, unidentified tracks - all familiar I am sure to anyone like me who accumulated music from various sources over the years.

When I started trying to use the US to manage these it was a bit of a nightmare - it took forever to fire up the App on Apple devices at the time, and trying to tidy it up on with Naim software was not really a practical option.  The US itself was forever churning as it tried to stay on top of all the music.  So I limited the scope of what the US software looks at to it's own collection of ripped albums and just a couple of other shares (downloaded HD tracks, now moved to the Download folder, and Apple Lossless originally from iTunes).  That calmed things down.

I then looked at various music management tools for all the rest, and opted for MediaMonkey (MM), which has useful configurable tools to populate album / artist / track names from files names or by looking them up on-line (which also gave album art when missing).  So using this I've eliminated lots of duplicated tracks and pretty much tidied up my whole catalogue. I've also rationalised the genres, made artist names consistent.  It seemed to take forever, but it feels almost worth it.

I can play music off the NAS using MM through an optical out link from my PC to my nDAC. Using the US to play music it ripped itself remains the best option for quality and ease of use.  But I backup the music on the US to the NAS, and let MM catalogue it, so I can integrate the US collection with the rest for playlists and convenience. 

Sounds good Martin, but it also sounds like you didn't do anything to those files that the UnitiServe ripped or backed up. 

Or did you also try to use MM on some of those files?

No/Yes (respectively) - I did use MM on the back-up files as described in the long note a few hours ago. 

But my use of MM on the US back-up files I think only changed the related metadata within MM itself - I doubt I actually changed anything in the WAV files themselves or in the US metadata, except deliberately to test what effect that might have.

You are aware that we (I) are flexible on hours if required...??

Phil

Ahhhh ... I believe that we have already communicated on this one - if you have had MediaMonkey edit the files in the backup folder then I'm afraid that your backup folder may well no longer be consistent with regards to the music files and the HDXs databasing files that are in them as MediaMonkey won't have been updating those to keep them consistent.

You may well have 'broken' your backup if you have let MediaMonkey edit it...

Phil 

Just to clarify, the purpose of a backup is to allow you to restore music to a machine.

We force a backup location to be empty because if you - say - have a new machine and set an old backup location (which contains music that was backed up from an old Serve) as a backup location on that new (empty) serve then the first time that your new (empty) serve does a backup then it would wipe the old backup location.

What you should do is set up a *NEW* backup location, set the old backup location as a music store and then move the music from there to your Serve, the serve will then look after everything for you - moving over the music from the old backup and generating a correct new backup as you go.

However - in the OPs case, if he has been editing the files in the backup folder with a third party application then he *MAY* have inadvertently broken the integrity of the backup and so may have possibly rendered it useless as a restorable music collection. (I believe I have discussed this with the OP by email a couple of weeks ago.)

Phil

Looking through our email conversation I don't see anywhere that I have said that ...

... however I have tried to explain why using MediaMonkey to edit the files in the backup folder structure can 'break' the consistency of the backup set.

...and I have often done out-of-UK-office-hours logins for customers too.

Phil 

My recommendation (which I can tell is Phil's too) is, "Don't mess with the files created by the Naim servers."  I suspect you've adopted that approach now.

You didn't - it was Steve Hopkins who said that at the very start  of the dialogue with Naim.   You weren't around at that time (I think you were on leave).

I wasn't offered any out of hours support at any time during the dialogue with Steve or yourself, but I will remember for the future.