Posts by Tag
Backup History
Visit our Archives Page.

Posts Tagged ‘WordPress’

Catching Up on Backups

Saturday, July 3rd, 2010

Well, this is embarrassing.

The last time I wrote my so-called weekly column was more than a month ago. And, believe me, it’s not because nothing has been happening in the world of backups. Life got just a bit out of hand and blogging slipped down the priority list. But now the Ur-Guru has gone home, the cats have settled in, the housemate situation is more or less sorted out, and I really have no excuses left. It’s time to wade in and deal with all those outstanding backup issues from the last 6 weeks so we can get back to our regularly scheduled program of product reviews and tales from the backup trenches.

  • To start with, our winner (and only entrant) in the Gladinet contest is Todd Vierling. Todd told an entertaining if manifestly apocryphal story about how Microsoft’s Azure Blob got its name.
  • I missed a pre-briefing on the new KineticD service from Data Deposit Box, so I’m following up on that.
  • Mozy launched Mozy 2.0 for Windows. According to the press release, “New enhancements include faster upload speeds and decreased bandwidth usage, new convenience and access features, and Mozy 2xProtect™ – a new feature which allows Mozy users to back up to a local external drive in addition to Mozy’s online data centers at no additional cost.” Could this be in response to Dmailer’s move into the online space? I haven’t had a chance to ask Mozy. Meanwhile, I guess Mac users are still stuck with the 1.0 version until the developers catch up.
  • I got a link request from BackupTechnology in  England. As it happened, I’d just installed their Online Backup for WordPress plugin on a client’s site and was about to try it. I’ve since set it up, and it backs up on schedule; I haven’t tested the restore function. Look for a more detailed review soon. (Though I might not do the restore test on a client site.)
  • There’s a new beta version of the Automatic WordPress Backup plugin. It now runs a nice little diagnostic of your server when you activate it. It still doesn’t seem very fond of my test blog on Dreamhost, though, so I may have to test it on a different host. (I admit to not being very fond of Dreamhost myself.)
  • Amazon S3 introduced something called Reduced Redundancy Storage. It lets you prioritize your data so you save fewer copies of less important stuff, thus taking up less space. Prices start at $.10 per gigabyte and go down (per gigabyte) from there.
  • Gladinet came out with a new product called CloudAFS (attached file storage). On the face of it, it sounds like the kind of enterprise product that most readers of this blog wouldn’t be interested in: “CloudAFS allows local storage to be used as tier one for fast access and delivers unprecedented storage space by using the cloud as tier two. If you have storage expansion needs, want to replace a tape backup solution or just want to leverage the efficiencies of cloud computing, you can now attach cloud storage to your existing IT infrastructure to create a cost-effective, multi-tiered storage solution with low impact and faster backup or recovery times.” But if you use a server at all for your business, you might check it out, since it’s only $4.99/month for a single license, and there are bulk discounts.
  • I got another link request from ProFusion Backups. I’d feel a bit better about them if they hadn’t left their fill-in-the-blank template below the part they filled out for the FileSlinger™ Backup Blog. I’m willing to take a look at it, but it won’t be first on my list.
  • Our friends at the Windows Azure Blob are now charging for their formerly free service. (Well, the introductory offer is still listed despite the fact that July 1 has passed, but that’s probably an oversight.) We knew they would someday. My only use for them was to test Gladinet; Windows Azure is trickier to use than Amazon S3. The prices are very similar, however:
    • $0.15 per GB for data transfers from European and North American locations
    • $0.20 per GB for data transfers from other locations
    • $0.01 per 10,000 transactions
  • Andy from CloudBerry Lab wrote to tell me that CloudBerry had upgraded its online backup product to include support for Amazon’s Reduced Redundancy Storage (see above). They also have a beta version of CloudBerry for Azure Blob Storage. That product is free while in beta, even though Azure Blob no longer is.
  • iConfidential asked for a review of their cloud storage/file sharing/backup product by posting a comment to the announcement about Dmailer’s contest. I deleted the comment, but I’ll probably review the product eventually. (Look, folks, if you want me to review something, read the Review Policy page and then e-mail me.)
  • BackupBuddy also got an upgrade and can now store your backups on Amazon S3. I did that with my backup of this blog before upgrading it to WordPress 3.0. I haven’t had any problems with the other dozen upgrades I’ve done to WP 3.0, but that didn’t mean I wasn’t going to back up the site, which uses a lot of plugins and an older (relatively speaking) theme. It worked like a charm, including the upload, which I checked on with S3Fox. (Sorry, Andy, but that was handiest.) Even though GoDaddy, the host I still have the Backup Blog on, doesn’t have its servers set up properly to use the magic restore function that makes BackupBuddy the Holy Grail of WordPress backup plugins, the backup still contains absolutely everything in a nice handy zip file, and I could if necessary unzip it and restore it manually.
  • Amazon Web Services finally got around to adding Amazon S3 to its AWS Management Console, so you can see what’s in your buckets without a third-party tool. Good of them.
  • I’ve been getting lots of e-mail from Zetta about their enterprise storage-as-a-service. They charge $0.25/GB/month and there’s a 15-day free trial—th
    e kind you have to provide a credit card for. Another thing to follow up on. Maybe I could get them and Data Deposit Box in the same room to duke it out.
  • My former client Spare Backup seems to have landed a $10 million equity line, because they’re publishing press releases about it.
  • I have a new computer. Expect to start hearing about Windows 7 soon.

