Denis L

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.
 

On 10/27/2023 at 12:08 PM, dbvirago said:

Denis, every time I do a manual export it works fine. Every time I try to run it on a schedule, I get some variation of below soon after it starts. Same external SSD drive used in both cases. 

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:

 

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.

4 hours ago, Denis L said:

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.

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.

On 10/22/2023 at 9:31 PM, dbvirago said:

Okay, then I'll definitely restrict it to enex or html. I assume that will make it faster? It took about 75 hours the first time.  I'll may drop down to twice or once monthly. That's a lot of recourses to tie up for 3 days+ every week. 

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.

On 10/22/2023 at 9:31 PM, dbvirago said:

Please let us know when you have incremental backups. 

Absolutely, I'll post here when the incremental backups will be available.

On 10/22/2023 at 9:31 PM, dbvirago said:

Edit: It also occurs to me to uncheck archival notebooks. Would those be left alone on my backup drive if a future backup excludes them?

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!

On 10/20/2023 at 7:36 PM, dbvirago said:

I've had the product for a few weeks, but haven't had time to complete a full backup. With 13K notes, I am currently at 30 hours and counting. Part of that is the frequent Quota Reached stalls. I am assuming on subsequent backups only changed notes or notebooks are backed up? 

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.

On 10/20/2023 at 9:41 PM, MvdH said:

Question for @Denis L   I have 15k notes and 40k in trash. I am very happy with backuppery. Great value for money for me. Making backups takes way too long due to the API call limits Evernote applies. Would not want incremental ones, but would like caching the DB so the API limits kick in less often. The full Backup could the be drawn from cache DB and API calls for changes. Do love the Backuppery automatic keeping multiple backups and deleting old ones. The question, do my 40k notes in trash also get backed up? Not necessary, but would be nice. 

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!

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.

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

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.

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.

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.

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.

14 hours ago, idoc said:

Thanks Denis.  Actually, Backupery completed doing its download. <...>

Hi Idoc!

20 hours ago, idoc said:

So after following several threads here regarding how to backup EN v10 (windows) I decided to try Backupery.  I elected the trial "limited" version so I could see what it could do. <...>

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!

On 6/12/2023 at 11:33 AM, MvdH said:

@Denis L a question about the "Evernote usage has been temporarily exceeded. Your data will be received in 37 minutes." message, to which you maybe have a quick answer. If Backupery exceeded the limit and is put on hold by Evernote, will my Windows clients also be on hold that same time, or can I work with that client on a seperate quota?

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

5 hours ago, MvdH said:

Thx for your statistics! For you, the incremental backups @Denis L was talking about would really help. 👍

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.

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!

21 hours ago, gazumped said:

I noted the "yet"...  Is it still possible that you will in the future?  Not asking for details or a date,  just interested!

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. 

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!

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).

On 6/18/2019 at 9:15 PM, RMorgan said:

Enex files are now split when exporting when they reach a certain size.  This is to help with export files being so large that they can not be properly imported due to memory restrictions.  By default the enex files are split around 2 GB.  When the export dialog pops up, it will give an estimated size of the exported data in the title bar.  The estimate is for the raw data size and the final size will be slightly larger due to the enex file format.

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.

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/

On 5/11/2018 at 10:41 PM, CalS said:

Feel free to DM if you have any other questions.  I am going to hold off on doing anything pending the fixing of the import issue.  I have to create multiple exports per big notebook in the meantime.  Good luck.

20 hours ago, gazumped said:

Me too with the DM

Thanks for your assistance! 

20 hours ago, gazumped said:

Resetting to a week ago,  we're back to normal - but after a solid 30 minutes of other issues,  I now have to wait until Backupery completes another backup or kill the processes in Taskmanager.  The app is showing the next backup as 'yesterday' so I guess it was affected by the system restore;  it kicked off a backup as soon as the OS loaded up.

Got it. Will fix that for the next release.

20 hours ago, gazumped said:

On another subject:  I was intrigued by one post that seems relevant here...  This fix originally from @Austin G has been rolled out a few times with (apparently) excellent results,  and seems to get totally around the drawback of simply copying the whole Evernote database (in Windows, anyway). 

19 hours ago, CalS said:

Plus, if for whatever reason, you want ENEX's of your current data base you can do it in one fell swoop by simply logging out and following the process.  For example, I 7-zip (compress and encrypt) my local ENEX's and store the result in the cloud so as to have off site back up.  Definitely a quicker way of doing getting the ENEX's even if I toss the synced ENEX's. 

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.

