Sunday, May 8, 2011

Bacula Disk Storage Maintenance

A little over a year ago, I set up Bacula to do backups for the various laptops, netbooks, desktops, and servers in our home network. A few months ago, the backup jobs started failing because the 500GB external drive that holds the disk based backup media files filled up. The issue of not having recent backups was bothering me, but other things were bothering me more, so I hadn't done anything about it yet. Then something crashed, and a file got corrupted, and there was no recent backup to restore, so getting the backups running again started bothering me enough to figure out how to fix it.
The problem is that Bacula is designed around a tape backup system where the physical media does not actually get destroyed, but is simply overwritten when it contains no un-expired backup files. The latest version of Bacula (version 5.0.1 or later) has a new directive to solve part of the problem by truncating the media file associated with a volume when its status changes to "Purged." However, upgrading Bacula seemed like it would take more effort and wouldn't solve the other part of the problem, which is that I had set things up such that the media file name (label) included the job name and the date/time so I could tell what was in each of the files simply by listing the files on the disk. If those volumes are just truncated and "recycled" they end up having stuff in them that doesn't match the media file name.

So before going on with an explanation of how I fixed it, here's a review of the relevant Bacula terms and concepts.

media-file - Instead of a physical tape, disk based backups use a file, on a disk (go figure) so instead of referring to these as Media, I'll call them media-files. (Try not to get stuck on the singular vs. plural thing here.)

backup-job - in this context, this is the record in the Bacula catalog that represents a backup job instance that has already run, has an associated retention-period, and is associated with one or more "volumes."

backup-file - in this context, this is the record in the Bacula catalog database that represents a backup of a file, has an associated retention-period, and is associated with a "backup-job."

volume - in this context, this is not the actual media-file, but refers to the record in the Bacula catalog database that keeps track of a Media File, links to the backup-jobs (and indirectly to the backup-files) for which the media-file contains data, and stores the volume's status, retention period, last-written date, etc.

pruning - The process of removing backup-job and backup-file records associated with a volume, once they're past their expiration date.

volume-delete - removing the volume record from the Bacula database. If the volume were associated with a physical tape, the tape could be reused, but if the volume is associated with a media-file on a disk, the media-file is NOT deleted.

media-file-delete - using and operating system command (rm) to remove the physical media-file from the disk. This should only be done AFTER the volume-delete has been completed.

volume-status - This isn't a complete list, but the relevant ones here are Full, Used, Append, and Purged. Volumes in one of the first three are candidates for pruning. Volumes in the last status, Purged, are candidate for volume-delete.


So, what was the problem that caused the backup storage disk to fill up? Bacula doesn't automatically delete the media-files when the volume status changes to "Purged." Also, if volumes are not set to auto-recycle there is never an event that would auto-prune a volume and change its status to "Purged" anyway. Both of these things have to be done by a scheduled process (e.g. cron) outside of the Bacula daemons (or they could probably also be implemented as Python scripts that run within the Bacula director daemon, but I've set that ambition aside for another day.)

So then, what's the solution? There is no single solution of course, but my solution was to write a shell script (BASH on Linux in this case) and schedule it as a cron job (weekly seems be often enough). First it invokes the prune command on each volume in the Bacula catalog which will mark the volume-status as "Purged" if all of the backup-jobs (and backup-files) associated with the volume have expired. If not everything has expired, the volume will not be marked as "Purged" by the prune command, so the volume-status will stay as it is. Then, for each volume that has a "Purged" status, volume-delete it to get rid of the record in the Bacula catalog database, and then media-file-delete it to release the free space on the disk.

Pseudocode for the script is:
  1. Invoke Bacula's bconcole list volumes command to list all volumes
  2. Pipe the output through grep to filter down to the volume info lines that indicate a status of Used, Full, or Append.
  3. Extract the volume name from each line and invoke Bacula's bconsole prune volume={volume-name} command to cause the status of each eligible volume to change to "Purged."
  4. Invoke Bacula's bconsole list volumes command again to list all volumes
  5. Pipe the output through grep to filter down to the volume info lines that indicate a status of Purged.
  6. Extract the volume name from each line and...
    1. Invoke Bacula's bconsole delete volume={volume-name} command.
    2. Invoke the operating system's delete (rm) command to remove the media-file associated with the volume.


Script 1: prune-all-volumes.sh

#!/bin/sh

