Jump to content

Denis L

Level 2
  • Posts

    68
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Denis L

  1. Yes, after careful consideration we decided to refocus our efforts on other applications. Not so many people are using Backupery for Evernote and being a small team we simply can't afford to continue developing the application. It was a tough decision, because a lot of effort has been put into the application during these years. We will still make fixes and improvements though, at least for a year. Thanks so much for using the application and providing great feedback! As I noted, we'll continue to support the app and deliver bug fixes for a year. Please let me know if you have any questions, I'd be happy to answer them.
  2. Thank you for reporting the issue and I'm sorry for the trouble! May I ask you to send me the error log file so I could analyze it and find out what the problem is? If yes, then go to the Help tab in the app and press the "Open Log Directory" link. Just DM me the file BackuperyForEvernote.exe_WarningsAndErrors.log. Alternatively, you may want to try the following workaround: Create two backup destinations: A folder on your local drive ("C:\Backup", for example). You external USB drive destination. Please note, your local directory should be first in the list: So the app will work with the first directory during the export and just copy the results to the second directory when the export is complete. Hope this helps. Please let me know how it goes.
  3. My tests show that data download step takes about 80-90% of the backup time, so yes, I'm confirming that at this moment disabling ENEX or HTML conversion should not change the backup time significantly.
  4. I'm pretty sure that the download process takes most of the time and restricting just to ENEX or HTML won't make it significantly faster. I'll check my statistics and report back though. Absolutely, I'll post here when the incremental backups will be available. Yes, they be left alone on your backup drive if your future backup exludes them. You may also consider increasing the number of backups to keep on your backup destination: If the number of backups reaches the limit, the obsolete backups are removed to save the destination space. Please let me know if you have any questions, I'd be happy to help!
  5. Thank you for using our app! There are two main reasons why the backups may be slow at this time: Evernote API rate limits. Evernote protects their servers from overload so they put some limits on the usage. That means that third-party apps need to do some pauses from time to time in order not to exceed the number of requests per hour. That is why the app has to just wait from time to time in order to continue downloading the data again. A bit more information about rate limits is here: https://dev.evernote.com/doc/articles/rate_limits.php Full Backups. At the moment of writing the application does full backups each time. It means that it downloads all the notebooks and notes on each scheduled backup. Of course, if the database is pretty large, it is time-consuming. To overcome both issues, we’re planning to add delta backups functionality, so the first backup only will be full and all the subsequent ones will contain changes only. In this case it would hopefully work faster as it will download significantly less data. Thank you for the hint. We’ll definitely consider implementing some caching mechanism as well! Notes that are in the trash are omitted by default at this moment and they are not downloaded. I think we should add an ability to back up them as well though. I’ve just put the task on our roadmap!
  6. idoc, thanks so much for confirming that! Also, we've found the reason why the user interface hung during the export. It was a bug in the app that made the user interface unusable during large resource processing under some circumstances. We've fixed that in the v. 2135 (and higher), so everybody welcome to update! To update, just download the new version here and install it over your current installation - your settings will be preserved. Actually updating is optional as the app will automatically update as needed by default.
  7. Idoc, I've just figured out a way to check if those notes were imported automatically by Evernote, so may I ask you to check it? If yes, then Just export the note to ENEX format using your Evernote client (even if the note is in Trash it is still possible to export it): Open the exported ENEX file using any text editor, Notepad, for example. Search for the "<source>" line: If the source is "import.folder" then the note was created by Evernote client automatically using the import folder, otherwise it was created in some other way. Please let me know if you have any questions.
  8. Hi Idoc, just a quick question - is it possible that your Evernote is configured in such a way that it automatically imports data from the backup destination directory to your Inbox notebook? Something like on the screenshot below: If yes, then it can explain how the exported files could have ended up in your Inbox notebook.
  9. Hi idoc, thank you for clarification. It is definitely not expected behavior as the application is never supposed to create/modify any Evernote data. I'm currenlty trying to figure out any idea on how this could happen. I'll keep this thread updated.
  10. Hi idoc, thank you for the info and I'm sorry for the late reply. Just to make sure I understand the issue correctly - you exported your Evernote notebooks using the tool and then imported the ENEX files into some other account, right? If yes, then I got your point - those empty notes are really confusing. Perhaps we shouldn't add them into ENEX files at all and leave the fully exported notes only. We'll definitely consider adding this into the next version of the app.
  11. Thank you for your reply and glad to hear it completed the export! Yes, at this moment the trial application exports 10 the most recent notes from each notebook. That's why your final download was much smaller than your entire database. We definitely should improve the wording though, so thanks for the hint. I'm not sure why the app was hanging though, so I'll try to reproduce the problem in my lab and try to see what could be causing the problem.
  12. Hi Idoc! Backupery developer is here. Thank you for trying the app and I'm really sorry for the issues! The idea behind the app is that it should provide an easy way to regularly export Evernote data without the need to manually export each notebook using Evernote client. It looks like something gone wrong during the export process, so could you please send me the application log file so I could analyze it and find out what the problem is? If yes, then go to the Help tab in the app and press the "Open Log Directory" link. Just PM me the files here or email to contact@backupery.com, please. Please let me know if you have any questions, I'd be happy to help!
  13. Rate limits are applied per application. So if you have Backupery app limited, your Evernote app should work as expected without any limitations. All other applications and services will also have access. In other words, each Evernote app has its own quota so they shouldn't interfere with each other. There is also an article from Evernote explaining rate limits in more details: https://dev.evernote.com/doc/articles/rate_limits.php
  14. Absolutely. Having the incremental backup feature will make all the following backups going much faster. I don't have estimations at this moment, but I'll definitely post here if when we add this feature.
  15. Hello! Backupery for Evernote developer is here. Thank you for trying our app and for your feedback! The new application has been released recently and now it does not require Evernote installed and support all Evernote versions (previously it used to rely on the Evernote scripting feature so it required to Evernote Legacy installed on the same machine). Now it connects directly to Evernote and downloads all the selected notebooks. It can also generate HTML exports if necessary. Please let me explain why the app may work not so fast as expected. The issue is that third-party apps should honor Evernote API rate limits. In other words, Evernote reasonably protects their servers from overload so they put some limits on the API usage. So the application has to do some pauses between requests to Evernote in order not to exceed the number of requests per hour. That is why you can see the "Evernote usage has been temporarily exceeded. Your data will be received in xx minutes" message from time to time. We'll continue working on decreasing the number of API requests to make the export faster. Also, perhaps I should note that API rate limits are counted for each separate app. So even if Evernote usage is exceeded for Backupery app, your other Evernote apps continue working as expected without reaching the rate limits. Please also note that the export process is supposed to survive the app or machine restart so you should not worry about interrupting your export process - the app will try to start the download process from the point where it was left off. Also, at this moment the application makes full backups only. That means that on each backup it will download all the selected notebooks. We're working on the incremental backups feature so the app will download the changes only, though I don't have any estimations at this moment. Please let me know if you have any questions or feedback. Any input is highly appreciated!
  16. I hope the Evernote team will enable scripting functionality sometime in the future, though I don't have any details. I'll keep this thread updated if I get any. Also, I'm currently researching a way to access the data by connecting directly to the Evernote Cloud API that is currently the recommended method of third-party interaction. In that case we won't need to rely on installed application or the internal database. It may be a big effort though as it will require significant reworking of the application.
  17. Backupery for Evernote users, please note, our app does not support Evernote 10 and above yet. To continue using Backupery for Evernote, please use Evernote 6.25.1 and under. We're sorry for the inconvenience!
  18. Denis from Backupery is here just to confirm that the latest changes in Evernote doesn't affect current workflow of the Backupery app. As already mentioned by Jefito and other members it seems the enex splitting option doesn't affect ENScript export now (Backupery for Evernote uses ENScript internally to make backups).
  19. May I ask if ENScript.exe on Windows also splits enex files? We've made several tests and didn't find any difference in behavior compared to the previous version of ENScript.
  20. Hello, New release of Backupery for Evernote is here. What's new: Backup retention policy (allows to set how many backup snapshots the app keeps on a backup destination) Ability to set time of a day when backup is scheduled Manual backup mode. It allows to perform backups manually when needed without being tied to a specific backup schedule Ability to cancel running backup Added support for official Evernote client installed from Microsoft Store (applicable for Windows edition) Works similar for Windows and Mac Lots of bugs were fixed More features coming soon! Download it here: https://www.backupery.com/products/backupery-for-evernote/ Windows app: Mac app: Here is a bit more info with screenshots: https://www.backupery.com/backupery-for-evernote-9-is-available/
  21. Thanks for your assistance! Got it. Will fix that for the next release. It looks interesting! I didn't know about this feature of Evernote client. Saving single EXB file looks much more simple than exporting a whole account to ENEX. It's something I should research thoroughly. Thanks for pointing me to this direction.
  22. Yes, you are right, there is no note ID information inside the ENEX export. What I'm thinking about is to read database in order to find ID of the exported note. It seems we have enough information in ENEX file at the export time to find out the ID of the note. Then we should store it somewhere just to be able to track the changes further. Basically it's a theoretical idea so I'll do some research. Thanks so much for the feedback. I've reviewed it carefully and took much of it into consideration. Actually the feedback is so essential since it is based on what a real user feel is important, which often can be very different from what I think is important ? Hope many of the requirements will be available in the next version of the app, so I'll keep this thread updated!
  23. Thank you very much for your comments! We're currently working on the retention policy feature, hope it will be available soon. Basically it will work the following way - a user sets the maximum number of backup sets that the tool should retain so the obsolete backup files are deleted automatically. You are absolutely right. Currently the tool doesn't provide an import option so users have to roll their own import routine based on Full or Incremental backup types. If we are talking about full backups the import process basically looks clear, except the possible large file import issue. Though I hope it can be solved by splitting a large ENEX file into small safe files. If we are talking about incremental backups it might be not an easy task to restore the data to the desired state (the issues described above by Gazumped take place). So yes, we definitely should improve the restoration for incremental backups. I'm currently thinking about the following option: what if when a user requests restoration from incremental backups the tool would automatically glue the first full backup with the following incremental backups? So if a user requests restoration to some date in the past then the tool produces a single ENEX file that contains the full backup to the desired date. Well, as we already noted, importing a full backup looks easier than importing incremental backups. I'll investigate this option.
  24. Thanks for the explanation. Yes, it was a problem with ENScript.exe tool on Windows that led to sporadic hang of the export process for large notebooks. I hope the issue is gone now but I'm still observing export logs in my test lab just to be informed if the problem occurs again.
  25. Thanks for the information. Yes, probably a very large file is the reason of the problem so the system just can't handle it correctly and import fails. I've just thought that since an ENEX file is basically an XML file so it can be broken up into small parts (other ENEX files) automatically during export process. In this case restoration would be a little more complicated (we would need to import several ENEX files instead of large one), but I think it's worth the efforts. What do you think on this?
×
×
  • Create New...