Whew! That took me more than an hour just to list. (I did have to check a few links.) Actually testing the new products is going to take longer. But I promise to be back next week to tell you about my initial experiences backing up on my new computer.

BackupBuddy: The Holy Grail of WordPress Backups Is Almost Within Reach

Sunday, March 21st, 2010
BackupBuddy logo From the moment I heard about the new BackupBuddy plugin from iThemes, I was dead keen to try it. A WordPress plugin that backs up everything? Really everything? Most backup solutions for WordPress only back up your database. The Automatic WordPress Backup plugin I reviewed in January (supposedly) backs up not just your database but your wp-config.php file, your uploads folder, your plugins folder, and your themes folder to an Amazon S3 account. My tests with AWB didn’t work quite 100%, but after my experience with testing BackupBuddy, I’m starting to think the problem is with my hosting companies and not with the plugin.

The reason that BackupBuddy is stirring up so much excitement in the WordPress community is that when it works (more on that in a minute), it’s so comprehensive that you can actually use it to move your WordPress installation from one server to another without having to do anything more than set up a MySQL database. That gets the developers who work on sites in one environment and then move them to another one excited, because it’s a time-saver. And it gets people who’ve had their web servers hosed excited, because they can get back up and running quickly.


BackupBuddy is a commercial product: unlike most WordPress plugins, you have to pay for it. It’s $25 for a single-user license, $75 for a business license, and $150 for the developer license. You can start with a single-user license and upgrade.

When I contacted iThemes and asked for a review copy, Cory Miller provided me with a 3-month subscription good for two sites.

After you buy the plugin (or, um, don’t, if you’re a reviewer), iThemes sends you an e-mail with a login and password for the membership site. That’s where you go to download the actual plugin, which you then upload and install to your WordPress site in the usual fashion. I opted to try BackupBuddy on (still hosted at GoDaddy because I didn’t get my act together to switch before the plan auto-renewed) and on the test blog I keep for the Podcast Asylum (hosted at Dreamhost, courtesy of the Ur-Guru.)

BackupBuddy: manage licenses

There’s an additional step, however. Before you can start using BackupBuddy, you have to get a license. When you click “Manage Licenses,” an AJAXy lightbox-effect window pops up and tells you how many license keys are available to you. The first time you use BackupBuddy, you’ll need to generate a key and link it to the site. If you later want to use BackupBuddy on a different site instead, you can go into the license manager and click “unlink from site,” then deactivate and uninstall the plugin.

BackupBuddy Options panel Once you have the license in place, you’ll see the BackupBuddy options panel in the WordPress dashboard. This is where you set your backup password and schedule, and also where you find the instructions on how to use the plugin. (Looking at the screenshot, it occurs to me that it might be more logical to put “Settings” right after “Getting Started.”)

BackupBuddy is designed to be easy to use, though it’s not quite at the ease-of-use level I’d recommend for my mother:


  1. Set a password in the Settings section if you have not done so.
  2. Perform a full backup by clicking Begin Backup on the Create Backup page. This may take several minutes.
  3. Perform database backups regularly to compliment [sic] the full backup as the database changes with every post and are smaller than full backups.
  4. Download the backup importer, importbuddy.php, for use later when restoring or migrating.


  1. Upload the resulting backup zip file and importbuddy.php to the root web directory of the destination server.
    You do not need to install WordPress or any other files on the destination server. [My emphasis.] The backup will handle this.
  2. Also upload the latest database backup ZIP file if one exists.
  3. Navigate to importbuddy.php in your webbrowser on the destination server.
  4. Follow the importing instructions on screen. You will be given the option to change settings on import.
  5. After completing the restore / migration, repeat the process, selecting the database backup zip on import.

