About backups - OrientDB does not backup indexes, it recreates them on restore - but creating indexes is the most expensive operation! For us it meant an unacceptable level of downtime during a restore.
The impression I got when I was working with OrientDB is that you focus a lot on features, and OrientDB definitely has a lot of them. So anyone that does a naive point by point comparison with other products will naturally be blown away by OrientDB. But many of these features are not well thought out, or are broken in obvious or subtle ways - e.g. you support Lucene for full text search but it's unusable for anything but the most simple use case.
It takes a lot of development time before it becomes apparent just how broken the product is, and that is the problem - if it'd let us down in the first few weeks I wouldn't be writing this. Instead we encountered a constant stream of strange bugs and edge cases, and to be fair to you, you fixed a lot of these problems quickly, but we'd always find new ones, and it became a case of death by a thousand tiny cuts. Nevertheless, because of launch pressure we got into a position where we thought we had something that would suffice, but when we tested it with real world data we got constant lockups and OOM problems. When we realised that one of the most fundamental features - transaction support - was broken, we decided we had no choice but to change data stores and rethink our entire architecture, and to have to do that so late in the game was extremely painful and risky.