How to Vet Your IT Partner on Backup and Recovery

Ask questions that force evidence, not vibes

Green dashboard lights are comforting. Restore day is when gaps show up: wrong systems covered, retention too short, cloud mail omitted, nobody sure who can start a restore.

Asking precise questions before a crisis is cheaper than discovering answers while the office is down.

Use this guide as a working script. You will build a one-page coverage summary and put a restore drill on the calendar.

Why this gets messy

Many businesses assume backups are fine because a green light appears in a dashboard. Restore day is when gaps show up: wrong systems covered, retention too short, cloud mailboxes omitted, or nobody remembering the recovery steps.

Asking precise questions before a crisis is cheaper than discovering the answers while the office is down.

This guide gives you a question list you can send to a current provider or any MSP you evaluate. Good partners answer without jargon fog.

Questions worth asking out loud

Share these with your current provider or any MSP you evaluate. Write down the answers. Vague confidence is not an answer.

• What systems are backed up today, by name: servers, workstations, Microsoft 365 mail and files, line-of-business apps, and network device configs?
• Where do copies live, and how long is each retention period?
• How often are restores tested, and what was the last successful restore of a real file or mailbox?
• Who gets alerted when a backup job fails, and what is the expected response?
• If ransomware encrypts endpoints, what is the recovery sequence and who leads it?
• What is out of scope? Local-only folders, USB drives, personal OneDrive, or specialty appliances often fall through cracks.
• If we change providers, how do we export or retain backup history without losing recovery options mid-transition?
• How are backup admin credentials protected relative to everyday admin accounts?
• What is a realistic restore time for a single file versus a full server or tenant scenario?

Build a one-page coverage map

Ask your partner to help you fill a simple table: system name, backup product, retention, last restore test, and owner. If a row is blank, that is a finding, not a formatting problem.

Pay special attention to cloud suites. Many offices learn during an incident that Microsoft 365 recycle bins and versioning are helpful but not a complete backup strategy for their retention needs.

Restore testing without a science project

You do not need a full disaster simulation every month. You do need a recurring proof that something useful can come back.

• Monthly or quarterly: restore a random file or folder to a safe location.
• Quarterly: restore a mailbox item or shared mailbox content sample.
• At least annually: walk through a more serious scenario (server image or critical app) and record time and blockers.
• After major changes (new file server, tenant migration, new backup product): test sooner, not on the old cadence.

What good looks like in practice

You can point to a short written summary of what is protected, how often jobs run, and how restores are verified. Failures create tickets with owners, not silent dashboard red lights.

Recovery expectations are realistic. A laptop file restore differs from rebuilding a server or recovering an entire tenant. Your partner should say which scenarios they can handle and which need vendor escalation.

Leadership can answer “when did we last restore on purpose?” without guessing.

Scenario: ransomware week versus restore week

In ransomware week, every delay is expensive: finding credentials, learning retention limits, discovering an excluded volume, waiting on a vendor. In restore week (a planned test), those same discoveries are inconvenient notes on a checklist.

Offices that schedule restore week rarely enjoy the process. They do enjoy not inventing a recovery plan under pressure.

Score answers: clear, partial, unknown

Use a simple rubric: clear, partial, or unknown. Clear means you could explain the answer to another owner. Partial means there is a product but fuzzy ownership. Unknown means nobody can show evidence.

Unknown on critical systems is a project, not a vibe. Partial on Microsoft 365 or line-of-business apps is often where small offices get hurt.

The one-pager to demand

Ask for a one-page summary updated at least quarterly. It does not need marketing language. It needs system names, products, retention, last restore test, and alert owners.

If a provider refuses to write that down, believe the refusal. Documentation reluctance is a reliability signal.

Easy-to-forget systems

Beyond servers and mail, ask about the awkward systems: shared WhatsApp or unofficial exports do not count, but these do.

• Line-of-business databases and how application-consistent backups work.
• Network device configs (firewall and switch) so a hardware swap is not a redesign.
• Cloud file sync tools and whether trash retention matches your needs.
• Owner or executive laptops that hold unique files outside shared systems.
• Image-level versus file-level recovery options and when each is used.

Ransomware questions without theater

You do not need a cinematic tabletop exercise to be more ready. You do need immutable or offline copies where your tooling supports them, separate backup credentials, and a written sequence for who leads recovery.

Ask whether backups are reachable from the same admin accounts that ransomware often targets. If the answer is yes with no compensating control, put that on the risk list in plain language.

Turn answers into a one-pager

After you ask the questions, convert the answers into a page leadership can read without a technical glossary.

Bring that page to quarterly reviews. Update dates when tests run. If the page cannot be produced, you have learned something important about the current arrangement.

