Todo mês é a mesma cena. Um escritório com oito estações e um servidor local rodando o Fortes AC. No dia 15, com a equipe inteira lançando guias e apurando impostos ao mesmo tempo, o sistema começa a arrastar. A tela do lançamento demora três, quatro segundos para responder. Alguém reclama que “o Fortes travou de novo”, reinicia a máquina, e a fila de trabalho para. No fechamento, esse tipo de lentidão não é um detalhe — é hora perdida em cima de prazo legal.

O problema quase nunca está no Fortes em si. Está em como o servidor, o banco de dados e a rede foram configurados por baixo dele. O Fortes Tecnologia é um sistema robusto e amplamente usado em escritórios de médio porte no ABC Paulista e em São Paulo, mas ele carrega uma característica que muita gente de TI generalista ignora: o banco de dados dele tem exigências específicas, e ignorá-las é a diferença entre um sistema que voa e um que engasga toda vez que a operação aperta.

Este post fecha nosso cluster sobre a infraestrutura de TI por trás de cada sistema contábil brasileiro. Se você usa o Fortes e quer entender o que precisa existir por baixo para o sistema rodar sem sustos, é aqui que a coisa começa: no banco de dados.

O banco de dados do Fortes Tecnologia: o que precisa saber antes de configurar o servidor

Os sistemas contábeis e administrativos da Fortes (Fortes AC e Fortes AG) rodam sobre o Firebird, um banco de dados relacional de código aberto. As instalações mais antigas ainda usam o Firebird 2.5, mas a Fortes já homologou e recomenda a migração para o Firebird 5.0, que traz ganhos reais de performance em ambiente multiusuário. O sistema também é homologado para Microsoft SQL Server, mas na prática a esmagadora maioria dos escritórios roda em Firebird — e é sobre ele que a TI precisa saber cuidar.

O Firebird trabalha em arquitetura servidor-terminal. Existe um computador principal, o servidor, com a instalação completa e o arquivo de banco de dados (a base .FDB). As demais estações são terminais que acessam essa mesma base pela rede. Isso significa uma coisa importante: o gargalo quase sempre está no servidor e na rede, não na estação do usuário. Trocar o computador de um contador que reclama de lentidão, quando o problema é o servidor sobrecarregado, é jogar dinheiro fora.

Vale entender que essa abordagem é diferente da de outros sistemas. O Domínio, por exemplo, usa o Sybase SQL Anywhere e vem migrando fortemente para modelos em nuvem, como explicamos no post sobre Domínio Sistemas em nuvem. O Firebird do Fortes é mais “caseiro” nesse sentido: ele foi pensado para rodar bem num servidor local bem dimensionado, e é aí que a Altcom concentra o trabalho.

A ferramenta que a Fortes disponibiliza para manutenção do banco é o Fortes Totem. É por ele que se faz backup, restauração e manutenção básica do Firebird — inclusive a restauração de uma cópia via o botão “Restaurar cópia Firebird”. Todo escritório que usa Fortes deveria ter alguém que sabe operar o Totem, porque é ele que salva a operação quando a base corrompe.

Requisitos de servidor e rede para o Fortes rodar sem lentidão

A pergunta que todo sócio faz é “que servidor eu preciso?”. A resposta honesta depende do número de usuários simultâneos, mas dá para estabelecer um piso. Para um ambiente multiusuário típico — de 5 a 15 estações — o servidor precisa de no mínimo 16 GB de RAM. Com 8 GB você até roda, mas no fechamento, quando todos batem na base ao mesmo tempo, a memória estoura e o sistema começa a paginar em disco. É exatamente aí que aparece aquela lentidão que ninguém explica.

O segundo ponto inegociável é o disco. O arquivo .FDB do Firebird precisa estar em SSD, de preferência NVMe. Firebird faz muita leitura e escrita aleatória, e um HD mecânico transforma cada consulta pesada em espera. A diferença entre um fechamento em HD e em SSD, no mesmo escritório, costuma ser de minutos por operação — que somados viram horas ao longo do mês.

Sobre o processador, um servidor com Intel Xeon ou Core i5/i7 de geração recente dá conta. O Firebird não é faminto por núcleos como um SQL Server pesado — ele se beneficia mais de clock alto e disco rápido do que de muitos cores. Isso, aliás, aproxima os requisitos do Fortes dos de sistemas como o Questor, que também exige atenção especial ao banco, como detalhamos no post sobre infraestrutura de TI para o Questor — com a diferença de que o Questor roda em SQL Server, mais exigente de memória.

A rede é o terceiro fator e o mais subestimado. Como as estações acessam a base no servidor pela rede, uma infraestrutura de cabeamento Gigabit não é luxo, é requisito. Wi-Fi para estação que roda Fortes é pedido de socorro: a instabilidade do sinal gera desconexões da base e, no pior caso, corrompe registros. Estação de trabalho com Fortes fica no cabo. Ponto.

Backup do Fortes: onde ficam os dados e como proteger contra perda

Toda a contabilidade dos seus clientes está dentro de arquivos .FDB no servidor. Se esse arquivo se perde e não há backup válido, o escritório perde anos de escrituração — e não existe “Ctrl+Z” para isso. Por isso, entender o backup do Fortes não é assunto de TI, é assunto de sobrevivência do negócio.

O caminho recomendado é usar o próprio Fortes Totem para gerar cópias do banco Firebird de forma consistente. Fazer backup copiando o arquivo .FDB “na unha” com o Firebird ativo é receita para uma cópia corrompida: como o banco está com transações abertas, o arquivo copiado pode estar num estado inconsistente. O backup correto passa pela ferramenta, que garante uma cópia íntegra da base.

