We wanted to migrate our current backup from a tape solution (LTO-3) to Microsoft Azure.  As we have an initial amount of ~1,5 TB of data to transfer to the Microsoft data center we decided to use the Azure Import/Export service (offline backup) and send it via snake mail to the Microsoft data center. Uploading it to Azure with our current connection will would have required ~1week of constant uploading and blocking the Internet connection.

I don’t want to deep dive into the process here as it is describe quite well (and updated) in this article Offline-backup workflow in Azure Backup . I’d rather like to give some hints to avoid the pitfalls we stumbled over.

disk space

You’ll need some temporary disk space in the size of your backup the use this service. When setting up the backup job you need to have a staging device ready where the Azure Backup Agent can store the data you’ll later copy to the disk you send to the data center. It’s recommended to have the space your backup will consume available although the backup will be compressed by the backup agent. So in reality you won’t need as much space as your original data consumes. The backup volume can be an internal disk, an network share or an USB attached device (but not the drive you want to send to the Azure data center).


As stated in the Microsoft documentation the device you send to Microsoft must be an 2,5” or 3,5” internal SATA II or III device. Microsoft will not accept any other devices!

To bring your data onto the to be shipped disk you’ll need to connect this disk to a Computer or the server where you are running the backup. You can either use a USB-to-SATA adapter or connect the disk to an internal port in you PC. When you use a internal Port you should be fine but you’ll at least need Windows 7 Enterprise (as Bitlocker is required) as Operating system to copy the data to your HDD.

Using a USB connector makes things a bit more flexible since you can directly attach the device to your copying computer and also to you virtual servers. But using USB connectors seems not to be as easy as it looks at first glance. As I had to learn while trying to use my existing ICY-Box to connect the disk, not all USB connectors seem to be supported by WAImportExport.exe

If you receive the following error from the WAImportExport tools you most likely have an incompatible device:

[Error] Command failed with exception: AzImportDll.AzImportException: Could not read serial number or signature for the drive. This is a critical error an the command cannot run. This may be due to certain USB adapter or disk drivers that are not fully compatible with the operating system.

I haven’t found any official list naming compatible devices. But while searching the net for the reason for this error I stumbled over this article naming some devices which should be working.

Luckily, I just had ordered another USB connector for a different private project which worked, so I had not to fumble around with this. But to avoid trouble you should order one of the listed to devices.

compatible devices

incompatible devices


Storage Account

Azure Import/Export service does currently only classic storage accounts . If you read the documentation carefully you’ll notice it but as it’s not as clear as it should be, I’d like to mention it here.


Running WAImportExport.exe

When running WAImport make sure your current path in the shell is inside the directory where the tool is located. Do not call it while being in a different directory as this will result in an error. Not knowing this has cost me about days because I had to run the tool 3 times until I found the problem. At the end of the copy operation the tool is looking for a file in the current directory rather then using an absolute path pointing the directory where it put the file. If this fails you have to do all copying again.

I wanted to automatically backup the configuration of our AudioCodes devices because I always forget to save the configuration file via the web interface before or after doing changes. Searching the net did not give any suitable solutions. There was only one guy playing around with trying to do http requests to get the ini file but since AudioCodes changed the whole UI in Version 7 onwards this no longer worked.
I’ve used RANCID for several years to backup my Cisco devices and noticing that AudioCodes uses a similar CLI, I tried to use RANCID for this but it didn’t work as I could not make any modifications to the code. Searching for a successor brought me to oxidized which basically does the same but in a more open and flexible way – Grabbing the configuration on a regular basis and allowing me to view diffs between the versions.

It took me a lot of sweat (and time) to get this working but finally everything is working and you can follow this manual to get it into your environment.


The following steps have been tested on Ubuntu 16.04LTS, You may have to adopt some steps to your operating system.


Install the needed software.

In the next step we need to download the oxidized git repository in the latest version. We cannot install the gem directly, because we need to modify something to get it work properly. (Version <=0.20.0)

If you’re behind a corporate firewall and need to use a proxy server type, you need to tell git to use it first.

Now we can download the repository. This will create a folder “oxidized” in your current working directory.


Beause oxidized by default requires an older version of net::ssh, which is not compatible with AudioCodes devices, we need to edit the built file to change the net::ssh version to 4.1.

Search the following line

and it change to

The next command will build the gem and install net::ssh version 4.1 and not 3.0.2 .

This will build the gem to the folder pkg, from where we can install it with:


Configure Oxidized

Before we can use oxidized we have to configure some basic settings.

First thing is to create a user and a home directory for oxidized as it’s not recommended to run oxidized as root.

I like to keep my config in a central place, therefore I created a folder under /etc where I can put all my configuration files

We will also need a directory where the saved configuration files will be stored. ( This is wher your backups land)

Now we can create a configuration file and put some basic configuration in it.

Here’s an example configuration you can use:

You have to change at least the following lines to fit your environment.


Change this to the IP where the webserver should be reachable.

Change this username and password to match your user for config backup. This credentials will be used on all devices in the group “sbc”:


Define where oxidized will put the backed up files. In this case we’ll use git to save our configs, the will allow us to enable versioning and see differences. If you’ll use plain files it’ll always update the file with the latest version. The user will only specify a username within the git repository, same as E-Mail, it doesn’t realy matter what you enter here.


Now we need to define where oxidized will find the list of hostnames it should backup. In this case we use CSV and the file is /etc/oxidized/router.db. Each line in the file will be one host. For each host we have a mapping defined here – first entry is name, second model and third group. Each value will be separated by “:”.


On my system, reading the router.db from an other place then /home/oxidized/.config/oxidized/router.db didn’t work. I therefore needed to create a symbolic link to point to /etc/oxidized/router.db as I wanted to have the config in a more central place.


Here is a basic example of a router.db file


At the time of writing this article the audiocodes.db file is not included in repository, therefore you must create it manually. 

Enter the following commands to create the file and folders and to open an the file for editing. Put in the content you find below.


Here is the content of the audiocodes.rb file.


Basic configuration is now finished, you can now try to logon as the oxidized user and start the service to see if it is running or throwing any exceptions.


When the Service is running, you can reach the webinterface using


If everything is fine and running you can add oxidized as a service, so it’ll automatically start on reboot. To do so, we need to create a configuration file for systemd and add it the configuration.


Add the following content to this file.


The created service now has to be added to systemd configuration. Afterwards we can start and stop the Service using the Service command. This will also start the service automatically on reboot.


To start the Service use:


To stop the Service use:


To see the status type:



Official Oxidized project page

Getting git work behind a proxy-server

Oxidized Tutoral which helped me a lot