I agree with Steven. If you're using a linux variant, may I also suggest automysqlbackup for the database side. As for filesystem backups of /opt/otrs, standard backup procedures should apply, (full backups and periodic incrementals or differentials) though I'd also consider pushing to a git repository as a different type of backup. At that point, you have history. On Sun, Jul 21, 2013 at 3:03 PM, Steven Carr wrote:

On 21 July 2013 19:49, Wayne Work wrote:

...

This is an easy one. Run OTRS within a VM appliance ( which every flavor you know best but VMware has the tools to automate most if this natively.) and perform SnapShots as often as your RPO/RTO requires. Make sure to delete old one and only keep a few "current" version (weeks worth is you are doing hourly/daily snaps). Put these into a SAN storage where that is backed up too and best would to rep them to a remote DR facility. You can restore and entire system from a snap in VMware in minutes even if you have to remove and place new hardware as the system is pretty hardware agnostic.

That's an awful lot of wasted backup storage space! Why would you ever want to backup the operating system, if you have proper administration procedures in place (debian preseed/centos kixstart/windows wds + puppet/chef/cfengine) you should be able to deploy a new OS within a matter of minutes and then restore the applications separately.

I just backup the /opt/otrs directory and the database, additionally the database has binary logging enabled so that I can roll the database back/forward to a specific point in time. This also allows you to pull out single files for restore in the case of someone modifying source code that breaks something (having to restore a full system snapshot for something like that is overkill).

Steve

--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs