Founded to deliver end-to-end software and digital marketing solutions, Partnerfy is the reliable technology partner of agencies and brands.
Want to code the future with us?
"Do you have backups?" — the answer must be yes, but that's not enough. The real question is: "Can we actually restore, in how much time, with how much data loss?" Hourly encrypted backups, three copies on two media with one off-site, immutable WORM storage, quarterly real-restore drills, and explicit RPO/RTO targets — that is the only thing that matters on the bad day.
An untested restore is not a backup — it is a hope. We do not sell hope; we deliver measurable recovery times and proven restore reports.
When the primary fails the secondary takes over automatically — verified with real drills.
First hard truth: the vast majority of backups are never tested. The cron runs every night, the log says "OK", the monitoring dashboard is green — but when you actually try to restore that backup the files are corrupt, the decryption key is missing, or the schema version is incompatible. A backup is not a backup until it has been restored; it is just a hope. With every client we mandate a full restore drill at least quarterly and we document the result.
Second problem: a lot of what is called "backup" is actually a snapshot living on the production server itself. A copy that shares the same disk, can be written by the same account, would burn in the same fire — that is not a backup, it is a second name for the same data. In a hardware failure, ransomware event or accidentally dropped table, that "backup" disappears with the production data. A real backup must live on a separate system, under a separate identity, ideally in a separate geography.
Third problem: no off-site copy. A backup that lives in a single datacenter, a single cloud region, becomes unreachable if that region goes down, hits a natural disaster, or has its account suspended. AWS can take down an entire region, Microsoft can lock an account within hours, a datacenter fire can last days — in those scenarios an off-site copy is the only thing standing between business continuity and bankruptcy. The "1" in 3-2-1 is non-negotiable.
Fourth problem: unencrypted backups. A backup file is a complete copy of your production database — meaning every customer record, every credit-card trace, every password hash and every internal email lives inside a single tar.gz. When that file is stolen, a breach is still a breach; GDPR and KVKK do not forgive you because it was a backup. All backups must be encrypted both at-rest (AES-256) and in-transit (TLS 1.3), with keys held in a KMS separate from the backup system itself — otherwise the backup is an attack surface, not a defense.
Fifth problem: no immutability. Modern ransomware does not just encrypt production data — the attacker first lands in your backup system, deletes or invalidates the last three months of backups, then encrypts production. If backup accounts share the same directory, the same VPN, the same SSO as production, ransomware will find them. The fix: WORM (write-once-read-many) storage, S3 Object Lock, a Veeam Hardened Repository, an air-gapped offline copy — in short, a layer where deletion is mathematically impossible even with administrative credentials.
A restore timeline, a ransomware-clean simulation and an RPO/RTO comparison panel — they make post-disaster decisions measurable in advance.
Hourly snapshots + daily full backups + weekly consolidation + monthly archive. Restore point selectable down to the second.
Encrypted data → restore from immutable backup → clean data marked with green check.
See the gap between "no backup" and our architecture at a single glance.
One hour of data loss = hundreds of orders, thousands of stock movements, broken payment reconciliation.
Restoring a single tenant's data should never require restoring the entire table.
Patient records must be kept for years, auditable; any loss is a GDPR/HIPAA breach.
BDDK, SPK, MASAK records must remain untouched and unmodifiable for years.
Lose design files, video projects, code repos and you will be calling clients one by one.
Petabyte raw footage, irreproducible historical material — needs dedicated architecture.
Lose a single controller config and the production line stops for hours.
Diplomas, transcripts, attendance must be continuous, durable and auditable.
From strategy design to runbook, ten layers in one package — none skipped, none bloated.
Business impact analysis, asset inventory, RPO/RTO matrix, contracted targets.
Physical or virtual backup appliance on-premises for fastest restores.
Async/sync replication to another datacenter or cloud region.
Lifecycle-managed, cost-optimized backups on S3, Blob, GCS.
S3 Object Lock, Wasabi Compliance, Veeam Hardened — the undeletable layer.
PostgreSQL WAL, MySQL binlog, MongoDB oplog, MSSQL transaction log.
VSS, fsfreeze, pre/post hooks for write-consistent disk images.
Periodic sandbox restores + integrity verification + report.
Step-by-step, who does what, who approves, who logs — written plan.
Trigger → isolation → forensic → restore → forensic-clean image.
Which system is how critical, acceptable data loss and recovery window; full business impact analysis.
Three copies, two media, one off-site; immutability + encryption + access model documented.
On-site appliance + cloud account + network isolation + monitoring + alerting brought online.
Hourly / daily / weekly / monthly cycle; AES-256 at-rest, TLS in-transit, separate keys in KMS.
Real-scenario restores; measured RPO/RTO compared to contractual targets; deviations corrected.
Backup success, storage trend, restore time on dashboards; monthly report + annual architecture review.
We do not sell any single tool on its own. We design your architecture, justify which tool belongs in which layer, and show the total cost of ownership transparently.
250k-SKU store encrypted Friday 03:14; full production restored from immutable Wasabi copy in 38 minutes — zero order loss.
Developer dropped a prod table; PostgreSQL PITR delivered a fully consistent restore in 4 minutes.
Hospital passed its 7-year PHI audit; mathematical proof of record completeness in the immutable archive.
Senior designer's laptop was stolen; 2TB of client deliverables were hourly off-site via Restic.
Broadcaster's raw archive tiered; active S3 + Glacier Deep Archive cut annual spend by 63%.
AWS eu-central-1 outage; automated DNS + DB failover to eu-west-1 in 11 minutes, no customer downtime.
No, a snapshot alone is not a backup. A snapshot is a point-in-time "photograph" of a disk or volume, and the vast majority of them live on the same storage system — often the same disk — as the production data. That means when production data is lost, the snapshot is lost too. Hardware failure, storage corruption, ransomware or admin error all hit the snapshot as well. Snapshots are a great first tier for very fast restores (seconds back in time) but for a true backup the snapshot must be copied to a separate system, under a separate identity, ideally in a separate geography. In our architecture a snapshot is always a tier — followed by an off-site backup, an immutable archive and a disaster-recovery replica.
The 3-2-1 rule is the industry-proven minimum backup strategy: three (3) copies of the data, on two (2) different media types, with one (1) copy off-site. One of the three copies is production itself, two are backups — so if one backup is corrupt the other is still there. Two media types protect against systemic failure of a single technology (e.g. every SSD failing due to a firmware bug): disk + tape, disk + object storage, NAS + cloud. The off-site copy protects against fire, flood, theft, regional outage or account suspension — a copy in the same building or even the same city does not count as off-site. The modern extension is "3-2-1-1-0": one copy must be immutable (1) and restore tests must show zero (0) errors.
Only if designed correctly. Modern ransomware lives on the network for weeks before encrypting production, discovering the backup system and deleting or invalidating existing backups — then it encrypts production, leaving nothing to restore from. Backup accounts must therefore be independent of the production directory, the production SSO and even the production network. The solution is WORM (write-once-read-many) storage: S3 Object Lock in Compliance mode, Wasabi Compliance, Veeam Hardened Repository, air-gapped tape. On those layers deletion is mathematically impossible even with admin credentials — the data is "frozen" for the retention period. Every client of ours has at least one WORM tier, and the ransomware recovery playbook is verified by drill.
At least quarterly, monthly for critical systems, and weekly automated for regulated environments. A test restore is the only proof your backup architecture actually works — a green "OK" in the log is not enough. A full drill includes restoring to an isolated sandbox, bringing the application up, verifying database integrity and checksums, comparing measured RPO/RTO against contractual targets. Automated tests spin up an "instant recovery" virtual copy after every backup, run intelligent scans and report results. We run both weekly automated verification and quarterly manual drills for every client; results are stored in a signed report — useful for audits, insurance and contract renewal.
No if designed correctly, extremely expensive if not. Cost has three main axes: storage (per GB per month), egress (download during restore), API calls (charged per file operation). The naive "put everything on S3 every day in full" can run into tens of thousands of dollars per year. The right approach is tiered: last 14 days in S3 Standard, last 90 days in S3 Standard-IA, last year in S3 Glacier Instant, older in Glacier Deep Archive — same data, cost differs 10-20x. Add lifecycle policies, compression, deduplication and an incremental-forever strategy, and a typical client's cloud backup spend is in the low hundreds of dollars per month. Knowing your restore patterns is the key to sizing; Glacier Deep is wonderful when you restore once a year, ruinous if you restore five times a day.
RPO (Recovery Point Objective) answers "how much data loss can we accept", RTO (Recovery Time Objective) answers "how fast must we be back up". The two numbers come from business impact analysis: when that system is down for an hour, when a day of data is lost, what is the real cost in revenue, customer trust and regulatory exposure? In e-commerce hourly revenue typically forces RTO into minutes; an order-taking system with 1-hour RTO is way too long. An internal CRM may live comfortably with 8-hour RTO. For RPO: how many minutes of business activity can you lose? Hourly snapshots put RPO at 60 minutes; transaction-log replication takes it to seconds. These targets are contractually fixed and re-measured at every drill — they are business decisions, not arbitrary numbers.
Yes, our architecture is fully aligned with GDPR, KVKK, ISO 27001 Annex A.12.3, SOC 2 CC9 and PCI-DSS 9.5/12.10. That means: all backups encrypted at-rest (AES-256) and in-transit (TLS 1.3); keys held in a KMS (AWS KMS, Azure Key Vault, HSM) authorised separately from the backup system; retention periods aligned with legal requirements with provable deletion when exceeded; a "right to be forgotten" procedure for searching backups and selective anonymisation; selectable data location (EU/Turkey); every access, restore and configuration change written to an immutable audit log. The audit-readiness package delivers architecture diagrams, policy documents, RACI matrix and the latest drill reports — every question an auditor can ask has a prepared answer.
Yes, we can take over your existing Veeam (or Rubrik, Cohesity, Commvault, Acronis) installation as-is; your licence stays, the hardware stays. In the first week we run a complete audit: current backup success rate, last restore date, retention policy, immutability status, access model, key management, monitoring and alerting — everything documented and risks reported as red/amber/green. Over the next 30 days the architecture is reviewed and, if needed, new tiers are added in bridge mode (old + new in parallel); no data is moved, new backup destinations are added. At end of month three a full restore drill is run and the baseline is signed off. We have certified Veeam VMCE and Rubrik RCSA engineers on staff; you do not need to switch vendor — we bring correct configuration and operational discipline.
In a free 30-minute call we review your current backup posture together: RPO/RTO targets, immutability gaps, last test-restore date and concrete steps for the next 90 days — delivered as a written report.
