ArticleStorageDB vs. ArticleStorageFS

[HervE]

Hello forum,

I'd like to have your opinion and experience feedback about attachment storage.

I was used to Ticket::StorageModule = ArticleStorageDB (default option).
But now that our OTRS database is very growing, I am really considering switching to the other option - which should make backups saving easier.

Is it so easy?
How about attachments that are inside the database up to now? Will they be carried off in the file system at the time I switch from ArticleStorageDB to ArticleStorageFS?
Where is the file system located?

It says:
"FS" stores the data on the filesystem; this is faster but the webserver should run under the OTRS user.
What does it mean?

You can switch between the modules even on a system that is already in production without any loss of data.
If I switch, will the new attachments be in a file system, whereas the old attachments will remain in the database?

Best Regards,
HervE

[crythias]

It's probably likely that the attachment source is stored and not modified upon switching locations, which makes sense in a "let's not break things" thought process.
But there is a script bin/otrs.ArticleStorageSwitch.pl that may answer the other part if you wanted to.

It seems pretty simple to use, just tell it where you want to move it from (-s ArticleStorageDB) and where to (-d ArticleStorageFS) and how old (as in closed) you want to start moving data.

Now, I've never used it, etc., so I am just looking at this from a "what should make sense?" and "what would I do?" perspective. Back up before doing anything nasty, test if you can...

[HervE]

there is a script bin/otrs.ArticleStorageSwitch.pl
Now, I've never used it

Thanks for your answer - interesting as usual.
Has anybody in the forum already tried this script?

Regards,
HervE

[jojo]

lot of times

[HervE]

Very good.
What can you say of it?
Is it safe?
Do you recommend to migrate all attachments from DB to file system? (so to keep the entire data homogeneous)
Where is the file system located?

It is said that "FS is faster but the webserver should run under the OTRS user".
What does it mean?

Regards,
HervE

[jojo]

yeea, it is safe and you should have for your kind of setup all attachments in the same location.

The permissions are for unix users, not for windows.

The location can be set by sysconfig

[palcic]

Hi!

I have a problem while I moving attch to FS.

Code: Select all

NOTICE: 10291/30040 (TicketID:10374)
ERROR: OTRS-otrs.ArticleStorageSwitch.pl-10 Perl: 5.10.1 OS: linux Time: Wed Nov 28 15:13:11 2012

 Message: Not all files are moved! (TicketID:10374/ArticleID:28962)!

 Traceback (26994):
   Module: Kernel::System::Ticket::TicketArticleStorageSwitch (v1.549.2.9) Line: 7609
   Module: bin/otrs.ArticleStorageSwitch.pl (v1.16) Line: 164

Any idea what should I do?

OTRS version is 3.1.11

[crythias]

Any idea what should I do?

Yes ... look at that ticket/article and check whether it's relevant to you.

[palcic]

Ok, so is it possible to skip that ticket or I must to delete it from DB?
And if is delete the only option, which data I should delete?

[crythias]

Ok, so is it possible to skip that ticket or I must to delete it from DB?
And if is delete the only option, which data I should delete?

I don't know if this *stopped* or skipped for you. I would hope it skipped this. Basically, I can't tell you the answer. You should look at tickets before and after this and see if there are attachments accessible. If so, don't worry about it unless you need *this* attachment. If the attachments around this ticket are inaccessible, you may have other issues, but only you would be able to determine the effects simply by observing the ticket attachments. If they work... don't worry about it. If they don't work, well, you may need additional professional assistance.

[palcic]

One ticket is not problematical, but what about other tickets after this error? Is process stopped or it's go further till the last ticket? My guess, it's stopped. So, how to move other 20k tickets after stop?

[crythias]

Please read my previous post again.

[palcic]

Oh my bad didn't read well

[palcic]

FYI I'd moved ticket to junk queue and deleted it. After that, I rerun script and finally moved all attch to FS.

[gilrim]

I don't know if this *stopped* or skipped for you. I would hope it skipped this.

I just had the same situation when migrating the article attachments out of the database...
got these error messages and had the script stop completly, had to use the force parameter to restart (pid-file not deleted).
[Wed Sep 17 13:46:26 2014][Error][Kernel::System::Ticket::TicketArticleStorageSwitch][7846] Not all files are moved! (TicketID:262/ArticleID:1905)!
[....]
[Wed Sep 17 13:47:55 2014][Error][Kernel::System::Ticket::TicketArticleStorageSwitch][7846] Not all files are moved! (TicketID:940/ArticleID:3600)!
Traceback (2050):
Module: Kernel::System::Ticket::TicketArticleStorageSwitch (OTRS 3.3.5) Line: 7846
Module: bin/otrs.ArticleStorageSwitch.pl (unknown version) Line: 160

So I checked the code at line 160, and found this:

Code: Select all

exit 1 if !$CommonObject{TicketObject}->TicketArticleStorageSwitch(

changed it for this, and now it at least skipps failed objects and finishes:

Code: Select all

 print "FAILED exporting!\n" if !$CommonObject{TicketObject}->TicketArticleStorageSwitch( 

[eandrex]

for the record, if you want to skip errors you dont need to change any code in otrs.ArticleStorageSwitch.pl

just execute it with -l argument

line 50

Code: Select all

"usage: otrs.ArticleStorageSwitch.pl -s ArticleStorageDB -d ArticleStorageFS [-c <JUST_SELECT_WHERE_CLOSE_DATE_IS_BEFORE> e. g. -c '2011-06-29 14:00:00' -C <JUST_SELECT_WHERE_CLOSE_IS_OLDER_IN_DAYS] e. g. -C '5' [-b sleeptime per ticket in microseconds] [-l liberal] [-f force]\n";

line 182

Code: Select all

    exit 1 if !$Opts{l} && !$Success;

so if the -l argument is present, it wont exit

[gilrim]

for the record, if you want to skip errors you dont need to change any code in otrs.ArticleStorageSwitch.pl

just execute it with -l argument

AH! didn't realize liberal would equate to "ignore errors", but I guess I should have...

now, I've got the files exported and stored in a nice hierarchy, but it seems I'm missing the link between them and their respective articles? Is there another syncing-script I should execute as well?