We do *EMC replication manager* for snapshots in Windows and make a backup out of it. It halts IO for 2-4 seconds only.
hp On Fri, Jun 22, 2012 at 3:13 PM, Bill Haskett <[email protected]>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". > > Thanks, > > Bill > > ------------------------------**------------------------------** > ------------ > ----- Original Message ----- > *From:* [email protected] > *To:* U2 Users List <[email protected]> > *Date:* 6/22/2012 9:39 AM > *Subject:* Re: [U2] UV Unix File Recovery > >> I don't know the method it uses, but if figures out what changed in the >> file and saves just that part. >> >> I have a 300gb partition set for our backups, and it can hold apx 8 >> months of 20 minute interval diff checks >> Granted, that figure would depend on the size of your database files (I'm >> not really sure what our base gb >> Figure is). >> >> It doesn't really impact noticeably our system processing speed either >> when it runs. >> >> It either uses rsynch or a modified version of it to determine the >> differences between the mirror and the >> Active file - rsynch is pretty fast also. >> >> For unix system, it might already be loaded (Redhat has it preloaded), >> otherwise it's pretty simple to >> Install, (does require python to be loaded) >> >> Load it up, give it a try >> >> It does not replace backups - but it does make for those oops moments for >> restore a file to it's previous >> State much faster than pulling tapes, assuming you have the incrementals >> for the time period you want. >> >> But to be honest, I've never actually tracked a large file with minor >> changes to see how large the >> Change files are. >> >> To help save space, the incremental files are stored in a compressed >> format, great for UV ASCII data. >> >> George >> >> >> -----Original Message----- >> From: >> u2-users-bounces@listserver.**u2ug.org<[email protected]>[mailto: >> u2-users-bounces@**listserver.u2ug.org<[email protected]>] >> On Behalf Of Bill Haskett >> Sent: Friday, June 22, 2012 12:06 PM >> To: U2 Users List >> Subject: Re: [U2] UV Unix File Recovery >> >> George: >> >> If you update a few records in a 2Gb file, isn't the incremental backup >> going to save the entire 2Gb file? So, your entire database will most >> likely be saved each time the incremental backup is run. >> >> Or is this some kind of imaging backup (I didn't get this from their >> website). >> >> Thanks, >> >> Bill >> >> ------------------------------**------------------------------** >> ------------ >> ----- Original Message ----- >> *From:* [email protected] >> *To:* U2 Users List <[email protected]> >> *Date:* 6/21/2012 8:20 PM >> *Subject:* Re: [U2] UV Unix File Recovery >> >>> From: >>> u2-users-bounces@listserver.**u2ug.org<[email protected]>[ >>> u2-users-bounces@listserver.**u2ug.org<[email protected]>] >>> On Behalf Of Wols Lists [[email protected]] >>> Sent: Thursday, June 21, 2012 6:56 PM >>> To: [email protected] >>> Subject: Re: [U2] UV Unix File Recovery >>> >>> On 21/06/12 16:53, George Gallen wrote: >>> >>>> We use rdiff-backup for onsite backups, it creates a mirror and keeps >>>> differential for >>>> Restoring to specific backup date images (although that is a file by >>>> file). >>>> >>> How easy is it to get back to any particular date? Disk space is cheap >>> (though network bandwidth isn't, if big files get modified). Not saying >>> my way is better, but it gives the appearance of multiple full backups, >>> while only doing an incremental copy. >>> >>> >>> http://www.nongnu.org/rdiff-**backup/<http://www.nongnu.org/rdiff-backup/> >>> >>> Multiple full backups would only occur if you used a backup method >>> to backup the mirror, >>> (excepting the directory which holds the incremental files). >>> >>> To restore a file, you can specify an exact date/time or an >>> estimated date (ie. 3d ago) >>> It also has a pruning utility if you need to free up disk space, >>> by deleteing older incrmental info >>> >>> It actually does a fairly good job at only saving the changes, >>> even to big files. >>> >>> >>>> We run our nightly backups off the mirror >>>> >>>> And update the mirror every 20 minutes - except while the backup runs >>>> >>> Yup - on the main server itself, I'd probably run mirrored disks, break >>> the mirror to do the backup, and then resync the mirror. >>> >>> In my case, I don't "break" the mirror, as it's not a real time >>> mirror, it's an every 20 minute >>> mirror. When I run my tape backup on the mirror, I disable the >>> every 20 minute run >>> until it's done, then restart the mirroring. >>> >>> The mirror can be on the same system, SAN or another network >>>> >>> Hmmm... If you can network the mirror, could you mirror it onto that >>> self-same linux box? >>> >>> Mirror the live disk onto the linux box, break the mirror to do a local >>> (probably cross-drive) backup, then resume the mirror. Rinse, repeat, >>> etc. >>> >>> Yup, you can mirror onto itself. Just like tar, you can specify >>> directories to not mirror >>> like the directory that holds the mirror, and anything else you >>> don't want mirrored. >>> >>> Rdiff-backup I believe will work between a linux box and windows >>>> >>>> Do you really want to spend loads of money on a Windows system just to >>> provide a cheap back-up server? And if the main server is hp-ux, it's >>> easier to keep everything within the nix family. >>> >>> Personally, I'd prefer *nix to *nix, but I thought the OP was going >>> from Windows UV >>> to *nix UV. >>> >>> >>> Cheers, >>> Wol >>> >> ______________________________**_________________ >> U2-Users mailing list >> [email protected] >> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users> >> ______________________________**_________________ >> U2-Users mailing list >> [email protected] >> http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users> >> > > > ______________________________**_________________ > U2-Users mailing list > [email protected] > http://listserver.u2ug.org/**mailman/listinfo/u2-users<http://listserver.u2ug.org/mailman/listinfo/u2-users> > -- *hp* _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
