Deduplication Database Store Location
I plan to have the management server and storage node installed in the same machine, say Server A. Then I have a NAS server (QNAP) set up to connect to Server A through network. A centralized deduplication vault is created on the NAS server. Here is my questions:
1. for the deduplication database, should I store it on the local drive of server A (storage node) or on the NAS server? What is the bese practice?
2. If the recommendation is to install the deduplication database on the local drive of server A, in the situation I lose the whole server A, i will lose the deduplication database as well, but the actual backup files will stay on the NAS server untouched. When i reinstall another machine as management server and storage node, will i still be able to recover the machines or files through the backup files saved on the NAS server even i lost the deduplication database? When i reattach the orginally created vault to the new storage node, will the deduplication database be recreated? It does mention in the user guide that "If the database is corrupted or the storage node is lost, while the vault retains its contents, the new storage node rescans the vault and re-creates the vault database and then the deduplication database." I just want to make sure i understand correctly.
Thank you!

- Log in to post comments

Fedor, Thanks for your answer.
I have one more question here: If i created a backup plan to back up data to one centralized deduplicate vault and at the same time replicate the data to another centralized deduplicate vault, I will have one separate deduplication database for each vault, correct? Thanks!
- Log in to post comments


Keep in mind that recovering a Vault without a dedup-database can take up to 10 days per TB of deduplicated data. So if you think you might be able to recover something from the vault quickly after some major incidend that included your ASN, your're wrong. I'm not sure if it makes sense to backup the dedup-db, as it should be only useful when synchronized with the vault. As the details of the deduplication engine are pretty much undocumented, you're on your own.
Put your Dedup-DB on an SSD. Seriously. If your vault gets bigger, you need lots of RAM (16G per TB I'd recommend) and an SSD to make a recovery worth waiting for.
Also, don't use deduplicated vaults for long-term archiving. If your vault goes corrupt (which it does from time to time) ALL the data inside it is gone. Of course you can open support cases, but as support tends to leave you hanging for 3-5 months on a case, consider your data lost, because you won't get timely help from Acronis.
Don't put important mission critical data into a deduplicated vault. Just my advice - I lost 8TB of data over a year due to bugs in the Storage Node.
- Log in to post comments


Heiko, If the dedupe vaults are so flakey, how do you recommend using them or avoiding them all together?
- Log in to post comments

Just think about it:
* Dedup-ASN puts all your backups in a proprietary type of filesystem (or database - it's essentially the same) and only the ASN is able to access it. There is no other alternative - so if the ASN has problems, you're in trouble.
* There is no tool in existance to check this proprietary filesystem for consistency. Closest thing is a planned Validate task over the complete vault. And even that doesn't mean your backups are restorable. I'm only asking for consistency check - repair would be a second step.
* There is no documentation about this filesystem - you're putting all your backups in a black box. If this black box locks up, only Acronis can possibly access it. You are completely dependent on Acronis Support - and they let me wait months and months.
* Inner workings of the ASN-Deduplication is completely undocumented. Fixed-Block Dedup is no magic at all - it's the most trivial form of deduplication technology (okay, file-based is even more trivial). Yet the Dedup-Vault format seems to be a trade secret...
* Acronis Support also has no tools to check this proprietary filesystem for consistency. Closest thing is throwing the Dedup-DB away and recreating it. This takes many days and might still not produce a consistent DB or useful error messages.
* Acronis 1st level support (at least in germany) doesn't know much about Dedup-ASN (for example I was told that the Dedup-DB is not recreatable - after having it recreated twice), Acronis Expert team knows a few fundamentals, but any real problem always went directly to development. This is where Support Cases really get to take months.
* During such a long case, your ASN is practically not usable.
* Dealing with Acronis support can be very frustrating (for both you and your support contact) - especially when the cases get longer.
So if you really want to use a dedup-ASN I recommend:
* Don't use it for mission critical stuff that might need a restore fast. Or at least keep a replica somewhere. A freshly started ASN with cold cache is very very slow. If your disaster plan depends on a Dedup-ASN without a fallback replica I would reject it.
* Don't use it for mid- or longterm archiving. I know it's tempting, but the better alternative would be:
* Backup your backup vault regularly (to tape for example). This gives you long-term archive on tape and you can roll back your vault if it breaks. Don't forget to backup the dedup-db along with it.
So that's pretty much every reason why I stopped using ASNs at all. I tried for more than a year and failed again and again. A little samba server is many times more reliable - just buy a cheap RAID or NAS and put some large HDDs inside. If you really want or need Dedup, consider a more professional solution (think NetApp or EMC) and a backup solution that's certified with it. Acronis Dedup is pretty cheap compared to those but I learned the hard way that I cannot afford the cheap solution.
Curiously - Veeam does inline dedup in their product - it's fast and uses only very little RAM - never had a serious problem with the vault that couldn't be handled by support in a week. They only do VM backups though.
- Log in to post comments

> Inner workings of the ASN-Deduplication is completely undocumented. <...> Yet the Dedup-Vault format seems to be a trade secret...
If it may help, the inner work of a dedup vault is documented here:
http://www.acronis.com/support/documentation/ABR11.5/index.html#3353.ht…
- Log in to post comments

Okay I guess we have differing opinions about what a technical documentation is supposed to be.
This: http://kb.acronis.com/content/21734
is a bit closer to what I consider documentation (and this information should go into the manual.)
But I guess if we're going to discuss documentation, we should start a new thread - it's offtopic here.
- Log in to post comments