temp_dir=/var/lib/bacula/maint_tmp

temp_file_all_volumes=`mktemp -p $temp_dir`
temp_file_volume_lines=`mktemp -p $temp_dir`

# use bacula's bconsole to list volumes and calculate which ones
# to run the prune command on based on the retention
# vs. last written date.
/usr/sbin/bconsole > $temp_file_all_volumes <<END_OF_DATA
list volumes
quit
END_OF_DATA

cat $temp_file_all_volumes | grep -E "\| Full|\| Used" > $temp_file_volume_lines
while read volume_info_line
do
  # Note: The sed part just trims leading and trailing whitespace
  # echo "line = '$volume_info_line'"
  volume_name=$(echo "$volume_info_line" | cut -d"|" -f3 | sed 's/^[ \t]*//;s/[ \t]*$//')
  retention=$(echo "$volume_info_line" | cut -d"|" -f8 | sed 's/^[ \t]*//;s/[ \t]*$//')
  last_written=$(echo "$volume_info_line" | cut -d"|" -f13 | sed 's/^[ \t]*//;s/[ \t]*$//')
  last_written_year=$(echo "$last_written" | cut -d"-" -f1)
  last_written_month=$(echo "$last_written" | cut -d"-" -f2)
#  if [ $last_written_year = "2010" ] && [ $last_written_month = "04" ]; then
echo "volume_name = $volume_name, retention = $retention, last_written = $last_written, year=$last_written_year"
/usr/sbin/bconsole <<END_OF_DATA
list volume=$volume_name
prune volume=$volume_name
yes
list volume=$volume_name
quit
END_OF_DATA
#  fi
done < $temp_file_volume_lines

Script 2 - delete-purged-volumes.sh:
#!/bin/sh

temp_dir=/var/lib/bacula/maint_tmp
log_dir=/var/lib/bacula/maint_logs
bacula_storage_device_dir=/mnt/wdmybook/bacula_data/storage_device_dir


datevar=`date +%Y-%m-%d-%H%M%S`
delete_script_log_file=$log_dir/delete-purged-volumes-$datevar.log
temp_file_all_volumes=`mktemp -p $temp_dir`
temp_file_purged_volume_names=`mktemp -p $temp_dir`

# use bacula's bconsole to list purged volumes
/usr/sbin/bconsole > $temp_file_all_volumes <<END_OF_DATA
list volumes
quit
END_OF_DATA
cat $temp_file_all_volumes | grep -E "Purged" | awk '{print $4}' > $temp_file_purged_volume_names

echo "Delete all 'Purged' Bacula Volume records"
echo "and the corresponding disk files."
echo "Remember to run maint-prune-all-volumes.sh first."
echo "or this may not do very much."
echo "For results/messages, review log file: $delete_script_log_file"

while read volume_name
do
echo '' >> $delete_script_log_file
echo Using bconsole to delete purged volume record $volume_name >> $delete_script_log_file
/usr/sbin/bconsole >> $delete_script_log_file <<END_OF_DATA
list volume=$volume_name
quit
END_OF_DATA
/usr/sbin/bconsole >> $delete_script_log_file <<END_OF_DATA
delete volume=$volume_name
yes
quit
END_OF_DATA
/usr/sbin/bconsole >> $delete_script_log_file <<END_OF_DATA
list volume=$volume_name
quit
END_OF_DATA
echo removing physical file $bacula_storage_device_dir/$volume_name >> $delete_script_log_file
ls $bacula_storage_device_dir/$volume_name >> $delete_script_log_file
rm $bacula_storage_device_dir/$volume_name >> $delete_script_log_file
ls $bacula_storage_device_dir/$volume_name 2>> $delete_script_log_file >> $delete_script_log_file
done < $temp_file_purged_volume_names

Wednesday, April 13, 2011

Stop the Verify Email Address Web Form Stupidity!!

I'm not sure when this trend started to put a second field on a web form to "verify" your email address the same way you type in a password twice, but it is moronic. It is CLEAR TEXT. The person filling out the form can READ what they've entered to confirm it is correct. There is absolutely no improvement to reliability achieved by forcing the same clear text information to be entered twice.

Passwords are different. Someone entering a password into a field that is masked with asterisk characters cannot see what they have typed. Entering a password a second time reduces the possibility that something incorrect was typed into the first password field, BECAUSE the person typing it CANNOT SEE WHAT THEY'VE TYPED!!

