RE: [U2] Unidata replication
There was an article in the Spectrum magazine not to far back about just this subject. If you look at this link you can find the article. It has a step by step procedure for implementing backup with rsync. http://www.intlspectrum.com/DesktopModules/Repository/MakeThumbnail.aspx?tab id=73id=33 We use it to backup about 36 gigs every night from and AIX server to a Linux backup server, it only takes about 10 minutes when the database is active, and the database in only off line for a couple of seconds. Shown below is the log file from our process. rsync of koidb began at 02:00:00 on 09/04/06. Suspension of file updates is active Snapshot for file system /koidb created on /dev/dbbkuplv Suspension of file updates is inactive UniVerse was back online at 02:00:02 on 09/04/06. rsync of koidb finished at 02:03:27 on 09/04/06. rsync of koiprogs began at 02:03:27 on 09/04/06. rsync of koiprogs finished at 02:03:29 on 09/04/06. # This is not a very active system, but this shows the process. We actually have a system where we keep disk images of the backup for the last 7 days, the last 5 Fridays, and the last day of the month for 13 months. All of this is available down to the field level. HTH Tom Dodds [EMAIL PROTECTED] 513-563-2800 Cincinnati Office 708-234-9608 Chicago Office 630-235-2975 Anywhere Cell -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Frost Sent: Sunday, September 03, 2006 10:04 PM To: u2-users@listserver.u2ug.org Subject: [U2] Unidata replication Hi, I was wondering if anybody uses rsync to keep a development database in step with another system between 2 tru64 Unix Alpha boxes. At present we use rcp after first putting the source data in read-only (dbpause) mode. But this copies every file regardless of whether any changes have been made. I think rsync copies changed files either by comparing datestamps and file size, or doing block checksum comparison. We copy about 60GB down a long 300km fibre 10M/bit pipe which takes 30 hours, so doing a 'changed blocks' only rsync process would save a lot of time. Steven Frost POWERCO 35 Junction Street Private Bag 2004 New Plymouth New Zealand Helpdesk 0800491491 DDI: +64 6 759 6583 Fax: +64 6 759 6253 Mob: +64 274 403940 Email:[EMAIL PROTECTED] Web: www.powerco.co.nz # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal # * *** CAUTION: This email and any attachments may contain information that is confidential. If you are not the intended recipient, you must not read, copy, distribute, disclose or use this email or any attachments. If you have received this email in error, please notify us and erase this email and any attachments. You must scan this email and any attachments for viruses. DISCLAIMER: Powerco Limited accepts no liability for any loss, damage or other consequences, whether caused by its negligence or not, resulting directly or indirectly from the use of this email or attachments or for any changes made to this email and any attachments after sending by Powerco Limited. The opinions expressed in this email and any attachments are not necessarily those of Powerco Limited. * *** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata replication
Steven, We use rsync a lot and in Redhat is works very well. As you say, rsync works by firstly checking the timestamps and skipping the file if they are the same. If the file is different, it does a checksum on a piece of the file and compares that to a checksum on the remote dest and only copies that piece of the file if the checksums differ and then moves to the next piece. Our primary uses: 1. Copying snapshots taken on the san down to local disk. 2. Disk to disk backups (excellent for this). 3. Remote DR location copies - also excellent for this. 4. The situation you describe, having a dev version of a live account. We do the dbpause, take a snapshot and dbresume (app. 1 to 2 seconds) and then do the rsync of the snapshot. If you are going to do the rsync inside the dbpause I would do a couple of rsyncs first to get the remote data in a similar state, do the dbpause and run another rsync prior to the dbresume although you still can't predict the database pause time as someone may have come in with a big update between the rsync's. Some other points: 1. You can choose the transport layer (ssh or rsh - we use ssh). By using ssh it uses the same trust relationship you may have in place for other automated ssh tasks. 2. You can compress/decompress on the fly using the z switch. This gives an excellent effective transfer rate on rsyncs to remote sites with slower network links. 3. It is very robust, you can just break it and carry on later. 4. To play nicely on some slower speed links or if you are worried about server load, use the --bwlimit switch to slow the transfer down. HTH Adrian Cavalier Bremworth ltd Auckland, NZ On 9/4/06, Steven Frost [EMAIL PROTECTED] wrote: Hi, I was wondering if anybody uses rsync to keep a development database in step with another system between 2 tru64 Unix Alpha boxes. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata replication
On Mon, 4 Sep 2006, Steven Frost wrote: Hi, I was wondering if anybody uses rsync to keep a development database in step with another system between 2 tru64 Unix Alpha boxes. At present we use rcp after first putting the source data in read-only (dbpause) mode. But this copies every file regardless of whether any changes have been made. I think rsync copies changed files either by comparing datestamps and file size, or doing block checksum comparison. I use rsync with Unidata on Solaris without a hitch. I know others using rsync on HPUX and AIX with similar success so I don't expect you'd have any trouble. rsync is nearly flawless when copying changed data. About the only trouble rsync runs into with U2 databases is if you have a file that changed from static to dynamic hashing - rsync is really unhappy if something that was a file becomes a directory (with the same name) or vice-versa. I've been using rsync to replicate our production database to other servers (backup, testing) for several years. After the initial copy, it's really fast. If you use rsync in conjunction with some sort of filesystem snapshot, you can replicate with only a few seconds of downtime on your production server. Jeff Butera Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 You're not right, Daddy my 3-year old showing her wisdom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniData Replication and File Resizing...
The replication happens at a record level so I wouldn't have thought that resizing the file would make any difference. You can, after all, replicate between different file types. We use Universe but I would think it would be pretty much the same on UD. From: [EMAIL PROTECTED] on behalf of David Wolverton Sent: Thu 27/01/2005 20:34 To: u2-users@listserver.u2ug.org Subject: [U2] UniData Replication and File Resizing... How does the subscribing machine act when you resize a published file? Just curious what we have to do, or if it is magically rezied on the subscriber as well (Which is actually logical, but seems like it would have been a lot of work for IBM to implement!!) David WOlverton --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ The information contained in this email is strictly confidential and for the use of the addressee only, unless otherwise indicated. If you are not the intended recipient, please do not read, copy, use or disclose to others this message or any attachment. Please also notify the sender by replying to this email or by telephone +44 (0)20 7896 0011 and then delete the email and any copies of it. Opinions, conclusions (etc.) that do not relate to the official business of this company shall be understood as neither given nor endorsed by it. IG Markets Limited and IG Index Plc are authorised and regulated by the Financial Services Authority and, in Australia, by the Australian Securities and Investments Commission. [demime 1.01d removed an attachment of type application/ms-tnef which had a name of winmail.dat] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Unidata Replication
We couldn't make it reliable enough to depend on. We experienced about .5% loss of data and IBM wasn't able to help us get to the source of the problem before the customer decided to pull the plug due to the excessive cost of solving the last bit. Maybe someone with a lot of deep internals experience or previous replication system experience could have gotten the job done quicker, but it isn't for the faint of heart. I would recommend waiting or looking at something like the RFS module which I believe is more robust (and more pricy). My biggest complaint was with the logging. There was no way to prove a successful xfer and doco/error messages were vague at best. Security issues were pretty scary as well. DanE -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave S Sent: Monday, July 26, 2004 4:31 PM To: U2 USERS Subject: [U2] Unidata Replication Any opinions on Unidata replication ? We are using Unidata 6.06 and are looking for honest opinions on the replication feature. - Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
