For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
May's giveaway is a STM32F411RE, mbed-Enabled Development Nucleo-64 series ARM® Cortex®-M4 MCU 32-Bit Embedded Evaluation Board. As it has a debug port, it's perfect for learning about working with ARM Cortex M4 MCUs. Enter the contest via this link.
Backups - we all talk about them, but too few of us do them on a regular basis. And it's critical to think through possible failure modes. Here's Jack's approach.
The hard disk in my daughter's MacBook Pro failed recently and she lost everything. Of course, she did have an external USB connected backup drive, which she never used. So she's out of all that data. I am Jack Ganssle and welcome to the Embedded Muse video blog. Today, I want to talk to you a little bit about doing backups for small teams and home offices.
In the last couple years I've worked with three engineering teams, whose entire engineering departments were consumed by fire.
They lost everything. Two of those companies were fine, they had a great backup system. They got wonderful checks from the insurance company, bought all new equipment, and they restored their backups. One had no off-site backups. They lost everything. The company went out of business. Four hundred people lost their jobs.
On the job, it's likely that all resource goes protected by version control system, where perhaps all the data is kept on a central server somewhere that is backed up every day by IT people. Smaller teams often don't use those; in fact, 40% of teams in the embedded space don't use any sort of version control. And probably at home, you don't do that at all. And then of course, there are those pictures and all those other important personal documents that you would hate to lose. Today, I'm going to talk about how we manage a small network. We have about 100 gigabytes of absolutely critical data that we can't afford to lose, and I'll show you how we go about backing things up. We have not lost anything in the 20 years that we've been doing it.
But first, it's important to find what the objectives are for the backup. In this case, I want to make sure we back up all the important computers. That the backups are done automatically, every night, that we don't have to remember to do them. That we keep multiple copies stored in different locations in case of some catastrophe, like fire. And finally, that we keep some number of old versions in case a recent version gets corrupted.
The main tool I use is called Second Copy. It's a $30 Windows-based application I've been using for many years that automates the backups. Here's Second Copy's main screen. You can see a number of different profiles are available here. This is one that backs up my Docs directory, which has most of the important stuff in it. For each of these profiles, you can define a variety of properties. For example, this is the path to that particular directory. I'm telling it to backup everything in that directory with all the sub-directories.
This is the path again, this is where it goes, which is through an external USB hard drive. It does this every day, at 3 o'clock in the morning, and when it does it, it keeps the 10 most recent copies of each of the changed files, to that external hard drive. Second Copy rolls everything out to a second internal hard drive inside a main computer, as well as to an external USB connected hard drive.
I have two of these external hard drives. One sits on the machine and is backed up to everyday, the other is stored in an undisclosed location, and every Friday I swap the two so one is always safe in case the office were to burn down. To maximize the paranoia, I also, every Friday, back everything up to a non-windows computer, in this case a MacBook Air using a program called GoodSync. I have a similar directory structure on the Mac as is on PC, so all the data I need is always saved there.
Before Second Copy actually starts doing its work, I have instructed it to execute this batch file, a portion of which is shown on the screen here. At first, it creates a log file so I can make sure that everything is working correctly. I then have it put out the date and time with the backup to the log file. Then you can see it executes task-kill command in DOS.
What that does is it kills off Microsoft Outlook, and I'll get back to that in a moment. Then it does this xcopy, this is one of actually several which is in the batch file, which copies the changed files from one of the other computers on our network over to my computer. Then what it does with the second xcopy is it copies Outlook's main PST file into my standard directory. Now, the reason for this is because I find that inconvenient to have Outlook working out of my normal working directory. Those files are stored somewhere else, but I want them in that directory for the sake of this backup.
This is the reason for the task kill, you can't actually copy this file if Outlook is executing.
The effort is just a couple of minutes each week. The result is we lose nothing, everything is preserved. Thanks for watching, and be sure to go to www.ganssle.com for thousands of articles about embedded systems.
Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 43,000+ engineers. Click here to sign up or enter your email here:
Latest Embedded Muse: notes on supply chain woes, determinism and software metrics.