This article was written under the guidance of Michael,
our Senior DevOps Engineer with 10+ years of experience in this domain.
By the time this article was written, our blog had already published an entire series of articles that led up to it. We recommend reading them, as they cover access to critical information, data preservation, monitoring, and data integrity (in two parts), and also touch on the topic of backup:
- Where Do Your Secrets Live? Security Architecture in Gambling and Fintech;
- Data Monitoring in FinTech and Gambling: A Question of Survival, Not Comfort;
- Data Integrity in FinTech and Gambling: How Not to Lose Data, Transactions, and Money. Part 1;
- Data Integrity in FinTech and Gambling: How Not to Lose Data, Transactions, and Money. Part 2;
- Disaster Recovery in FinTech and Gambling: How to Get Your Project Back Online After a Data Center Failure.
This article addresses backup specifically in FinTech and iGambling projects — where it is by no means an “archive just in case.” It is one of the key elements of business continuity. When a system handles payments, balances, bets, withdrawals, bonuses, KYC/AML, CRM, and external providers, data loss is no longer merely a technical problem. As we established in the very first article of this series: data loss equals financial loss.
A properly structured backup strategy must answer not just: “Do we have a database copy?” but the far more important question: “Can we quickly, safely, and reliably restore the system without losing money, transactions, or critical information?”
A comprehensive backup strategy in FinTech and iGambling projects must be the combined result of narrower strategies covering data integrity, disaster recovery, monitoring, and reconciliation — and must also include regular restore testing. That is precisely what this article covers.
Backup Is More Than a Database
There is a widespread misconception in IT that backup is the same as a database dump. For other types of projects, this misunderstanding may not be fatal — but for FinTech and iGambling, it is critically dangerous. In reality, a backup encompasses far more than just database records. For projects in this space, the following components are mandatory:
- Database;
- Project code;
- Configuration files;
- Docker Compose / Kubernetes manifests;
- .env parameters or references to secrets;
- Uploads / user files;
- KYC documents;
- Payment reports;
- Logical exports;
- Queues or outbox events;
- Cron scripts;
- CI/CD configurations;
- Infrastructure documentation;
- Recovery runbook.
In addition to what needs to be backed up, the storage location matters just as much. First and foremost, code and databases must be backed up separately, as they represent fundamentally different types of data. They require different backup frequencies and distinct approaches that are difficult to manage together within a single system. The key takeaway is that backup must cover not only data, but the entire minimum set of components required to restore the business. For example:
Separate Backups for Code and Database
Why should code and database not be stored together? The answer is straightforward: these elements serve fundamentally different purposes. Code is logic — a set of instructions to be executed. A database is the state of information. This leads to a wide range of different working practices that are appropriate for one but counterproductive for the other. For example: code can be freely copied anywhere, whereas correctly copying a database requires clustering; developers always need access to the code, whereas database records are treated as confidential information, and so on. For this reason — especially in FinTech and iGambling projects — separate backup streams are required for each critical component:
- Code backups → repository, releases, Docker images, configs, manifests;
- Database backups → full backup, incremental backup, binlog/WAL, schema dumps;
- File backups → uploads, documents, reports, media, exports;
- Infrastructure backups → IaC, Docker Compose, Kubernetes manifests, Ansible/Terraform.
Separating backup streams eliminates most of the technical complications that arise from the different nature of the data and their working requirements:
- Code changes through releases;
- The database changes continuously;
- Files may change independently of the code;
- Infrastructure may change independently of everything else;
- Restoring code and restoring data involve entirely different procedures..
For example, in the case of a bad deploy — a failed deployment where a new version of the application, website, or service produces errors, becomes unavailable, or interacts incorrectly with the database after going live — rolling back the code to the previous version may be sufficient. However, if the database has been corrupted, a completely different recovery process is required: backup, PITR, ledger check, reconciliation — all of which were covered in previous articles.
The following is an effective backup directory structure, validated through years of hands-on project experience:
/backups
/code
/database
/files
/configs
/logs
/restore-tests
Or using an S3 bucket — Amazon’s convenient cloud storage service:
code/
database/
files/
configs/
daily/
hourly/
monthly/
staging/
database/
files/
Full Backup Every Night
The standard practice for large and complex projects is to perform a full database backup at least once per day. “Nightly” is the default term, but the actual timing should be set during the period of lowest system load. If your business serves a different time zone, scheduling the backup simply during your local nighttime makes no sense. A full daily backup should include:
- A fixed, recurring schedule (every night);
- Execution during the period of minimum load;
- Compression;
- Encryption;
- Checksum verification;
- Upload to an S3 bucket;
- Local copy stored on the server or a dedicated backup node.
A full backup provides a stable recovery point. However, in FinTech and iGambling, a nightly backup alone is not sufficient — and here is why. Consider the following scenario: a full backup is created at 02:00. An incident occurs at 17:40. In this case, up to 940 minutes’ worth of data can be lost in an instant — which is simply unacceptable, given that thousands of deposits, withdrawal requests, bets, settlements, bonus accruals, KYC/AML updates, CRM syncs, affiliate events, and payment callbacks are all at stake. The nightly backup should therefore serve only as the baseline level of data preservation — not as the entire strategy.
Hourly Quick Backup
Alongside recurring full backups, FinTech and iGambling projects require “quick” hourly backups. Depending on the architecture, this may take the form of an incremental backup, a differential backup, a snapshot, or a logical dump of critical tables. The important thing to understand is that planning this practice at the start of a project is far easier on the system than implementing it once the project is already live. Managing large volumes of existing data all at once is extremely challenging. A gradual, parallel approach, however, makes the process significantly less resource-intensive. In practice, this might look as follows:
Hourly quick backup:
- Every hour;
- Quick dump or snapshot;
- Stored locally;
- Copied to an S3 bucket;
- Shorter retention period;
- Used for rapid recovery after minor incidents.
For MySQL, the recommended combination is:
- Daily full backup;
- Hourly incremental backup or snapshots;
- Binlog archiving for point-in-time recovery.
For PostgreSQL:
- Daily base backup;
- WAL archiving;
- Hourly snapshots or logical dumps for an additional layer of protection.
A quick hourly backup reduces the potential volume of data loss, but for financial transactions it is still advisable to use binlog/WAL and point-in-time recovery. To summarize: the nightly backup protects against catastrophe. The hourly backup reduces the impact of an incident. WAL/binlog enables the system to be restored as close as possible to the moment of failure.
- AWS S3;
- OVH Object Storage;
- Vexxhost / OpenStack Swift;
- Wasabi;
- Backblaze B2;
- MinIO or another trusted S3-compatible storage solution.
The correct backup storage architecture looks like this:
When configuring an S3 bucket, security best practices must be followed:
🔐 Private bucket;
🔐 Encryption at rest;
🔐 Versioning;
🔐 Lifecycle rules;
🔐 Limited IAM access;
🔐 Separate credentials for the backup writer;
🔐 No public access;
🔐 MFA delete or object lock where available;
🔐 Audit logging;
🔐 Retention policy.
A key principle to follow here: the production server should be able to write a backup to the bucket, but must not be able to delete all backups without additional oversight. This protects against the scenario where an attacker gains access to the production server and deletes not only the live data but the backups as well.
Storing Backups in a Dedicated Server Directory
In addition to an S3 bucket, it is useful to maintain a local copy of backups in a dedicated directory on the server or on a separate backup node. For example:
/var/backups/project/
database/
daily/
hourly/
code/
files/
logs/
Local backups in dedicated directories are most valuable for rapid recovery when the issue is minor — in such cases, there is no need to spend time and resources downloading full backups or locating specific parts required for restoration. Examples include a corrupted table, a failed deploy, accidentally deleted data, or quickly spinning up a staging copy. In these situations, downloading a large archive from object storage would be excessive.
The key point here is not to forget that local backups must never be the only copy. They are an effective supplementary tool, not the foundation of a business continuity strategy. The correct approach looks like this:
- Local backup → rapid recovery;
- S3 / Object Storage backup → protection against server or data center loss;
- Remote backup provider → an additional layer of disaster recovery.
Retention Policy: Periodic Backup Cleanup
Keep, keep, and keep again — that has been the message so far. However, storing everything indefinitely is not feasible, and over time what is stored inevitably accumulates unnecessary clutter. With backups, the situation is even more problematic: these are not merely massive volumes of data consuming system resources — they also contain sensitive information that can quietly end up in the wrong hands. This is why FinTech and iGambling projects require a retention policy: a set of rules defining how long different types of backups are kept. For example:
- Hourly backups — retain for 24–72 hours;
- Daily backups — retain for 14–30 days;
- Weekly backups — retain for 2–3 months;
- Monthly backups — retain for 6–12 months;
- Yearly archive — as required by compliance obligations.
To bring order to backups on a local server, cron jobs can be configured with clear, targeted instructions — without indiscriminate deletion:
- Delete hourly backups older than 72 hours;
- Delete daily backups older than 30 days;
- Retain weekly and monthly archives;
- Log all cleanup operations;
- Never delete the last successful backup.
For S3 buckets, lifecycle rules are preferable to manual deletion rules. These are automated instructions for managing data in cloud storage that allow you to configure policies under which the system automatically moves or deletes files, optimizing storage costs. The rules here differ noticeably from local cleanup, for example:
- Move older backups to a cheaper storage class;
- Automatic deletion after the retention period expires;
- Separate rules for daily, hourly, and monthly backups;
- Object lock for critical backups;
- Versioning to protect against accidental deletion.
One important point worth emphasizing: the backup cleanup process is necessary, but it must never put the project at risk. The purpose of automated rules is to retain only valuable data and to prevent the accidental deletion of working copies that may be needed in a critical moment. Designing all of this correctly is no trivial task — but extensive experience with large-scale projects can be put to work for yours as well.
This concludes Part 1 of the article. In Part 2, you will learn about encryption and backup access controls, Point-in-Time Recovery, backup testing, and much more. Stay with BeFund and develop your business with full awareness of all potential risks and challenges.
