Self-documenting backups

Ideas
#1

I often wish that I knew more about a backup file found among old sets of DVDs. I don’t want to create a destination, import a backup, and blunder through the Data just to identify the contents.

It would be helpful if a Note in a Tree could be designated as the source of exported content to a ReadMe.txt file. This file could be inserted at the top-level of the backups generated by Gramps.

If I’m about to do something foolishly risky in Gramps, I’ll often make a special backup as a recovery point. But the difference between this backup & the next can rarely be explained in the filename. A description metadata would probably work… but I always walk away during the backup and neglect that final bit of housekeeping. So popping up the Note Editor in a bottombar with that designated note during the backup options would be a nice nag.

Perhaps a Database summary report (plus the System Info from the Bug Reporting Assistant) & could be embedded too… or maybe a Book could be generated for a more expansive look at the focal data… like, a person who does better with visual learning might want to have a graphical Pedigree or Fan Chart report on the Home Person instead of a text report.

If the backup restore had a (suppressible) display of the Database Summary during the file selection in the Restore process, there’d be less guesswork during selection. And if the ReadMe was displayed as the Restore was in progress, you could use it as a Distribution Note system. Tell people the points of interest (or recent discoveries) in a Tree distributed in backup format.

#2

Right now, I can add such annotations to the archive as a post-processing step. Just generate the content & add it with 7zip.

#3

What does Gramps do when you (attempt to) import this file?

#4

The Gramps import entirely ignores the ReadMe.txt and the PDF report I’ve added.

1 Like
#5

It’s actually strange that XML in General, but also the and the packed Gramps archive doesn’t have Metadata fields where information for the file could be written…

Personally, I always add a date in ISO format and a descriptive name for any backup file, regardless of software. In addition I usually try to add them to a folder structure that also are descriptive…

Actually you can add a comment in the xml file, and just open the file with a text editor like VS Code, Atom etc.

But, Yeh, I agree, it would have been nice if there was a “Note” or Description Field that somehow was easy to read without importing the data or open the file itself in a text editor…

Make a feature request

1 Like
#6

Hadn’t considered the metadata option for XML. Good point! (I was thinking of OS level metadata.) Might be a nice supplement for knowledgeable users. Nontechnical users like something that’s less covert.

I consider ideas posted here to still be in the brainstorming phase.

Threads here get input. Feature Requests tend to be taken literally and are seen as more immutable.

My workflow is often a bit too convoluted. So I appreciate people shooting holes in my ideas. And I also transcribe ideas users posted in other forums.

There are 2 general styles of feature requests that appeal to different Developer personalities.

Some Developers like an objective without pushy specifications… they’d rather come up with their own approach. Other developers prefer a fully fleshed out feature specification … they even like mockups of a GUI.

But I rarely find any developers who enjoy prying out input through long discussion threads. Teasing out ideas is painful.

I had created Feature Request 11817 (Backup option: Add Note selection for ReadMe.txt insertion) but realized that it was underdeveloped. So the developer is being tortured too much with the discussion.

#7

I’m not a developer, so you’re not torturing me :cactus: , I’m only volunteering/helping out with triaging and checked and found your feature request, and find it very interesting :sunny:

Although the bugtracker has developer beside my name I believe that is only a permission level so I can triage.

2 Likes
#8

OK, I’ll just torture you with questions about the iconset template in the wiki then! :crazy_face:

That port from mediawiki seems to be your baby. It is great but confuses the heck out of me. (I haven’t made the leap to understanding the template design & parameter passing conventions yet. My confusion is what lead me to add internal usage documentation to a few wiki templates. I document as a method to learn the pattern of how they were coded. But I’ve only gotten to a few of the ‘include’ style template so far.)

1 Like
#9

As a developer, and as a user, I’d suggest that on every backup, Gramps invites a user to enter details of what the backup contains.

Further - It would ‘automatically’ add an entry, perhaps to a database file created for the purpose named something like ‘backup history’ to state the date and time of the backup, plus any additional information. The restore can then also reference the fixed identity file and display the ‘latest’ item which is the current content of the backup, and enquire if this is the correct one (or, under a setting, not do so)

So the use case would be something like

Decide to do a backup
Yes - start process. At commencement the system asks ‘Do you wish to add some notes about this backup in addition to date and time?’
options - no - use standard date and time only
yes - add a description or ‘use previous’

write the preferred option and backup files

at end, write another record to the file to state that backup (date, time) ended normally.

On restore
invite user to review backup history log to check that this is the backup they expect. Invite agreement

run backup, or abort.

just my first thoughts

Richard

5 Likes
#10

I’m ambivalent about the use case described. While many of the stages make sense, the thought of transiting a series of dialogs to do a process is not good. (At the very least, it would have to be like the Export Assistant… which informs the users how many hoops have to be leapt through & which hoop they are leaping.)

In some instances, a manual backup is prompted by the system beginning to show symptoms of being fragile… such as interface latencies. So you may want to plug in a thumbdrive and do a quick backup in case the box smokes. (Or the monitor failed and you’re having to do a headless backup.) Each additional step adds anxiety to the process.

Perhaps the features could be added without steps that require adding recursive dialogs?

And a ‘backup successful’ write to file should be considered thoroughly. Does this dirty the file? If so, it would cause an unnecessary backup upon exit. Naturally, there shouldn’t be a success dialog that has to be dismissed. Those modal dialogs interfere with OSes waiting for apps to complete before shutdown.

Perhaps it should be a quiet success verification? Maybe just writing it to the Session Log?

Speaking of the Session Log, maybe copying that to the non-tree (informational) part of the backup could be an option. If the automated backup was set to ‘upon exit’, the Session Log would provide a sense of what differences could be expected.

#11

I think the idea of a confirmation “Backup Successful” would be useful (for example, I use Macrium Reflect for Windows backup and this gives a “Backup Completed Succesfully in 25 mins” or similar etc) for a manual backup. When doing a manual gramps backup, all ones sees the small progress bar bottom left and it’s silent on completion (I note emyoulation’s point about a silent completion on automatic backup)

I’d rate a “Backup Successful” for manual backup notifcation more highly than writing comments/backup log, but they’re both good ideas. Perhaps the log could include: n records written, x people, y events p citations, q notes etc from database kkk on YYYYMMDD HHMMSS

1 Like
#12

My earlier post was something of a brain dump, and I’d concur about the devil’s in the detail.

Some things about backups i hold dear at the level of being ‘laws of physics’

  • All information needed is collected at the start
  • the backup will document itself, and if possible, permit restarts from waypoints in the event of failure
  • the user will always be able to determine whether the backup they started was completed normally.
  • the user will always be able to determine the content - automatically added by date and time and identifier, plus other information they may wish to add.

Nice to have are the tools to check all this - configure things like identities to added or incremented automatically / use same as last time / blah blah / log record counts, sizes, time taken, transaction counts or whatever. Number of copies to make (off-site additional copy…)

Someone mentioned record counts, and having a profile available in a log is hugely useful - the day you need it.

Richard

1 Like