ioSafe to the Rescue

Recently, I had to remove my remote Synology device from service—not because of failure, but due to the closing of the remote location. My off-site backup was no longer available. This provided food for thought. Why do we use an off-site backup? Could an on-site backup work in its place? The answer was an ioSafe.

To answer our questions:

Why do we use an off-site backup? This backup is in case all local data is no longer available.

Could an on-site backup work in its place? Yes, as long as no data is lost due to fire, flood, theft, etc.

Why is ioSafe the answer? ioSafe puts a Synology into a housing that is fire- and waterproof (well, up to a specific temperature). This ensures your local data is safe. Could the data be stolen? Now, that was a question that needed more thought. The placement of the ioSafe is important so that alarms and locks protect the device. The device itself weights quite a bit: it is, after all, a safe!

So, since I have fire and flood covered, I have to consider theft. That is the potential issue. I will look at that a bit later.

The ioSafe answered my initial questions. So, what does it take to migrate from my Synology 1513+ to an ioSafe 1517+? Please note that both run Synology’s DSM software. This is in essence a Synology to Synology disk transfer. Here are the steps I took, as well as the missteps:

  1. I opened up the ioSafe and removed the disk trays. To make my life easier when I placed them back into the ioSafe, I numbered the trays from 1 to 5.
  2. I took the disks out of the Synology 1513+ in the appropriate order and placed them into the ioSafe trays with their corresponding number. These disks were transferred to the ioSafe.
  3. Ah, but I misstepped and had to undo everything—which I did, and then I powered back on the Synology 1513+ and dumped the configuration to local disk on my Linux VM.
  4. I repeated #2.
  5. I battened down the hatches on the ioSafe, booted, and got a lovely screen that said, “Do you wish to reconfigure your array?” Woah!
  6. I contacted ioSafe support, and within about thirty minutes, I got my reply indicating that I should follow the instructions within a Synology KB article. Kudos to ioSafe for not just redirecting me to Synology support.
  7. I followed the instructions, and my array came back. After entering my credentials for the first time, I was able to reconfigure using the saved configuration. On load of the saved configuration, it stated it would create file shares with _1 at the end, I told it not to by deselecting the shares in question. Yet, they were either already created or it created them anyway. This is more a Synology DSM issue, not an ioSafe one.
  8. Then, I added a static IP, and everything went south! Was it a DSM issue? An ioSafe issue? No, a duplicate IP address. So much for good records and ping. The problem was that the VM it was attached to was behaving poorly. I powered off the VM, and voilà, it all worked!
  9. I changed the static IP to one not in use.
  10. Then I needed to set up Shared Folder Sync; this failed the first time.
  11. I checked the Shared Folder Sync’s rsync configuration, updated, and tried again. Once more, failure.
  12. Once more, it was not an ioSafe issue, but a DSM issue. The solution on the ioSafe was to remove all @eaDirs and all *_1 directories and contents. For good measure, I also removed the @eaDirs from the shares I wanted to replicate.
  13. I fired off Shared Folder Sync, and now it worked.
  14. Shared Folder Sync now works from my regular Synology DS3615xs to the ioSafe 1517+.

Now I have a working ioSafe with Shared Folder Sync happening as required. More will be added over time: it all depends on space within the ioSafe. My plan is to upgrade the drives to hold even more. The problems I faced were related not to ioSafe but to Synology DSM software.

I would like to request a few changes to the ioSafe, however:

  • Add a lock to the front. Using an allen key is well and good, but a lock is better. Make it more safelike to access. Perhaps a pair of barrel keys.
  • Provide a means to lock the device to another device such as a rack to make it harder to move.
  • Provide a temperature sensor, gauge accessible via DSM software plugin so we can see how well the system is doing. There is a lot of insulation there!
  • Number the trays to help in migration and disk updates.
  • Provide 10G connectivity options.

All in all, I am very pleased with the ioSafe. I have no issues: everything syncs easily, and all is working and retrievable. Now my data is protected from fire and flood.

Protection from theft is achieved by where the ioSafe lives and other non-ready backups of data.

Edward Haletky

Edward L. Haletky, aka Texiwill, is an author, analyst, developer, technologist, and business owner. Edward owns AstroArch Consulting, Inc., providing virtualization, security, network consulting and development and TVP Strategy where he is also an Analyst. Edward is the Moderator and Host of the Virtualization Security Podcast as well as a guru and moderator for the VMware Communities Forums, providing answers to security and configuration questions. Edward is working on new books on Virtualization.

Leave a Reply

Your email address will not be published. Required fields are marked *

5 × two =