Backup satashare as SOURCE

Currently reading
Backup satashare as SOURCE

Hi there

I have just connected an old SATA SSD to my ds218+ using an eSATA caddy. I am using it to store my FLAC music library for my Roon Server also running on the NAS (in a docker). Theory being the user experience is better as file read/access is quicker from the SSD than it is from one of the main spinning disks in the NAS. Certainly does seem to have sped things up.

I want to create a regular back up of the contents of the SSD, BUT hyper backup will not let me select the satashare folder as a source for the backup. In fact it refuses to show it on the folder tree when creating a new tasks.

Is it possible to trick hyperbackup to allowing this or does anyone have a workable alternative to suggest? I've tried using a symbolic link from the main disk to the satashare folder, but hyperback up wont recurse into symbollic links...

Any suggestions much appreciated...
Why not look at it another way...

Place the music on the NAS's RAID and do a single version Hyper Backup to the SSD. That way there's always two copies and the SSD can still be used as a Roon source. How much space is the music library taking? You can always then do a multi-version backup to an off-NAS destination.

I keep my ALAC music (16bit/44.1kHz; 24bit/48kHz and 96kHz) on the NAS 'spinny' disks and haven't noticed any problems in playback: Audio Station, Plex/Plexamp, Media Server to HEOS. Mostly I've noticed it's the player that causes gaps where none should be, such as concert recordings.
Hi fredbert - great idea, hadn't thought about it that way around!

Just tried it, and there is a slight snag, hyperbackup reports that the target directory is in use by another task. I am wondering if this is due to the Roon server process accessing files within that folder (which it will need to). Any thoughts?

PS - Roon does seem to be perceptibly faster now all the files are on an SSD. I guess its access patterns are more susceptable to latency because of how the Roon client apps access the library (as compared to plex media server).

tried it, and there is a slight snag, hyperbackup reports that the target directory is in use by another task.
It means another HB task is targeting the same destination location, and I see you already have two suspects (Music_Flac Bac... and Roon_Backups...)

Try to select a subfolder on the SSD which will be where the music will be backed up to. So long as its not the same or within a destination as another task you should be ok.
Those backup tasks are for google drive destinations (my off site backups), so definitely not the same as the sata drive.

However, I did figure it out. Basically hyperbackup does not like it when you select an existing subfolder with data in it as the destination directory. So I let hyperbackup create a new destinaiton folder on the sata drive, and then moved all the content into it. And bingo! Works perfectly. And the great thing is that Roon is blissfully unaware as I just re-point the folder mapping in the docker container set up...

Thanks for your help fredbert.

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Yes. I just changed the timing of the integrity check, giving it enough time to complete before backup...
Unfortunately, HB does not support QC. It's either, a public IP, DDNS, or LAN IP.
Backup software cannot accurately predetermine what its final backup size is going to be. You need to...
Well I'm glad it was just an unplug issue this time.
  • Question
That will work with 4.1 version. Looks like user feedback has been implemented.
Hello eveyrone, Out of nowhere, now getting ""server data backup task on <server name> failed." Digging...
You are welcome! Glad that you got it eventually working. You can still create a Synology support ticket...

Welcome to! is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!