23 hours ago, CalS said:

What does "glue" mean in this context?  Potentially multiple versions of the same note in the resultant imported notebook?  Without access to a note ID (I don't think it is in the ENEX export) I'm not sure how you put a notebook back together cumulatively.   Plus I don't think deletes can be managed with incremental backups.  So incremental backups may not work well for creating the status of the notebook as of date x.  Full backups would be needed.

Otherwise stitching together base plus incremental backups for selective note recovery (oopses in my case) would be fine.  Also like the purge after x versions concept.

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.  

17 hours ago, gazumped said:

Back to practical considerations - in light of the above I switched back to full backups,  so now have several folders with a 'grandfather' notebook ENEX file,  several partial backups files,  and (now) another 'father' backup.  Unfortunately the backup hit while I was working earlier,  so my system disk resources were maxed out by Backupery activity.  It was not a happy time.  There's no clock on the backups either,  so unless I start a new backup at a different time,  I can look forward to the same problem every day from now. 

Obviously my last act today will be to start a new backup series at a new folder location,  using a date or number identifier for the backup destination that I can change easily.  But the app really really needs a 'pause' or 'delay' button so that backups don't slow the system down at a busy time,  and(or) a clock so I can set a time for the backup process to start. 

Automatic purging of older files would also be good so I can set a (maybe) one-week limit to the number of files I'll collect - and it would be really good if the folders containing notebook backups could be grouped below a parent level for that single backup;  so you'd have Monday/notebook1,  /notebook2,  /notebook3 etc,  then Tuesday/n1, /n2 etc.  If I ever want to restore my whole database or move it across to another device,  each set of notebook files will be easier to identify and use.

With my big database and a total for all files of around 20GB per backup,  a week's worth of activity will use 150GB which is about as much 'spare' disk space as I want to afford!  (Though I might be tempted to save a separate set of backups once each month so I can reach back 6 months if I need to...?)

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!

Thank you very much for your comments!

On 5/8/2018 at 2:00 PM, gazumped said:

There's currently no way to manage that - if you have a lot of notebooks that means visiting each. mortal. one. to tidy up the file structure - or (my favourite) changing the backup destination to start another folder tree.  I've already suggested that Backupery should include some backup management options,  like overwriting the oldest files after an optional number (3+) complete backups,  otherwise storage space is rapidly going to fill up.  Limiting file size just makes that process more complicated.

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. 

22 hours ago, CalS said:

Does the tool do a consolidated import based on the incremental backups, or do you roll your own?

Musing as I typed this, I guess to get some automation I could turn my main notebook into a stack of notebooks by year or something, simulate what I do today.  Really, really don’t want to do that, import needs to get fixed.

21 hours ago, gazumped said:

@Backupery do I have this part right? -

It appears that importing the initial full backup will restore a copy of all notes at a given date,  with the later imported incremental files amending some of that,  plus any previous incremental imports that were 'restored' already.  But AFAIK those imports will go into different temporary notebooks during the import process so you'll have multiple conflicting copies of some notes,  and duplicates of others (???) - a major mess to sort out to ensure you have the latest copy of all notes!!  I could have that wrong,  but it looks like a major issue. 

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.

On 5/6/2018 at 1:19 PM, gazumped said:

My bad - poor explanation on my part.  With the previous incomplete copy of big database backup problems I was running the app set for a full backup to ENEX to check the size of the finished backups.  With a 19.4GB database,  I was getting a range of sizes of total ENEX files from 4GB up to 19GB - most clearly not a full backup of the database,  just partial copies.  I eventually gave up on it,  since I didn't feel I could rely on it.  I started again and the total ENEX files for the latest backup are around 23GB from the same size database...  I'll wait for the next run to see what happens!

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. 

On 5/5/2018 at 7:44 PM, DTLow said:

I hit this once (.enex import issue) and it soured me on enex backups.  
It was a Mac and approx 5000 notes.

Packing all your data into a single file; what could possibly go wrong.
I've switched to html export with separate files for each note.

To recover local notebooks, I rely on a full database restore from my TimeMachine backups.

 

On 5/5/2018 at 10:46 PM, CalS said:

Windows platform.  In the neighborhood of 17k notes about 10GB file size when I first encountered the issue, September of last year.  The notebook has grown since then so splitting 19k notes into two notebooks.

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?