Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking into FreeBSD to provide a more comprehensive backup and disaster recovery strategy for database servers. Ideally I want to mimic what google is doing with "Persistent disks"

I am hoping someone who knows more about FreeBSD can validate these ideas/questions:

  1. I have read that FreeBSD can take instant disk snapshots, therefore if our databases trigger a consistent state (Block all writes, and flush buffers to disk), I would assume I could take snapshots every hour without service interruption for more than a few seconds. Is this true?
  2. Is there a way to take snapshots and back them up offsite easily? Can this be done incrementally as to save how much disk space is actually used?

  3. If a rollback needed to be done, how long does this typically take? Is a rollback also instantaneous?


share|improve this question
Is FreeBSD a requirement? – ewwhite May 31 '14 at 7:31
No, FreeBSD is not a requirement, but it seemed like low hanging fruit. – Casey Jordan Jun 4 '14 at 16:16
up vote 3 down vote accepted

I recommend you use FreeBSD with ZFS. See the FreeBSD handbook's section on ZFS at . And FreeBSD 10 has some major improvements over earlier versions.

  • ZFS can take instant disk snapshots without any noticeable service interruption. Many shops do this this with MySQL & Postgres databases. Oracle database administrators do this using Oracle Solaris & ZFS.

  • ZFS snapshots can be rolled back.

You can backup the .zfs/snapshot directory using your regular backup software. I have heard of people using zfs send and zfs receive for this purpose, but we couldn't get it to work. In theory, you could do something like zfs send | mybackupsoftware --hostname and store the image offsite.

   zfs send [-vR] [-[iI] snapshot] snapshot

   Creates  a  stream  representation of the second snapshot, which is
   written to standard output. The output can be redirected to a  file
   or  to a different system (for example, using ssh(1).

   zfs receive [-vnF] filesystem|volume|snapshot

   Creates a snapshot whose contents are as specified  in  the  stream
   provided  on  standard  input
share|improve this answer
Very cool, this is exactly what I needed confirmed. Thanks! – Casey Jordan May 30 '14 at 19:44

FreeBSD can do UFS snapshots (the process is described in the handbook). Many operations (mine included) take advantage of this by quiescing a database (we do a full shutdown on our slave DB), making a snapshot, then reactivating the database.
The snapshot can then be mounted and backed up using your regular backup tools (in our case Bacula).

(For more drum-banging on how UFS is awesome, see here).

The big disadvantage I see is that UFS snapshots can't be (easily) rolled back - the most efficient technique I'm aware of is to rsync data off the snapshot (which isn't very efficient because of the nature of UFS snapshots), but for making backups they're usually fine.

As Stefan points out ZFS may be a better choice.
ZFS has a number of advantages over UFS for something like a database (like the ability to quickly and easily add more disk space to the partition if you outgrow it, and the ZFS Send/Receive capability for moving snapshots around).

Another advantage of ZFS is that snapshots are effectively "free" (ZFS is a non-overwrite filesystem so all it does is not reuse any sectors in the snapshot - UFS needs to do some extra bookkeeping while the snapshot exists), and you can make them writeable if you have to.

The only disadvantage of ZFS that I can think of is it's memory hungry, particularly compared to UFS. You will want to think about that (and about tuning ZFS) before rolling it out in production.

share|improve this answer
Note that for both UFS and ZFS you may not have to quiesce your database (for example, Postgres would happily recover if I just took a snapshot with the DB running - it would declare an "unclean shutdown" and replay its transaction log). We do the shutdown mainly as an extra level of paranoia, to guarantee that the database is "ready to start immediately" with no replay required in the event we need to go to our backups. – voretaq7 May 31 '14 at 4:05
So you suffer downtime every night in order to shorten the time window for a presumably very rare DR scenario by at most a few minutes? That makes zero sense. – rmalayter May 31 '14 at 6:09
@rmalayter read carefully: we do a full shutdown on our slave DB. There is no "downtime", merely a ~1 minute window where the slave is not replicating from the master (during shutdown/restart). This is (IMO) entirely sensible in order to have a 100% guarantee that the backup is of a clean, consistent database that will restart with no issues every time. These backups are also regularly restored to our QA environment (both as a restore test and for QA testing purposes), so it's saving "a few minutes" quite often. – voretaq7 May 31 '14 at 6:22
Thanks this info is really good. Based on what you have said I think ZFS is better suited for me, specifically because I want to take snapshots at 30min intervals (Forcing a very brief < 5s pausing of database operations each time), and be able to rollback very quickly. The memory issue is concerning, but I expect no single server will have over 1TB of data. I think with out setup I could easily give ZFS 1GB-RAM/TB-Disk. Any thoughts on this? – Casey Jordan Jun 4 '14 at 16:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.