how to troubleshoot backup not working

[rd836]

In the older v.1.7.9 beta 9 test.2 the saving with 9 levels of backups took so much time I had the autosave turned off, and saved manually from time to time, then used old DOS type batch files to copy those files with modified names to my own folder in appdata\roaming.

I only recently found this very new v1.9.5.2, and put it in the same C:\Utilities\KeyNote folder, after renaming the older one to KeyNote-OLD, like I do with all the Github "installs" from unzipping archive files.

Edit: I have my Keynote folder for the actual Keynote NF files in Windows "Documents" structure.

Then, I starting customizing it to be like the old one. In v1.9.5.2 I set the backup folder to something similar down in appdata\roaming\ as a "separate directory" and have all the backup options checked. I.e., at regular intervals, backup original file when saving, the full 9 backup levels, to see how the speed would compare with the older.

But while Keynote NF makes the "*_BAK_Day.knt.TXT" type files for "before any modification" in the appdata\roaming\ folder, it makes very few backups of any sort. I will get the occasional "BAK_Day", "BAK@W1", "BAK@2024_11" and "BAK@2024_10" backups, there is never any current backup of the current file, and none of the 1 - 9 named files.

Edit: I did have one "knt.bak2" a few weeks ago.

The backups don't work like the manual suggests.

Where would I begin looking to troubleshoot this?

At this point, simply having Task Scheduler do a once a day copy of the main Keynote file to a different appdata\roaming folder, with a modified name, like I used to do, would be more effective.

Otherwise, all the functionality that I had with the older version is there.

Edit: My idea was to turn on all the backing up it could do natively, then see if/how to back off of the too many files, to see what I should then copy over to a more permanent storage in my own backup folder, that KeyNote doesn't know about. But every time I look at the back ups that Keynote makes, it is always "behind".

Edit: I also have the Keynote files, Auto save, for every 720 minutes.

[dpradov]

Hello @rd836

I only recently found this very new v1.9.5.2, and put it in the same C:\Utilities\KeyNote folder, after renaming the older one to KeyNote-OLD, like I do with all the Github "installs" from unzipping archive files.

I recommend that you install v1.9.5.2 from the installer and not just by unzipping the zip. At least in this first version after an old one like 1.7.9, which will ensure that the necessary permissions are assigned, for example. Using the installer will also make it easier for you to upgrade to another version.

the saving with 9 levels of backups took so much time

Since v.1.7.9 beta 9 test.2 there have been many changes. Among them the new image management. In many cases the use of images has caused the files to grow enormously and with it also the time needed to save. If you haven't done so yet, I recommend you take a look at the "Image management in KeyNote NF" section in the help (F1).

But while Keynote NF makes the "*_BAK_Day.knt.TXT" type files for "before any modification" in the appdata\roaming\ folder, it makes very few backups of any sort.

I don't understand, because the backup files, both those created by the 'Backup at regular intervals' function and those created according to "Backup original file when saving changes", must be saved in the folder indicated in the options, according to 'Original file's directory' or in the one indicated in 'Seprate directory'. Do you have appdata\roaming\ indicated as the backup folder?

[rd836]

I have "Auto save" on:

And all the "Backup options" on:

But my main file:

never seems to be currently backed up:

The backups always seem to be "behind" the actual file. E.g., 3:30 pm vs. 8:08 pm.

My concern is if the computer gets locked up where I need Ctrl-Alt-Del to recover, or if there is a power outage lasting longer than my UPS can keep it going, the current file might get corrupted, and I'd have no current backup to recover from.

It seems that the program is working as intended, but I'll need to have a Task Scheduler batch file to make daily copies to another directory as a different type of safety net.

[dpradov]

The backups always seem to be "behind" the actual file. E.g., 3:30 pm vs. 8:08 pm.

It's normal. When you click Save, what happens is that the existing file on disk is renamed as .knt.bak and all the previous ones that exist are renamed cyclically (bak9 is eliminated (in your case) if it already existed, 8 becomes 9, 7 becomes 8, etc. That is, after saving you have the current situation in your .knt file, and you keep the previous versions in the .knt.bak, as well as in the @W1, .. files, in your backup folder. Seen another way, every time you save you will not have two identical copies on the hard disk of that last version. It would be very impractical. Of course you can use other additional backup mechanisms, but what you get with the backup system that KNT offers you is to protect yourself from possible errors (perhaps yours, if you delete or modify things by mistake) or corruptions in the main file, which if there are any and you have to resort to a previous copy, you would only lose the changes made to that backup. You shouldn't allow too much time between backups, although that depends on how many changes you can make in that interval, of course.

