Discussion about backups and alternate databases

[Peobody]

In a discussion on the 590/595 forum, reference was made to routinely saving routes to the hard drive which then led to the mention of the backup and alternate database functions in Basecamp. This got me to wondering how forum members use these functions. I currently do the following:

• Exports of routes to the hard drive are for sharing the route by email and for copying the route to the SD card so that it has a meaningful filename.

• Backups are for the purpose of recovering from database corruption.

• The alternate database function is something that I am aware of but have not used.

What are you doing?

Is it logical/possible to do an annual backup followed by a selective cleaning of the current database, and then restore those archival backups to alternate databases for easy reference?

Edit: I just read the section of Johns' pdf document "Zumo 590, 595 & Basecamp V43 ZumoUserForums". This makes me think that creating a new database and then restoring a backup to it is feasible. One piece that is unclear is a reference made about storing the routes associated with different tours in their own databases. I don't see a method by which routes can be copied between databases so I am thinking that this requires forethought, creating the new database before starting to create the routes.

[rbentnail]

I use the List Folder/List structure in Base Camp, exporting files only when I want to share them, and after sharing I often delete the exported file. I won't need it for anything. I simply give each one a meaningful file name to begin with, right there is BC. It's good enough for me as it seems I am not as picky as to file and point names as others seem to be and I honestly don't get all the hoop jumping but to each his/her/its own. I see no need for me to create an archival database or whatever just to have duplicates I'm never going to use. From BC, I drag and drop the file(s) to my XT's SD card, no need for more data manipulation than that. Simple, straightforward, functional.

Long, long ago I created a folder in Documents called Base Camp Backups. Every once in a while I backup BC to there and delete the old backup file. About once per month I backup my computer to an external drive.

To answer "Is it logical/possible to do an annual backup followed by a selective cleaning of the current database, and then restore those archival backups to alternate databases for easy reference?" To me, no. It is not logical. To me BC IS a reasonable database for easy reference. Why create another "for easy reference" when what is needed is already right at my fingertips?

[lkraus]

I use a single Basecamp database. It is stored on two of my computers and in the "Cloud", which keeps the database on both computers in sync. Both computers are backed up regularly to a 4TB hard drive attached to our router. I use Macrium Reflect, one of many programs that will make scheduled incremental image backups of my drives. The software makes a backup of everything on a drive and then subsequent backups of only the changes since the previous backup. The desktop PC is automatically backed up every day, the less-used travel laptop is backed up once a week or as soon as it is turned on after a longer period of disuse.

I have never had a database (or other user data) corrupted or lost, but I have had viruses or faulty "upgrades" make my entire system unusable without a complete wipe and reinstall of Windows and all the programs. This can require DAYS to get everything re-installed and updated and all my settings and customizations restored. With Reflect, I can simply run a restoral program, point to the last backup known to be good, and in an hour or two return my system to the exact state in was in at the time of the backup. Reflect can also mount a backup file as a virtual read-only drive from which I can copy individual files and folders - useful for accidentally deleted items.

So at any moment, I have current copies of my Basecamp database on my two computers, one in the cloud, and additional copies of various ages in backups. All without manual copying or needing to remember to run a backup for Basecamp or any other program/data on my computers.

[lkraus]

I don't see a method by which routes can be copied between databases so I am thinking that this requires forethought, creating the new database before starting to create the routes.

Select the data (points, tracks, routes, lists, list folders) export to .gpx, switch databases, import the .gpx.

[bicyclenut]

I'm primarily using Basecamp on a Mac but I backup database everytime I use Basecamp to the Cloud. I can then use these backups to restore on any of my computers to work on as I have a Desktop, a MacBook Pro and a MacBook Air I usually take for air or Moto travel. Secondary, I have a recent backup if I mess something up to the point that I need to just go back a day or so.

Usually at the end of the month I delete all these daily/weekly backups and just save one for the month that was done last. This was I could go back and restore an old backup if these was a need to do so and find old routes, tracks, waypoints, etc. Gives you a restore point to go back to if needed. I also sometimes save backups with added names like 072023BMWMOARALLYVA (2023 BMW Rally in VA) where I may have created some routes and tracks for an event, etc. that I don't think I will ever use again, but save a copy of database at that time, just in case I need to go back and get those routes for some reason I can restore the database, export the routes and data and then restore the database to my current backup.

Hopefully that make sense

[Peobody]

I also sometimes save backups with added names like 072023BMWMOARALLYVA (2023 BMW Rally in VA) where I may have created some routes and tracks for an event, etc. that I don't think I will ever use again, but save a copy of database at that time, just in case I need to go back and get those routes for some reason I can restore the database, export the routes and data and then restore the database to my current backup.

This is what I am giving thought to. My Basecamp database is getting cluttered with tours that I will never do again but then when I start thinking about a new tour in the same general direction as a previous one I like being able to open the previous one to see if I want to re-use any of it. I don't need the data from the old tours in the current database, just available in case I want to look back.

[bicyclenut]

It has worked well for me for a number of years (on Mac), just need to be methodical about backing up each time you add data, at least if using on more than one computer, may not be an issue if ONLY using for backup as you may not restore database often.

[lkraus]

Basecamp data does not take up very much storage so I don't worry too much about "clutter" from old rides in Basecamp. A bunch of separate .gpx files seems harder to manage and maintain. Just make a list folder "Past Rides" with whatever internal folder structure that makes sense to you. With the folder collapsed, it only takes up one line in the Basecamp Library, and everything is right there where you will use it, not scattered in separate files elsewhere.

library.jpg (48.84 KiB) Viewed 2876 times

I build new trips in Temp or their own list folder at root level until completed, then drag them into the appropriate "Past" folder after completion.

[Peobody]

Basecamp data does not take up very much storage so I don't worry too much about "clutter" from old rides in Basecamp.

I'm not concerned about space, just clutter in the Basecamp Library.

My Library is similar to yours @lkraus except that each of my tours has its own list folder. Moving them into a higher level list folder or two would indeed condense the list.

[bicyclenut]

I primarily do the backups to be able to use the same Library/Files on 3 computers as I have mine organized by folders and subfolders and move these about depending on what I am working on. And these folders allow you to declutter the map when needed. I keep most of my routes and data but occasionally delete stuff that I know I'll never use again or may be experimenting with. Never hurts to have back-ups though.