• What is protected (system list).
• How far back we can go (retention).
• How we know it works (last restore test).
• Who acts when a job fails (alert owner).
• What we are explicitly not protecting yet (gap list).

Changing backup tools safely

When changing backup products or MSPs, avoid a hard cut that deletes old recovery points before new ones are proven. Run overlap where possible. Restore-test the new path before you cancel the old one.

Write down who owns cancellation of the old service. Orphaned backups that nobody can access are not a strategy, and sudden cancellation without a bridge is how companies lose months of history.

Fifteen-minute leadership tabletop

You do not need a full disaster exercise. Sit down for fifteen minutes and answer these out loud.

If those answers are shrugs, your backup product may be fine and your operating readiness is not. Fix the readiness gaps on purpose.

• If ransomware hit tonight, who is called first?
• Which system do we restore first so the business can take payments or see patients or serve clients?
• Where are backup credentials, and who has them besides one technician?
• What is an acceptable time to be down for our worst realistic scenario?
• What would we tell staff and customers in the first hour?

Evidence for quarterly reviews

Ask for artifacts, not adjectives.

• Screenshot or export of recent backup job history for critical systems.
• Ticket or note from the last restore test with what was restored.
• List of backup failures in the last quarter and how each was resolved.
• Updated coverage one-pager with any new systems or gaps.

Cloud suite recovery specifics worth naming

Ask your partner to explain Microsoft 365 or Google Workspace recovery in plain language: mailboxes, SharePoint or Drive files, Teams or Groups content if you use it, and retention differences versus native recycle bins.

Then ask what happens if an admin account is compromised. Can backup settings be changed by the same attacker path? What compensating controls exist? These questions separate brochure backups from owned recovery.

Workstation backup decisions for small teams

Not every laptop needs a full image backup. Many offices are fine protecting cloud mail and shared files while treating workstations as replaceable, as long as unique local data is not hiding on desktops.

Make that decision explicit. If designers, accountants, or clinicians store critical local files, either redirect that data to protected locations or include those endpoints in backup scope. Silent assumptions are how “we thought OneDrive had it” becomes a bad week.

Why precise questions beat dashboard screenshots

Green lights are not recovery. Restore day reveals gaps: wrong systems covered, short retention, omitted cloud mailboxes, or nobody knowing the steps.

Ask precise questions before a crisis. Write answers down. Vague confidence is not an answer.

Coverage questions by system class

Walk systems by name, not by vibe.

• Servers and their volumes.
• Workstations that hold unique local data.
• Microsoft 365 or Google Workspace mail and files.
• Line-of-business databases and app-consistent needs.
• Network device configs for firewalls and switches.
• Cloud file sync tools and trash retention reality.
• Specialty appliances often forgotten in closets.

Retention, location, and independence

Where do copies live? How long is each retention? Are copies offline or immutable enough for your risk? Are backup credentials separate from everyday admin accounts?

Independence matters in ransomware scenarios. Backups reachable through the same compromised admin path are weaker than they look.

Restore testing questions

How often are restores tested? What was last restored? Who watched? How long did it take? What failed?

Ask for artifacts: ticket notes or a short report. Adjectives are not evidence.

Failure response questions

Who is alerted when a job fails? What is the expected response time? Who leads ransomware recovery? What is out of scope?

Also ask how you retain recovery options if you change providers midstream.

Build an owner-friendly one-pager

Convert answers into a page leadership can read: what is protected, retention, last restore test, alert owner, and explicit gaps.

Update it quarterly. If a provider cannot produce it, believe the refusal.

• Protected systems list.
• Retention summary.
• Last restore test date and result.
• Alert owner and escalation.
• Known gaps and decisions.

Restore drill program you can run

Monthly or quarterly file or folder restore. Quarterly mailbox sample. Annual deeper scenario for server or critical app. Extra tests after major changes.

Record time, blockers, and follow-ups. Put the next drill on the calendar before you leave the room.

Cloud suite recovery specifics

Make the partner explain mail, SharePoint or Drive, Teams or Groups if used, and how native recycle bins differ from true backups.

Ask what happens if an admin account is compromised and whether backup settings share that blast radius.

Workstation backup decisions

Not every laptop needs full imaging. Many offices protect cloud mail and shared files while treating workstations as replaceable, if unique local data is not hiding on desktops.

Make the decision explicit. Redirect critical local data or include those endpoints in scope.

Ransomware readiness questions

What is the recovery sequence? Who leads? How are backup credentials protected? Do you have immutable or offline copies? What is realistic downtime for our worst plausible scenario?

Demand plain language. Heroic claims without a sequence are marketing.

Changing backup tools safely

