Redundancy
A second, sufficiently independent component takes over a task. Data consistency, failure detection and tested failover are crucial.
← Offers & operationsRESILIENCE THAT FITS YOUR NEEDSA plan for
A plan for
a second route.
What can fail? How long can it take to recover? And which data needs to be available again? We add the protection that fits your product and your budget.
Find your productThree questions before adding infrastructure
- Recovery time: When must the workflow be working again?
- Data loss: How much recent data could you afford to lose?
- Dependencies: Which database, sign-in service or external system does the workflow need?
More instances only improve resilience if they do not share the same failure point.
Backup
A separate copy of data helps after deletion, errors or corruption. Replication may copy those errors immediately; independent backups remain necessary.
Recovery
A real test makes an outage plan verifiable. We record the time taken, the recovered data state and functional checks. A written plan is not yet a successful restore.
OUR CATALOGUE · USEFUL ADDITIONSEvery product has
Every product has
different failure points.
A good backup may be enough for a simple information website. A running shop or an internal work system may have much higher requirements. Existing backup and monitoring coverage is taken into account.
Website & campaign page
A second independently operated delivery destination and monitored failover. Forms must continue to accept inquiries reliably during an outage or visibly defer them.
Often straightforward for static content. Consider CMS, uploads and inquiry storage separately. DNS caches rule out a blanket promise of instant failover.Implementation after an architecture review; additional instance, DNS or traffic service and support are separate.
View the availability roadmapOnline shop & subscriptions
Protect application instances, database, uploads and queues together. Payment webhooks must be repeatable after an outage without duplicate orders or charges.
A second web server alone does not keep checkout available. Orders, payments and inventory must be consistent after recovery.A bespoke redundancy proposal with failover and recovery tests. Provider outages remain separate dependencies.
View the availability roadmapWeb apps, SaaS & FireFlint
Map sessions, writes, database, media and task processing. Distribute suitable components across separate hosts or zones.
First check whether the application supports parallel instances and the selected database model. Another copy on the same host is not independent protection.Offer topology, replication, quorum and rollback planning individually; do not assume a product supports high availability in every setup.
View the availability roadmapPrivate business access
A second subnet router on a separate host, identical approved routes and a documented failover test.
A second router replaces neither a second internet connection nor protection for the coordination server, identity provider or target application.Fixed-price addition to business access; hardware, hosting and site redundancy are separate.
Calculate router add-onEmail & domains
Plan mail delivery, queues and mailbox storage separately. For DNS, assess independent authoritative nameservers and tested zone recovery.
A second MX does not provide mailboxes. A second domain is not a redundant registration of the same address. DNSSEC and provider dependencies must work together.Account for existing provider redundancy first. A bespoke proposal addresses only the remaining gap.
View the availability roadmapIntegrations, Peppol & analytics
Durable queues, idempotency, traceable retries and monitoring. For KoiForge, also plan for sources, data freshness and rebuilding an analysis.
Retries must not create duplicate invoices. An outage is shown as pending or delayed. A second Peppol provider is not an interchangeable parallel connection for the same identity.Recovery and, where needed, provider migration follow the specific integration agreement; KoiForge use depends on available product capabilities.
View the availability roadmapDApps & blockchain
Operate frontend and indexer independently, add suitable RPC access with consistency checks and test outages of external data sources.
Two RPC providers do not guarantee a correct shared chain state. Repeated transactions and key management require coordinated logic.A project-specific addition to the DApp proposal; network fees, RPC quotas and operations are separate.
View the availability roadmapDEFINED SERVICES TO COMMISSIONGet clarity.
Get clarity.
Test recovery.
Availability roadmap
Identify failure points and prioritise protection by benefit and cost.
€349.00
one-off, including 19% VAT- Document up to three applications or services for one company, including shared dependencies
- Agree the desired recovery time (RTO) and tolerable data loss (RPO) together
- Evaluate options for a second instance, data storage, independent backups and failover tests
- Written action plan with one-off costs, ongoing costs and one remote follow-up round
Scope & requirements
Planning service. No already deployed HA system, SLA or guaranteed recovery time. Implementation and infrastructure are offered separately. Existing hosting backups and monitoring are taken into account and are not sold again as extras.
Restore rehearsal
Restore an existing backup in isolation and check the result.
€249.00
one-off, including 19% VAT- Restore one existing documented backup of up to 50 GB into a provided isolated test environment
- Up to five agreed functional and data checks
- Report recording backup age, measured duration, results and recommended actions
Scope & requirements
Technical suitability and access are checked before the order. Production is not overwritten. Test environment and storage are separate; repairing corrupt backups, new backup systems and ongoing tests are separate. A failed restore is documented and does not confirm recoverability. This rehearsal does not create redundancy.
Implementation & ongoing operations
After reviewing your system, we prepare a suitable proposal for a redundant website, database or application, with separate costs for setup, additional infrastructure and support.
- Independent hosts or zones and any remaining shared failure points
- Measurable acceptance criteria for failure and recovery
- Responsibilities, maintenance and repeat tests after changes
Availability, response times and on-call cover are only promised when explicitly agreed.
Request implementation