It's the Monday of a payroll week. Your controller comes in early to process certified payroll for three prevailing wage jobs, opens Sage, and gets an error. The server in the back office won't boot. IT thinks it's the RAID controller. Parts are two days out.
Now the question that actually matters: how much work is gone, and how long until people can work again?
Most contractors have never answered those two questions precisely. They have "backups", a job someone set up years ago, a external drive that gets swapped on Fridays, a checkbox in a utility nobody has opened since. What they don't have is a recovery plan they've tested. Those are very different things, and the difference only shows up on the worst day of the year.
What's actually at risk
Construction accounting data is unusually painful to lose, because so much of it is unreproducible and time-sensitive at the same time.
Think about what lives in Sage 300 CRE, Sage 100 Contractor, your estimating databases, and Paperless:
- Job cost history going back years, the only record of what things actually cost you, and the basis for every future estimate.
- Work in progress and over/under billings that your bonding company and lender expect on a schedule.
- AIA pay applications and lien waivers tied to hard contractual deadlines. A missed G702 can push a draw a full month.
- Certified payroll and compliance records you're legally required to retain and produce on demand.
- Subcontract records, change orders, and commitments: the documentation you'd need if a dispute ever went to arbitration.
- Estimating databases and price lists representing years of accumulated cost knowledge and crew production rates.
- Scanned invoices, contracts, and RFIs in Paperless, often the only copy left after the paper went in the shredder.
You can rebuild a workstation in an afternoon. You cannot rebuild eight years of job cost history.
Backup is not disaster recovery
These get used interchangeably, and it causes real damage. A simple way to keep them straight is to think in two numbers.
RPO : Recovery Point Objective. How much data can you afford to lose, measured in time? If your backup runs at 10 p.m. nightly and the server dies at 4 p.m., your RPO is 18 hours. That's a full day of AP entry, timecards, and job cost postings that someone has to re-key from paper, assuming the paper still exists.
RTO : Recovery Time Objective. How long until people are working again? This is where most plans quietly fall apart. Having the data on a drive is not recovery. You still need hardware, an operating system, the database engine, the correct Sage version and service pack, licensing, printer and third-party integrations, and user permissions. For a typical on-premise contractor, honest RTO after a total server loss is three to seven days.
Backup answers "do we still have the data." Disaster recovery answers "when can the team work again." You need both, and you need to know your numbers before you're asked.
Why the server-in-the-closet plan usually fails
When contractors do discover their backups didn't work, it's almost always one of these five reasons.
1. Nobody ever tested a restore. A backup job that reports "success" is only telling you it finished writing a file. Whether that file can be restored into a functioning system is a completely separate question, and the only way to know is to actually do it.
2. The backup was on the same network. This is the ransomware problem. Modern attacks specifically hunt for and encrypt connected backup targets and mapped drives before they trigger. If your backup drive is plugged into the server or reachable over the LAN, assume it goes down with everything else.
3. The database was live when the copy ran. This one is specific to your software and it's the most common technical failure we see. Copying database files while the database engine is running frequently produces a corrupt, unrestorable backup. Sage 100 Contractor (v20 and later) runs on Microsoft SQL Server. Sage Estimating uses SQL Server as well. Sage 300 CRE runs on Actian Zen/Pervasive PSQL. Each requires a proper application- or engine-aware backup, a SQL backup job, or a stop of the services during the copy window. File-level copies of open database files are not backups.
4. Paperless documents and the Paperless database drifted apart. Paperless keeps document images in one place and the index in a database. Back up one without the other, or back them up hours apart, and you can end up with documents you can't find or index entries pointing at nothing.
5. Retention was too short to matter. Corruption and quiet data problems often aren't discovered for weeks. If you keep seven days of backups and a bad payroll import happened three weeks ago, all seven copies contain the problem. You need enough depth to go back past the mistake.
What good actually looks like
The standard worth aiming for is often written as 3-2-1-1-0: three copies of your data, on two different types of media, with one copy offsite, one copy immutable, and zero errors on your last verified restore test.
The two additions to the classic 3-2-1 rule are the ones that matter most right now. Immutable means the backup cannot be altered or deleted for a set retention window — not by an attacker, not by ransomware, not by an administrator with stolen credentials. Zero errors on a verified restore means someone actually performed a test restore and confirmed the application opened and the data was intact. If that hasn't happened in the last twelve months, you don't have a recovery plan. You have a hope.
It's also worth noting that cyber insurance carriers have caught up here. Offsite immutable backups, MFA, and documented recovery testing increasingly show up as conditions of coverage rather than nice-to-haves and a claim can be denied over a control you attested to but didn't actually have in place.
How hosting changes the math
This is the part where the on-premise model struggles most, because a good backup and DR posture is expensive and labor-intensive to build for one office. Hosting spreads that infrastructure across many contractors.
When your Sage 300 CRE, Sage 100 Contractor, Estimating, and Paperless environments run in a hosted datacenter, several things change at once:
- Backups are engine-aware and automatic. Databases are backed up correctly for their platform, on schedule, without anyone remembering to swap a drive.
- Copies live offsite and geo-redundant by default. A fire, flood, or burst pipe at your office has zero effect on your data, because your data was never at your office.
- RTO drops dramatically. There's no server to rebuild and no software to reinstall. Your team needs internet access and a device a laptop at home, a tablet in a jobsite trailer, a machine at a temporary office. People are working the same day, not the same week.
- The office itself stops being a single point of failure. For a business where the accounting office may be nowhere near the work, that's a meaningful structural improvement.
Hosting doesn't remove your responsibility to understand the plan, it just means you're inheriting one that's professionally maintained instead of building one on nights and weekends.
Five questions to ask this week
Whether your systems are hosted or in the closet, get real answers to these:
- What is our RPO? If we lose the system at 3 p.m. Thursday, what's the last moment of work we still have?
- What is our RTO? Realistically, when is the accounting team fully productive again?
- When did we last complete a test restore, and who watched the application open afterward?
- How far back can we go? Thirty days? Ninety? Enough to get behind a problem discovered late?
- Can our backups be deleted by someone with admin credentials? If yes, they are not protected from ransomware.
If any answer is "I'd have to check," that's worth an hour of somebody's time this week rather than a week of everyone's time later.
Want to know what your recovery picture actually looks like? myCREcloud hosts Sage 300 CRE, Sage 100 Contractor, Sage Estimating, and Paperless environments in secure datacenters with managed, application-aware backups and offsite redundancy built in. We're happy to walk through your current setup and tell you honestly where the gaps are. Contact us to schedule a conversation.