Mas gerar a cópia é só metade do trabalho. Essa cópia precisa sair do servidor. Um backup que fica no mesmo disco (ou no mesmo prédio) não protege contra incêndio, furto ou ransomware. A regra que a Altcom aplica é ter cópias em mídia separada e em nuvem, com pelo menos uma cópia fora do escritório. E, criticamente, o backup precisa ser testado: restaurar a base num ambiente de teste e abrir o Fortes para confirmar que os dados vieram íntegros. Backup que nunca foi restaurado é uma suposição, não uma proteção.

Nos períodos de pico — fechamento mensal, entrega de obrigações, temporada de IR — a estabilidade do sistema e a integridade do backup ficam sob maior estresse. Vale rodar o checklist de TI para o fechamento mensal antes de cada virada de mês, justamente para não descobrir um problema de backup no pior momento possível.

Conectando o Fortes a Power BI e Excel via ODBC

Uma dúvida cada vez mais comum: “dá para puxar os dados do Fortes para o Power BI ou para o Excel?”. Dá — e é aqui que um escritório sai do operacional e começa a entregar informação gerencial ao cliente. Como o Fortes roda em Firebird, a ponte é feita por um driver ODBC do Firebird instalado na máquina que vai consultar os dados.

Na prática, o fluxo é: instala-se o driver ODBC do Firebird, configura-se uma conexão apontando para o arquivo .FDB no servidor (host, caminho da base, usuário e senha), e a partir daí Power BI e Excel enxergam as tabelas do banco como fonte de dados. Com isso é possível montar painéis de faturamento por cliente, controle de obrigações entregues, evolução de honorários — informação que hoje mora presa dentro do sistema.

Um cuidado técnico importante: a conexão de leitura para BI deve usar um usuário com permissão apenas de leitura, nunca o usuário administrativo do banco. Uma consulta mal feita, ou um relatório que roda em cima da base de produção durante o fechamento, pode competir por recursos com quem está lançando. O ideal, em escritórios maiores, é replicar a base para um ambiente separado só para análise — assim o BI nunca disputa desempenho com a operação.

Fortes em ambiente de nuvem: o que funciona e o que exige atenção

Muito escritório quer “colocar o Fortes na nuvem”, e a pergunta é legítima — trabalho remoto, filiais, home office do fechamento. O ponto é entender o que “nuvem” significa aqui. O Firebird do Fortes não é um banco nativo de nuvem multi-tenant; ele foi feito para rodar num servidor. Então a forma correta de colocar o Fortes na nuvem é hospedar esse servidor num ambiente de nuvem privada e publicar o sistema via servidor de aplicações remotas (RemoteApp / Terminal Server), onde cada usuário abre o Fortes numa sessão remota.

Funciona muito bem — desde que dois pontos sejam respeitados. O primeiro é a latência: como o banco fica no servidor remoto e o usuário acessa por sessão, uma internet instável no escritório derruba a experiência. Link redundante e de qualidade é pré-requisito. O segundo é o dimensionamento do servidor na nuvem: RAM e vCPUs suficientes para o número de sessões simultâneas, pelo mesmo raciocínio do servidor local — só que agora medido em recursos de nuvem.

O que não funciona é imaginar que existe uma versão SaaS mágica do Fortes rodando puro no navegador sem servidor por trás. Quem promete isso está simplificando demais. A nuvem resolve mobilidade e elimina o servidor físico embaixo da mesa, mas o Firebird continua lá, exigindo dimensionamento, backup e manutenção — só que agora num data center, com a robustez que ele traz.

Conclusão

O Fortes é um sistema sólido, e a maior parte dos problemas que os escritórios atribuem a ele são, na verdade, problemas de infraestrutura: RAM insuficiente, banco em HD mecânico, rede via Wi-Fi, backup que nunca foi testado. Acertar o banco de dados Firebird, o servidor, a rede e a rotina de backup transforma a percepção do sistema — do “Fortes que trava” para o “Fortes que aguenta o fechamento”. É um trabalho de fundação, e é exatamente esse tipo de fundação que sustenta um escritório crescendo sem sobressaltos.

Perguntas frequentes

Qual banco de dados o Fortes Tecnologia usa?
O Fortes AC e o Fortes AG usam o Firebird (versões 2.5 até 5.0, com recomendação de migrar para a 5.0). O sistema também é homologado para Microsoft SQL Server, mas a maioria dos escritórios roda em Firebird.

Quanta memória RAM o servidor do Fortes precisa?
Para ambiente multiusuário de 5 a 15 estações, o mínimo recomendado é 16 GB de RAM. Com 8 GB o sistema roda, mas tende a travar nos picos de fechamento, quando todos acessam a base ao mesmo tempo.

Como fazer backup do Fortes corretamente?
Use o Fortes Totem para gerar cópias íntegras do banco Firebird, envie essas cópias para fora do servidor (mídia separada e nuvem) e teste a restauração periodicamente. Copiar o arquivo .FDB manualmente com o sistema aberto pode gerar uma cópia corrompida.

É possível usar o Fortes na nuvem?
Sim, hospedando o servidor num ambiente de nuvem privada e publicando o sistema via servidor de aplicações remotas (RemoteApp/Terminal Server). Exige internet de qualidade e dimensionamento adequado de recursos, mas elimina o servidor físico do escritório.