Page 1 of 1

Backups - Data Directory or separate filer?

Posted: Fri Jul 12, 2013 3:26 pm
by jimicron
Hi all,

We are trying to come up with a back up strategy (IS Dept along with our Finance Systems team) and the route I guess we are going to take is a process on each TM1 Server Instance that will be scheduled. It will create a zip folder of the data directory.

So, on Page 7 of this document by IBM, option 2: performing a live backup

http://public.dhe.ibm.com/software/dw/d ... _guide.pdf

Our basic structure is that our data directory resides on the virtual server where tm1 is installed. We have split out the data files from the logging files per the suggestion.

:?: THE QUESTION: Are there advantages or disadvantages of NOT saving the backups on the same server (same location as our data files). IS is wanting to put them on a separate server (filer) - totally different location than where the data directory resides. Is there any advantage or disadvantage to that?

I've been looking through the forum on best pratices but didn't see anything specific like WHERE to save the zip file to so thought I would ask. Please let me know if you need more info. Look forward to your suggestions! Thanks a lot!

Re: Backups - Data Directory or separate filer?

Posted: Fri Jul 12, 2013 4:02 pm
by George Regateiro
The biggest drawback is what happens when you have a server issue and your backup is on the server having the issue. Your backup is useless if you cannot get to it.

From a practical stand point I generally keep the backup on the server and then copy it to the remote server also. This is because

1) If I need the backup quickly it is on the server and dont have to mess with the network.
2) By doing the zip on the server rather then to a network share you take any network issues out of your backup. We would have backups intermittently fail when going direct to another server.

So I have a command file that does the following

1) Create the Zip of your data directory to the local server
2) Copy the Zip to the network server
3) Clean up backups that are out of the retention policy