Migrating Server

[mcollis]

I've been running an old version of ORTS for some time and am now looking at migrating to a new server.
Is it poissible for a new system to pull open tickets from an old system leaving the old one in an archived state?


I'm asking as the database has grown quite a lot and the performance of otrs has dropped significantly, I also want to migrate to a MSSQL server to centralise our SQL Servers into 1 instead of having many of them around the place.

Thanks All.

[crythias]

*A* way to do this is to:
1) Backup your old database (!!!!!) [And filesystem, especially if you're using FileSystem storage of attachments] (optional addition is to use phpmyadmin to copy database structure and data to another database name, then change connection Config.pm to one copy for archive and one for prune, one for original).
2) Generic Agent delete all tickets that are not New or open (Danger, but you know why you backed up this in the first place!)
3) Migrate the database to the new install, and apply database updates per version update requirements (Read UPGRADING) (3.n.latest -> 3.n+1.latest -> 3.n+2.latest, etc.)

[mcollis]

Is there anyway to convert from DB file storage to FileSystem storage?
I have a feeling that the files stored in our database have caused half the issues with performance

[crythias]

Is there anyway to convert from DB file storage to FileSystem storage?

bin/otrs.ArticleStorageSwitch.pl
You might want to browse the results of a forum search on this and backup first, etc.

bin/otrs.ArticleStorageSwitch.pl --help

(s=source, d=destination)

also
Edit Config Settings in Ticket -> Core::Ticket
Ticket::StorageModule

[mcollis]

Thanks,

Is it possible to re-direct the data directory to an alternate folder?
I would ideally like to divert the data that is saved to a separate shared file on our file server instead of in the local storage of the installed system.

[crythias]

oh, but for performance reasons and for just ... it could crash horribly, you probably don't want to use network shares to host data.

[mcollis]

bear in mind we use Windows servers for OTRS, so it would be nice to know if there are permission requirements etc for the folders.

[crythias]

Permissions? Likely in the context of the authentication running your Web service.

[mcollis]

How do you configure where the files are stored?

There is also this that i have come accross and still been left confused:
"FS" stores the data on the filesystem; this is faster but the webserver should run under the OTRS user.
What does it mean?

Does it mean that the service for both the web server and OTRS should be run as the same user?

[crythias]

What does it mean?

It means that in Linux land, apache should be running as user "OTRS" so it can have permission to write the files in its directory.

Does it mean that the service for both the web server and OTRS should be run as the same user?

May not matter to you in Windows. You can switch modes and future tickets will go into the currently assigned mode. Test and then ask.

[mcollis]

where do the files get saved to by default?
this will then allow me to workout where the files are for backups to work

[crythias]

See the next entry under
Edit Config Settings in Ticket -> Core::Ticket
Ticket::StorageModule?
ArticleDir

Default value: <OTRS_CONFIG_Home>/var/article
Specifies the directory to store the data in, if "FS" was selected for TicketStorageModule.

[briancphy]

Thank god for this thread, or should I say, thank god for mcollis and crythias. This is just the information that I was looking for. This whole migration has been giving me migraines...

[mcollis]

I'm going to run the following on our server:
otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS -c '01/01/2011' -f
will this work how I expect it to? - IE: extract all attachments that are in tickets closed before 01-01-2011?

I intend to do small date ranges until all attachments have been extracted


Thanks

[crythias]

will this work how I expect it to?

It should do what it says on the box. If you expect different results, you should back up first.