I’m not sure why they ask you to start by creating a password, because so far I haven’t needed to use it. The rest of the settings are for your FTP server login info if you are backing up that way.

Backing Up

BackupBuddy saves its backups to a folder on your web server. Right now there are two options for what it can do with backups once they’re complete: upload them to another server by FTP, or e-mail them to you. Personally, what I want to do with them is download them, without having to turn my laptop into an FTP server. I suspect the easiest way to accomplish that would be to have the program e-mail me when the backups are ready, so I can go get them myself. A few people in the support forums have also requested Amazon S3 as a possible backup destination, and I suspect we’ll see some new options in the future.

You can create multiple backup schedules—say, a full backup once a month and a database backup weekly, daily, or even hourly (depending on how often you post to your blog). E-mailing database backups isn’t usually a problem, but you don’t want to send your entire site backup (the one I made for was about 42 MB) via e-mail. Either FTP it to another server (preferably on another host) or download it to your hard drive and have it included in the backups you make offline. (I suppose I could create a monthly backup schedule and then just set up a reminder in Outlook, but it would be really nice if BackupBuddy could do this itself somehow.)

It was with great eagerness that I set out to make my first backup on the test blog, but I immediately ran into problems:

Backing up database……………………………………

ZipArchive class not available. This is typically the case if your server runs PHP 5.1 or older.

Falling back to compatibility method. Note that this method is slower.


When I downloaded the backup, all it contained was the database, even though I’d set out to make a full backup. To make matters more confusing, when I checked with the Ur-Guru about the PHP version, he said that the server my site was on used PHP 5.2. Nevertheless, there was apparently no ZipArchive class, and so BackupBuddy couldn’t work properly. I reported the issue to Cory, who passed it on to lead developer Dustin Bolton, and also posted it in the Support Forum.

Meanwhile, I tried creating a backup on and had better luck.

BackupBuddy creating backup

When I downloaded that backup and opened the .zip file, it looked complete to me. I later learned that it hadn’t been, quite. Dustin and the team have put out at least three updates since I first installed BackupBuddy, and now they report to you on the condition of the backups. The following list comes from the test blog over at Dreamhost.

BackupBuddy Error Messages

As for what was happening when I tried to run the backups, I went from the “ZipArchive class” errors to getting a 404 page. Yet when I would go back to the “backups” page, there would be backups—in that invalid format. (Definitely invalid: I downloaded one and tried to back it up.) Something must be happening, because these files are larger than the first backups, but I couldn’t really tell you what, or where the problem originates.

I’m all in favor of having a program tell me when a backup is no good, though. That’s critical information. It might be something you want an e-mail message about if it happens with a scheduled backup instead of a manual one, but I suspect that just getting BackupBuddy to work on the major hosts is a more pressing problem right now.


There’s a 46-minute video introduction that walks you through the steps of backing up and restoring your site with BackupBuddy. Otherwise, support comes from the Support Forum, and responses from iThemes tend to appear in the evening. The guys are obviously working very hard to address the issues their users have been raising, given the number of new builds they’re putting out, but I just don’t think there are enough of them to keep up with BackupBuddy’s popularity.


Of course, no backup is any good unless you can restore your data from it. I’d hoped to do that test with the test blog, since there’s nothing to lose with it. But since the only good backup I could get was of the Backup Blog, I needed to test my restore on GoDaddy, even though I’d seen in the support forums that there could be issues there, too.

So I created a new directory in my main hosting account and uploaded the backup .zip file and the import.php file there, then navigated to the import.php file in my browser. and voila!

backupbuddy restoration & migration

Step 1 was both easy and obvious: I’d only uploaded one backup, so I didn’t have to worry about which file to choose from that drop-down menu. I just clicked “Next Step” and went on. Steps 2 and 3 were similarly straightforward.

Backup Buddy restore step 4