Perhaps the same idiots who think it is useful to type in an email address twice should consider forcing the user to enter every element of the form twice, just to be sure. It wouldn't help any more than typing the email address two times, but it would sure increase the annoy-the-user factor, which is the only plausible reason for requiring an email address the second time. Soon we should see forms with fields for First name:, Verify first name (that you just typed in clear text):, Last name:, Verify last name (that you just typed in clear text), etc. etc.

Maybe someone thinks there is something magical about having an '@' symbol and one or two '.' characters in something that is typed in clear text into a form. I guess someone must have a nutty theory that all those other fields on a form must be easier to visually review in a single entry box because they don't have any "special" characters in them. What if someone had an accent mark in their name somewhere? Wouldn't that be just as likely to be typed in incorrectly? Shouldn't that be entered twice too?

I'm sure somewhere, someone is making the excuse that the email address is more important because it must be correct in order for an actual electronic communication to succeed. I'd answer that with, "Sure it does, BUT YOU CAN STILL SEE WHAT YOU'VE ENTERED!!" If it's wrong, it's wrong twice. If it's right, it's right. If it's wrong and the form hasn't been submitted yet, the user CAN SEE THAT IT'S WRONG and correct it in ONE FIELD.

As much as this useless technique seems to be used on web forms, I'd bet there is a book or two in print that suggests this irritating web-form feature serves some purpose. And I'd bet there is a group of people who would defend it with all kinds of fabricated statistics from some ill-conceived usability study involving web aware howler-monkeys and internet-users over the age of 87. But really, I hope web form designers everywhere will finally get a clue and stop doing this.

I guess until sensible behavior is re-introduced into the world of web forms, I'll just enter my email address once, LOOK AT WHAT I'VE TYPED, select what I've typed, copy, click the other email field, and paste. I'll also try to convince myself that someone in an over-authorized marketing department somewhere forced an otherwise reasonable person to include the "Confirm email:" field on the form.

Thursday, February 24, 2011

Problems creating SAAJ object model

Getting wsse enabled in Oracle WebLogic 10.3.x (11g) using CXF as a web service engine and Maven as a build tool proved to be a bit of a challenge. After many Google searches that came up empty, the solution included the following elements.

1) Do not package saaj-api.jar or any saaj-impl.jar with a war or ear deployed into WebLogic.

This requires a bit of work in the pom.xml files that build your project. Many of the CXF libraries have dependencies on saaj-api.jar and saaj-impl.jar so in the in all places where there is a direct or transitive dependency on a CXF library, those need to be excluded.

Example:



<dependency>
<groupid>org.apache.cxf</groupid>
<artifactid>cxf-rt-frontend-jaxws</artifactid>
<version>2.2.9</version>
<exclusions>
<exclusion>
<!-- Remove SAAJ (soap attachment) lib version that conflicts
with Weblogic Built-In version. -->
<groupid>javax.xml.soap</groupid>
<artifactid>saaj-api</artifactid>
</exclusion>
<exclusion>
<!-- Remove SAAJ (soap attachment) lib version that conflicts
with Weblogic Built-In version. -->
<groupid>com.sun.xml.messaging.saaj</groupid>
<artifactid>saaj-impl</artifactid>
</exclusion>
</exclusions>
</dependency>


2) Explicitly set the Soap MessageFactory class in a JVM startup parameter on the WebLogic container's JVM.

-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl


REFERENCE: http://blogs.sun.com/fintanr/entry/saaj_classcast_error_with_jdkhttp://blogs.sun.com/fintanr/entry/saaj_classcast_error_with_jdk

Friday, February 18, 2011

Oracle JDBC Connection String Nonsense

After spending several hours trying to sort out the cause of a cryptic message from Oracle's JDBC driver I finally tried something that worked, but the cause, as is often the case with Oracle error message, was completely absent from the error message text. I'm posting this because it was also completely absent from any Google results.

I had a DataSource set up with a connection string as follows:

jdbc:oracle:thin:@//10.0.50.1:1521/mysid

Any attempt to open a connection using that DataSource resulted in the following, completely useless error message:

java.sql.SQLException: Io exception: Got minus one from a read call

Changing it to a slightly different JDBC URL string format made it work.

jdbc:oracle:thin:@10.0.50.1:1521:mysid

