https://community.logos.com/forums/p/121491/796939.aspx#796939
Feel free to add anything that was missed.
Thanks Lynden, having seen the accumulating posts this morning I felt guilty about having contributed towards sidetracking the other thread, and was about to start a new one, as Super.Tramp has suggested.
how does Crashplan cope with backing up a large (several GB) Logos index.idx file to cloud backup I'd recommend excluding the "BibleIndex" and "LibraryIndex" folders from cloud backup. The data in them can be completely rebuilt from your resources locally, and on most computers (with common Internet connection speeds), it's going to be quicker to rebuild the index locally than to download it from the Internet. Backing it up is probably a waste of bandwidth IMHO.
how does Crashplan cope with backing up a large (several GB) Logos index.idx file to cloud backup
I'd recommend excluding the "BibleIndex" and "LibraryIndex" folders from cloud backup. The data in them can be completely rebuilt from your resources locally, and on most computers (with common Internet connection speeds), it's going to be quicker to rebuild the index locally than to download it from the Internet. Backing it up is probably a waste of bandwidth IMHO.
Thanks Bradley
Hi Mark, how does Crashplan cope with backing up a large (several GB) Logos index.idx file to cloud backup, since the file is updated quite regularly (sometimes a few times a week if not more)? I know about its block mode backup, does this only update the changes to the file resulting in small file updates and lower internet bandwidth required? That's correct. CrashPlan only uploads those parts of a file that have changed. From their FAQ: After initial backup of the file is complete, only new or changed information is sent when the file is backed up. When CrashPlan scans a file, it knows that the file changed and the progress bar runs through the file as if the information is new. But as it goes, it discovers the information hasn't actually changed and only transmits the new information to the backup destination. For the technically savvy: CrashPlan does incremental deltas by block within the file. Speaking personally, I only backup my Logos installation locally (using CrashPlan), but I do backup 120Gb+ of MySQL tables online, and CrashPlan uploads changes to those extremely quickly. If I wanted to backup Logos online, I'm quite sure CrashPlan would handle it very smoothly, even with a regularly updating index.
Hi Mark, how does Crashplan cope with backing up a large (several GB) Logos index.idx file to cloud backup, since the file is updated quite regularly (sometimes a few times a week if not more)? I know about its block mode backup, does this only update the changes to the file resulting in small file updates and lower internet bandwidth required?
That's correct. CrashPlan only uploads those parts of a file that have changed. From their FAQ:
After initial backup of the file is complete, only new or changed information is sent when the file is backed up.
When CrashPlan scans a file, it knows that the file changed and the progress bar runs through the file as if the information is new. But as it goes, it discovers the information hasn't actually changed and only transmits the new information to the backup destination.
For the technically savvy: CrashPlan does incremental deltas by block within the file.
Speaking personally, I only backup my Logos installation locally (using CrashPlan), but I do backup 120Gb+ of MySQL tables online, and CrashPlan uploads changes to those extremely quickly. If I wanted to backup Logos online, I'm quite sure CrashPlan would handle it very smoothly, even with a regularly updating index.
Thanks Mark, that's helpful.
I raised concerns in November already, well before all the corporate changes. Here's my user voice request resulting from the discussion back then:
https://logos.uservoice.com/forums/42823-logos-bible-software-6/suggestions/10936203-installable-software-library-and-license-backup
Relevant threads are linked from the request. Please vote up if you like the idea of an integrated backup function.
I would appreciate reading the rationale, from Faithlife, for why beginning with Logos 4 a local backup and restore function was not included in the platform design.
I have not pressed the question before because I don't like speculation.
I would not expect local backup and cross-platform synchronization to co-exist in an application. And enough people run backup and mirroring software that those who truly need a local backup probably already have it covered. Yes, I can think of scenarios where for a tech-savvy user it would be useful to have a local backup so I wouldn't discourage people from making them. But as a system need justifying the expense and added fragility ... I think not.
And enough people run backup and mirroring software that those who truly need a local backup probably already have it covered.
This is my situation and, in light of this, I too don't see this as a pressing need.
Backups will work for many things I would imagine. It will not save your Atlas, Logos Now or some of the other datasets/books that require a license check periodically. As I recall there was a post in the past that mentioned that some datasets/books required license checks but I could be wrong.
Either way, I do not anticipate this being a real problem any time in the near future as I think FS is in good standing and simply trimming what is not needed based upon some re-direction or focus going forward. Just my humble opinion.
I hope anyone who is concerned about the long-term availability of the resources they have purchased will find ease of thought in this regard.
I find the absence of inbuilt backup and restore functionality personally inconvenient but it has not discouraged me from significant purchasing.
I would not expect local backup and cross-platform synchronization to co-exist in an application.
Why so? Can you elaborate?
All very well, unless your hardware changes.
But as a system need justifying the expense and added fragility ... I think not.
I understand your reasoning here. I would like to have seen an official rationale prior to speculation, even highly well-informed speculation.
OT: This often seems to me the implied reason, like a blanket, that other long standing features were designed out beginning with Logos 4. I continue to reserve judgment on the merit in each case.
From nearly six years ago ... and the problem of syncing has only gotten worse with the growth of the tablet market:
I feel like this has already been beaten to death, but since it just won't go away, I'll take one more shot. First, let me say that we do listen to our customers. Even when we say "we're not planning to do that," we keep listening. The evidence shows we change our minds when necessary, if not every time you want. Now, the simple explanation. I believe that the future of consumer applications is simple, convenient and in the cloud. I know everyone doesn't agree. I know everyone doesn't like it. I just think it's going to be "the ways things are" in the near to mid-term future. For the record, I have zero photos on Flickr, only use Gmail as a throwaway address, and generally don't use cloud apps. I have a technical person's aversion to data out of my reach. Except I'm lazy, and I'm finding the few cloud apps I do use to offer a really compelling benefit in the way of convenience and simplicity. So no amount of anti-cloud articles from the technical press or enterprise analysts is going to mean much to me. I already dislike the cloud. It's just that it's so useful and popular, I can't help it. :-) Call me when your friends stop using Facebook and Flickr. So I see a future in which consumer applications (like Logos Bible Software) are, by definition, cloud applications. For example, Gmail is a consumer email client, Google's attempts to sell it to business not-withstanding. Nobody complains that Gmail runs on Google's servers. It's a cloud service. Even the availability of a desktop client wouldn't cause the world to clamor for Gmail that stored all its data on your hard drive. Nobody is surprised when your email messages are archived on Google's server. That's what cloud apps do, so you can access them from other machines, have online backup, etc. Logos was a desktop only app, and it's moving towards being a cloud app. It isn't there yet, and may be a hybrid for a long time, or even forever. So I understand that this change is catching some people off guard, and upsetting others. Not everyone will even agree that it's a good idea. I've had the same experience with other apps myself. (Family Tree Maker used to be something I had a purely offline experience with. Now Ancestry.com is the new "cloud" solution they're pushing towards. Weird change at first, but now I appreciate it.) Yes, your data is your data. And so we are working on better copy, export, and print features. These are literally being coded right now, and you'll have them soon. I'm sorry they weren't in the first release, but for that excuse I'll refer you to any number of "why did you release it now?" forum threads back in November. :-) As for the argument that allowing people to simply turn of sync for certain document types is just 20-30 lines of code, my answer is: true. But those would be the most troublesome and expensive 20-30 lines of code in the app. More than 20 years in software development has taught me that there's no association between "easy to code" and "a good idea." As a formerly very geeky programmer (now just mildly geeky), I was a big fan of an option for everything. Total control for the user of every conceivable controllable thing. Secret .INI files and registry settings to allow changing those other settings considered too obscure for even the Tools > Preferences > Advanced dialog box. Stupid, stupid, stupid. Every setting and option is one more way your system can be different from everyone else's, and from the one technical support is using to try and help you. Every setting is one more thing to preserve, import, upgrade in the next version. One more thing to document, test, and maintain. One more thing to make the application scary and overwhelming for the very non-technical user. Let's look at the implications of this particular proposed change: Scenario A: We put in code to let users turn off prayer list syncing. User loses laptop, installs on new machine, is delighted to find all their books, licenses, notes automatically restored from the server. Phone call: "Where is my prayer list?" Scenario B: To avoid Scenario A, we implement a local backup option. Lots more than 20-30 lines to write backup option. (We have to make a special, separate data store for just the non-syncing data, apart from the syncing data, which we don't want in the non-syncing backup. Then we have to write code to read in "restored" backups. Have to make sure it's version aware, in case you choose not to restore for years, and expect future versions to import old backups. Etc.) Now we need code to remind you to backup. Or else we have to trust you to do it. (Real world: nobody does it.) Or we have to tell you when you call, "Sorry, no way to restore those. It's your fault." Scenario C: You have a desktop and notebook. You have synced notes. You read a Newsweek article on the dangers of the cloud. You turn of syncing of your notes on your desktop. You forget to do it on your notebook the next day. You continue to work on the synced notes on the notebook, and the no longer synced notes on your desktop. Later you turn off sync on the notebook. Six months later you upgrade your desktop. How do we get your notes to your new desktop? What if you decide the cloud isn't so bad, and want to use it to make the switch convenient, so you just turn it back on. And you're getting a new notebook, too, so you turn it back on there. We have to code UI and conflict resolution algorithms for worst-case scenarios of merging long-detached note files. What if you edited the same note, then turn sync back on? What if you don't want sync back on, but had left it on on the notebook, used it on the new desktop, and now want to bring the unsynced old desktop's version of that same note file over to the new desktop? What's the UI? Scenario All-of-the-Above: You call tech support and are on the phone for 2 hours. Scenario Highly-Likely: You are not a very technical user, and didn't understand the implications of syncing or not. A friend said "they're reading your prayers! turn that off!" and you did, and now months later you just want your new machine to have all your prayer lists on it, just like it has all your notes, and you call to ask why just some of your data made the transition. Are these problems solvable? Yes. Are they 20-30 lines of code with no implications for telephone support? I don't think so. Will we do them, and suffer the hassle and inconvenience, if they are the top priority of a huge number of users? Yes. But I hope that's not the case, and so far the feedback we're getting is that sync, and automated (if time consuming) downloads are a welcome benefit. And when users install on new, or secondary, machines, they're positively gushing about the convenience and simplicity of the second installation. And all this is before we even gets notes and prayer lists (and more) to your smart phone. Logos 4 has already cut our support costs by a third. (They're actually up, but not as much as they'd be if they were the same ratio of sales as they had been.) And those savings are put to work for you: we're hiring more programmers, processing more books, creating more data, offering (free) new platforms like the iPhone, iPad, etc. Is it less customizable? Yes. Will we have to adapt, in response to your feedback? Yes. Am I happy with the direction, and confident that it's the right call for the vast, vast majority of our users? Yes. We have discussed things like private encryption keys, which could be used to encrypt your data before sending it to us. But even that has difficulties: you could lose the key, and we'd be unable to restore your data. If you synced a machine to encrypted data but hadn't yet entered the key, we'd have to make all those records read-only (and not show the encrypted content). Not impossible, but a lot more code, and UI to explain why a note was present but unreadable, etc. And what if you entered different keys, and typed different notes, into two machines using the same account, before they had a chance to sync? Which key should be used? New UI to coordinate the keys without transmitting them, to warn when you've already used a key on a different system, etc. etc. (These are all obscure scenarios, but unfortunately we have to code for these "edge cases." Which is why we try to minimize complexity whenever we can.) Which really gets to the bottom line: where do you want us spending our time? We've got a smart team. We can implement whatever grade of security and smart synchronization our users want. But my impression is that < 1% of our users care for more security than we presently offer, and the other 99% think that keeping deep, personal secrets out of their Bible software is a pretty small trade-off in order to keep the programmers building better Bible study tools instead of constructing yet-another digital vault. Thanks for your patience, and for engaging us in discussion. It's great to have a user base that cares! -- Bob More on security: Almost every web site at which I've created an account will email my password to me. This is terrible security; if I walk away from my computer while logged into email, any passerby can retrieve any password. If you can guess just one password of mine, you can retrieve nearly all of them. (I lock my workstation. Do you? Every time you get up?) This is why my bank doesn't email my password. Try losing your bank password, and resetting it. Big pain. Probably involves snail-mail or a visit to the branch. American Express is so secure that I just stopped using their site. I won't sign up for e-billing because it's much easier to mail a check in response to a paper bill. (Actually, I hate paper mail and writing checks, too. So what I really did is just stop using my American Express card. I only work with them on the corporate side, where I've got an accounting department they can annoy.) I'm glad my bank won't email my password. However, I'm also glad all the other sites will. Because I don't keep anything terribly important at most of them, and value the convenience and simplicity that lets me come back months later and have the site "just work," even if I forgot my password.
I feel like this has already been beaten to death, but since it just won't go away, I'll take one more shot.
First, let me say that we do listen to our customers. Even when we say "we're not planning to do that," we keep listening. The evidence shows we change our minds when necessary, if not every time you want.
Now, the simple explanation. I believe that the future of consumer applications is simple, convenient and in the cloud. I know everyone doesn't agree. I know everyone doesn't like it. I just think it's going to be "the ways things are" in the near to mid-term future.
For the record, I have zero photos on Flickr, only use Gmail as a throwaway address, and generally don't use cloud apps. I have a technical person's aversion to data out of my reach. Except I'm lazy, and I'm finding the few cloud apps I do use to offer a really compelling benefit in the way of convenience and simplicity.
So no amount of anti-cloud articles from the technical press or enterprise analysts is going to mean much to me. I already dislike the cloud. It's just that it's so useful and popular, I can't help it. :-) Call me when your friends stop using Facebook and Flickr.
So I see a future in which consumer applications (like Logos Bible Software) are, by definition, cloud applications. For example, Gmail is a consumer email client, Google's attempts to sell it to business not-withstanding. Nobody complains that Gmail runs on Google's servers. It's a cloud service. Even the availability of a desktop client wouldn't cause the world to clamor for Gmail that stored all its data on your hard drive. Nobody is surprised when your email messages are archived on Google's server. That's what cloud apps do, so you can access them from other machines, have online backup, etc.
Logos was a desktop only app, and it's moving towards being a cloud app. It isn't there yet, and may be a hybrid for a long time, or even forever. So I understand that this change is catching some people off guard, and upsetting others. Not everyone will even agree that it's a good idea. I've had the same experience with other apps myself. (Family Tree Maker used to be something I had a purely offline experience with. Now Ancestry.com is the new "cloud" solution they're pushing towards. Weird change at first, but now I appreciate it.)
Yes, your data is your data. And so we are working on better copy, export, and print features. These are literally being coded right now, and you'll have them soon. I'm sorry they weren't in the first release, but for that excuse I'll refer you to any number of "why did you release it now?" forum threads back in November. :-)
As for the argument that allowing people to simply turn of sync for certain document types is just 20-30 lines of code, my answer is: true. But those would be the most troublesome and expensive 20-30 lines of code in the app.
More than 20 years in software development has taught me that there's no association between "easy to code" and "a good idea." As a formerly very geeky programmer (now just mildly geeky), I was a big fan of an option for everything. Total control for the user of every conceivable controllable thing. Secret .INI files and registry settings to allow changing those other settings considered too obscure for even the Tools > Preferences > Advanced dialog box.
Stupid, stupid, stupid.
Every setting and option is one more way your system can be different from everyone else's, and from the one technical support is using to try and help you. Every setting is one more thing to preserve, import, upgrade in the next version. One more thing to document, test, and maintain. One more thing to make the application scary and overwhelming for the very non-technical user.
Let's look at the implications of this particular proposed change:
Scenario A: We put in code to let users turn off prayer list syncing. User loses laptop, installs on new machine, is delighted to find all their books, licenses, notes automatically restored from the server. Phone call: "Where is my prayer list?"
Scenario B: To avoid Scenario A, we implement a local backup option. Lots more than 20-30 lines to write backup option. (We have to make a special, separate data store for just the non-syncing data, apart from the syncing data, which we don't want in the non-syncing backup. Then we have to write code to read in "restored" backups. Have to make sure it's version aware, in case you choose not to restore for years, and expect future versions to import old backups. Etc.) Now we need code to remind you to backup. Or else we have to trust you to do it. (Real world: nobody does it.) Or we have to tell you when you call, "Sorry, no way to restore those. It's your fault."
Scenario C: You have a desktop and notebook. You have synced notes. You read a Newsweek article on the dangers of the cloud. You turn of syncing of your notes on your desktop. You forget to do it on your notebook the next day. You continue to work on the synced notes on the notebook, and the no longer synced notes on your desktop. Later you turn off sync on the notebook. Six months later you upgrade your desktop. How do we get your notes to your new desktop? What if you decide the cloud isn't so bad, and want to use it to make the switch convenient, so you just turn it back on. And you're getting a new notebook, too, so you turn it back on there. We have to code UI and conflict resolution algorithms for worst-case scenarios of merging long-detached note files. What if you edited the same note, then turn sync back on? What if you don't want sync back on, but had left it on on the notebook, used it on the new desktop, and now want to bring the unsynced old desktop's version of that same note file over to the new desktop? What's the UI?
Scenario All-of-the-Above: You call tech support and are on the phone for 2 hours.
Scenario Highly-Likely: You are not a very technical user, and didn't understand the implications of syncing or not. A friend said "they're reading your prayers! turn that off!" and you did, and now months later you just want your new machine to have all your prayer lists on it, just like it has all your notes, and you call to ask why just some of your data made the transition.
Are these problems solvable? Yes. Are they 20-30 lines of code with no implications for telephone support? I don't think so.
Will we do them, and suffer the hassle and inconvenience, if they are the top priority of a huge number of users?
Yes.
But I hope that's not the case, and so far the feedback we're getting is that sync, and automated (if time consuming) downloads are a welcome benefit. And when users install on new, or secondary, machines, they're positively gushing about the convenience and simplicity of the second installation.
And all this is before we even gets notes and prayer lists (and more) to your smart phone.
Logos 4 has already cut our support costs by a third. (They're actually up, but not as much as they'd be if they were the same ratio of sales as they had been.) And those savings are put to work for you: we're hiring more programmers, processing more books, creating more data, offering (free) new platforms like the iPhone, iPad, etc.
Is it less customizable? Yes. Will we have to adapt, in response to your feedback? Yes. Am I happy with the direction, and confident that it's the right call for the vast, vast majority of our users? Yes.
We have discussed things like private encryption keys, which could be used to encrypt your data before sending it to us. But even that has difficulties: you could lose the key, and we'd be unable to restore your data. If you synced a machine to encrypted data but hadn't yet entered the key, we'd have to make all those records read-only (and not show the encrypted content). Not impossible, but a lot more code, and UI to explain why a note was present but unreadable, etc. And what if you entered different keys, and typed different notes, into two machines using the same account, before they had a chance to sync? Which key should be used? New UI to coordinate the keys without transmitting them, to warn when you've already used a key on a different system, etc. etc.
(These are all obscure scenarios, but unfortunately we have to code for these "edge cases." Which is why we try to minimize complexity whenever we can.)
Which really gets to the bottom line: where do you want us spending our time? We've got a smart team. We can implement whatever grade of security and smart synchronization our users want. But my impression is that < 1% of our users care for more security than we presently offer, and the other 99% think that keeping deep, personal secrets out of their Bible software is a pretty small trade-off in order to keep the programmers building better Bible study tools instead of constructing yet-another digital vault.
Thanks for your patience, and for engaging us in discussion. It's great to have a user base that cares!
-- Bob
More on security:
Almost every web site at which I've created an account will email my password to me. This is terrible security; if I walk away from my computer while logged into email, any passerby can retrieve any password. If you can guess just one password of mine, you can retrieve nearly all of them. (I lock my workstation. Do you? Every time you get up?)
This is why my bank doesn't email my password. Try losing your bank password, and resetting it. Big pain. Probably involves snail-mail or a visit to the branch.
American Express is so secure that I just stopped using their site. I won't sign up for e-billing because it's much easier to mail a check in response to a paper bill. (Actually, I hate paper mail and writing checks, too. So what I really did is just stop using my American Express card. I only work with them on the corporate side, where I've got an accounting department they can annoy.)
I'm glad my bank won't email my password. However, I'm also glad all the other sites will. Because I don't keep anything terribly important at most of them, and value the convenience and simplicity that lets me come back months later and have the site "just work," even if I forgot my password.
When asking why beginning with Logos 4 a local backup and restore function was not included in the platform design I was thinking only of the ability to backup the license and to restore my libraries exclusive of user-generated data.
I think in terms of export/import, or archive, with regard to user-generated data - notes, highlighting, collections, etc. With other software in several cases I routinely both export/import and synch the same user-generated data without complications and appreciate this required considerable effort to code well.
Yes, your data is your data. And so we are working on better copy, export, and print features.
When asking why beginning with Logos 4 a local backup and restore function was not included in the platform design
Which works easily if and only if you have Logos installed on only one device. Otherwise when you do a reinstall from backup the questions of your intent regarding changes made after that point becomes very ambiguous. Do you want all your installations rolled back to you reinstall point? Do you want you reinstall rolled forwards negating the need for you own backup? Do you want all installations frozen while you reload or do you want want you are doing on another platform .... you get the idea.
When it comes to disaster recovery (my main/only reason to be wanting a backup function), these questions are less relevant. I'd just take whatever data can be restored.
They are more important to you than you realize because of the potential for corrupted databases ... and I, for one, have had more than enough experience with Logos and corrupted indices. [:(]
Hi there, i have a few questions about Crashplan. My reason is because i don't have a large internet cap so if anything goes wrong i battle to get Logos up and running again.
1 Can i use Crashplan to backup to an external hard disk?
2 Do the license file get backed up automaticly when backing up the folder where logos is stored in?
3 If something goes wrong, must i install Logos first and then restore the backup?
Greetings
Yes (and it's free to use in this scenario).
No, but you will need to backup a registry key: HKCU\SOFTWARE\Logos4
Can you explain how to backup that hkcu\software\logos4 please? Do i also backup it with Crashplan?
Thanks for helping. This is the last time that i had to download about 8 gb of Logos.
