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
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.
[mailto:u2-users-boun...@listserver.u2ug.org] 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 <firstname.lastname@example.org>
*Date:* 6/21/2012 8:20 PM
*Subject:* Re: [U2] UV Unix File Recovery
> From: u2-users-boun...@listserver.u2ug.org
> [u2-users-boun...@listserver.u2ug.org] On Behalf Of Wols Lists
> Sent: Thursday, June 21, 2012 6:56 PM
> To: email@example.com
> 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