Install Acronis Storage Node on hyperv virtual machine?
Hi,
Our backup situation is:
One dedicated physical server with two partitions. One partition for ABR 11 sofware (all options installed) The other partition is used for storing the backups on this partition/disk. After storing the backups on disk they are transferred to a tape library which is connected to the same physical server.
Now we want to implement deduplication. For best practices it is not wise to install the deduplication database on the same physical server.
Is it an option to install the storage node with the deduplication database on a new virtual machine under hyper-v?
Thx
Ramon
Thx for your answer. But its not the same physical server. The AMS is installed on a dedicated physical server. So the Storage Node would be installed on a hyperv physical server (but on a virtual machine).
Is this OK?
If I had a dedicated physical server, I'd rather installed Storage Node there, and AMS inside a VM.
My advise would be: Stay away from deduplication. Stay away from managed vaults. At least for ABR11's current build. It's not stable and the requirements from the manual are not what the vaults need in reality.
* Manual says optimum is 64bit and 8G RAM. It's more a "minimum". I have a dedicated VM with 4 cores and 8GB with Storage on a FC-SAN (with a dedicated 15K RPM HD for this) and the node is still slow as hell. I'd say minimum for system(catalog) and dedup would be a SSD because the main bottleneck of a managed vault is seeking around in an SQLite database.
* You should double the expected space allocation for dedup. And you should have about triple the amount of free space on the system drive for the catalogue. For 500GB of deduped raw data (that'll be about 1.5T of uncompressed backups - so for us it's 10 Notebooks doing a GFS-plan) you should have 20-30G on your dedupdrive and at least 30 (better 50G) free for the catalogue. The catalogue is in this case only 6G, but once your plans start deleting old backups, it will grow. For technical reasons (it seems) the catalogue size doubles temporarily when a backup is deleted. It'll shrink again once the node is idle - so make sure your storage node is idle for a few hours once in a while. It's not easy because cataloging and indexing 4-5 Backups a day (including deleting old backups) can keep a storage node busy for the day and half the night. If you're unlucky, it crashes during the process and needs to start over. Keep that space free, because cataloging operations will fail with weird errors, not indicating the actual problem - and your catalogue will be (possibly) damaged - and support won't be able to tell you if your catalogue needs repair (or how to do it).
* Your vault may become damaged and then you'll play waiting game. I have vault that won't validate and won't export (or restore) any backups. Support Case is open since mid September and still nobody can even tell me if the data is lost or salvageable. 24x7 support only means you can open a case all day and you may get help with simple problems that are in the script of 1st level support (or in the KB).
* expect at least build 17318 to crash frequently during backup (Once a week - depends on load). Especially when the storage node is busy indexing or cataloguing, an incoming backups can crash it easily.