Step 4 was where it got interesting. The program pulled the database info straight out of my wp-config.php file (including the password). It occurred to me (and if it hadn’t, there was that warning to tell me) that I might not want to overwrite my existing database information, so I changed the database prefix, a trick that lets you use the same database for more than one blog. Then I went on to Step 5…

BB restore step 5

And stopped.

That was as far as the restoration process ever got. A little reading in the support forum suggested that GoDaddy is inclined to kill scripts that take more than 30 seconds to run. (This didn’t happen when I was making the backup, but who knows?)

I tried navigating to the site’s home directory to see what I could find, and discovered that my theme was there but I got a 404 on the home page.

Wondering whether I’d have better luck if I tried using a new database, I set one up and ran import.php again. Same result.


This is, shall we say, a tiny bit frustrating. It’s like having the Holy Grail just beyond reach of my fingertips. It almost works. It works well enough, in fact, that I could use it to move my sites from GoDaddy to one of the hosts where it works the way it’s supposed to. I wish I had a comprehensive list of those, but I don’t. The video mentions Hostgator and Bluehost favorably. I know there are issues with GoDaddy, Dreamhost, and Rackspace Cloud.

If you host your WordPress installation at Hostgator or Bluehost, run-don’t-walk over to the BackupBuddy site and GET THIS PLUGIN. If you don’t, then you might want to wait a few months, or at least check with the sales team before purchasing to find out whether there have been any reports of problems with the hosting company you use. But bookmark the site and keep an eye on it, because this is what WordPress site owners—and especially developers—have been waiting for.

Why You Need Your Own Website Backups

Thursday, March 11th, 2010

I was listening to Marketing Over Coffee a few weeks ago and heard a sad tale of woe from co-host John Wall. His blog, Ronin Marketeer, was down for four days. Hosed, in fact.


On February 20th, there was an an accident during the annual inspection of the fire-suppression system at WestHost’s data center. If you rewrite WestHost’s account of the incident in the active voice, it amounts to “The vendor forgot to remove an actuator before the inspection, and this triggered a release of Inergen all over the data center.”

According to Wikipedia, Inergen is non-toxic…to humans. It is, alas, highly poisonous to computer servers. And John’s blog just happened to be on one of the worst-affected machines.

Bye-bye blog.

The good news is, WestHost actually had backups of its clients’ sites. Not all hosting companies actually back up your website for you. (You can usually make your own backups through the control panel, but you may or may not be able to automate this process. Of course, if you have a traditional HTML site and edit the files on your computer before uploading them, you should be able to back up your local versions easily.)

The better news (theoretically) was that John, being a smart guy with lots of IT experience, had recently made his own backup of his blog. That meant he was starting out in better shape than Jeff Atwood over at Coding Horror, who had to rely on other people to piece together bits of his lost blog for him.

But the first attempt to restore Ronin Marketeer left a bit to be desired. When I sent a sympathetic inquiry to John after hearing the podcast, he sent me a link to a post he had titled “When Even a Backup Is Not Enough.”

As you can see, everything is all f’d up here.

Over a week ago disaster struck at my hosting company, during a fire alarm test the suppression system was triggered, hosing all the servers. This blog was dead for a full week.

We were offered to move our hosting from the version 3 infrastructure to v4, and I took up the offer since it got my domain back 2 days earlier. Unfortunately the new environment is not the same – even though I have a full backup of my Database that supports this blog, the new system does not allow you access to the directory where that data is kept.

I’m no expert in MySQL, but it looks like I’ve gone from having my own instance to sharing one on the server with everyone else.

The end result is that all my archives are gone for now and my Google juice vanishing as there’s no access to any of my archives. It looks like my only path is to install WP and MySQL on a box of my own, then do a WordPress export so I can then import it back in. I cannot believe that having the actual files is not enough for me to do a restore.

“My god,” you may be thinking. “If having the backup is no good, why bother making one?”

But if he hadn’t had the backup, the story would not have had a happy ending, and it does. John had to do some heroically geeky things, but he was able to get the blog back up and running. He did lose some comments, probably due to the nature of the restore process, but everything else seems to be intact. John started Ronin Marketeer in November 2006, and he’s a pretty prolific blogger. It would have been a serious loss, and no fun to try to reconstruct from the Google cache and the Wayback Machine.

I’m betting John will be especially interested in the WordPress backup plugin I’m going to be writing about next week. Everyone else certainly seems to be, and I’m very impressed so far.

A New Way to Back Up WordPress

