Two different problems get the same word applied to them, and people buy one expecting the other. The difference becomes obvious the first time somebody needs a message that was deleted.
A backup reflects deletions
A backup copies the mailbox as it exists when it runs. That is exactly right for recovery: a mailbox lost to a failure is restored to how it looked.
But a message deleted before the backup ran is not in the backup. If someone removes correspondence and the next backup runs that night, the record is gone from both.
For recovery, that behaviour is correct. For keeping a record, it is the opposite of what is wanted.
An archive captures independently
An archive records messages as they are sent and received, separately from the mailbox. The user can delete their copy immediately and the archived one remains.
That is the entire point. An archive answers "what was actually communicated", which a backup cannot.
It is usually implemented at the mail server or through a service that receives a copy of every message.
Which you need
Both, for different reasons.
Backups protect against failure: a corrupted mailbox, a mistaken deletion the user wants undone, a server lost.
Archives protect against absence; a retention obligation, a dispute, a departed employee whose mailbox was closed, a question about what was agreed.
A small business with no regulatory obligation may reasonably run backups only. One that handles contracts, financial advice or regulated services usually cannot.
Manage size by moving, not deleting
The practical reason this matters day to day.
Mailboxes fill, and the instinctive response is to delete old mail. That frees space and destroys the record.
Moving old mail into an archive frees the same space and keeps it. On a hosting account this matters twice over, because a full account stops accepting mail and stops the website writing. There is more on finding what filled it in managing mailbox quotas and email disk usage.
Decide a retention period
Keeping everything forever is a decision people make by not deciding, and it has two costs.
Storage, which is minor. And liability, which is not: everything retained is discoverable, and a mailbox holding fifteen years of correspondence is fifteen years of exposure in any dispute.
Pick a period appropriate to your obligations (commonly a small number of years) and apply it consistently. Consistency is what makes a retention policy defensible; deleting selectively is what does not.
Departing staff
The most common gap.
An employee leaves, the mailbox is deleted to free the licence or the space, and their correspondence goes with it, including the customer agreements only they had.
The sequence that avoids it: archive the mailbox, set a forwarder to whoever takes over the work, then remove the mailbox after a period. Shared and role-based mailboxes explains reducing how often this arises. A role address does not leave the company.
Personal archives are not an archive
Users who file old mail into local folders on their own machine have removed it from the server, from backups, and from any archive.
The organisation's record now depends on one laptop. That is a common arrangement and it is not archiving.
If people are doing this, it is usually because mailbox quotas are too small, which makes it a capacity problem presenting as a records problem.
Test retrieval, not storage
An archive is only useful if you can find things in it. The test is a realistic one: find every message between two people about a particular subject in a given month.
Do it once, before it matters. An archive nobody has searched is an assumption, in exactly the way an untested backup is. Restoring a website explains the same principle on the hosting side.
Decide what actually has to be kept
Retaining everything is the default because deciding is work, and it is the most expensive option available.
Most organisations need to keep a small proportion of their mail for a long time and the rest for a short time. Contracts, invoices, anything relating to a dispute and anything the law names are the first category. Internal scheduling, notifications and the vast bulk of routine correspondence are the second.
Setting one retention period for everything means either keeping trivia for seven years or discarding something that mattered. Both are avoidable by deciding once, in writing, which categories exist and how long each is held.
The decision is a business one rather than a technical one, and it is the part that never happens because everybody assumes somebody else owns it.
Retrieval is the requirement, not storage
An archive is judged by whether a specific message can be produced when somebody asks for it, and that is a different problem from keeping the data.
du -sh ~/mail-archive 2>/dev/null find ~/mail-archive -type f 2>/dev/null | wc -l grep -ril 'invoice 2024-118' ~/mail-archive 2>/dev/null | head
Search across the whole archive, by sender, by date range and by content, and time how long it takes. If the answer involves restoring an archive first, the retrieval is measured in days rather than minutes.
That distinction matters most when the request comes with a deadline attached, which is the situation archives exist for. A store that holds everything and cannot be searched has met the letter of the requirement and none of its purpose.
Who can read it is part of the design
An archive contains every message anybody sent, which makes it the most sensitive store the organisation holds.
Access to it should be narrower than access to the mail system itself, logged, and granted per request rather than standing. An administrator who can read any mailbox is a normal arrangement; an administrator who can silently read seven years of everything is a different exposure.
Where the archive is held by a third party, the same question applies to them, and it is worth reading what their agreement actually says about access and about what happens to the data if the relationship ends.