If you're on windows, take a look at Syncrify. It's essentially doing an rsync for Windows: I've been using it for a few months now on the client side and it's saved me a load of time for doing offsite backup to a hosted VM for peace of mind.
Getting the first backup took me several nights(!) but my ISP doesn't charge for traffic between midnight and 6am and once it had that in place it's perfect for scheduling. Now it rsyncs through about 60GB worth of backups in about half an hour over a slow (rural) connection. In-house on a lan it should be very quick. Remember that whatever route you take, you must pause the database and be on a relatively recent version of UniVerse. Going back, dbpause didn't sync the shared memory headers recording dynamic file loads/splits/pointers so on restoring they would be corrupted. Plus there's always the new replication functionality to consider. From the few reports I've heard it's a lot more solid now. Brian -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Wols Lists Sent: 23 June 2012 00:22 To: [email protected] Subject: Re: [U2] UV Unix File Recovery On 22/06/12 20:13, Bill Haskett wrote: > George: > > Unfortunately, I'm on Windows. I do full backups each day, but the > 15Gb backup files shut down the dbms for about 30 minutes each night. > We're not a 24/7 shop by any means, but we do span a number of time > zones, so our window for backups is about three hours each evening. > > I've always wanted to use something simple but can't find anything. > One would think your backup method (mirrors, breaking them, backing up > the mirror, then re-syncing) would be part of the U2 admin guide (or > be on some wiki). I do this with a couple of simple Windows scripts, > but it's strickly a full backup operation with no mirrors. I did have > to change the scripts and the method of implementation for Windows > 2008 R2 from previous windows using "ntbackup". > Sounds like you want proper mirrored disks on your server. dbpause, break mirror, dbresume. Then you can back up the broken mirror at your leisure before resuming the mirror. Your database won't even be down a moment. As for minor changes to a 2Gb file, that's where btrfs would come in handy. It's a "copy on write" filesystem, so when you change a file it only updates the bits that have changed. And it cascades those changes up the hierarchy, so that if you "snapshot" the file system, it will archive the then-root of the filesystem. All new changes go to a new root. Only thing is, if you want to get back to a previous state of the filesystem (ie retrieve a backup), I understand it's a reboot. But if you had the true mirror on your server, you could run an infinite loop of dbpause, break mirror, dbresume, rsync broken mirror to linux btrfs, snapshot btrfs and restore mirror, wait for mirror to resync, rinse and repeat. It would take an awfully long time to fill up the linux backup server's disk... (rsync is the unix command that will sync two file systems, and it's very good at only updating the parts of files that have changed). Cheers, Wol _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