The only differences are that // just following the @ has been removed, and the "sid" is delimited at the end by : instead of /

I hope having this matched up with the error message gets someone past all the noise about the number of processes or the number of connections in the listener. At least in my case, that stuff had absolutely nothing to do with it.

Wednesday, February 9, 2011

Colorado Capital Bank - Irresponsible

This evening I opened a letter from a "Senior Teller" at Colorado Capital Bank which stated that they did not have an "updated signature card" for my account. Enclosed was the "signature card" form with boxes highlighted where my wife and I were to sign and return the form in a postage paid envelope, also enclosed. I wish the only thing about this letter to be irritated about was the wasted postage and the absurd notion that our signatures would need to be updated (since they haven't changed much in nearly 20 years).

Here's a link to their Privacy Policy, which is nothing but a bunch of empty words that have absolutely NO bearing on the behavior of Colorado Capital Bank employees.

http://www.coloradocapitalbank.com/Privacy.aspx

There were a few small problems with this signature form that added up to one gigantic problem. The form included a few pieces of information in addition to the signature boxes. First, it had our entire account number (no part masked, no part truncated). That alone might have been forgivable. But wait there's more. The form also had my full name as it appears on the account, my full social security number, my date of birth, my drivers license number, my mother's maiden name, my full phone number, and my complete home address. Granted, anyone stealing this document from my mailbox could figure out the home address part, but it didn't end there. The form ALSO had my wife's full name as it appears on the account, her full social security number, her date of birth, her drivers license number, and her mother's maiden name.

There it was, all on one page, EVERYTHING anyone would need to steal our identity without making any effort at all. No social engineering would have been required, because ALL of the typical information ANY bank, utility, insurance company, credit card company, or numerous other identity dependent organizations might ask in order to verify our identity was offered up by Colorado Capital Bank on a single sheet of paper, sent to us through the U.S. mail, and expected to be returned to them through the U.S. mail.

If you have an account at Colorado Capital Bank, you should do what I intend to do and close the account immediately and demand that they destroy or secure ALL records related to the account. They are grossly irresponsible in the way they handle the vital information they have on file. If you are considering opening an account at Colorado Capital Bank, I urge you to take your business almost anywhere else. Allowing Colorado Capital Bank to mis-handle your personal information in the first place would be a VERY bad decision.

Unfortunately, I probably can't force them to be responsible with the information they already have on file. I can only close my account and hope that that removes any reason they would have in the future to send EVERY SINGLE THING required for an identity thief to make a huge mess of my financial life. A bank that acts so irresponsibly should NOT be trusted with your money, your identity, or anything else.

This is a warning for others who might find this before it is too late.

STAY AWAY FROM COLORADO CAPITAL BANK!!

Tags: complaint review bank colorado Castle Pines Castle Pines North Castle Rock South Denver irresponsible identity theft privacy policy

Sunday, September 19, 2010

Why are So Many Mom & Pop Retail Stores Run by Idiots?

I just want to offer a bit of general feedback to all those Mom and Pop stores that find themselves trying to compete with large, volume-buyer, retailers. It's acceptable in many circumstance to charge a little extra for the things you sell. Everyone probably understands that you can't discount your prices as much as a Wal-Mart type store that buys the same item in multiples of a billion. However, if the only way you think you can stock a common (i.e. non-specialty) item is to charge way over list price for it, you'd be better off just not stocking it at all. When your customer finds out they've been dramatically overcharged, it will likely be the very last thing you sell to that customer.

I recently visited "The Country Pedaler" in Castle Rock, CO on the way to a mountain bike ride to pick up an innertube, just in case I had a flat on the ride that couldn't be patched. It's a small shop, so I went in expecting to pay up to the full retail list price for the tube. The store location was convenient because it was along the way to the trailhead, so I didn't even mind paying a bit more than I would have paid for that item at a larger bike store like BikeSource or Performance Bicycle. I had never bought a tube of the particular size I needed so I wasn't sure what its normal price should be. I was charged $10.00, which I thought was a little high, but I trusted that even if the price was on the high end of the retail price range for that item, it wouldn't be too different than what I might find elsewhere. So, I considered the convenience factor to be worth maybe 10% or 20% and bought it anyway.

Any time I find that I have been charged more than 40% OVER the full retail list price for a basic, commodity, accessory item (like a bicycle innertube), I can't help but feel I've been ripped off. I found out later that the same exact item has a full retail list price of $7.00. To make things even worse, I found that the price for a similar (maybe even better) quality tube, at other local specialty bike stores, was as low as $5.29. "The Country Pedaler" price was marked up in excess of their competitors by a margin of almost 90%. You read it right, almost double the price other local stores charged for the same simple accessory item. It wasn't hard to find or in short supply. It didn't require special expertise or consultation from a sales person. It was just WAY overpriced.

The tube was the very first thing I purchased from The Country Pedaler bike store, and, because it was so drastically overpriced, it will likely be the VERY LAST thing I purchase from that store. They don't really have any option to correct their mistake now because they've already proven that I can't trust their prices to be even approximately fair, never mind competitive. Offering a refund or price adjustment now wouldn't even change my impression that the store generally charges an exorbitant amount over even full retail list prices. I wonder if it is any consolation to the store's owner that he gets to keep that extra $3.00 profit on that one sale (assuming I don't just return it for a refund) or if he even realizes how much it cost his business to jack up the price on a simple accessory item.

