Slashdot Mirror

← Back to Stories (view on slashdot.org)

NetBSD's Real-Time Network Backup

Posted by ryuzaki0 on from the old-hardware-power dept.

jschauma writes "One of NetBSD's developers, der Mouse, was interviewed by DaemonNews about his real-time network backup system (originally presented at BSDCan 2005), where changes to your local filesystem are automatically propagated to a backup server. In his interview der Mouse tells about his idea, how it works, and of course, how cool it is."

15 of 166 comments (clear)

  1. Correct me if I'm wrong by thedletterman · · Score: 5, Interesting

    But hasn't Sun been doing this with Solaris for at least 3 years?

    --
    Any fool can criticise, condemn, and complain, and most fools do. - Benjamin Franklin
    1. Re:Correct me if I'm wrong by operagost · · Score: 4, Interesting

      OpenVMS has been doing this for even longer using volume shadowing.

      --

      Gamingmuseum.com: Give your 3D accelerator a rest.
    2. Re:Correct me if I'm wrong by Anonymous Coward · · Score: 1, Interesting

      I run solaris on non-sun x86 server hardware. For what we do, none of the linux distributed clustering solutions are as good as solaris.

  2. B.S. D? by ExE122 · · Score: 1, Interesting

    So we could have backup servers all over the world keeping track of disk write commands...

    This is indeed very neat, but isn't it sorta how transactional databases have been working?

    I also don't see how this solution is effectively any better than RAID... If anything, a backup server is more expensive than a second hard drive for a RAID system (though it may pay off eventually). I'd think the backup server would need to be maintained as well... and if your backup ever fails, it seems like it would require a lot to set up another.

    There also seem to be a lot of limitations as far as network security, filesystems, encrypted files, etc go. Furthermore, I don't see how the bandwidth hit is worth it (though I guess that depends on where your priorities are).

    Admittedly, I'm no expert on this topic... so am I totally missing something?

    --
    Capitalism: When it uses the carrot, it's called democracy. When it uses the stick, it's called fascism.
    1. Re:B.S. D? by dpilot · · Score: 2, Interesting

      I don't actually run RAID, but I've gotten some interesting stories from some (more than 1) people who do.

      In a RAID cabinet, you have a bunch of identical drives, most likely purchased together, too. Then you submit them to an essentially identical environment and operating history. Barring a defect, and assuming wearout-type phenomena, something bad may well happen.

      The weakest drive fails first. Power down the RAID box to replace the bad drive, so you can bring it back up and restore the data. The stress of the power-down and restart is enough to kill the second-weakest drive. Now you have to go back to tape, and RAID didn't do squat. This doesn't happen all the time, but it's surprisingly more likely than you'd think - enough so that they've quit using RAID as "backup".

      Another alternative would be using different drive models, or finding some other way to change the vintage/history issue. Hotplugging drives while leaving the cabinet up would be another good idea.

      --
      The living have better things to do than to continue hating the dead.
    2. Re:B.S. D? by MonkeyOfRage · · Score: 2, Interesting

      I also don't see how this solution is effectively any better than RAID... If anything, a backup server is more expensive than a second hard drive for a RAID system (though it may pay off eventually). I'd think the backup server would need to be maintained as well... and if your backup ever fails, it seems like it would require a lot to set up another.

      I only skimmed TFA and it's not clear to me how like or unlike Windows' Distributed File System it is, but I'll give you a quick picture of what DFS does for us here to give you a better idea how NetBSD's backup could be handy. We've got a primary and secondary server, each with its own RAID array, and DFS isn't a replacement for it - it's a supplement to it. I'd consider this to be the same.

      For starters, when your server fails your RAID array goes with it. The data's fine of course (knock on wood), it's just not available until you either fix the server or shuffle the array into another system. Compound that with the fact that I only drop by here a couple times a week, and I'm the only person who could do this work (we're a small office). When that failure happens, the data would probably be offline for hours at minimum, and that would be a hardship in this environment. Having our data perpetually backed up on another working system that's just waiting to take over is easily worth the trouble and expense of a second system.

      In addition, DFS doesn't actually record a duplicate copy of the whole disk's file system (one-way to the backup server), nor does it work in the transactional manner that I picture this working, but it replicates files within a special share both ways. You create this share, and it isn't actually on either server - it's on BOTH servers. DFS decides which one to use and keeps the copies synchronized. If the primary server catches on fire, gets stolen, explodes etc., users would hardly notice. There's a little lag in replication sometimes, so something very recently saved in the primary copy of the share might not actually be in the secondary yet. Aside from that, almost everything else just keeps working.

      The bandwidth could be an issue in another environment, but this particular server only gets a mild-to-moderate workout, and DFS is able to keep up. There are a couple database applications that I only allow to replicate one-way because initially DFS started to choke trying to keep it synchronized both ways. For those, someone would have to switch the clients manually from using one server to using the other. Aside from those two, I can reboot either server at will without ever disturbing a user. I think that in the worst case, this is what you'd need to do with NetBSD's backup.

  3. Neat. by Pig+Hogger · · Score: 3, Interesting
    This is definitely the way to go. With huge hard-disks that offer capacities beyond tape drives, it is less and less feasible to use traditionnal tape-based backup systems in many organizations, if only by the time taken by the frigging tape drive...

    Here is the idea behind the setup I am currently using: Easy Automated Snapshot-Style Backups with Linux and Rsync.

    1. Re:Neat. by Lord+of+Ironhand · · Score: 4, Interesting

      I prefer Dirvish, and I highly recommend that people looking for a good harddisk-based backup system take a look at it. I've looked long and hard for a good backup system and this is the first that seems to fit the bill for me.

  4. How is this different from Windows VSS? by YU+Nicks+NE+Way · · Score: 1, Interesting

    Volume shadow storage is exactly this kind of incremental, real-time backup process. How does this differ technically from that? (Other than the fact that you can now dynamically back up your morning toast, which is useful if a slice goes up in flames...)

  5. Good idea, but there has to be a better way by TheFlyingGoat · · Score: 3, Interesting

    This idea is really cool, but implementing it by putting hooks into each device driver seems overly complicated. It also doesn't sound like they're any sort of priority setting for this or any type of data filtering.

    Personally I'd like to see something like the MS filesystem in development that allows SQL calls to be run against it (not sure if there's any other filesystems that are similar). Query every 5 minutes for changed data that fits the backup parameters (within the system dir, the user's home dir, certain filetypes) and then transfer the data as the network isn't being used.

    That would achieve the same thing, but more flexibly and without affecting normal use.

    --
    You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
    1. Re:Good idea, but there has to be a better way by jcgf · · Score: 3, Interesting
      A hook into each driver does seem like a strange way to do this, you would think that it could be done once at a higher level.

      Query every 5 minutes for changed data that fits the backup parameters (within the system dir, the user's home dir, certain filetypes) and then transfer the data as the network isn't being used.

      Then you loose the realtimeness.

    2. Re:Good idea, but there has to be a better way by ivoras · · Score: 4, Interesting
      This idea is really cool, but implementing it by putting hooks into each device driver seems overly complicated.
      FreeBSD's GEOM is solving that: http://www.bsdcan.org/2004/papers/geom.pdf

      Also, there's "GEOM gate" on FreeBSD: http://garage.freebsd.pl/GEOM_Gate.pdf
      For other cool stuff with GEOM see here and here. See also this discussion thread about ggate's limits.

      --
      -- Sig down
    3. Re:Good idea, but there has to be a better way by Jack9 · · Score: 2, Interesting

      Device drivers would be the best solution for me. I want an exact copy of what I wrote to a physical drive. Hook, encrypt, send to another HD to repeat. Realtime, low-level. This allows it to be relatively fast (as opposed to having to process through layers of abstraction), accurate (as opposed to something an abstraction might do to it), and realtime...

      I want dual transactions. 1 for onsite and 1 for offsite. I'm not even interested in encrypting the data. I need to be able to kill my onsite immediately and failover to the offsite with a simple endroute change. I need to be as realtime as possible...Why would I want a 5 min backup? I can get near-realtime NOW with many of the systems in this thread; I just want nearer.

      --

      Often wrong but never in doubt.
      I am Jack9.
      Everyone knows me.
  6. Invented by Larry Robertson in the mid 1980s by Anonymous Coward · · Score: 1, Interesting

    Larry Robertson came up with this concept in the mid 80s as I recall, implemented it for VMS way back then as a remote shadowing system. He told me about it in one of the Anaheim DECUS meetings back then, published it (his company being called Bear Software back then). While the idea was not patented, the idea of moving updates wide area and doing local journalling so that the "shadow" needed only to keep up with average write I/O rates, rather than peak write rates, was AFAIK new back then and he deserves credit for thinking of it and implementing it. If anyone should try to patent it, he could be contacted also to show prior invention and public description. (Another outfit that came out shortly later with something similar had, as I have been told, a copy of the Bear program in house. That suggests my belief is correct that Robertson came up with the idea first, and that duplicate invention did not occur there.)

  7. Re:accidental deletion? by Umrick · · Score: 2, Interesting

    What I want is something like Plan9's Fossil+Venti file system. Versioned, with permenant copies offloaded to archive media. It's a rather nice, though not blazingly fast, complete view of data. Not the rather ephemeral view most of us take. Restore to any point in time since inception.

    Failing that, something like OpenAFS with mirrored globally addressable volumes that can work at the system level rather than user level. Sure you can use IP security for OpenAFS, and a few brave folks have even gotten network booting to OpenAFS working... Again, snapshots are an option.

    The world view of data should really be 1. Create 2. Version 3. Archive. Instead we have as-it-stands-now and arbitrary-backup-in-case-of-failure-or-user-stupid ity. Sure some people do put /etc under SVN/CVS control, but not many.