* Backup not responding

[Keithj]

I'm having a variant of the problem reported in this topic.

When I click "Backup" at the end of a session, there is an almost immediate "Adding files to backup", with reference to File 1 of N.
Very soon after that comes the "Not responding" label on the backup window. There it sits for a while. It may "crash out" - just close that window without completing the backup. Sometimes, "Not responding" disappears and the file number starts to increment. It may stop a few times more and display "Not responding" again, before eventually completing the backup. If it restarts once, thus far it has always completed the backup (eventually).

Whether I run the "Full" or the "Min" backup, the zip file is within a few percent of the same size - around 620MB.

The working GED file is just over 8MB; the cache file is just over 400MB; the media folder has 1367 items totalling 165MB; the plugin folder has 6 items totalling 328kB. That totals 573MB - less than the backup zip file size, which seems odd.

For the moment, to ensure nothing gets lost, I've written a batch file that I run after finishing a session with FH6. It takes under ten seconds to back up (much faster than FH6) and produces a backup with everything present that is smaller than FH6's own backup (it's exactly the same size as the source files).

The batch file is one line -

robocopy D:\FamilyHistorian6\Family~1\ A:\FHBU%date:~6,4%%date:~3,2%%date:~0,2%\ *.* /s /r:0 /COPY:DAT /xj /A-:SH /MT

Some of the switches in that are probably not needed for FH6, but it's a standard format that I use elsewhere, it's fast, and it works.

[tatewise]

Hi Keith.
I presume when you say "Full" or "Min" backup you mean "Full" or "Medium" backup?
The difference is that "Full" includes everything in your D:\FamilyHistorian6\Family folder including the Public folder, whereas "Medium" excludes the Public folder.

The pauses are probably caused by very large files being compressed/zipped.

However, that does not explain why the robocopy backup (uncompressed) size is smaller than the FH compressed zipped backup.

The way to check the size of the full D:\FamilyHistorian6\Family folder is to right-click it and check its Properties.

BTW: The FH Backup is only intended to thwart accidental deletions/mistakes in the FH database.
It is NOT a substitute for full backups of MyDocuments, etc, to protect against PC/Disk crash, and worst disasters.
See glossary:backup_and_recovery|> Backup and Recovery.

I suspect it needs investigation by Calico Pie for further analysis.

[Keithj]

Indeed, Mike, the size information is from right-clicking "A:\FH6Backup\FH Project Backup (min) - Jillings 2015 - 2015-07-18 1210.zip" which shows as 601,665 KB.

The contents of that Zip should be virtually the same as the contents of my robocopy backup at "A:\FHBU20150723" which is 591,967 KB. I've added maybe a dozen media files and a half dozen names since 2015-07-18 1210. The Public folder isn't included in either. I've not unzipped it to see if there are any glitches to explain the size difference.

Out of curiosity, I ran WinZip and zipped FHBU20150723. It took just under a minute to Zip, and ended up at 567,775 KB. Since I'm not short of backup drives or space, I wouldn't normally bother to zip something for that small a saving.

"FH Gedcom Backup", "FH Project Backup (min)" and "FH Project Backup" (plus project name, date and time) are, as far as I know, the default names for the three optional backup types - unless it asked me to suggest names when I was installing it. I don't remember it doing that.

Because I tend to do a lot of work on family history on the days I do it, I back up each time. There's nothing worse than a crash that loses a day's work (which is what drove me away from FTM). With the robocopy routine, it's a double-click on the icon next to FH6 on the desktop.

Separately, the PC does a complete (automated) data backup weekly, alternating round a set of five external drives. That's the primary use of the robocopy command. I don't like backups that resort to Cabfiles or Zipfiles, because it can take a very long time to find and recover the specific item when it's needed (been there, had the problem). Similarly, I don't like incremental backups because of the tendency of some routines to overwrite the good file with the new corrupt one. I keep old backups on a "cycle" so anything newer than two years old is highly likely to be available. I can find any file I want within a few seconds if it's in the most recent backup.

In summary: I'm not bothered with the size of the backup file (although the "cache" file size still amazes me, and I wonder if it needs to be backed up anyway). My concern is that the backup routine crashes more often than it works. That may be something on my PC - the data files are on drive D and the FH backup is to drive A - but that isn't likely to be unique and I wouldn't expect a backup routine to care which drive letters are used.

As you say, one for Calico Pie. I have a workaround which works for me.

[tatewise]

Yes, the FH Backup names are a bit inconsistent:
Full creates FH Project Backup files.
Medium creates FH Project Backup (min) files.
Small creates FH Gedcom Backup files.

I agree that the cache file should be omitted (try deleting it before FH Backup to see if that helps).

Your backups sound better than most, but have you considered the risk of major power glitch, flood, fire, etc, that affects all your equipment?

Please report the symptoms to Calico Pie.

[Keithj]

I think the fire, flood, etc risks are pretty well catered for. Even the burglary one is covered!

I'll report to Calico Pie.