It is possible that I might decide to give The Country Pedaler a second chance several years from now, just to see if they got a clue and changed how they're setting their prices, but for now, they've lost me as a customer. Somehow I doubt the store will survive if they continue to alienate potential customers they way they have with me. I suspect anyone who finds this blog post will be reluctant to do business with them either. I certainly won't be recommending that anyone else visit that shop. In fact, I'll definitely warn them and send them elsewhere whenever possible.

Other mom and pop retailers that wish to keep customers and remain competitive should take this as a warning. You might be able to justify prices closer to full retail because you may be in a more convenient location than the "discounter" shop. Your customers might not even mind spending a little extra with you if you're able to give them more personal attention when they visit your store. But beware if you go beyond "a little extra" on your prices and gouge someone by pricing a relatively insignificant item well over its fair retail price. You're compromising the trust they have in your store, swapping positive word-of-mouth advertising for bad, and forfeiting any profit you might have earned on future purchases. All you gain for that is a few extra bucks, one time... most likely one LAST time.

Saturday, September 18, 2010

Garmin PC Map Updater Software SUCKS

I'd venture a guess that Garmin spends 99+% of its software development resources on the software that is actually on the device. I have experience with Nuvi, eTrex, and Forerunner models and most of the time, the menus, functions, and display options a Garmin GPS device seem to be reasonable and stable. But then Garmin's Windows based tools to support those GPS devices SUCK. I mean they REALLY, REALLY SUCK!! My last 3+ hour episode of utter frustration using one of Garmin's crap-ware tools was while attempting to simply update the Maps on a Nuvi automotive GPS device. I know it costs money to keep map data up to date, but the $90 I had to pay was still a bit steep for the marginal improvement in usability. Roads just don't change that significantly, that often. The map updater software required the following steps before it completed the simple simple task of checking a purchase license, matching it to the device serial number, and transferring map data onto a USB device.

1. Install a "communicator" plugin into the web browser (Firefox). Web browsers already have as their single most definitive purpose, "communicating with web servers" so it is aggravating that Garmin feels it is necessary to introduce additional software to accomplish this for "their" data.

2. Realize that for some unreported, unexplained reason, the Garmin Firefox plugin just doesn't work. No error message appeared suggesting that something was wrong. It just didn't ever "communicate" anything.

3. Install a "communicator" plugin into Microsoft Internet Explorer. IE is not the browser I normally use, so I have to remember this for any other interaction with Garmin's special IE only web site. C'mon Garmin, those days are long gone. Only the worst type of idiot-clown web sites authors still lock their content into IE only.

4. Play a guessing game with the Garmin web site to figure out where exactly they have the page where I can actually purchase the map update product I'm after. Enter credit card information to pay the excessive $90 fee. In my opinion, a GPS device that includes map data, should just include the map data updates for at least 5 years or so as part of the initial purchase price. After all, the pre-loaded map data already a bit out of date when it was first purchased, presumably because it had been sitting on a shelf in a store for a few weeks or months already.

5. Go check email for a link to another web page that contained the download link for the purchased map update data. Listen Garmin, the only reason I should need to give you an email address at all is if I want to receive a receipt or some other notification from you. Once I enter valid credit card information and purchase the maps, JUST FORWARD MY BROWSER DIRECTLY TO THE !@#$% DOWNLOAD PAGE!!!! All you accomplish by making me jump through the email link hoop is to make me even more angry when I get to the next boneheaded step.

