Actually, my original post was not about aix, but about windows. There is a conflict between LiveVault and UV with the "persistent storage manager service" so for the time being, we need to find another backup solution. -Dianne
Scott Richardson wrote: >Hello Diane, >I am interested to hear how your company's evaluation of "eVault's" AIX >back up solutions on AIX went? Were they able to handle your UV >database? > >Does anyone else use this type of backup solution? > >Thanks! >Scott > > >----- Original Message ----- >From: "Dianne Ackerman" <[EMAIL PROTECTED]> >To: <[email protected]> >Sent: Wednesday, November 16, 2005 2:46 PM >Subject: Re: [U2] [UV] LiveVault backup software > > > > >>Thanks Allen for this description, it is very helpful! >>-Dianne >> >>Allen Egerton wrote: >> >> >> >>>From: <[EMAIL PROTECTED]> >>> >>> >>> >>> >>> >>> >>>>We are looking at a company "eVault" but I have concerns about their AIX >>>>agent that does incremental backups. And how UV on AIX writes to disk. >>>> >>>> >Is > > >>>>HASH.AID/HASH.HELP a UV tool or an AIX tool? Does UV have its own file >>>>system compared to AIX? >>>> >>>> >>>> >>>> >>>In reverse order, as it were. AIX is the operating system, and thus is >>> >>> >the > > >>>owner/operator of the file systems. UV is a *very* large application >>>running on top of AIX, or SunOS, or HPUnix, or Windows, etc, etc. Thus >>> >>> >UV > > >>>has to live within the boundaries established by the operating system. >>> >>>That having been said, understand that within those boundaries, UV has >>> >>> >its > > >>>own rules including the structure of the data files. To Unix, files are >>>just strings of bytes, the organization is imposed by the application. >>> >>> >So, > > >>>the files are readable and writable by Unix operations, but they're >>>typically not understood by those operations. Much as a MS-Word document >>>looks like gibberish if you open it with notepad, (or any other text >>>editor), UV data files will look like gibberish to most unix utilities. >>> >>>Which can make it extremely dangerous to work with tools that aren't >>>cognizant of the UV structure, except where the structure is not specific >>> >>> >to > > >>>UV. Program files for example are typically type 1 or 19, which are >>> >>> >simply > > >>>sub-directories containing flat files. Those flat files can be edited >>> >>> >using > > >>>vi, or emacs, or anything else you'd like without damaging the data >>> >>> >because > > >>>the data layout isn't specific to UV. >>> >>>HashAid/HashHellp are UV tools, which run under *nix, they "understand" >>> >>> >the > > >>>file structures particular to UV, and thus can traverse them, analyze >>> >>> >them, > > >>>and report on them. >>> >>>UV writes by at a very low level instructing *nix to write. But it's >>>critical to understand that UV has determined the actual location within >>> >>> >the > > >>>data stream to perform the write. >>> >>>Backup strategies typically fall into two methodologies. Either you >>> >>> >freeze > > >>>the data and copy it, or you use UV tools which pay attention to >>>record/group locks so as to get a clean backup. Classic mistake is to >>> >>> >have > > >>>your users modifying the data while you back it up with a non-UV product. >>>When you restore the file(s), they're potentially corrupted because their >>>internally inconsistent. >>> >>>I can't speak about "eVault" other than to say that it *appears* that >>> >>> >their > > >>>incremental backup would back up every file that's been modified. So, >>> >>> >your > > >>>CUST.MAST file which gets hit every day would be included in your >>>incremental backup in its entirety, while your MONTH.END file would get >>>picked up after it was modified at the end of the month, and presumably >>> >>> >only > > >>>until you ran a "full" backup. But this is guesswork on my part based >>> >>> >upon > > >>>little information. >>>------- ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
