Les Mikesell <[email protected]> wrote on 09/10/2009 10:38:56 PM:
> Maybe I'm not making this clear. I want the physical backuppc host > to be able > to mirror its current 750 GB backuppc partition onto what appears at > the time to > be a virtual partition, but which results in the updating of the files that > comprise a vmdk disk. Backuppc isn't running on a VM. After this step > completes, I want to rsync those files to copies elsewhere. At the other > location, I might want to access the vmdk from a VM if it is necessary to > restore something. So you're attempting to convert a physical BackupPC server into a virtual image? VMware has conversion tools that do this. I've only used the Windows version of VMware Converter, but it has worked perfectly for converting a physical host into a virtual host. There is a Linux version. I would look into this, rather than trying to do a poor-man's version of it. It's a very simple process, and after a somewhat long wait (but shorter than doing a RAID1 rebuild) you will have a brand new virtual clone of your physical box! And if all you're doing is to try to capture a file-based version of your block device (a physical partition) that you want to mount using some other physical server (or even a virtual server, come to think of it), I think you'd be *far* better off just dd'ing the partition into a file and using a loopback mount to mount it someplace else. In other words, the only time you should be dealing with VMDK files is if you're trying to create a new virtual guest. And if you are doing this, the proper way of doing this is *not* by trying to use LVM/RAID weirdness, but using the VMware Converter tools to do this for you properly. If you're *not* trying to create a new virtual guest, then don't mess with VMDK files. They're an annoyance that should only be dealt with if you actually have to. > > I think you need > > to really think long and hard about the hoops you're trying to jump > > through. The logic that you'd use for a physical machine is obselete when > > you're dealing with VMware. Just copy the native files as native files to > > another machine with VMware server, and start the host. That simple. > > I need to get the image of my working system on there in the first place. OK, then what I explained above is probably correct. The way you do this is by using the VMware Converter tools, not by trying to do it yourself! :) > > Again, what is your logic here? You don't move the contents of a block > > device from one guest to another. YOU MOVE THE ENTIRE GUEST. Period. > > This is so, very, very way better than what you're trying to do. > > The point is to get the data which is on a physical host partition > into a vmdk > that can be copied as a set of smaller files - and used that way > directly if needed. Yup. Use the conversion tools. > > But you can't get VMware for OpenSolaris! :) I hate to tell you, ZFS > > buys you *NOTHING* in this situation. You'll be forced to use VMware > > snapshotting anyway, in which case you no longer *need* filesystem > > snapshotting. > > Virtualbox seems to be a reasonable match for VMware these days. Itcan even > use vmdk format disks directly. With zfs I'd be able to use the incremental > send/receive function which would likely be even better than > rsync'ing the files > sitting on top of it. VirtualBox compares fairly with the free VMware Server, but VMware server is about 10% of what you can do with VMware--with the paid-for tools. When it comes to commercial tools, VMware is in a class by itself, though Citrix is trying hard with XenServer (still too cumbersome and unpolished compared to VMware, and requires VM hardware for Windows). When it comes to free-as-in-beer, XenServer is the best. It's still cumbersome, but they give you several of the items for free that VMware charges for. VirtualBox is neither the best tool overall, nor the best tool for free. And unfortunately, the GPL'ed code is only a fraction of what you really need for a usable virtualization environment. If you want GPL tools, KVM (especially in RHEL 5.4) is the best around. The only advantage that VirtualBox has is that it runs on OpenSolaris (or OS/2...). For me, that's a non-feature. Obviously, YM *does* V... :) Interesting thoughts. I've never been a fan of running BackupPC inside of a virtualized guest. Basically, my philosophy is to put as little between my backups and the hardware as possible. I don't even use compression on my backups! The idea of putting my backups inside of a virtual disk on top of yet another filesystem is not overly appealing. Now I've got two ways for EXT3 to screw me! :) But the ability to rsync collections of VMDK files to a remote host *is* appealing. Interesting... However, you could achieve the same thing in other ways without having to run BackupPC in a virtualized guest. You could simply use an rsync-like process for copying the block device to a remote (physical) host. Years ago someone posted a script that read a block device 64k (IIRC) at a time and did an MD5SUM on it and compared it with a remote block device (via netcat, again IIRC). If the blocks matched, they were skipped. If they didn't, the block was sent over. You could do something like that to a physical block device to achieve largely the same thing. Or, if you wanted to use actual rsync and you wanted to avoid block devices, you could do the same thing by using a (very large!) loopback file for your BackupPC pool partition on a physical server and a physical partition and rsync the file (after you stop BackupPC and unmount the partition). In fact, you could create a partition for your pool and create a single file that fills the entire device, and use that file as a loopback partition. In that case, you could very nicely use LVM tools to snapshot the outer partition and you could even restart BackupPC while the remote sync was taking place! How much performance do you lose using a loopback mount? It's *gotta* be less than the overhead of virtualization! I like that idea even better. But all it buys you is being able to use rsync directly on a file instead of coming up with a way to copy a block device in an rsync-like manner... And, to me, that's the best way of all. Of course, now we've come full circle: how do you copy a physical block device in an rsync-like manner? :) Tim Massey ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