6. Realize that after all the hassle and effort to get the communicator plugin working, it was only so I could download a map updater program that must run outside the web browser in order to transfer the map data to the Nuvi USB device. What a colossal waste of time. Please, just cut all the web browser calisthenics and let me jump straight to the download. Any web browser works just fine for that task, without any modification, extensions, plugins or anything.

7. Download and run the map updater program.

8. Watch the map updater program attempt to install Microsoft's .net framework 3.5 in spite of the fact that it was ALREADY INSTALLED on the machine.

9. Watch the .net install step fail and roll back, also without any explanation, which stops the map update process with no obvious next step. Frankly I don't know whether to thank Garmin or Microsoft for this aggravation, but since Garmin chose to require the .net framework, and their map updater program doesn't properly detect whether it is already installed, I'll still give Garmin the blame.

10. Switch to another computer (which is an option Garmin should know isn't available to a large percentage of their customers) and start basically from the beginning again.

11. Install the stupid "communicator" plugin for IE.

12. Poke around Garmin's web site to eventually find the link to download the map updater again.

13. Start the map updater. BTW, the version of the Garmin map updater initially downloaded from the site immediately downloads and installs different version. This happens transparently, but WHY? Once again, Garmin has absolutely no respect for their customer's time. Whenever I have observed other software doing this, it is usually doing something sneaky. My level of trust in Garmin's software was already very low, but this just helped push it well in to negative territory.

14. Wait approximately 1/2 hour while it installs the Microsoft .net framework (and yes it was already installed on this machine too).

15. Scream loud enough for Garmin's software staff to hear every expletive I know, no matter where in the world they happen to be because at this late stage, the map updater finally checks to see if there is even enough free disk space (which is a whopping 5GB on the System (c:) drive BTW) to complete the update process. WHY DIDN'T IT CHECK THAT SIMPLE MATTER UP FRONT. Yikes, how stupid are these people?

16. Since the only machine that would get though all the .net nonsense and run the map updater was a netbook that came pre-partitioned with a small system drive having less than 5GB free, the map updater wouldn't run without playing some space-available tricks. I suspect this is also an option that is not within the know-how limits of the majority of Garmin's customers. Garmin's map updater software offers no options to choose another drive or partition to use for temporary space so if your machine doesn't have at least 5GB free on the C: drive, just give up.

17. After several hours of frustration and false starts trying to get the map updater to run, then you have to leave it all of it running for several hours. Yes, I said SEVERAL HOURS while it downloads, unpacks, and transfers updated data to the device. Just to be sure it is able to make it through this process without making the GPS device into a brick, it would be best to have a redundant internet connection, an uninterrupted power supply, and fix Windows power management settings temporarily so that it never shuts off the hard drives or initiates system stand-by. This process takes a VERY LONG TIME. By the way, the map-updater's downloader client program consumes 100% of your internet connection's available bandwidth making everything else that needs to share the connection slow to a crawl. Garmin, this isn't just amateur network client software design, it is OBNOXIOUS and RUDE!!!

Garmin should be ashamed. How they could so totally screw up such a simple piece of software is utterly perplexing. It has been a very long time since I encountered a software utility, especially something that does nothing more complicated that transferring data from a server to a portable USB device, that was SO COMPLETELY frustrating and so poorly designed. I'm hoping that this blog post eventually costs Garmin as much in lost sales as their crap-ware map updater has cost me in aggravation. Even if it doesn't, maybe it will save someone else some of the annoying troubles getting map updates for their Garmin GPS device.

CHAPTER 2

On a second Nuvi device that I now DEEPLY regret ever having purchased, the Garmin Map Updater software forced a firmware update to the GPS device and WIPED OUT ALL MY ROUTES, ALL MY FAVORITES, and EVERY BIT OF TRACK DATA that I might have been able to capture first or restore later if there had been any indication at all that the crapware was about to wipe it all out. Someone in charge of Garmin's map updater software really needs to be put in prison. There is absolutely no excuse for this blatant disregard for Garmin's customers. I expect there must be a special place in hell for the a**hole who released this stinking pile of garbage into the lives of unsuspecting Garmin Nuvi owners throughout the world. May the responsible person rot in a pit of their own waste.