Backup and restore: file size and processing time

You probably still have old database files that are also being backed up.

Check the %APPDATA%\Garmin\BaseCamp\Database folder. On my machine that is C:\Users\falagar\AppData\Roaming\Garmin\BaseCamp\Database.

You probably have subfolders like "3.2", "3.3" etc. in that folder. You can delete all but the most current folders if you would like to save space. If anything goes wrong, you can restore one of your backups and you should be where you left off.

I hope this helps.

We are also looking into cleaning up those folders automatically (only leaving the current one and the last one) and into backup being smarter about what to back up.

Hi Falagar,

Thanks for your response.
I do have those subfolders. However, the "3.0", "3.1" and "3.2" folder have a total size of 36 Mb. The current folder "3.3" has a size of 94,5 Mb. Deleting the first three folders would only solve part of the problem, I'm afraid.
What puzzles me, is that the backup file still has a size of appx. 117 Mb, regardless of how many items I delete before making the backup. In other words, what I would like to see is an option to reorganize the database so that unused space in it is released, resulting in a minimum database size (which in its turn gives shorter backup and restore times). A feature request for some future release ;) ?

So you could definitely remove the 3.0, 3.1 and 3.2 folders. Do you have any BirdsEye or Custom Maps? These are not stored in the 3.x folder, they are stored in %APPDATA%\Garmin\BaseCamp\KmlOverlays resp. So do you have any significant data in %APPDATA%\Garmin\BaseCamp, that is not in the database folder? That stuff gets zipped up as well during the backup.

What kind of data do you have? Is it all routes, waypoints and tracks (and no geotagged photos, custom maps or birdseye)?

If so, you could export (not backup) your data, close BaseCamp, delete all of BaseCamp's data (blow away the %APPDATA%\Garmin\BaseCamp) folder, and re-import it. You would lose all list and folder information, but would end up with as little data as possible.

So I decided to spread the tracks over several files, one per country. To achieve this I deleted the tracks of all countries except one, created a backup (say Country_1.backup), restored the original backup file (with all countries), repeated the process for country_2, and so on.

What surprises me, is that each backup file still has a size of about 100 Mb, regardless of the number of tracks in it. Even if I delete every item (waypoint, track, route, etc.) I am stuck with a backup file of 100 Mb.

Forgive me in advance for asking an obvious question which you may take as insulting, I am not a highly experienced BC user myself. But let's say you have deleted all but what is for one country (which then still creates a 100 Mb backup file). If you select "My Collection", does the data window in fact show only the data for that country, or does it perchance still show all the data you thought you deleted?

If you have no Custom Maps, BirdsEye or geotagged photos there are two things that could make your database folder bigger than necessary:

1. The backup files. AllData.gdb and FolderData.gfi get backed up automatically. AllData.gdb.bak and FolderData.gfi.bak hold these backups. These probably shouldn't be part of the user backup, we'll look into that. The backup files might be a reason why your manual backup file doesn't get noticeably smaller immediately after you delete (because the bak files still contain your old data).
2. There might be some issue in that we write too many track segment files. We will fix that in 4.0.1. This could be fixed by exporting the data, blasting the database, and re-importing. But this is of course prohibitive if you have an elaborate folder/list structure.

Once we address these issues, reorganizing should not be necessary. We are already rewriting the actual database file (AllData.gdb) and folder/list file (FolderData.gfi) every time we save.

I hope this made sense.

Thanks, from various forums (fora?) it seems that for many, especially those of us coming from MapSource, it is not intuitive that the delete key does not delete, you must shift-del.

One other thought, perhaps from left field... It seems that if you fully delete an item in BC, and you have not yet closed and re-opened BC, you can undo the delete with the undo command. So the deleted data is still in the database somehow though not shown, or perhaps in some hidden "session data" file. If you were to do a backup at that point, perhaps all the stuff you deleted is still included in the backup in some "still could be undone" category? Whereas if you close BC and then re-open it, undo is no longer possible, so presumably the act of closing it really got rid of that data? So is the backup smaller if you don't create it until you close/reopen after deleting a large proportion of data?

Seems the backup file should not include any "undo-able" data, but just wondering...

Falagar,

FYI, I've checked the size of individual files and folders in my version 3.3 database folder:

AllData.gdb and AllData.gdb.bak both have a size of 2.118 Kb.
FolderData.gfi and FolderData.gfi.back have a size of 75 Kb each.

The subfolder GeocacheLogs as a size of 0 bytes and is empty (which makes sence to me).
The subfolder TrackSegments contains 7.962 individual files which add up to a total of 40,1 Mb disk space (data size is 20,9 Mb). Individual file sizes in this folder are in general less than 10 Kb; most files are not bigger than 2 Kb.
The subfolder Thumbnails has 2.471 files with a total disk space of 80,4 Mb (data size 75,5 Mb). Individual file sizes are mostly between 30 Kb and 40 Kb.

The backup file essentially is a zip file renamed with another extension (.backup). It is a known fact that zipping and unzipping a large number of small files (as is the case in the BaseCamp.Backup) takes much more time than zipping or unzipping the same amount of data stored in just a few larger files.

My original problem (splitting the data into several 'country files') isn't the backup size itself (plenty of disk space available) but the time it takes to backup and restore. I now understand the reason why (at least part of it) and leave it to you to think of some solution (if at all possible).

For the time being I restored my original backup file containing all countries so that I don't have to switch files.

Hello Falagar,

I've been working with the 'large' database since my previous post (a month ago).
But now my backup file has grown very large. And I mean really, really huge, this time. Its size is now 1,7 Gb (yes, 1,7 Gigabyte). The number of tracks and routes hasn´t changed significantly during the past month. What I have been doing, however, is geotagging about 900 photos from my holiday. But after that, I have deleted the pictures from Basecamp. Somehow, I guess, the database space used for storing the photos is not released when the photos are deleted.

For the time being, this is not yet a problem for me but I think it is an issue that needs to be adressed in a future release-patch of BC. Just my 2 cents .

If you delete photos in BaseCamp, they should get deleted. There seems to be an issue, I'll take a look.

To bring down the size of the backup, you can delete all folders but the 4.0 folder in %APPDATA%\Garmin\BaseCamp\Database\ (C:\Users\{username}\AppData\Roaming\Garmin\BaseCamp\Database). Make sure you have a backup in case something goes wrong, of course.

Also, check the C:\Users\{username}\AppData\Roaming\Garmin\BaseCamp\GeotaggedPhotos folder. Do you have a lot of photos in there that are not present in BaseCamp? If so, you can delete those as well.