Friday, January 15th, 2010

Automatic WordPress Backup logo

If you search the WordPress plugin repository for “backup”, you’ll get—as of today—195 results. I wrote about two of those plugins, WordPress Database Backup and WordPress Backup by BTE, just about a year ago, and installed them on all 8 of my own WP sites, as well as insisting that my clients use WP-DB-Backup at minimum.

Both of those plugins back up different parts of a WordPress installation and then either save it there on the server or e-mail it to the admin. I get a lot of e-mails with database backups, as you can imagine. These aren’t large files, and it’s not too time-consuming to save them with other client files and let them get backed up as part of my regular backup routine.

But the BTE plugin backs up your uploads, plugins, and themes directories. And those can start to get pretty large after a while. Not large in absolute terms of how much room I have on my hard drive or backup drives, but large in terms of what it’s convenient to receive by e-mail, especially multiplied by eight or more. And then there’s the fact that the mail server for, my primary business website, absolutely WILL NOT accept the plugins backup file, even though it’s a ZIP. It believes that file is full of malicious code out to attack me, and refuses it. (Ta ever so, mailer-daemon.) And then there’s the lack of versioning, because each week’s backups of those directories has the same name. These are minor annoyances, but real.

Now there’s a new plugin that combines the functions of these two stalwarts, with a few extras besides: Automatic WordPress Backup, sponsored by Melvin Ram’s Web Design Company, developed by Dan Coulter.

AWB lets you schedule daily, weekly, or monthly backups of your database, your wp-config.php file, your wp-content folder (themes, plugins, and uploads), and even your .htaccess file. Instead of e-mailing them to you, it uploads them to Amazon S3.

aws_logoS3 stands for “Simple Storage Service.” It’s not actually quite as simple as all that, but the idea is that you only pay for as much storage and bandwidth as you actually use. Since a typical WordPress installation—even with a lot of plugins and uploads—isn’t very large, backing up via S3 shouldn’t cost more than a few cents each month.

Before you install the plugin, go to Amazon S3 and sign up for an account if you don’t have one already. (Signing up is free.) Once you get that confirmed, go to “Security Credentials” under the “Your Account” tab to get the information you’ll need to configure the plugin.

WDC-optionsThen log into your WordPress dashboard and install the plugin normally. There’s a handy YouTube video that walks you through installation over on the AWB website. This is a nice touch. I just wish Amazon had done the same for S3! Once you activate AWB, you’ll be prompted to configure the settings. If you need to find them later, they have their own options submenu at the foot of the right sidebar.


Fill in your AWS Access Key and Secret Key, create an S3 “bucket” (the Ur-Guru was a bit disparaging about that term) to store your backup in, and decide what you want to back up, how often, and when to get rid of old backups.


I like both the option to automatically delete old backups and the option to make backups only once a month. There are sites that I don’t update any more often than that, even though I know I should.

When I first installed AWB on the test blog over at the Podcast Asylum, it didn’t seem to work. After you hit “Save Changes and Back Up Now,” you see a message telling you that there will be a link to download your most recent backup when you come back to that page—but there was never any link.

That was when I realized I didn’t know how to see what was on my Amazon S3 server. Amazon’s own site wasn’t too helpful; their AWS Management Console doesn’t work with S3 yet. Fortunately, there are plenty of other tools to let you get access to your S3 account. I picked S3Fox, a plugin for the Firefox web browser. Once I’d installed that, I was able to confirm that while my “testblog” bucket had been created, there was nothing in it.

Yet when I installed Automatic WordPress Backup here on the FileSlinger Backup Blog, it worked just fine. Was this a hosting issue, I wondered? (The Podcast Asylum site is on Dreamhost and the Backup Blog is on GoDaddy—and I don’t actually recommend either of them for WordPress hosting these days.) I got in touch with Melvin Ram, who walked me through installing the development version of the plugin, due for release next week sometime.

That fixed the problem: after clicking “Save Changes and Back Up Now,” I saw the following message:


That “Restore from a backup” tab is new in the development version; in the current version, 1.0.2, you have to download the backup and restore it manually. Not quite all the bugs are out of the restore process yet, though. I double-checked in S3Fox, and sure enough, the ZIP file was there.


