You wrotethis answer on using CLI to check status in feb 2018, its July 2019…WTF are you FORCING me to use a command prompt command instead of a program with a GUI to find the status of my backup and sync??? WTF is wrong with you. I have 30 TB to back up and I want the status, how long it will take, what has been backed up, what has NOT been backed up, what the F, carbonite does this, why not you…why do you keep me in the blind and show me ONLY 4 files that are being copied ??? Do you literally think its appropriate for me to use
I’ve been using PC’s since 1980 and even UNIX back then, so , command line is not a problem but its year 2019… what the F are you guys thinking ??? I may very well NOT buy odrive in 4 days just because I have NO idea of what is happening and how long it will take…
Hi @h2fuel,
The CLI status actually gives pretty much the same information as the odrive menu, so there isn’t usually a need to use it over what you can see in the odrive menu unless you are doing something like scripting.
Please keep in mind that odrive is not a traditional backup solution. It is a sync solution and, as such, may not be the right solution for your backup use case.
Sync is a much, much heavier process than traditional backup, so when you apply sync to more massive data repositories, like multi-terabyte data repositories (especially on external drives, or NAS), it can make odrive work extremely hard to continually ensure that both sides are always in lock-step with each other. This can create CPU heat, large memory footprints, and excessive network calls. Sync also needs to be much more aggressive than traditional backup, since a key component of a good sync engine is speed of reflection on both sides. In a traditional backup use case most of this sync work is wasted, because the user is never going to change anything on the remote side and local changes do not need to be reflected as quickly as possible.
This is also why there isn’t a summary status screen that gives totals and estimated time. odrive is optimized for speed of pick-up and reflection, which are important for a responsive sync engine. This means it performs in a “sync as you go” manner, immediately syncing items as it encounters them. It doesn’t try to scan and index everything on both sides before starting because that can take a very long time and the state information can rapidly become stale in a full-sync environment.
odrive works well for what it is intended for: full, bi-directional, near real-time sync, with the ability to target specific areas of your potentially vast storage collection using features like “unsync” and “sync to odrive”.
If you are needing to backup 30TB of data across more network drives than you can assign drive letters to, I would say that odrive isn’t going to work satisfactorily for you unless the majority of your data is very large files (keeping the total object count to a reasonable level). The more objects (files and folders) odrive has to track, the more work it has to do to keep all of those objects in perfect sync. Once you scale to many hundreds of thousands of actively tracked objects you will start to see performance issues as odrive races to keep that vast data set in sync.