When changing products or MSPs, avoid hard cuts that delete old recovery points before new ones are proven. Overlap where possible. Restore-test the new path before canceling the old.

Name who owns cancellation of the old service. Orphaned backups nobody can access are not a strategy.

Evidence to request in quarterly reviews

Job history for critical systems. Last restore test note. Failure list and resolutions. Updated coverage one-pager.

If evidence never appears, you are buying reassurance, not recovery.

Tabletop for leadership (fifteen minutes)

If ransomware hit tonight, who is called first? Which system restores first so you can take payments or serve clients? Where are backup credentials? What downtime is acceptable? What do you tell staff and customers in hour one?

Shrugs mean readiness gaps even if the product logo is impressive.

Scenario: excluded volume after expansion

Disk expanded, backup job still green, restore incomplete. Drill found it. Production incident would have hurt more.

Questions about volumes and app-consistent backups exist to catch this class of failure.

Scenario: cloud mailbox retention surprise

A deleted mailbox conversation is older than native retention and no backup exists. Customer dispute becomes painful.

Ask retention questions before you need the email.

Scoring answers: clear, partial, unknown

Clear means you could explain it to another owner. Partial means a product exists with fuzzy ownership. Unknown means no evidence.

Unknown on critical systems is a project. Partial on cloud suites is a common small-office wound.

FAQ: backup and recovery questions

How many questions are enough? Enough to fill the one-pager without gaps on critical systems.

What if our partner gets defensive? That is signal. Recovery should welcome scrutiny.

Do we need immutable storage? Often valuable; ask what your tooling supports and what risk you accept without it.

How does Cytrix help? Inventory what is covered, clarify ownership, and put restore testing on the calendar.

Question block 1: Inventory first

Before interviewing a partner, list systems you believe matter. Bring invoices for backup products. Bring any portal screenshots you have. Incomplete inputs still beat starting from zero.

Ask the partner to correct your list. The corrections are often the most valuable part of the meeting.

Question block 2: Coverage interrogation

For each system on the list, ask: is it backed up, by what product, on what schedule, with what retention, and where are copies stored?

Write answers in a table as you hear them. Empty cells are findings.

• System name.
• Product.
• Schedule.
• Retention.
• Copy locations.
• Owner who can restore.

Question block 3: Restore evidence request

Ask for the last restore test of a real object. If none exists, schedule one before you debate tooling brands.

Watch who hesitates. Hesitation often means restores are rare.

Question block 4: Ransomware path walkthrough

Ask them to narrate hour zero to hour forty-eight of a ransomware event for an office your size. Who isolates? Who talks to leadership? Which system restores first? What vendors are engaged?

A credible narrative includes uncertainty. An incredible narrative promises perfection.

Question block 5: Credential separation review

Ask how backup admin credentials are stored and who can change retention or delete jobs. Ask whether everyday domain admins can destroy backups.

If the answer is effectively yes, discuss compensating controls before you move on.

Question block 6: Exit and portability

Ask how you would keep recovery options if you leave the partner or change products. Ask what history you lose and what notice is required.

Portability is part of resilience, not a distrust exercise.

Sample interview script you can reuse

Open with business context: headcount, locations, critical apps, and any hard deadlines. Then walk coverage, retention, restore evidence, alerting, ransomware path, and exit.

Close by asking them to produce the one-pager within a week. Set the expectation that blank cells are acceptable if labeled unknown with a plan.

How to compare two MSPs on backups

Compare evidence quality, not logo count. Prefer the partner who shows a restore note and a clear gap list over the partner who claims complete protection without artifacts.

Price matters, but untested cheap backups are expensive on the wrong week.

Operational cadence after you get answers

Put restore tests on the calendar. Review failures monthly. Update the one-pager quarterly. Tie gaps to roadmap funding.

Questions without cadence become a one-time workshop that decays.

Recovery time and recovery point in plain English

Recovery point is how much recent work you can afford to lose. Recovery time is how long you can afford to be down. Ask your partner what their design aims for on your critical systems, and whether anyone tested against those aims.

If nobody can translate the product settings into those two ideas, keep asking until they can. Budgets make more sense when tied to business tolerance.

Immutable and offline copies explained without hype

Immutable or offline copies make it harder for ransomware or a compromised admin account to delete every recovery point. Ask what your tooling supports and what it costs to enable.

If you cannot enable it yet, document the accepted risk and a revisit date. Silence is not acceptance.

Application-consistent versus crash-consistent backups

Databases and some line-of-business apps need application-aware backups or vetted procedures. File copies alone can be insufficient. Ask which of your apps need special handling and who owns that procedure.

This is a common gap in small offices that added a server years ago and never revisited backup design.

