Running osTicket

[joe....@rcstn.net]

Another project I need to work on is osTicket. This is an open source work order system which would be great for both my department and our maintenance department. The problem here is that their documentation is sketchy (and I think intentionally so to sell their support services). osTicket simply requires a LAMP setup to run and I somehow stumbled my way through that to give ourselves a sandbox for practice. Here are some questions I have.

1. I set this up on a virtual server with VMware. My experience is limited here too. What's a good set of numbers for allocating hard drive space and RAM for this server? Also, what is thin provisioning and should I use it?
2. Backups are important. I see where VMware allows me to take a snapshot of the server and would think this would be the simplest way to run backups. We are using the free version of VMware so does that mean I do not have the ability to automate snapshots?
3. If I cannot automate snapshots how do you backup the mySQL database and then restore it if the need arises?

[Michael Chaney]

On Wed, Apr 9, 2014 at 11:27 AM, <joe....@rcstn.net> wrote:
>
> Another project I need to work on is osTicket. This is an open source work order system which would be great for both my department and our maintenance department. The problem here is that their documentation is sketchy (and I think intentionally so to sell their support services). osTicket simply requires a LAMP setup to run and I somehow stumbled my way through that to give ourselves a sandbox for practice. Here are some questions I have.
>
> I set this up on a virtual server with VMware. My experience is limited here too. What's a good set of numbers for allocating hard drive space and RAM for this server? Also, what is thin provisioning and should I use it?

For a typical LAMP setup a half gig of RAM and 10GB of disk space should suffice.  Since disk is cheap you might want to go to 20GB.

> Backups are important. I see where VMware allows me to take a snapshot of the server and would think this would be the simplest way to run backups. We are using the free version of VMware so does that mean I do not have the ability to automate snapshots?

> If I cannot automate snapshots how do you backup the mySQL database and then restore it if the need arises?

Even if you can automate snapshots there's no guarantee that the on-disk database will be in a consistent state when the snapshot is taken, meaning that the database might be unusable after recovery.  The best way to get around this is to do a database dump at a given time each day so that the database dump - which will be guaranteed recoverable as long as it finished - is backed up.

mysqldump -uroot -pmysqlrootpassword databasename | gzip -9 >/path/to/dumps/databasename.dump.gz

There are other incantations available, such as sticking the data in the filename and then using a variation of "find /path/to/dumps -type f -amin 10080 -delete..." to get rid of dumps older than a week, for instance.

Another idea is to use something like duplicity to do a more concise backup of what needs to be backed up on your disk.  You can cause duplicity to dump to a share mounted on another machine or something like that if you wish, or even do an offsite backup to amazon s3.

The takeaway on this is that a low-level backup of the virtual drive might not provide a recoverable mysql instance, so make sure to do something else that will.

Michael

--
Michael Darrin Chaney, Sr.
mdch...@michaelchaney.com
http://www.michaelchaney.com/

[Chris McQuistion]

Backups via VMware are fantastic, but VMware has limitations on their API, so backup software companies can't use those API's to backup the free version of ESXi.  I use Veeam Backup and it is fantastic.  Veeam even has a free version (which basically has all the features, except scheduling.)  Unfortunately, it will only work with a licensed version of ESXi because of the terms with VMware.

There are a few alternatives, supposedly.  Here is a thread that talks about some of them:

https://communities.vmware.com/thread/435152

Chris

On Wed, Apr 9, 2014 at 11:27 AM, <joe....@rcstn.net> wrote:

--
--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com
To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en

---
You received this message because you are subscribed to the Google Groups "NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nlug-talk+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tilghman Lesher]

On Wed, Apr 9, 2014 at 11:27 AM, <joe....@rcstn.net> wrote:

> Backups are important. I see where VMware allows me to take a snapshot of
> the server and would think this would be the simplest way to run backups.

I would strongly caution you against using VMware's snapshots for
anything but the ability to rollback changes quickly after you make a
change you're not sure won't screw things up. They will slow down
your VMware instance _tremendously_, if one even exists on the VM.
The reason this is is that all changes after the snapshot is taken are
stored as a delta to the last snapshot, and any file access has to
grab the file from the snapshot, then apply the accumulated deltas.

As I said, they're fine temporarily, so you can verify that a change
works as expected, but get rid of the snapshot as quickly as you
reasonably can.

--
Tilghman

[Kent Perrier]

You vmware snapshot may or may not be good enough to get your database back in a consistent state. You should definitely put that mysqldump backup in cron if you are going to use the snapshots. At my previous job we used VMWare snaphots to back up our virtual environment. Took the snapshot, copied it off the host (the backup agent used changed block tracking to only backup up the stuff that was new since the last backup) and then removed the snapshot (VERY IMPORTANT! :)).