I did notice, however, that while the ZIP file contained my wp-co
nfig.php file, my .htaccess file, and my wp-content folder, it was missing my WordPress database. (So was the one from So I might want to wait through a few more development versions before I completely replace WP-DB-Backup with Automatic WordPress Backup.

Nevertheless, I think WDC has made a great start with this plugin, and that it’s going to be extremely useful once they’ve got the bugs out.

Even Geeks Suffer from Data Loss

Tuesday, December 15th, 2009

Yesterday the Ur-Guru pointed me to a post on Coding Horror entitled “International Backup Awareness Day.” Coding Horror is normally a blog, and the permalinks to posts don’t normally look like the one I just pasted in there. Depending on when you read this, clicking on that link might get you a “404: Page Not Found” error. Thanks to catastrophic data loss, Coding Horror is only pretending to be a blog right now.

Here’s the story. Jeff Atwood, geek extraordinaire, hosted his blog on a virtual machine (VM) on a server at a web hosting company. VMs are great for developers, because you can simulate different operating systems in order to test your software on them, and you can take snapshots and re-create them easily.

Unlike Jeff Atwood or the Ur-Guru, I’ve never worked with a VM. To use them you need more RAM than I have at my disposal. I can see how it might be handy to have one to test backup software on without cluttering up the registry of my main machine, though. But apparently backing up the contents of a VM doesn’t work quite the same way as backing up your ordinary operating system and files. This is a setup for a very dangerous situation: when you think you have backups, but don’t. (Have I said “Test your backups” lately? Test your backups.) And this, it seems, is exactly how Jeff lost his blog:

  1. The server experienced routine hard drive failure. (Ed. note: hard drive failure is described as “routine.” In data centers, where drives are spinning 24/7, that’s exactly what it is.)
  2. Because of the hard drive failure, the virtual machine image hosting this blog was corrupted.
  3. Because the blog was hosted in a virtual machine, the standard daily backup procedures at the host were unable to ever back it up.
  4. Because I am an idiot, I didn’t have my own (recent) backups of Coding Horror. Man, I wish I had read some good blog entries on backup strategies!
  5. Because there were no good backups, there was catastrophic data loss. Fin, draw curtain, exeunt stage left.

Now, I don’t know what blogging platform Jeff was using. Given that he’s one of those extreme geek types, it could be something really obscure, even something he created himself. (Power geeks are like that; they’re as likely to insist on developing their own tools as to use anyone else’s.) I don’t even know what operating system his VM was running. But I know that there were ways to back up this blog when I was using Blogger (published by FTP to my own website), and there’s no excuse for not backing up WordPress blogs, since there are handy plugins to make it easier. And any offline blog editor like Windows Live Writer or Ecto will save local copies of your posts, so you can back them up along with the rest of the data on your hard drive. (Back in the days before Windows Live Writer, I used to write my blog posts in Microsoft Word, but you don’t actually want to paste from Word into anything that uses HTML. It did, however, mean that I had local copies.)

Jeff was able to re-build the text portion of his blog in HTML thanks to a fellow extreme geek who’s been archiving the Internet, but lost many of the images (which are not, apparently, on his hard drive, or not readily identifiable from among those on his hard drive). I shudder to think just how much work this must have been—and how much more work it will be to convert it back into blog format if he chooses to do that.

The lessons Jeff Atwood learned from the demise of Coding Horror are not just for geeks.

What can we all learn from this sad turn of events?

  1. I suck.
  2. No, really, I suck.
  3. Don’t rely on your host or anyone else to back up your important data. Do it yourself. If you aren’t personally responsible for your own backups, they are effectively not happening.
  4. If something really bad happens to your data, how would you recover? What’s the process? What are the hard parts of recovery? I think in the back of my mind I had false confidence about Coding Horror recovery scenarios because I kept thinking of it as mostly text. Of course, the text turned out to be the easiest part. The images, which I had thought of as a “nice to have”, were more essential than I realized and far more difficult to recover. Some argue that we shouldn’t be talking about “backups”, but recovery.
  5. It’s worth revisiting your recovery process periodically to make sure it’s still alive, kicking, and fully functional.
  6. I’m awesome! No, just kidding. I suck.

So when, exactly, is International Backup Awareness Day? Today. Yesterday. This week. This month. This year. It’s a trick question. Every day is International Backup Awareness Day. And the sooner I figure that out, the better off I’ll be.

Have you checked your backups lately? Now might be a really good time.

FileSlinger Backup Blog at Blogged


Blogging Blog Directory
Google Ads