Jump to content

warmbowski

Members
  • Content count

    12
  • Joined

  • Last visited

Community Reputation

0 Neutral

About warmbowski

  • Rank
    Newbie
  1. This is what I see when there has been a paged pool error during backups with Retrospect. This is especially prevalent on 32bit servers. You should see Event ID's like 333 and 2020 or 2019 in your server logs. There is a tendency for retrospect to fill the paged pool of memory, as it fills, you will notice the backups slowing down and the CPU usage creep up. Occasionally there is a memory leak or corruption and the pool becomes unstable until the next reboot. You might follow these instructions to see if the tweak will help fix the pool corruption http://support.microsoft.com/kb/312362
  2. warmbowski

    My backups get slower and slower

    I see this too with my full backups to file backups on a SATA drive. What does your CPU do during the course of a long backup? My full backups are about 350 GB, and at the start of a backup I will have very low CPU (like 15%) and speeds around 1100MB/min. Later on, the speed can reduce to 200MB/min, with a CPU working around 90% (with about half of the usage from Retrospect and half from System). I assumed it had to do with the MD5 digests that are going on during the backup. But I don't see why that should get more difficult as the backup progresses.
  3. warmbowski

    Vista , 7.6 and Activity Monitor

    Does anybody actually see retrospect.exe listening on port 22024 (you can use Active Ports 1.4 to test this.)? If so, did you upgrade from 7.5 or did you do a fresh install of 7.6? As others with this problem have said, I see retromonitor.exe trying to connect on the 22024 port, but it has nothing to connect to.
  4. warmbowski

    Vista , 7.6 and Activity Monitor

    I get the same blank Activity Monitor after upgrading from 7.5 to 7.6 on a Win2003 Server.
  5. warmbowski

    broken after upgrade to 7.6

    thanks, it seems that there is a process listening on 497 but I will have to investigate as to why: [root@mail2 Retrospect]# netstat -npl | grep 497 tcp 0 0 192.168.0.8:497 0.0.0.0:* LISTEN 319/mysqld udp 109140 0 0.0.0.0:497 0.0.0.0:* 319/mysqld The process is from my Zimbra install. [root@mail2 Retrospect]# ps aux | grep mysqld zimbra 319 0.1 9.7 388296 101088 ? Sl Aug24 1:55 /opt/zimbra/mysql/libexec/mysqld --defaults-file=/opt/zimbra/conf/my.cnf --basedir=/opt/zimbra/mysql --datadir=/opt/zimbra/db/data --pid-file=/opt/zimbra/db/mysql.pid --skip-external-locking --port=7306 --socket=/opt/zimbra/db/mysql.sock --external-locking Thanks for the help, I can probably get it from here.
  6. I upgraded my linux client from 7.5 to 7.6 and now the client terminates immediately after starting. retropds.log is never created. All I have for debugging is this in the retroclient.log: 1219682225: ConnStartListen: starting thread ConnStartListen for 127.0.0.1:0 1219682225: iplud: bound to address 0.0.0.0 1219682225: ipludAddMembership: adding membership for 0.0.0.0 1219682231: IPNSRegister(1): registered: "my.fqdn.com"/"f4a22e51b44d2af6" 1219682231: ConnStartListen: starting thread ConnStartListen for 192.168.0.8:0 1219682231: connListener: bind() failed with error 98 Retrospect Client Terminated. The upgrade process was done with via rpm -e retroclient to uninstall the old version and then rpm -ivh Linux_Client-7_6_100.rpm to install the new one. The service seems to start correctly, but terminates within 10 secs of starting it. If I do a status immediately after starting the service it shows [root@mail2 ~]# service rcl status Server "my.fqdn.com": Version 7.6.100 back up according to normal schedule currently on readonly is off exclude is off 0 connections, 0 authenticated I have since downgraded by uninstalling the 7.6 rpm and installing the old 7.5 rpm and now that one has the same problem with it terminating with the same bind error. any ideas on how to trouble shoot this?
  7. So now that we got it all sorted out as to how to set up external scripting for a Linux client, I wanted to make sure to post the script that I needed to create. This script is for backing up Zimbra Collaboration Suite on a Logical Volume, though I am sure it can be adapted to other apps that need to be backed up with minimal downtime. In my case the /opt folder is a unique logical volume and contains my Zimbra install that I need to backup (as well as some other apps). Since Zimbra is fairly self contained, all I need to do is backup this folder to get a backup of the app and data. But before I back it up, I need to make sure that the database has flushed all tables to disk and nothing is changing during that time (i.e. maintain state). I do this by having retrospect stop Zimbra before taking the snapshot and then restarting it. Then retrospect backs up the snapshot. Downtime is about 3 min (which is ostensibly the time it takes to restart zimbra). To do this, you need to make sure you have some unused partition space on your volume group (in my case 3GB), usually about 10% of the size of the volume to be backed up (I'm backing up ~40GB currently). Then put the code below in a file called /etc/retroeventhandler and make it executable and tweak the variables to suite you. This code is pretty much the verbatim code for lvm backup from the Zimbra wiki, but split up to execute the relevant parts before and after the backup. #!/bin/bash # # Retrospect Client retroeventhandler script # # Contact Information # # EMC Corporation # 3003 Oak Road, 3rd Floor # Walnut Creek, CA 94597 # 800.225.4880 or 925.948.9000 # customer_service@dantz.com # # Copyright 2000-2005 EMC Corporation # # # How to use this script # # Any executable with pathname /etc/retroeventhandler will be run # at the beginning and end of each source in a scripted backup. # The executable is passed one of the following parameter arrays: # # StartSource, Script name(string), Source path(string), # Source name(string), Client name(string), Err file(empty) # # EndSource, Script name(string), Source path(string), # Source name(string), Client name(string), KB stored(int), # Files stored(int), Duration in seconds(int), Source # start(date string), Source end(date string), # Script start(date string), Backup set(string), # Backup type(string), Source parent(string), # Errors(int), Fatal errors(int), Result(string) # # If a non-zero exit code is encountered for an execution trig- # gered by the StartSource event, that backup source will # be skipped. # # Notes # 1. The Source path is non-intuitive for mount points; it shows # the Retrospect object path rather than the Linux or Unix path. For # example, on client Bongo Fury with an external drive mounted # to /mnt/ext, the source path is "Backup Clients/Bongo Fury/ext", # while the source name is "/mnt/ext". # # 2. Parameters 2 through 17 are passed double-quoted, so you # have to include the double quotes in your string for exact # pattern matching in tests (e.g. $X = [ "\"ScriptName\"" ]) # # This sample script appends a timestamp and the arguments it # receives to a log file. LOGFILE=/var/log/retro-events.log date >>$LOGFILE for X in "$@"; do echo $X >>$LOGFILE done # This sample script prevents a script named Invasive from # backing up the /mnt/ext mountpoint. #if [ $2 = "\"Invasive\"" ] && [ $4 = "\"/mnt/ext\"" ]; then # exit 1 #fi ################################################################################### # # Script to backup a Zimbra installation (open source version) # by installing the Zimbra on a separate LVM Logical Volume, # taking a snapshot of that partition after stopping Zimbra, # restarting Zimbra services, , then using retrospect to backup the snapshot. # # This script was originally based on a script found on the Zimbra wiki # http://wiki.zimbra.com/index.php?title=Open_Source_Edition_Backup_Procedure # and totally rewritten since then. # # Copyright (C) 2007 Serge van Ginderachter # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License version 2 as # published by the Free Software Foundation. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # Or download it from http://www.gnu.org/licenses/old-licenses/gpl-2.0.html # #################################################################################### #### Modify the following variables according to your installation # backup_dir - directory to backup to zm_backup_path=/home/zbackup # zm_lv - the Logical Volume that contains /opt/zimbra - /opt mount point expected zm_lv=LogVol00 # vol_group - the Volume Group that contains $zm_lv zm_vg=VolGroup01 # zimbra_path - the path beneath the Logical Volume $zm_lv that needs to be synced zm_path=zimbra # zm_lv_fs - the file system type (ext3, xfs, ...) in /opt/zimbra zm_lv_fs=ext3 # lvcreate lvremove - path and command for the lvm logical volume creation and deletion command LVCREATE=/usr/sbin/lvcreate LVREMOVE=/usr/sbin/lvremove #### Modify the following variables according to your taste and needs # zmsnapshot - the snapshot volume name for $zm_lv zm_snapshot=zbackup # zmsnapshot_size - size avalable for growing the snapshot zm_snapshot_size=3GB # zm_snapshot_mnt - zimbra snapshot mount point zm_snapshot_path=/mnt/zbackup #### Following parameters probably shouldn't need to be changed log_facility=daemon log_facility_mail=mail log_level=notice log_level_err=error log_tag="$0" say() { MESSAGE_PREFIX="zimbra backup:" MESSAGE="$1" TIMESTAMP=$(date +"%F %T") echo -e "$TIMESTAMP $MESSAGE_PREFIX $MESSAGE" logger -t $log_tag -p $log_facility.$log_level "$MESSAGE" logger -t $log_tag -p $log_facility_mail.$log_level "$MESSAGE" } error () { MESSAGE_PREFIX="zimbra backup:" MESSAGE="$1" TIMESTAMP=$(date +"%F %T") echo -e $TIMESTAMP $MESSAGE >&2 logger -t $log_tag -p $log_facility.$log_level_err "$MESSAGE" logger -t $log_tag -p $log_facility_mail.$log_level_err "$MESSAGE" exit } ########################################## # Create and mount snapshot prior to retrospect backup ########################################## if [ $1 = "StartSource" ] && [ $4 = "\"/mnt/zbackup/\"" ]; then # load kernel module to enable LVM snapshots /sbin/modprobe dm-snapshot || error "Error loading dm-snapshot module" # Output date say "$2 backup started" # Stop the Zimbra services say "stopping the Zimbra services, this may take some time" /etc/init.d/zimbra stop || error "error stopping Zimbra" kill -9 $(ps -u zimbra -o "pid=") #|| error "Error stopping Zimbra" #added as a workaround to zimbra bug 18653 # Create a logical volume called ZimbraBackup say "creating a LV called $zm_snapshot" $LVCREATE -L $zm_snapshot_size -s -n $zm_snapshot /dev/$zm_vg/$zm_lv || error "error creating snapshot, exiting" # Start the Zimbra services say "starting the Zimbra services in the background....." (/etc/init.d/zimbra start && say "services background startup completed") || error "services background startup FAILED" & # Mount the logical volume snapshot to the mountpoint say "mounting the snapshot $zm_snapshot" mount -t $zm_lv_fs -o ro /dev/$zm_vg/$zm_snapshot $zm_snapshot_path # Create the current backup say "snapshot ready for retrospect backup" fi ########################################## # Unmount and remove snapshot after retrospect backup ########################################## if [ $1 = "EndSource" ] && [ $4 = "\"/mnt/zbackup/\"" ]; then # Unmount $zm_snapshot from $zm_snapshot_mnt say "unmounting the snapshot" umount $zm_snapshot_path || error "error unmounting snapshot" # Remove the snapshot volume # https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/71567 say "pausing 1s and syncing before removing the snapshot from LVM" sleep 1 ; sync say "removing the snapshot" $LVREMOVE --force /dev/$zm_vg/$zm_snapshot || say "error removing the snapshot" # Done! say "$2 backup ended: ${17} ($6 KB - $7 Files - $8 Folders)" fi Automating the backup with this code has worked out well, although I have yet to do a test restore. I will post more about restore upon completing it. Enjoy
  8. warmbowski

    external scripts won't execute

    Well smack my butt and call me Sally. That makes complete sense! That worked (tested with the default script). I will set up my LVM backup scripts and post them in a new thread for all to use. Thank you for your work in clearing that up. -Paul
  9. warmbowski

    external scripts won't execute

    Hey, thanks a lot! Much appreciated. Now that LVM is pretty ripe and many server apps are database driven, I don't think that I'll be the only one looking for this in the long run. I see tons of tutorials on the Internet explaining how to backup via lvm snapshot . It's quick and easy. I prefer to use Retrospect to rsync. It's an awesome product.
  10. warmbowski

    external scripts won't execute

    I just wanted to bump this again and see if I could get anyone else to try to get external scripts via the Linux client working, or at least verify my problem with a test run of external scripts. LVM backups are SAAH-WEET! I am manually creating an LVM snapshot, running a backup via the Linux client, and then removing the snapshot. So far my experience with this performance-wise is very good. The only thing I am missing is automation. Downtime for the mail server amounts to 2min - tops, which is the amount of time it takes to stop and start all the mail server processes. The snapshot is darn near instantaneous. Once I can get Retrospect to create and remove the snapshot, I will have an awesome backup solution. Any other automation suggestions would be welcome. THX
  11. warmbowski

    external scripts won't execute

    I haven't actually gotten external scripting to work before, but I have used the client for Linux backups without scripting since version 7.0 came out. I have only tried scripting on RHEL 4 once before about a year ago and had the same problem as described above. I gave up right away at that time. I had seen in the past instances of people using this to restart the client after a backup (to combat the Linux client problem that you mentioned). Here are some successful examples: http://forums.dantz.com/showtopic.php?tid/13688/post/50862/hl/retroeventhandler/fromsearch/1/#50862 http://forums.dantz.com/showtopic.php?tid/3256/post/12413/hl/retroeventhandler/fromsearch/1/#12413 The scripting would be very useful these days, because I need to run a script before backup that will take an lvm snapshot and mount the snapshot for retrosepect to back up. This seems to be the best and quickest way to do a cold backup of a system that requires minimal downtime and needs to maintain state (no changes) during the backup. (I am actually backing up a Zimbra Collaboration Server). I kind of assumed that the external scripting was a neglectable component of the Linux client, judging by the lack of mention in the user guide. I, and a few other consultants like me, would find this useful for lvm backups if we could get it to work. For now I can get buy with performing the snapshot with a cron job well in advance of the backup. But, I'd rather have the client initiate the snapshot. --- On the technical side, do you know how retrospect calls the execv() function? And do you know if I have to have certain packages installed for this function to work? Error 13 usually implies permission denied, is this the case here? I double checked and the the script permissions were 777. I am not sure if this is the actual problem, but this seems to be where the trail ends for me. I hope this is informative. -Paul
  12. I can perform backups via the 7.5.112 linux client of volumes on my RHEL4 server. But when I enable external scripting (by creating the /etc/retroeventhandler folder), all backups fail and the server gives the error: Source volume skipped (external script intervened: ). This happens when there is no script in the folder and when the folder contains the default retroeventhandler script, copied over from the /usr/local/dantz/client folder. The script will run just fine when called directly from the command line. One clue to the problem might be in the retropds.log file. When I enable the external scripting I get this error when a backup is executed and fails: volScriptFork[1]: execv() failed with error 13 This implies to me that the retrospect client cannot run the execv() function which executes the script. Does this mean that I am missing some dependencies? Like maybe some compat C libraries or maybe GCC or Xorg packages? Has anyone else had this problem and/or have a solution? Thanks.
×