[Joe Swann]

Based on what you and Tilghman have said (and I am reiterating in my own words to make sure I am understanding), the VMware snapshot is an excellent tool for things like taking a picture of your server once it is set up and ready to use in production, but not for incremental backup.

It sounds like I would want to keep a snapshot around simply to make setup easier should disaster happen but rely on a script running on a schedule to backup the daily changes. Restoration in the event of a disaster would then be a two set process: restore the snapshot then reload the data from the most recent backup.

Joe Swann
Education Technology
Robertson County Schools

[Tilghman Lesher]

Think of the snapshot functionality this way. You're running some
application, and a new version comes out. You're thinking about
upgrading, but you don't want to mess up your production environment.
If you take a snapshot before you start the upgrade process, you
essentially have a point that you can rollback to, in case the upgrade
goes badly. Once (and if) the upgrade goes smoothly, you can delete
the snapshot, and the delta is merged into the existing image, and you
lose the ability to rollback, but you get your full speed back. Make
sense?

--
Tilghman

[Joe Swann]

It does. That was my original understanding of the feature. The natural question that followed in my mind was, "if snapshots can be used for this purpose wonder if they could be used for this other purpose?" In this case the answer is no. Thanks.

Joe Swann
Education Technology
Robertson County Schools

> --
> --
> You received this message because you are subscribed to the Google Groups "NLUG" group.
> To post to this group, send email to nlug...@googlegroups.com
> To unsubscribe from this group, send email to nlug-talk+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en
>
> ---

> You received this message because you are subscribed to a topic in the Google Groups "NLUG" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/nlug-talk/gg7-zmId9bQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to nlug-talk+...@googlegroups.com.

[Howard White]

On 04/10/2014 10:26 AM, Joe Swann wrote:
> It does. That was my original understanding of the feature. The natural question that followed in my mind was, "if snapshots can be used for this purpose wonder if they could be used for this other purpose?" In this case the answer is no. Thanks.
>
> Joe Swann
> Education Technology
> Robertson County Schools

Snapshots may serve a number of purposes. The cost of running those
snapshots on a continuing basis may exceed the value returned.

Howard

[Chris McQuistion]

If you use backup software that utilizes snapshots, but moves those snapshots off the original datastore, you get the best of both worlds.   This is exactly what Veeam does (and most other commercial VMware backup products).  They basically make snapshots, then move them off to some other storage (or multiple backup destinations) and then delete the snapshot.  You don't have snapshots hanging around on your primary datastore, but you have all the advantages of those snapshots when you need them.

As everyone mentioned, you should still do SQL dumps and such.  VMware snapshots aren't perfect, particularly when taking a snapshot of a running VM with a running database, but they are a VERY fast way to restore a server.

The "safest" way to utilize snapshots is to shut down the running VM, make a snapshot, then boot it back up.  You can't run into problems with an open database if the whole machine is shut down.  This is what I do on a couple of my production VM's, when I'm upgrading something major.  I'll shut it down, take a snapshot (which takes seconds), then boot it back up, install the upgrades, and test things out.  I'll usually let it run for a few days and keep that snapshot around just in case something isn't right.  If everything is fine and some time has passed, I'll go ahead and delete the snapshot.  In most cases, it doesn't make THAT MUCH performance difference to have a single snapshot hanging around.

Chris

--
--
You received this message because you are subscribed to the Google Groups "NLUG" group.
To post to this group, send email to nlug...@googlegroups.com

To unsubscribe from this group, send email to nlug-talk+unsubscribe@googlegroups.com

For more options, visit this group at http://groups.google.com/group/nlug-talk?hl=en

--- You received this message because you are subscribed to the Google Groups "NLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nlug-talk+unsubscribe@googlegroups.com.

[Michael Chaney]

On Thu, Apr 10, 2014 at 10:16 AM, Tilghman Lesher <tilg...@meg.abyt.es> wrote:
>
> Think of the snapshot functionality this way.  You're running some
> application, and a new version comes out.  You're thinking about
> upgrading, but you don't want to mess up your production environment.
> If you take a snapshot before you start the upgrade process, you
> essentially have a point that you can rollback to, in case the upgrade
> goes badly.  Once (and if) the upgrade goes smoothly, you can delete
> the snapshot, and the delta is merged into the existing image, and you
> lose the ability to rollback, but you get your full speed back.  Make
> sense?

And when you take that snapshot you probably want to be at run level 1

(single user mode) to make sure that mysql and everything else isn't

running.

Michael