Seed devices, bandwidth, and first full backups

Initial backups of large data sets can saturate office internet or take days. Ask how first full backups will be handled for servers or large file stores, especially at smaller suites with modest circuits.

Planning here prevents a quiet week of slowness and incomplete first jobs.

Restore destination planning

Know where restores land: isolated share, alternate folder, spare server, or cloud recovery target. Know who approves production overwrites when that is truly required.

Drills should usually avoid overwriting production. Emergencies sometimes cannot. Write the difference down.

Communication plan during a multi-hour recovery

Who updates staff? Who updates ownership? Who talks to customers if client-facing systems are down? How often do updates go out even when there is no new technical news?

Recovery fails socially when technical work is fine but nobody hears anything for three hours.

Checklist: evidence pack to request annually

Coverage one-pager. Restore test log for the year. Failure and resolution summary. Credential separation notes. Ransomware path narrative updated for your current systems.

Annual does not replace quarterly drills. It packages proof for leadership and insurers when asked.

• Coverage one-pager current.
• Restore test log.
• Backup failure summary.
• Credential separation notes.
• Ransomware path narrative.

Workshop agenda: ninety minutes on backups

15 minutes: business critical systems. 30 minutes: coverage table fill-in. 20 minutes: restore evidence and gaps. 15 minutes: ransomware path. 10 minutes: next drill date and owners.

Leave with artifacts, not only discussion. The table and the next calendar invite are the deliverables.

Extended FAQ for stubborn edge cases

What about NAS devices in closets? Include them by name. What about founder laptops with unique files? Redirect data or back them up explicitly. What about SaaS tools outside Microsoft 365? Ask whether exports or backups exist and who owns them.

What about backups that succeed but cannot restore a particular application? That is why application-aware questions and drills exist. What about partial tenant compromises? Your ransomware path should include identity containment, not only disk restores.

Runbook outline for a full day of recovery

Morning: declare incident, isolate, assemble roles, confirm backup accessibility. Midday: restore priority system one, communicate status, protect backup credentials. Afternoon: restore next systems, verify integrity, plan staff return to work. Evening: document timeline and remaining gaps.

Customize the outline to your critical systems. The value is having roles and order before adrenaline decides for you.

• Incident lead named.
• Technical restore lead named.
• Communications lead named.
• Priority restore order listed.
• Backup credential access confirmed.
• Status cadence set.

Questions for cloud-only small offices

If you have no servers, do not skip backup questions. Ask about mailbox and file retention, ransomware rollback, accidental deletion beyond native recycle bins, and admin account compromise scenarios.

Cloud-only is not backup-free. It changes which questions dominate, not whether questions matter.

Procurement checklist when buying backup tooling

Coverage for your real systems. Retention options. Restore test support. Alerting. Credential controls. Exit story. Support path when restores fail. Cost clarity for storage growth.

Tool choice without this checklist becomes logo shopping.

Full question bank you can paste into an email

What systems are backed up by name? Where do copies live and for how long? When was the last restore of a real file or mailbox, and what was the result? Who is alerted on failures and how fast do they respond? What is the ransomware recovery sequence and who leads it?

What is out of scope today? How are backup credentials separated from everyday admin accounts? What happens to history if we change providers? What restore time should we expect for a single file versus a critical system rebuild? Which line-of-business apps need application-aware handling?

Send the bank before the meeting. Ask for written answers. Meeting time then becomes clarification, not first discovery.

• Coverage by system name.
• Retention and copy locations.
• Last restore evidence.
• Failure alerting and response.
• Ransomware sequence and roles.
• Out-of-scope list.
• Credential separation.
• Exit and history portability.
• Restore time expectations.
• App-aware requirements.

After the answers: 30-day action plan

Week 1: publish the one-pager with unknowns labeled. Week 2: schedule the next restore drill. Week 3: close or fund the top two gaps. Week 4: present status to ownership with revisit dates for accepted risks.

Questions without a 30-day plan become trivia. Attach dates.

Closing note: make recovery discussable

The goal of these questions is not to embarrass a partner. The goal is to make recovery discussable in ordinary language before a crisis. If answers are clear, celebrate and schedule drills. If answers are partial, fund the gaps. If answers are unknown, treat that as urgent project work.

Central Texas offices that can show a one-pager and a recent restore note are already ahead of peers who only have a green icon.

When to call Cytrix

Call Cytrix when you need a clear backup and restore conversation, or when you cannot get straight answers from the current setup. Bring any existing backup portal access or invoices so we can inventory what is actually covered.

If you are preparing for an MSP change, ask us to include backup ownership and restore testing in the transition checklist.

You can also call 512-518-1228 for a quick triage conversation during business hours.