Why can't OD make an automated daily dump of the database?

[Jay]

Recently XDR's software team retired their DB backup tool and made daily mySQL DB dumps, a basic feature of the latest version of XDR. New backup files don't overwrite the old but simply bear a datestamp. In future this may be doable more frequently in which case the files will bear a timestamp. To do this they created a new instance of the mySQL service called myXDR (to avoid clashes with OD) and appended the backup routine into their (already existing) License Checker service.

This is so convenient that I am curious why OD wouldn't do the same. That way users (especially newbies) would not have to worry about the following annoyances:

1. open DB files

2. using Crashplan Pro only because no other online service guarantees backups of open databases

3. writing batch files that stop mySQL, copy the DB folder and restart mySQL.

4. buying utilities that dump the DB e.g. dbForge Studio

5. Windows scheduler to make aforementioned batch files or utilities run on a schedule.

As most people here know, the dumped database can be copied like any other file by a whole host of online and local backup software services.

The backup engine already exists within the OD executable. A button in the Manage tab invokes it. Can't the software team just add a timer (as a Windows Service) to make the backup engine run automatically on a schedule?

Am I the only one or does anyone else here think this is a missing feature, not a feature request?

[jordansparks]

Just to the same machine as the original database? That would only cover one of the three necessary backup strategies. You'd still be missing backup to another machine and offsite backup. It would be of limited use.

In your list of annoyances, you seem to be under the impression that you can't backup a live database. This just isn't the case. No backup software or strategy that I'm aware of has any problem at all backing up the live database. The only time you need to stop mysql is to do a restore.

[Jay]

In your list of annoyances, you seem to be under the impression that you can't backup a live database. This just isn't the case. No backup software or strategy that I'm aware of has any problem at all backing up the live database. The only time you need to stop mysql is to do a restore.

I am sure it would work but things are a bit more complicated because in many instances this would constitute 'unofficial' use so in the event of a problem, the backup company would simply say, "We told you not to do this." Carbonite phone support, for instance, doesn't even want to talk about it. They just tell you not to use Carbonite to backup open database files.

A couple of examples

Carbonite's recommendations
http://carbonite.custhelp.com/app/answe ... -databases

Even Crashplan's seems to recommend dumping the database as a preferred strategy:
http://support.crashplan.com/doku.php/f ... y_database

[jordansparks]

The link on the CrashPlan website doesn't recommend dumping as the preferred strategy. It lists it as one of the two acceptable strategies. As for Carbonite, they are just taking the easy way out. We've been doing it for 10 years without any problem.

[wjstarck]

That's right.

We have been using Carbonite to backup our OD Database for well over a year now and it backs up OD without any problems when it is running (we've restored from these backups to confirm).

The only hitch seems to be if you're running plugins - sometimes the file seems to be locked by Carbonite so occasIonally OD can't access it and you'll get an error. So our workaround is to set Carbonite's schedule to not backup during our regular business hours and that fixes it.

Carbonite has recently lowered their plan prices so it's really quite affordable. The only downside I have found with them is if you want them to overnight you a hard drive of your backup (you may want to do this because images can take 1-2 days to restore, or more depending on the size of your internet pipe) they won't do it because of HIPAA.

We recently had a potential catastrophe averted when I recently upgraded our VMWare Esxi from 4.1 to 5.0. The datastore that holds the VMs was supposed to be left untouched by the upgrade but was completely erased. I recovered everything with Carbonite. The images (we have about 25 GB) took about a day to get back, but we have a fairly hefty FIOS pipe (30 up /45 down).