Slashdot Log In
NetBSD - Live Network Backup
Posted by
Zonk
on Fri Apr 29, 2005 09:55 AM
from the de-backup-mouse dept.
from the de-backup-mouse dept.
dvl writes "It is possible but inconvenient to manually clone a hard disk
drive remotely, using dd and netcat. der Mouse, a Montreal-based NetBSD
developer, has developed tools
that allow for automated, remote partition-level cloning to occur
automatically on an opportunistic basis. A high-level description of the system has been posted at KernelTrap. This facility can be used to
maintain complete duplicates of remote client laptop drives to a server
system. This network mirroring facility will be presented at BSDCAN 2005 in Ottawa, ON on May 13-15."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Mac OS X (Score:1, Interesting)
use rsync (Score:2, Informative)
(Last Journal: Monday September 25 2006, @01:19PM)
Re:use rsync (Score:5, Informative)
As the article says, this is drive imaging whereas rsync is file copying.
Pros and Cons (Score:5, Insightful)
On the flipside, this would be a boon to company network admins especially with employees at remote sites who have a hard crash.
Another reason to build a high speed backbone. Getting my 80GB harddrive image from Seattle, while I'm in Norfolk would be a lot of downtime.
Perfect for those moments... (Score:4, Interesting)
(http://www.intergalacticbasement.com/)
Now we can just hit a button and restore everything, a few thousand miles away.
The only thing left is to write code to block stupid people from reproducing.
Re:Perfect for those moments... (Score:4, Funny)
Unfortunately the user interface for the relevant hardware has a very intuitive point and shoot interface.
How long before this becomes a hack? (Score:4, Insightful)
(http://www.identityinitiative.com/)
Done this for years (Score:5, Funny)
Dump? (Score:1)
Maybe setup is inconvenient. (Score:3, Informative)
How does this handle active filesystems? (Score:2)
Automatic Backup for Paranoids? (Score:1)
Well, I'm not really paranoid, but I had some cases where faulty file system drivers or bad RAM modules changed the content of some of my files and where I have then overwritten my backup with these bad files.
Isn't there any automatic backup solution that avoids such a thing? What I have in mind: there should be several autonomous instances of backup servers (which may actually reside on desktop PCs linked via LAN) that control each other on a regular basis. They should also keep back old versions of files as far as disk space allows.
Then, there should be a KDE tray applet showing me the state of the backup server network. It would indicate if servers haven't been cross-checked for some time or if CRC errors or general malfunction problems have occurred.
Wouldn't that be nice? Never ever care again for your backups. It's all done in the background and in a total paranoid manner.
Meh. You can use DRBD on Linux anyway. (Score:1, Informative)
Right solution, wrong problem (Score:3, Interesting)
(http://sourcery.blogspot.com/ | Last Journal: Tuesday September 18, @11:53AM)
Most (all) of my quick restore needs result from users deleting or overwriting files - the hardware is more reliable than the transaction. I do have on-disk backups of the most important stuff, but sometimes they surprise me.
I'd like a system library that would modify the rename(2), truncate(2), unlink(2), and write(2) calls to move the deleted stuff to some private directory (/.Trash,
Just a thought.
Re:Right solution, wrong problem (Score:5, Informative)
I'd like a system library that would modify the rename(2), truncate(2), unlink(2), and write(2) calls to move the deleted stuff to some private directory (/.Trash, /.Recycler, whatever). Obviously the underlying routine would have to do its own garhage collection, deleting trash files by some FIFO or largest-older-first algorithm.
Done. [netcabo.pt]
nothing new (Score:2, Interesting)
(http://ranko.homelinux.net/)
It is nice though to have something like this in the open source world though. Competition is good.
How Soon (Score:1)
SIGS!!!We don't need no stinkin sigs
Wacky idea (Score:3, Insightful)
I was thinking - I know how Ghost supports multicasting and such. I was thinking about how to take that to the next level. Something like Ghost meets BitTorrent.
Wouldn't it be great to be able to image a drive, use multicast to get the data to as many machines as possible, but then use BitTorrent to get pieces to any machines that weren't able to listen to the multicast (ie it's on another subnet or something) and to pick up any pieces that were missed in the broadcast, or get the rest of the disk image if that particular machine joined in the session a little late and missed the first part?
I think that would really rock if someone wanted to image hundreds of machines quickly and reliably.
I'm thinking it'd be pretty cool to have that server set up, and find a way to cram the client onto a floppy or some sort of custom Knoppix. Find server, choose image, and now you're part of both the multicast AND the torrent. That should take care of error checking too, I guess.
Anybody care to take thus further and/or shoot down the idea?
How does this compare to md over a network block (Score:1, Insightful)
I'm asking because I'm backing-up about a dozen servers in real-time using this method, and if this method is more efficient, then I might be able to drop my bandwidth usage and save money.
dd over a LAN (Score:1)
ghost 4 unix (Score:3, Interesting)
http://www.feyrer.de/g4u/ [feyrer.de]
This is great (Score:2)
And since we're running OpenBSD on those machines, porting this should be fairly straightforward... although now that I look at it, he adds some patches for sockets... eugh...
Scalability Forking? (Score:2)
(http://slashdot.org/~Doc%20Ruby/journal | Last Journal: Thursday March 31 2005, @01:48PM)
WTF (Score:5, Informative)
First of all, it means backing up a 40GB with 2 GB of data may actually take 40GB of bandwidth.
Second of all, it means the disk geometries have to be compatible.
Then, I have to wonder if there will be any wackiness with things like journals if you're only restoring a data drive and the kernel versions are different...
I have been using ufsdump / ufsrestore on UNIX for
# ssh user@machine ufsdump 0f -
or
# ufsdump 0f -
So -- WHY are you people so keen on bit-level dumps? Forensics? That doesn't seem to be what the folks above are commenting on.
Is it just that open source UNIX derivative and clones don't have dump/restore utilities?
The Dark Side of Image Backups (Score:5, Informative)
(http://www.backupcritic.com/ | Last Journal: Friday October 15 2004, @01:02PM)
Image backups certainly have their place for people who can understand their limitations. However, a good, automatic, versioning file backup is almost certainly a higher priority for most computer users. And under some circumstances, they might also want to go with RAID for home computers [backupcritic.com].
the shared secret (Score:1)
----------- Confucious say: "The shared secret is no longer a secret."
Have this been invented? (Score:1)
(http://www.michel.eti.br/ | Last Journal: Thursday December 15 2005, @09:47AM)
rsync does a fine job for backups. (Score:1)
It makes it alot easier to find a file, cause it exists in the same location, uncompressed.
The huge advantage though, is that rsync only transfers those files that have changed. Which means that backups are very quick.
I also mount samba shares on the backup server, and do rsync backups of "My Documents" folders for the windows boxes. Works great there too!
Even better, the My Documents folders are available as (read only) Samba shares on the backup box, and the users can find their own files in the backups.
I have been doing this for years, and it works great!
Not scalable. (Score:3, Interesting)
(Last Journal: Tuesday October 30, @10:59AM)
Now, rsync would have been fine if we'd unmounted the filesystem and done it on the raw partition. But there's a couple of problems with that:
It's not live. Not a big deal for us, since it's a backup machine to begin with, but still...
rsync doesn't do that. A couple of people have submitted patches to allow a flag for rsync to copy block devices as if they were files. They were tiny patches, but they were rejected out of a fear of users doing stupid things with them. I guess the usual Rsync Way is to duplicate the filesystem, so that devices are copied with mknod, not dd.
Re:BSD is 10 years too old (Score:1)
(http://slashdot.org/)
Re:DOS of the backup server (Score:3, Insightful)
This is a good idea, even if its niche is small, but I'm interested in how it handles the encryption. If it doesn't allow key re-generation on the fly, HMACs, certificates (or at least PSKs) and other things we expect from modern (SSH, IPSec/IKE, etc) systems then it's not going to be very useful. And unless I missed something it's going to be difficult to tunnel through a system that does do these things.
Personally I use SSH to tunnel everything possible, especially from Windows where IPSec is a joke, and the thought of sending all of my disk writes over a security system that is any less secure is a worry. Just imagine the problems if a man in the middle (or just a sniffer) catches plaintext: they know what you're doing, they know the contents of what you're doing, and highly likely they know what to do to exploit what you're doing. It's a very good thing that system entropy under nix is stored in the kernel, not on disk
Re:der Mouse? (Score:2)
(Last Journal: Tuesday October 03 2006, @07:58PM)
It does seem wrong to allow for an anonymous developer as NetBSD has, Mike Parker sounds much better than der Mouse.
That they allow this is their choice however, that he is bitter about Theo de Raadt and his OpenBSD project does not warrent that kind of behaviour true, but it is up to NetBSD to choose what they view as proper behavoir within their developer circle.
They made that choice with Theo years ago, maybe with time they will choose to reign Mike in. Mike doesn't seem to be counted amoung the core developers, so it's not exactly the same as the situation with Theo however.
Perhaps this reflects poorly on the level of maturity of the developers on the project, but it is the choice of the developers.
And you cannot base your feelings about someone's programming based on their behaviour, or everyone would hate OpenBSD for Theo being a dick.