¿Por restauraciones te refieres a un Restore de una DB o la de un equipo?
Tener las imágenes en una DB secundaria puede ayudar a acelerar un poco más las cosas. Aunque por diseño Firebird se encarga de guardar los blobs en un "sector" propio dentro de la DB por lo que operaciones tradicionales no se ven afectadas por la existencia de un blob. La única excepción es cuando explícitamente se invoca en alguna operación al campo blob. Por ejemplo un SELECT todos los campos excepto blob FROM tabla funcionará igual de eficiente y rápido sobre una tabla idéntica que no tuviera el campo blob. Pero un SELECT * si dispondrá del blob y ahora si se apreciaría una baja en el rendimiento (en particular cuando uno esta recorriendo el conjunto de datos y/o moviendo el cursor).
La otra ventaja de tener los blobs por aparte es que hacer un Backup&Restore es mucho más rápido. Y si no es tan necesario, o prioritario, tener a la par un Backup&Restore actualizado cada vez que lo realizas sobre la DB principal ya ganas otro plus ya que no tienes que estar todo el tiempo dedicandole "service".
Generalmente lo que se suele guardar en un BLOB, no suele tocarse ni cambiarse demasiado. Es más hasta en ocasiones no se cambiará nunca. La situación ideal es cuando el BLOB es destinado para algo secundario y en donde lo típico es apenas una consulta y que incluso rara vez se presente.
Ahora bien, si en realidad el trabajo de los usuarios (y por los propios procesos y actividades dentro de la empresa) depende muchísimo de tener las fotos disponibles, pienso que vale la pena tener un proceso en el que se priorice medidas que den seguridad ante un fallo por ejemplo. Ahí, es importante conservar un respaldo de esa DB secundaria.
Ahora, una posible desventaja de tenerlas fuera de la DB principal. Firebird 2.1 y versiones inferiores (no recuerdo si también afecta a 2.5) no tiene capacidad de hacer consultas externas. No es posible consultar y cruzar dos bases de datos. Asi que por ejemplo, si la idea es que las fotos estén asociadas a algunos registros de la DB principal y usas 2.1- para aprovechar mejor los recursos del server sería que esten en una misma DB. De otra forma deberás tener dos conexiones activas en tu aplicación (o bien, una y estar cerrando y abriendo cada una cuando sea necesario), una para cada DB y hacer la "correspondencia" a mano.
Ahora bien, hay otras alternativas que quizá pudieras evaluar. Si cada cliente va a estar generando fotos y que éstas estén disponibles en los otros equipos una posibilidad es aprovechar es la sincronización de archivos, de esa forma todos tendrán las fotos en sus propios equipos. BitTorrent Sync es una buena herramienta en este sentido. Un cambio en un archivo luego se ve reflejado en el resto de los equipos a los que estén sincronizados. Es bastante rápido, sobre todo en una misma red y si es LAN mucho mejor. Un defecto: un borrado, y todos se ven afectados, por lo que eventualmente quizá debieras de considerar un respaldo.
La otra: servicios en la nube.
Pero a mi ver los respaldos son necesarios. Guste o no.
Saludos,
