VDR email notifications working...

[grandview]

We've managed to get email notifications working from our VDR installation (1.1.0.707). It certainly is not the most elegant solution; but I am hoping by sharing it with the community that it can be made much better.

There is an MTA running in the VDR; but I had no idea what the ramifications of configuring it would be. So we went a much simpler route.

I installed the telnet (telnet-0.17-39.el5.x86_64.rpm); and wrote a script to compare the prior list of logged errors found to the current list of errors found. A cron job runs every 15 minutes and an email is sent (via telnet) when new error messages are found.

I have attached our shell script and the rpm to this posting for your review. Please be gentle 8^)

[jim3cantos]

"If it makes you feel better, beta VDR 1.2.0.1046 Build 249035 still has

slow full integrity checks and recatalog. : ("

...does it delete automatically damaged restore points?

[vmbru]

Not sure, I know we haven't had to do that manually, ever. If they could only fix the slow integrity and other cleanup tasks. What version you on? Are you using iSCSI, CIFS/SMB or NFS for backup destination?

Use VDR in this order for better performance:

1. Use a seperate (not same device that VM's reside) iSCSI device

2. Use a seperate NAS device with NFS

3. Use a seperate CIFS/SMB device (no more then 500GB)

I've been testing 2 and 3.

Will try FREENAS and iSCSI soon.

Ryon Brubaker

Information Systems Manager

Kemba Credit Union, Inc.

http://www.kemba.com/

[jim3cantos]

We are on 1.1. Until recently we had a single 300GB FC SAN disk for backup and "integrity failure check" because of "damaged restore points" started to appear very frequently. We have added a second 300Gb disk and pointed backups jobs to it (keeping old backups in first disk for now) and we got only one "integrity failure check" in several weeks for the moment...

It is no sense to require the user to delete damaged restore points when they are useless and no backup jobs can be executed with them, or at least and option to do it automatically.

[vmbru]

Sounds like a hardware issue? Not rebooting the vCenter server daily are you? That will goof up VDR processes as we found out.

I think the VDR service gets hung from time to time, might create a CRON "preventive maintenance" task to stop/restart the service during non-backup window but need to figure out a way to make sure nothing is running.

Ryon Brubaker

Information Systems Manager

Kemba Credit Union, Inc.

http://www.kemba.com/

[MattseG2]

Email-notivications up and running with CRONTAB, Yeah and MANY THANKS

OK Guys, maybe off-topic here, but:

Our VDR-Target is a separate NFS-Drive on a Win2k3-VM in RAID51-SAN (Datacore SanMelody iSCSI-SANs on 2 ESX4).

So all of our VI is hosted in only two redundant Boxes. Very virtualized, isn't it?

What about frequently occcuring corrupted restore-points?

Since update to VDR 1.1.0.707 this occurs very often. Before it was rather rare.

Backup-windows and Environment didn't change.

I understood the meaning of stretching the check-interval and putting datarecovery jobs in a quasi non-multitasking state by modifying datarecovery.ini, but is the stretching secure?

If a restore-point is corrupted, and we have a very short retention policy due to storage-limitations (1 last month, 1 last week and the last) and let's say the point 31st last month is being corrupted, then the two following points of the next week are useless, correct?

Any suggestions?

Is there any other good thread concerning this issue?

[vmbru]

We have never had to mess with corr. restore points.

We use default settings for retention policy.

Open a case with vmware on the corruptions. You should only have to worry about backups that did not finish due to end of backup window.

When you went to 1.1, did you disable/remove the older vdr plugin before installing 1.1?

We have backups back to early march.

Good luck, wish I could help.

Sent on the Sprint® Now Network from my BlackBerry®

[ben13]

I know you have your crontab setup now but just so its noted (Paul did have it in his email but it was in brackets and maybe easy to miss or skip over) as I'm sure there are others not familiar with linux but trying out VDR.

As mentioned typically linux systems have the file but VDR does not. If you use putty (or another SSH client) and log in to VDR then simply type "crontab - e" you can add to crontab (which uses VI as the editor)

root@vdr etc# crontab -e

00 06 * * 1 /root/vdralert.sh

[MattseG2]

Of course i replaced the VDR-plugin when moving to 1.1.

But i can't remember exactly, if i did it just before or just after installation of 1.1.

However, i am nearly sure, that VDR 1.1. was never used nor configured with older PlugIn.

But the deduplication-store was taken from the old version, but that is not a problem, i think.

[vmbru]

>But the deduplication-store was taken from the old version, but that is not a problem, i think.

Right, shouldn't be the problem but...I'd create a fresh new backup destination. If you can, start from scratch, like I said, I have never had to mess with bad restore points, etc...

Although, we're beta testing 1.2 and so far just have had the vdr service hang and a reboot clears all. Maybe 1.2 fixes the restore point issue. I skipped from 1.1 to 1.2 with not much testing on 1.1

[MattseG2]

Hello, all!

I followed vmbru recommendation and set it up complete fresh:

1. Backed up crontab and vdrreport.sh, killed appliance and de-dupe-vmdk.

2. Checked VDR-plugin version and rolled out a new VDR-appliance from OVF with 8 GB ram and 4vCPUs.

3. Configured network, timezone and other parameters.

4. Formatted de-dupe-store to mount it and set up new backup-tasks.

5. Logged on via WinSCP and installed telnet with yum -y install telnet.

6. Copied crontab to etc and vdrreport.sh to var/vmware/datarecovery like i had before.

7. Restarted the appliance.

vdrreport.sh works from CLI, but not from crontab...(surely i checked crontab entries...)

What did i miss?

[ben13]

can you post your crontab file? Permissions on the file okay?

Alternatively instead of using a crontab file placed in \etc try typing "crontab -e" from CLI and adding that way. (when you run crontab -e you'll be in VI the editor, paste the contents of your crontab file into here and save then exit)

Also keep in mind depending on who's version of vdrreport.sh file you use if there is nothing to report it won't send an email. Eg if you run manually it will send the first one but on cron running there are no new errors so it won't send. You would have to delete the diff.out and olderror.out files to start "fresh", hope that makes sense.

[vmbru]

Check permissions, you chmod that sh script?

chmod 755 vdrreport.sh, or 777?

I think I had to do that for crontab to execute our script.

Send up your crontab -e config so we can see. Maybe a typo somewhere, have one of us take a look see.

By the way, running VDR 1.2 for over 2 weeks, stable. Maybe June you folks can get, otherwise join their beta. Recommend VMFS or NFS to backup destination, skip over SMB/CIFS as integrity checks are super slow.

Ryon Brubaker

[MattseG2]

See attached files...

Rights for both on 755.

Script is sending, even when no new entries are found. i.e. "Jobs OK:0, FEHLER:0"

I tried a new with crontab -e, see if it will work now...

[MilesAtk]

Hi, I'm out of the office until the 3rd May 2010, I will attend to your message on my return.

Thank you,

Miles Atkinson

[ben13]

you could try taking out the user part as you shouldn't need it (the root) at least not if you set it up with crontab -e

results of my crontab -e

00 06 * * 1 /root/vdralert.sh

also have you checked /var/log/cron file to see if anything is listed in there?

[MattseG2]

It wasn't the user part.

It seems to had really to do with only copying the crontab file to etc by sftp3 without using crontab -e or "echo xxx >> etc/crontab".

Maybe CronD didn't recognize having a crontab until usage of one of these commands.

In my first try i used the echo-method and it worked.

My second try was the copying by SFTP3 and it didn't work.

And the last try was to do the "crontab -e"-method and it worked.

So we learned: Use "crontab -e" or "echo "00 09 * * * root /root/vdrreport.sh" >> etc/crontab" and it will work...

By the way, before usage of one of these commands, var/log/cron shows

"Apr 23 11:54:02 localhost crond[3768]: (CRON) STARTUP (V5.0)"

"Apr 23 12:33:01 localhost crond[3768]: (system) BAD FILE MODE (/etc/crontab)"

every time the appliance is booted.

[ben13]

glad its all sorted now. Like you pointed out , looking at /var/log/cron showed that it didn't like the file.

Did you maybe create the file in windows in notepad or something and then sftp it over?

Another alternative would have been to create the crontab file with VI directly on the machine and paste the contents in.

[MattseG2]

I copied the files by sftp from the "old" appliance, then killed everything and reinstalled.

After that, i copied the files again by sftp to the newly installed appliance and did chmod 755 to them.

You're right. I tried to use the VI but i wasn't used to it and couldn't exit from it. (Oh, these newbies......)

[ShaneWendel]

I used MileATK's version that sends the attachment with Mutt, but I added a .muttrc file in /root so that I could tell which appliance it was coming from.

set realname = 'ApplianceName'

set from = 'ApplianceName@yourdomain'

-

---

Shane Wendel

VCP: vSphere 4

VCP: VI3

[Jelloir]

Hi,

Here is something I put together that you may like to use.

Rather than using telnet etc I just configured exim and installed mailx using yum.

the Perl regex is not perfect, hence the additonal sed in the script but it looks nice enough.

we like to have all servers reporting each day as opposed to just errors.

Thanks

Edit: 12/06/2010 - I have added another version (vdr-reportv2.sh) using just sed to tidy the file which now outputs nicely! You should use this instead.