I am confused with Mac OS X Server Time machine backup plan

Hello,

I have no answers, but I am trying to solve a similar problem. This is in a school network setting.

Using Carbon Copy Cloner, I have sucessfully cloned my 10.6 Server RAID 1 system to an external FireWire drive. However, I now realize that because of the way RAID must be spread over two disks, I won't be able to boot from that single FireWire disk clone and so the clone does me no good as a backup. I am at a disappointed loss as to how I may proceed to create a user-friendly backup for the server.

I wonder if I'd have been better off not to use RAID in the first place rather than to loose the battle-tested power of a bootable CCC clone of my entire system . . .

I have no answers, but I am trying to solve a similar problem.

Then please don't threadjack. Your question has little or nothing to do with the original post, so consider starting a new thread rather than distract from the original poster's question.

Time Machine is not like many other backup solutions, it is especially not the same when it comes to backing up server environments which typically have very different requirements than client systems.

The answer to your question lies in understanding what you're trying to achieve in terms of backup and restore. If you want to be able to quickly reboot your machine from a backup in case something goes wrong with your main installation, then Time Machine is not for you. That's not where Time Machine's strength lies.

It is possible to rebuild a machine from a Time Machine backup (boot from the install DVD and choose to restore from your Time Machine backup, but that's a lengthier process than just switching boot devices.

On the other hand I have never, and would never, trust a tool like CCC for backing up my server. I know other people do it, and I guess it depends on what you do with your server, but for any kind of dynamic content you have to be careful about how you back it up.
AFAIK, CCC can't, for example, backup live MySQL databases that are in a state of constant flux. What's the good of your clone if you can't trust the data you restore?
That's not to slight CCC (or any other entire-disk based backup solutions, but it's just a fact of life in dealing with server processes.

In a server environment you will need server oriented backup software, such EMC's (previously Dantz) "Retrospect for Mac", Tolis Group "BRU", Backbone's "NetVault", or MacKeeper's "Mac Disk Recovery" software. Server backup software has the ability to capture opened files, many times has available agents for sql engines that will allow you to back up open datafiles without having to shut down the engine first, and they all do incremental backups (getting only those files that have changed since the last backup). Time Machine in SLS really is not there for the server, but is there for client backup operations.

... you will need server oriented backup software, such EMC's (previously Dantz) "Retrospect for Mac"...

No you don't, unless you really want to deal with angry users complaining about server outages.

The other packages might work well, but Retrospect is an absolute dog that has an awful history of crashing servers. Don't use it. A quick search on the boards here will turn up a slew of issues related to Retrospect (including weird, apparently unrelated issues that 'magically' go away as soon as Retrospect is uninstalled).

I haven't heard anything recently that tells me EMC have fixed the issues.

There is must something I misunderstand, would you please give me some suggestion?

In order to provide robust, continuous server operation you need two servers (or more).

Apple's point is correct in that Time Machine on Mac OS X Server won't backup internal data, but that's not to say that it can't be backed up.

The recommended method involves replication, whereby multiple servers continuously replicate the data. In this way changes made on server 1 are automatically copied to server 2.

Now, if server 1 dies, server 2 can take over the load while server 1 is rebuilt, and it can sync the data back from server 2 when it comes back. In this way you don't lose any data, including changes that were made while server 1 was offline, or changes since the last backup.

Most of the server-based applications support replication. MySQL does, Open Directory does, DNS does, it's just a matter of configuring the second server.

Replication is the only way to obtain a reliable backup of your server data without taking it offline.

If you don't mind taking your server offline while the backup runs, then CCC (or similar) should work. There's just no practical way that a backup that takes any significant time to execute can keep up with constantly-changing data.

Camelot,

Sorry to hear you've had so much trouble with backups. From your post, I guess you know something that CA or Tivoli doesn't. Your method may work, but not if you have a site power or fire failure, want to have a cost effective solution (requires complete servers), or have off-site backups (to take one off-site for storage you will have to buy another server), not to mention various compliancy issues.

I have been using BRU for some time now, backing up two OSX minis, a DroboPro w/4TB, and a W2K3 server, with limited problems, no user interactions or outages, and, save for having to shut off the sql engine before one short backup, no outlying problems. The cost was less than $300.00 for software, including agents, and less than $300 for a 1TB staging drive.

Sorry to hear you've had so much trouble with backups

On the contrary. I have no issues with my backups. What gave you that idea?

From your post, I guess you know something that CA or Tivoli doesn't.

If you're referring to my umm... disdain for Retrospect I would have to assume they're aware of the problems running their product on production Mac OS X Servers. It's not hard to find references to people running into problems with it. If they're not aware then their support escalation process needs work.

Your method may work, but not if you have a site power or fire failure

OK, you lost me there. Which method are you referring to? replication? That's entirely viable as a protection against power or fire - locate the replica in a different datacenter/office/whatever.

want to have a cost effective solution (requires complete servers)

How valuable is your data? How much does downtime cost you?
How much does a second server cost?

or have off-site backups (to take one off-site for storage you will have to buy another server)

See my point above.

not to mention various compliancy issues

If you're dealing with any of the major compliancy issues (e.g. SOX, HIPPA, PCI, etc.) then the cost of a replication server is trivial compared to the cost of even thinking about compliance (most consultants charge thousands of dollars just to walk in the door and say 'hi').
Not to mention that any of the above compliance rules pretty much require replication, and you taking a weekly (or even daily) copy of your disk home with you is just not going to cut it.

I have been using BRU for some time now

I have a lot of respect for BRU. One of the better options out there (assuming they fixed the awful UI issues they had in early versions).

save for having to shut off the sql engine before one short backup

Thank you for validating my statement - you cannot backup an active server without terminating services that are writing to the disk.

Of course, in the replication model, you could temporarily stop replication, shut down the service, perform your backups, then restart services/replication (which will automatically catch up with the intermediate changes), while allowing clients to continue talking to the primary server.
THAT is the definition of performing backups of live data/servers without impacting users.

When is a server not a "continuous" server? By nature, any box providing services to a community of clients in 24x7 is a "continuous" server.

Trust Apple's document regarding what is not backed up using Time Machine for SLS. Having not read the caveat we flattened a box and restored using the TM backup and found that just about all of the services had to be reinstalled and reconfigured because the configuration files were not backed up. The users home directories are in the backup, but many system files are not. You will have to use something else to get them backed up.

As to using CCC. I use it to create a bootable image of my server on a separate partition to allow me to boot without the dvd and to run disk warrior and other utilities on the main partition. The limitations of CCC is that is only does full volumes: you can't select from individual directories. For example, it doesn't allow you to back up just the home directories if they're not on a separate volume. It's good for full backups, but can't give you "snapshot in time backups" (no way to respond to "Please restore file XXXX from Monday September 27 at 10:00A as well as the version from Sunday, September 26 at 6:00P")

You want something that will give you weekly/daily full/incremental backups. Look at "Data Backup" by Prosoft. It's economical ($59.00) and you can run scheduled copies (full or incremental) of selected directories or files.

Camelot,

Offsite redundancy is normally not an answer for most businesses because of three major impediments: latency, bandwidth, and cost. In order for a remote file server to be usable as a failover or backup it must be able to respond consistently within a short period of time, usually within < 20ms. To get that speed from offsite systems of some distance away you will need to have big dedicated site-to-site pipes, such as OC3s or OC48s, especially if you are intent on backing up gigabytes of data. An 8/3 asymmetrical won't cut it because it will take you 45 minutes just to get 5G down, and over 20 hours to push up the data to replicate a single server of 100GB. To get speed you have to pay, and business quality internet costs big (99.97% uptimes, >95% speed guarantees). Average cost for 8/3 is about $200 per month, 20/5 about $400, with 20/20 symmetrical will set you back around $600 per month (TimeWarner for metro LA, XO is higher). This is why you find that only large firms who can support the connection and support costs (Microsoft, IBM, Safeco, Chase, etc.) will deal with multi-site redundancy (Microsoft does it for load balancing site across the world, for example).

You state: "If you're dealing with any of the major compliancy issues (e.g. SOX, HIPPA, PCI, etc.) then the cost of a replication server is trivial compared to the cost of even thinking about compliance (most consultants charge thousands of dollars just to walk in the door and say 'hi').
Not to mention that any of the above compliance rules pretty much require replication, and you taking a weekly (or even daily) copy of your disk home with you is just not going to cut it."

HIPAA, PCI, PI, and SOX do not require redundancy, they require data security, which you are forced to do regardless of your business size (if you handle it, you've got to secure it!). FAA requires redundancy and offsite dead backups. Business sense requires backups: incrementally daily and full weekly and monthly with the weekly and monthlies being taken off-site and stored. If you do run redundant non-local systems each system will have to be in compliance and the connection between them will have to be hardened to be non-penetrable (also in effect if you are shuffling PCI [credit card info] between sites).

As to having to deactivate services to run a backup, this only occurs if the software you are using does not have a database engine agent, which BRU does not. BackupExec and Tivoli both do, and thus do not require any interaction on the part of an admin to function. But they are also $$$ systems (Tivoli will easily set you back $100,000).

Let's agree to disagree 🙂

Offsite redundancy is normally not an answer for most businesses because of three major impediments: latency, bandwidth, and cost

That's assuming you're trying to perform backups over the WAN link. I'm not suggesting that.
What I suggested was replication, which is entirely different.

Here's an example:

You have a MySQL database with 1 million rows of data in a table, consuming 2GB on disk.

You perform an update/insert query that changes one row of data.

Backup: most backup software notices that this 2GB file has changed and copies the entire 2GB file over the WAN (slow).
Replication: MySQL replication sends the update/insert query to the remote server (tens to hundreds of bytes). When the remote replica gets the query it executes and updates its tables. The data remains in sync with little overhead.

That replication does not require a high-bandwidth, low-latency link.

The same is true for Open Directory replication (only copies changes to the directory, not the entire directory). Other services may do the same.

In either case, my point is that replication is often a better solution for backing up high-availability data (where it's inconvenient to take the server offline to backup files at-rest). Whether that replication is local or across the country doesn't really matter.
I did not say that replication was an alternative to backups - replication isn't going to maintain a user's home directory, for example. For many cases you may find a combination is required - replicate your dynamic data, backup your configuration files/user data/etc..