I don't see anything anomalous in the way the backup mechanism works. What I do think could give you problems is the huge size of your file (106 MB). And I don't see it as convenient at all. It seems to me that it must be taking much longer than expected to save, and I see that it must be like that because you have set a very high automatic save time, 12 hours (720 m). I don't know how you work, if you never turn off your computer and keep it suspended. But if you turn it off, and you don't work with it for more than 12 hours in a row, the application is unlikely to trigger an automatic save.

I personally have it set up in 10 minutes, and I don't have a single file that big. I have multiple files. But even if you have a single file I find it hard to understand how it can take up more than 100MB if you don't have a lot of images embedded in the old format (embedded in RTF). If you have images I recommend using an image storage mode like External + Folder, or if you want them embedded in the file, like EmbededdedKNT. You can also reduce the file size a lot by using the compressed format.

I recommend you take a look at the notes "Recommendations on when to save and how to make backup copies" and "File formats. Comments" in the help file.

Coming back to your question about the behavior of backups, I recommend that you create a small test file, set a very short automatic save time (e.g. 5 minutes or less) and save manually or let the application do it and check how the files are created. I don't see anything abnormal in the operation.

[dpradov]

On the other hand, I don't think your use of the appdata\roaming\ folder is advisable. I have consulted ChatGPT and this is what it answered in relation to it:

Saving backup files in the C:\Users\XXX\AppData\Roaming folder is not ideal and generally isn’t recommended for several reasons:

1. Purpose of the Folder: The AppData\Roaming folder is intended to store configuration files and application-specific data that syncs when a user logs in on different computers within a network (mostly in enterprise environments). It’s not designed to store personal documents or user files.

2. Accessibility and Visibility: AppData is a hidden folder, making it less accessible and visible to the average user. Since it’s hidden, it’s easy to forget that there are files stored there, which can complicate organization and data retrieval.

3. Permission and Backup Issues: Many backup programs tend to skip this folder, as it’s not considered a standard location for personal files. When files are stored outside standard locations, they might be left out of certain backup systems. Additionally, updates or system reinstallations may put files in AppData at risk of being lost or affected.

4. Storage and Space Management: The AppData folder often fills up with configuration data, application profiles, and other internal items, so its size can grow quickly. Storing personal files here could make space management more challenging, as it can be difficult to differentiate between configuration files and personal documents.

5. Risk of Data Loss During Restorations: If the user relies on system restore points or a full Windows reset, the AppData folder may be restored to a previous state or deleted entirely, potentially resulting in data loss for any backup files stored there.

Recommended Alternatives

For backup or storage purposes, it’s better to use locations such as:

• Documents (C:\Users\XXX\Documents): This is a standard location where most users store files, and it’s usually included in backup programs.
• Secondary Drives (D:, H:, etc.): Creating folders on secondary disks or external drives is often safer in case of issues with the operating system.
• Cloud Storage: Services like OneDrive or Google Drive are also excellent for backups, as they keep a copy in the cloud, making it accessible from other devices and safer against local failures.

In summary, storing backups in more accessible and secure locations, like Documents, external drives, or the cloud, is far more convenient and reliable.

[rd836]

Seen another way, every time you save you will not have two identical copies on the hard disk of that last version. It would be very impractical. Of course you can use other additional backup mechanisms,

That is one of the reasons I made my own backup mechanism back with the older KeyNote. I need backups for two reasons, for two dramatically different time scenarios.

• The first is in case of a computer crash where the currently live file might get damaged in the crash.
• The second is for months or years later, when I find that some whole segment is gone, due to some corruption in the main file, as you said.

What I do think could give you problems is the huge size of your file (106 MB). And I don't see it as convenient at all. It seems to me that it must be taking much longer than expected to save,

No. This new KeyNote 1.9.5 saves the file instantly, even with all the backup options on. The older KeyNote 1.7.9 would take forever.

But even if you have a single file I find it hard to understand how it can take up more than 100MB if you don't have a lot of images embedded in the old format (embedded in RTF).

If you have images I recommend using an image storage mode like External + Folder, or if you want them embedded in the file, like EmbededdedKNT. You can also reduce the file size a lot by using the compressed form

Yes, I am using Embededded KNT now with v1.9.5. I have only one topic that uses screenshots, and found they didn't look very good, in the older KeyNote 1.7.9.

My idea was to use all the backup options v1.9.5 has, to see when what backup would be made, with what names, to then decide how many of them I need to copy over to my own separate directory.

Coming back to your question about the behavior of backups, I recommend that you create a small test file, set a very short automatic save time (e.g. 5 minutes or less) and save manually or let the application do it and check how the files are created.

Aha – Yes, my 720 minutes is too wide, and your five (5) or ten (10) minutes would give me the "immediate" backup I need in case of a computer crash. I'll try that next.