Continuous point in time backup with restore to any minute in the last 35 days, replicated to a second geographically separate Azure region. Included in the subscription, not an upgrade.
Most backup conversations are about whether a copy exists. The harder question is what happens on the Tuesday somebody deletes a batch of orders, or a bad import overwrites a season of costs. AIMS360 protects your data continuously rather than on a schedule, which means recovery is a point in time, not a file from last night.
AIMS360 backup runs continuously in the background as point in time protection. Nobody on your team schedules it, monitors it, or maintains it, and there is no window during the day when the last good copy is hours old. Because capture is ongoing rather than periodic, recovery targets a specific moment down to the minute rather than whatever a job happened to write at 2am. The window is 35 days, and it is included in the subscription for every customer rather than sold as a higher tier.
Protection is continuous. There is no backup schedule to design, no job to watch, and no morning where someone discovers last night's run failed silently.
Because capture is ongoing, the target is a moment rather than a file. You name when things were still correct, not which tape to pull.
Long enough to cover the mistake nobody notices until month end reconciliation, which is where most real data loss is discovered.
Backup and recovery are part of the subscription. There is no storage line item, no retention upsell, and no separate disaster recovery product.
Hardware failure is not what takes apparel brands down. People are. Somebody selects the wrong date range and deletes a batch of orders. A vendor sends a revised cost file and an import overwrites a season of landed costs with the wrong ones. A well meaning cleanup removes styles that turn out to be on open purchase orders.
The nightly backup answer to that is to restore last night, which throws away everything the business did today. The point in time answer is different: you call the Support Center, name the moment before it went wrong, and the rollback targets that minute.
| What happened | What recovery looks like |
|---|---|
| A batch of orders deleted this morning | Roll back to the minute before the deletion rather than to last night's copy |
| A bad import ran two weeks ago | Still inside the 35 day window, so still recoverable |
| A data entry error found at month end reconciliation | Five weeks back is the case the window is sized for |
| A whole region has an outage | Copies exist in a second geographically separate region and the system can be brought up there |
Recovery runs through the AIMS360 Support Center rather than a self service button in the software. That is deliberate. A rollback is a decision about a range of work, not a single record, and the scope gets agreed on the call before anything moves.
Backups are held in multiple copies at the primary data center and replicated to a second data center in a geographically separate region. If an entire region went down, your data still exists elsewhere and your system can be brought up there. Every AIMS360 customer gets that arrangement. It is not an upgrade and there is no premium tier that adds it.
All of it runs on Microsoft Azure, which means your recovery posture is Microsoft's. Azure regions are built from availability zones: physically separate data centers with their own power, cooling and networking, so one going down does not take the rest with it. Microsoft also pairs regions, so a regional event has somewhere to fail over to.
That matters more than it sounds for a mid sized brand. Building this yourself means two facilities, replication between them, and somebody whose job is to test the failover. Running on Azure means the redundancy is infrastructure you inherit rather than a project you fund.
Backups are encrypted and integrity checked automatically, and they sit in isolated infrastructure that cannot be reached from outside, including by AIMS360 engineers. Deleting a database does not delete its backups: those are still held for the full retention period, which is the point of separating them from the live system in the first place.
The practical consequence is that a person with credentials to your live tenant does not thereby have a path to your backup copies. Ransomware and insider deletion both work by reaching the backups, and infrastructure that cannot be reached from the outside is what breaks that pattern.
Three things are worth being straight about, because they are where brands get caught.
An error introduced fourteen months ago is not recoverable by rollback. Retention protects against mistakes, not against the need for a long term historical archive. If you need one, export on a schedule and keep it yourself.
Returning to a moment means the work recorded after that moment is part of the conversation. That is why recovery is handled with the Support Center rather than triggered by a button, and why calling early is better than calling late.
Your data is yours and you can export it whenever you want. The open API at api.aims360.com pulls anything out of the system and Live Excel feeds reporting into your own files. After termination AIMS360 may erase customer data, so export before you go rather than after.
Recovery undoes damage after the fact. Permissions decide who can do the damage in the first place. Role based access is the front half of this problem and backup is the back half.
| The assumption | What is the case |
|---|---|
| Cloud software means somebody is backing it up nightly | Nightly is a schedule. AIMS360 protection is continuous, so recovery targets a minute rather than a file |
| Disaster recovery is a premium tier | Multi region replication is included for every customer at no additional charge |
| We need our own backup process on top | You do not need one for recovery. You may still want scheduled exports if you need an archive older than 35 days |
| If our database were deleted the backups would go with it | Backups are held separately for the full retention period regardless of what happens to the live database |
| A restore means losing today's work | Point in time recovery targets the minute before the problem, not the last scheduled copy |
| Our vendor's staff can read our backups | Backup infrastructure is isolated and unreachable from outside, including by AIMS360 engineers |
Thirty five days. Because protection is continuous rather than scheduled, recovery targets a specific moment inside that window down to the minute, rather than whichever nightly copy happens to exist. Thirty five days is sized for the case that matters most in practice: a data entry error or bad import that nobody notices until month end reconciliation five weeks later.
No. It runs continuously in the background. There is no schedule to design, no job to monitor, no retention policy to configure and no storage to provision. Nobody on your team owns it, which also means nobody on your team can forget it.
You call the AIMS360 Support Center and identify roughly when things were still correct. The rollback targets the moment before the deletion rather than the last scheduled copy. Recovery is handled with support rather than by a self service button because a rollback affects a range of work, not a single record, and the scope is worth agreeing on before anything moves. Call early rather than late.
Multiple copies sit at the primary data center, replicated to a second data center in a geographically separate region. All of it runs on Microsoft Azure. Azure regions are built from availability zones, which are physically separate data centers with their own power, cooling and networking, and Microsoft pairs regions so a regional event has somewhere to fail over to. If an entire region went down, your data still exists and the system can be brought up elsewhere.
Neither. Backup and recovery are part of the AIMS360 subscription, and the multi region arrangement applies to every customer. There is no storage line item, no retention upsell and no separate disaster recovery product to buy.
No. Backups are encrypted and integrity checked automatically and sit in isolated infrastructure that cannot be reached from outside, including by AIMS360 engineers. That isolation is also what makes the backups survive a deleted database: they are held for the full retention period regardless of what happens to the live system.
Anything older than it. A mistake introduced fourteen months ago cannot be fixed by rollback, because retention protects against recent errors rather than serving as a long term archive. If you need historical snapshots going back years, for audit, legal hold or your own reporting, export them on a schedule and keep them yourself. The open API at api.aims360.com and Live Excel both do that.
Your data is yours and you can export it at any time during your subscription. The open API at api.aims360.com pulls anything out of the system, and Live Excel already feeds reporting into your own files. One practical caution: after termination AIMS360 may erase customer data, so run your final exports before you leave rather than after.
It gives you a way back, which is not the same as prevention. Backup is the back half of the problem and permissions are the front half. Role based access controls who can delete, adjust or export in the first place, and the 35 day window is what covers you when someone with legitimate access makes a legitimate mistake.
Last reviewed 16 August 2026 by the AIMS360 team.
Reviewed against the AIMS360 backup and disaster recovery policy as stated to prospective customers, and against Microsoft's published Azure availability zone and paired region architecture.
Bring the scenario that worries you, whether that is a bad import, a deletion, or a regional outage, and we will walk through exactly what recovery looks like on your data.
