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".



----- Original Message -----
*To:* U2 Users List <>
*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 

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.


-----Original Message-----
[] On Behalf Of Bill Haskett
Sent: Friday, June 22, 2012 12:06 PM
To: U2 Users List
Subject: Re: [U2] UV Unix File Recovery


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



----- Original Message -----
*To:* U2 Users List <>
*Date:* 6/21/2012 8:20 PM
*Subject:* Re: [U2] UV Unix File Recovery
[] On Behalf Of Wols Lists 
Sent: Thursday, June 21, 2012 6:56 PM
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.

       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.

U2-Users mailing list
U2-Users mailing list

U2-Users mailing list

Reply via email to