Hello!
We’ve added Local Backups to the desktop app, so you can now save a copy of your Workflowy data on your own computer as OPML and JSON files. You can choose your backup folder, pick a backup time, and decide how long to keep your backups.
Backups run whilst the desktop app is open. If it’s closed at your chosen time, it’ll catch up when you next open it. You’ll find Local Backups in Settings.
Give it a try and let us know what you think!
Yes, I discovered that the other day and started using it immediately. Great new feature.
I like the local backups very much. I do wish the content was identical to a local export, as dividers in the sidebar, starred items and special nodes (Hotkeys & Inbox) fail if they have been renamed, becoming regular folders.
It’s soothing to know that if the worst happens, you’ll have a local backup.
@Phil what are the differences between the contents of
The export dialog tries to be smart and depending on the current context might e.g. expand and walk a mirror.
The Dropbox and local backups don’t need to solve the context problem, so they just slam your entire account into a file, whatever you have available in your tree at the moment, top to bottom.
If you’ve been regularly using export as a safety measure, you should switch to the local backup instead.
Good to know, thanks.
Backup retention
Choose how many days of backups to keep. Older backups are removed automatically, but may remain in the local backup folder for a while.
Is this based on date interval (i.e. any backups older than N days are removed)?
Or on number of daily backups that are present (i.e. oldest files are removed so that only N files remain)?
These are NOT necessarily the same, in particular if one manually does staggered manual pruning (as is prudent), e.g. : keep all files for past week, then weekly files for past month, then monthly files for past year.
Or if one doesn’t use the app regularly, so that not every day has a backup.
Both JSONL and OPML files are produced.
What are the use cases / kinds of data that each of these includes?
What is the meaning of the .provisional suffix in the backup folder names? I’m finally getting accustomed to it, but my initial reaction is still always that the backup is not yet complete (like .crdownload or .partial) which is unsettling.
The retention policy currently means “calendar days” but it was a mistake and we’re changing it.
The OPML format is present because this is usually what is requested when people talk about exports / backups.
The JSONL format is just JSONL - it’s normal JSON, but instead of serializing the whole array you serialize individual objects. It allows you to read the file in chunks instead of loading into RAM the entire thing.
The .provisional backup is used in case the app wasn’t running precisely at the scheduled time. E.g. if you have the backups scheduled for 6pm, but close the app at 5pm, we still want to have backup for that day. Maybe I should have used a different name, we’re open for suggestions.
I mostly use WorkFlowy’s web app. Wish I could do local backups from the web app.
Unfortunately browsers don’t allow to freely save files to your computer. There are some promising APIs that we might leverage, but they aren’t widely adopted yet and have their own limitations. We generally recommend to use to the desktop app because some upcoming capabilities are going to be available only there.
I don’t see why that should affect the naming. The time is already in the filename (and the time stamp). But if you really want to flag that explicitly, how about .delayed or .late ?
(“provisional” : “for the present time but likely to change” or “serving for the time being : temporary”)
Thanks for the format explanations.
Concerned to hear that; my use of WF is so integrated into 2-way web access. But in this case, I’ll open a new topic for hopes about making the desktop app more useful.
(“provisional” : “for the present time but likely to change” or “serving for the time being : temporary”)
Well… it is sort of the meaning: “The app has made an opportunistic backup for today. If the app still works at the scheduled time, the backup will be replaced. Otherwise this one will remain as the today’s backup”.
Concerned to hear that; my use of WF is so integrated into 2-way web access. But in this case, I’ll open a new topic for hopes about making the desktop app more useful.
Just to clarify: I do not mean that we somehow prioritize the desktop app. I mean that some planned things are technically impossible to implement in a browser (e.g. local MCP or, well, local backup the way it works now).
As a long-time fan of ‘standalone apps’ as opposed to ‘web apps’ (even within wrappers), I can totally understand having more capabilities in a standalone. Web apps are far too limited in terms of controls/widgets used, their capabilities and the sandboxing that prevents them from having the security to do important tasks (i.e. access to local hard drives). Every browser’s individual limitations only make it more difficult for coding, having to select only the common denominators amongst the browsers for use, instead of being able to take advantage of the more powerful controls and capabilities of native code. Granted, more simple webapp UIs are easier to achieve since the number of platforms needing to be addressed is simplified.
Puzzled … Surely this stands in for the already missed backup, rather than for the one whose time has not yet arrived?? If I want to back up at the end of each day, say 10 pm, but it’s not running Monday at 10 pm, so it ends up backing up Tuesday at 8 am when I open it, surely that’s my best approximation of Monday’s state, and should not be replaced by the one at EOD Tuesday?
I’m sure that you’ve considered an obvious, but more expensive to develop, approach, namely to have a lean backup process which runs on schedule (or ASAP) in the background whether the app is open or not.
It does look obvious in the specific example you provided, but once you start taking into consideration all possible scenarios, it’s not obvious at all what the user will consider obvious. If after using the feature for a while the community settles on an alternative algorithm that feels more logical, we’ll consider replacing it.
For now we opted for a straightforward algorithm: the app runs that day → you get a backup as close as possible to the scheduled time.
Our data engine is still backed into the web process, so running the backup in background would require running a hidden Electron window with the whole app started in it. We’re working on detaching it, but it will take some time.
But that’s not what you’re doing in my very normal example: 8 am is much closer to last night’s 10 pm missed schedule than to tonight’s 10 pm schedule. And widening the context – if the point is to provide a daily backup, then doing it ASAP after, and keeping it, is the closest to that, even though you would end up with two with the same calendar date. And the algorithm is just as straightforward, perhaps more so than the current one.
Maybe I should have phrased the rule more precisely: the app runs that day → you get a backup as close as possible to the scheduled time that day. We don’t try to do “as close as possible to the scheduled time, period”, it’s “that [calendar] day” specifically, according to your computer timezone.
Also, I don’t suggest that this algorithm is superior in general or to the one you’re suggesting. My message is: 1. This is the algorithm; 2. It was chosen because it was considered straightforward and reliable; 3. We’re open for a proposal of a better algorithm by the community, but only if it’s worked out well and considers potential edge-cases (which should probably happen in a dedicated topic if there’s interest at all).