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 continuation was written, our blog had already published a whole series of materials leading up to it. We recommend checking them out, as they cover access to critical information, data preservation, monitoring, and data integrity (in two parts), as well as 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
- Backup in FinTech and Gambling: Not Just a Database Dump, but a Business Recovery Guarantee. Part 1.
Be sure to read Part 1, since it lays all the groundwork and covers important questions. Now let’s move on.
Encryption and access to backups
Encryption is the process of converting readable information into an unreadable set of characters (ciphertext) using special mathematical algorithms and keys. Its main purpose is to protect data from interception or unauthorized access. In the context of our topic, encryption shouldn’t be treated as an IT side-note, but as an effective tool for protecting your Business Recovery. Applying cryptography when working with backups is exactly what’s needed, since backups contain:
- Personal user data
- Payment history
- Balances
- KYC documents
- Transactions
- Bets
- Withdrawals
- Logs
- API tokens in configs
- User emails/phone numbers
It’s now clear that backups are just as important as the business’s “original”, which is hosted on the servers. In other words, for attackers, an attack on backups can be just as profitable as breaking into your working systems. Most business owners don’t take this into account, but the BeFund team’s experience warns you of this danger. And while encrypting production isn’t practical, doing it for backups is exactly the right move.
We recommend an effective approach that’s capable of thoroughly spoiling the plans of anyone who has chosen the backups of your FinTech and iGambling projects as an attack target:
- Encrypt backups before sending them to S3;
- Use server-side encryption in the bucket;
- Restrict access through IAM;
- Store encryption keys in a Secret Manager / Vault;
- Don’t store the encryption key alongside the backup;
- Log access to backups;
So when it comes to the question, “Should backups be protected with encryption or not?”, the choice should clearly favor the first option. It doesn’t require many resources, but it lets you feel more confident and not worry about related threats. Modern cryptography is at a stage of development where restoring an encrypted dataset is harder than trying to steal an unencrypted one. So it’s worth keeping that in mind.
Backup consistency: how to avoid a corrupted dump
Consistency in IT is a state in which the data or rules of a system are logical, non-contradictory, and uniform across all its parts. In our case, this term applies both to databases and to code in general. Database consistency is the guarantee that any transaction moves the database from one correct state to another. For example, when transferring funds, money is debited from one account and is guaranteed to be credited to another, rather than disappearing. Code consistency implies a single coding style (indentation, variable naming, architectural approaches). This makes the project easy for the whole team to read and maintain.
Let’s look at a possible bad scenario from a consistency standpoint:
- Backup file exists;
- cron shows success;
- The archive uploaded to S3;
- But the dump is corrupted or incomplete;
- Restoring from it is impossible.
To make sure such an unpleasant surprise doesn’t become a serious problem for you at a critical moment, you need to follow a few simple rules. Of course, none of this should be done manually — all processes must be automated:
- Check the exit code of the backup command;
- Check the file size;
- Generate a checksum;
- Verify that the archive opens;
- Log the start and end of the backup;
- Verify the backup exists in S3;
- Set up an alert if the backup wasn’t created;
- Set up an alert if the backup is too small;
- Set up an alert if the backup hasn’t been updated.
|
MySQL: |
PostgreSQL: |
|
mysqldump for small/medium databases; |
pg_dump for logical backups; |
|
Percona XtraBackup for large production databases; |
pg_basebackup for physical backups; |
|
binlog archiving for PITR. |
WAL archiving for PITR. |
It’s also worth remembering that for large production databases, a regular dump can be too slow and create unnecessary load. To counter this, you can use a Physical Backup solution, which copies data at the block or whole-disk level, or an Incremental Backup, which stores only the data that has changed since the last backup (full or partial). The best solution is chosen individually for each business.
Point-in-Time Recovery
Most users think of backups in terms of when they were created — for example, “Backup from 09:00:00 on 6/18/2026.” It’s clear that such a copy includes the data that existed up to that point in time. However, in FinTech and iGambling projects, simply knowing the time boundaries isn’t enough — you need the ability to restore data to any required moment, down to the second. For example, if an erroneous SQL query was executed at 14:37, the database needs to be restored to the state at 14:36:59.
Point-in-Time Recovery tools provide exactly that capability. This requires having a Full backup plus binlog / WAL, and for different database management systems it looks like this:
MySQL: | PostgreSQL: |
Full backup + binary logs | Base backup + WAL archives |
Among the most common errors that Point-in-Time Recovery is best suited to fix are:
- Accidental data deletion;
- Table corruption;
- Failed migrations;
- Bad deploy;
- Human error;
- Compromise of part of the data;
- Incorrect bulk update of records.
Although point-in-time recovery is extremely precise, once it’s complete you should always double-check payments, withdrawals, the ledger, the outbox, queues, webhooks, and read models. It’s always better to check than to skip it and have to restore the system again soon because something, somewhere, wasn’t saved or caused an inconsistency.
Backing up code
Storing and restoring code is usually Git’s job — a worldwide practice that works great at the current stage of technology. But even here, simply having a Git account and hoping nothing bad will happen isn’t enough. Something will happen, so you should always have:
- A primary Git repository;
- A mirror repository;
- Backup of critical branches;
- Backup of release tags;
- Backup of Docker images;
- Backup of CI/CD configs;
- Backup of deployment scripts;
- Backup of infrastructure configs;
- Backup of documentation.
Here is the most effective and clear scheme:
These precautions are based on quite specific reasons that can prove critical at a decisive moment. After all, Git is just another third-party service involved in your business. And we know that any tool can fail for a thousand possible reasons outside your control. Here are the main problems you may run into when using repositories:
- The Git provider may be unavailable;
- The repository may be deleted or corrupted;
- The Docker registry may be unavailable;
- You may need to quickly bring up a specific production version;
- The CI/CD config may be lost;
- Infrastructure scripts may be critical for recovery.
Overall, to be confident that your code is properly preserved, you should always be able to answer 5 questions. If you have the answers, this part of the strategy has been done correctly:
- Which version of the code was deployed;
- Which Docker image corresponds to that version;
- Which migrations were applied;
- Which configs were used;
- How to roll back to the previous release.
Backing up files and uploads
Code and the database are far from everything that needs to be backed up in FinTech and iGambling projects. In this area, individual files generated and accumulated during operation are critically vulnerable and important. These include:
KYC documents | invoices |
user uploads | contracts |
payment receipts | admin files |
generated reports | media |
exports | logs for audit |
CSV/XML integrations |
|
Why is preserving these files so important? It’s simple enough: in FinTech and iGambling, there’s no such thing as “unnecessary” information. As we wrote in every previous article in this series, “data loss = financial loss.” Working files contain large amounts of information that’s critical to the entire system. So in the event of an incident, even restoring the database doesn’t guarantee that the related uploaded files will be fully restored. And that’s a cause of inconsistency across the whole structure. The way to counter this is with the S3-compatible storage tools already mentioned:
- AWS S3
- OVH Object Storage
- Vexxhost / OpenStack Swift;
- Wasabi
- Backblaze B2
- MinIO or another S3-compatible storage that you trust.
The settings recommended by the BeFund team relate to:
bucket versioning | access logs |
encryption | private access only |
lifecycle policy | separate IAM credentials |
replication to another bucket/region | regular restore test |
Restore testing: an unverified backup is just an assumption
Across two articles, we’ve been stressing: “Backups are necessary,” “Backups are important,” and so on. That’s true, but now let’s write down and remember one great idea: “A backup that no one has ever restored is not a guarantee — it’s an assumption.” Indeed, you can set up every possible method of storing and restoring data, but if no one has ever tried working with the results, you’ll never know whether all the effort and resources you’ve invested actually make sense. That’s why having the development team test backups is just as important as setting them up. Here’s what that looks like in practice:
Once a week | Once a month | Once a quarter |
check that the backup was created | spin up a staging/test environment | run a full disaster recovery drill |
check the checksum | restore the database from a backup | measure the real RTO |
check that it’s present in S3 | check the migrations | check the RPO, update the recovery runbook |
| check that the application starts |
|
| check the core APIs |
|
| check authorization |
|
| check the payment sandbox |
|
| check the queue workers |
|
| check the cron jobs |
|
| check logs/monitoring |
|
The key takeaway from all of this is simple: a restore test should show not just that the database was restored, but that the system actually works. That’s one of the keys to your business’s success and to protecting your resources.
Monitoring backups
In the article on data monitoring in this series, “Data Monitoring in FinTech and Gambling: A Question of Survival, Not Comfort”, we looked in detail at examples of processes that require special automatic or manual control. With backups, monitoring is just as necessary, since it signals — in most cases — problems with creating backups. Alerts are clearly needed for cases such as:
- The backup wasn’t created;
- The backup is taking too long to run;
- The backup file is too small;
- The backup failed to upload to S3;
- The S3 bucket is unavailable;
- The checksum doesn’t match;
- There’s no recent backup within the last N hours;
- The backup disk is running out of space;
- Backup cleanup deleted more files than expected;
- A restore test hasn’t been run in a long time.
So, to sum up: backups need to be checked regularly, regardless of how well the system has been configured. Otherwise, a backup can stop working, and the team will only find out at the moment of an incident.
Summary. Recommended backup strategy
The best solution for setting up a backup strategy is to turn to specialists who have done this many times and understand all the details. The BeFund team is the best choice for this. Otherwise, you’ll need to handle the following model on your own:
Full database backup:
- Every night;
- Encrypted;
- Compressed;
- Uploaded to S3;
- Copied to a local backup directory;
- Checksum verified.
Hourly quick backup:
- Every hour;
- Incremental/snapshot/logical critical dump;
- Local storage + S3;
- Short retention.
Binlog / WAL archiving:
- Continuous;
- For point-in-time recovery;
- Stored separately from the main database.
Code backup:
- Git repository;
- Mirror repository;
- Release tags;
- Docker images;
- Deployment configs.
Files backup:
- Uploads/KYC/reports;
- S3 bucket;
- Versioning;
- Lifecycle;
- Replication.
Cleanup:
- Keep hourly backups for 24–72 hours;
- Daily backups for 14–30 days;
- Weekly backups for 2–3 months;
- Monthly backups for 6–12 months.
Example backup structure
In short, visually:
On the server | In the S3 bucket: |
/var/backups/project/ | s3://project-backups/ |
database/ | production/ |
hourly/ | database/ |
2026-05-13-10.sql.gz.enc | hourly/ |
2026-05-13-11.sql.gz.enc | daily/ |
daily/ | weekly/ |
2026-05-12-full.sql.gz.enc | monthly/ |
2026-05-13-full.sql.gz.enc | code/ |
weekly/ | releases/ |
monthly/ | docker-images/ |
code/ | configs/ |
releases/ | files/ |
configs/ | uploads/ |
files/ | kyc/ |
uploads/ | reports/ |
reports/ | restore-tests/ |
logs/ | logs/ |
backup.log |
|
restore-test.log |
|
Absolutely unacceptable
Finally, let’s go over situations that are extremely dangerous. In general, all prohibitions can be divided into two types: “not forbidden, so it’s allowed” and “not forbidden, but still not allowed.” At the moment of an incident, it can turn out that a backup exists but can’t be restored quickly or safely. So right now, the BeFund team is briefly summarizing what you must NOT do on FinTech and iGambling projects:
- Keep backups only on the production server;
- Don’t encrypt backups;
- Don’t test restores;
- Have no retention policy;
- Give all developers access to production backups;
- Store credentials inside the backup archive without control;
- Don’t verify checksums;
- Don’t monitor backup jobs;
- Don’t have PITR;
- Not know how long a restore takes;
- Delete old backups without verifying the new ones are valid;
- Store code and the database as one chaotic archive.
The following items also can’t be considered separately from the project’s financial integrity:
- ledger;
- balances;
- payment statuses;
- withdrawal statuses;
- provider reconciliation;
- bonus transactions;
- bet settlement;
- outbox events;
- queue state;
- CRM sync;
- KYC/AML statuses;
- read models;
- audit logs.
So, ultimately, backups must be tied to:
- data integrity;
- ledger;
- idempotency;
- reconciliation;
- monitoring;
- disaster recovery;
- incident response.
Conclusions
In FinTech and iGambling, a backup isn’t just a “nightly” database dump. It’s a comprehensive system for protecting the business against data loss — and, therefore, against the loss of money and user trust.
A proper backup strategy should include:
- A full backup every night;
- A quick backup every hour;
- Binlog/WAL for point-in-time recovery;
- Storing backups in an S3 bucket;
- A local copy in a separate directory or on a backup node;
- Separate backups for code, the database, files, and configs;
- Encryption;
- A retention policy;
- Periodic cleanup;
- Monitoring of backup jobs;
- Regular restore testing;
- Reconciliation after recovery.
That covers everything on backups and ensuring business continuity for your FinTech and iGambling projects. We hope this information was useful and relevant for you. If you have any questions, feel free to reach out to the BeFund developers, and we’ll… help you out 😉
