How to Run a Google Workspace Backup Health Review Without Extra Tools

Many small environments run Google Workspace without a dedicated SaaS backup solution. That doesn’t mean you can’t assess your recovery readiness. Using only native tools, you can run a meaningful backup health review that answers three questions:

• What data is retained long enough to meet recovery needs?
• How quickly and reliably can we restore specific items or accounts?
• What risks could prevent recovery?

This guide shows you the steps to run a Google Workspace health review without extra tools.

Steps to run a Google Workspace health review

Before starting, ensure you have the following requirements for a smooth process.

📌 General prerequisites:

• Super Admin or Admin roles with access to Admin Console, Audit and Investigation, and Vault if licensed.

💡 Vault is Google Workspace’s eDiscovery and retention tool that helps preserve, search, and export data for compliance and recovery.

• Knowledge of organizational units and Shared Drives in your tenant.
• For optional API checks, a Google Cloud project with Admin SDK Reports API enabled and an OAuth client for delegated access.
• A worksheet to capture findings, Recovery Time Objective (RTO), Recovery Point Objective (RPO), and remediation owners.

Step 1: Define scope and recovery objectives

Before running a Google Workspace health review, you must establish the scope and recovery objectives. Be clear on what you’re protecting and how success can be measured.

📌 Use Cases: Establishing baseline recovery expectations.

📌 Prerequisite: Admin access to Google Workspace.

Steps:

1. Inventory data locations.

• • Identify active users, suspended users, and recently deleted accounts.
  • List Shared Drives and check file ownership patterns.
  • Include Gmail, Calendar, Contacts, and Drive content.

2. Set recovery targets.

• • Define Recovery Point Objective (RPO): How much data loss is acceptable?
  • Define Recovery Time Objective (RTO): How quickly data must be restored?
  • Set minimum retention windows that meet these targets.

💡Read “RTO vs. RPO” to learn the difference.

3. Select review samples.

• • Choose at least three user accounts representing key departments (e.g., HR, Finance, Sales).
  • Pick at least one Shared Drive with high collaborative use.
  • These samples will be used in later restore tests.

Deliverable

Create a one-page scope and targets sheet that includes:

• Data types and locations covered
• Users and Shared Drives selected for testing
• RPO and PTO targets per data class
• Minimum retention requirements

Step 2: Validate retention and holds with Google Vault

With your scope and recovery objectives defined, the next step is to confirm that Google Vault supports those requirements. Vault enforces retention and legal holds across Gmail, Drive, Chat, and Meet, making it the foundation of your long-term data protection.

📌 Use Cases: Ensuring compliance with data retention regulations.

📌 Prerequisites:

• A Google Workspace edition that includes Vault (Business Plus, Enterprise, or Education).
• Admin privileges to review and configure Vault policies.

Steps:

1. Check that Vault licenses are assigned to all users covered by your retention policies.
2. Review default and organization unit (OU) retention policies.

• • Navigate to Vault > Retention and review rules for:
    1. Gmail
    2. Drive
    3. Chat
    4. Meet recordings
  • Verify that rules exist and that exceptions are documented.

3. Confirm time windows and delete behavior after expiry.
4. Verify legal holds.

• • Navigate to Vault > Holds and check:
    1. VIP mailboxes (e.g., executives, HR, finance, legal)
    2. Ensure holds are active and scoped correctly.

1. Understand expiry behavior.

• • Gmail: Messages can be permanently purged once the user’s Trash (30 days) and Vault retention expire.
  • Drive: Items may take up to 15 days to be removed after retention ends.

Deliverable

Create a retention matrix listing:

• Each service (Gmail, Drive, Chat, Meet, Groups)
• Rule type (default, OU-specific, hold)
• Time window
• Exceptions or gaps

Step 3: Confirm native restore paths without Google Vault

If your organization or Google Workspace editions don’t include Vault, you must rely on Google’s built-in restore options. This step confirms what you can recover without Vault and where the limits apply.

📌 Use Cases: Quick recovery of accidentally deleted files or emails.

📌 Prerequisite: Admin access to the Google Admin Console.

Steps:

Use Admin Console and app trash features to validate restore capability when Vault is not in scope.

1. Drive restore by Admin (within 25 days after trash is emptied)

• • Path: Admin Console > Users > [select user] > Restore data > Drive > choose date range

⚠️ Important: After 25 days post-Trash, items are permanently purged.

2. Gmail restore by Admin (for permanently deleted messages)

• • Path: Admin Console > Users > [select user] > Restore data > Gmail > choose date range

⚠️ Important: This only works within the 25-day window after deletion.

3. Calendar restore (user-level, within 30 days)

• • Path: Calendar web > Settings > Trash > Restore events

⚠️ Important: Events are only recoverable for 30 days.

4. Drive restore (user-level, within 30 days)

• • Path: Google Drive > Trash > Restore item

⚠️ Important: Files in Trash are auto-deleted after 30 days.

Deliverable

Prepare a quick-reference table that shows:

• Who can restore (Admin or User)
• What type of data can be restored
• Time limits
• Navigation path

Recommendation

If native restore limits don’t meet your defined RTO or RPO targets, implement one or more of the following:

• Adopt a third-party SaaS backup to achieve longer recovery windows or granular item-level restores.
• Adjust retention and offboarding policies to minimize data loss within the native limits.
• Add Vault licensing for all covered users to extend retention and recovery options.

Step 4: Test account-level recovery scenarios

Validate user-level recoverability by simulating events such as offboarding, accidental deletion, or security incidents. This confirms that your team can restore user data and access shared resources when accounts are removed or restored.

📌 Use Cases: 

• Employee offboarding and preserving user data.
• Recovering from accidental user deletion.

📌 Prerequisites:

• Admin access to the Google Admin Console.
• A test user account or a recently suspended account for simulation.

Steps:

1. Undelete a user (within 20 days)

• • Path: Admin Console > Users > Recently deleted > Restore

⚠️ Important: After 20 days, the account and its data are permanently deleted.

2. Validate file ownership transfer and access

• • After restoring the user, check:
    1. Drive file ownership: Are files still accessible?
    2. Shared Drive membership: Is the user still listed?
  • For deleted users, confirm recovery of Drive files based on:
    1. Whether files were shared.
    2. Whether ownership was transferred before deletion.
  • Path: Admin Console > Apps > Google Workspace > Drive and Docs > Transfer ownership.

Deliverable

Create a documented playbook that includes:

• Step-by-step recovery instructions
• Ownership transfer procedures
• Time constraints

Step 5: Audit risky events using the Audit and Investigation Tool

Protecting your backup and recovery plan also means monitoring threats that can compromise data integrity. Use Google Workspace’s Audit and Investigation Tool to detect user or admin actions that could affect recoverability.

📌 Use Cases: 

• Detecting mass deletions or ownership changes.
• Investigating incidents that may lead to data loss.

📌 Prerequisite: Admin access to the Security Center in Google Workspace.

Steps:

1. Open the Audit and Investigation Tool.

• • Path: Admin Console > Security > Audit and investigation > [select relevant data sources]

2. Run a Drive audit search.

• • Filter for:
    1. Delete
    2. Empty trash
    3. Ownership changes
    4. Bulk sharing or external sharing

3. Run as Admin activity audit.

• • Filter for:
    1. Changes to retention rules
    2. Sharing policy updates
    3. Vault configuration changes

4. Export findings to a CSV or Google Sheet for tracking.

Deliverable

Produce a weekly or monthly export of high-risk events that includes:

• Event type
• Affected users or files
• Time of occurrence
• Remediation actions taken

Step 6: Perform sample deletion-and-restore exercises

This step tests your backup review in practice. Run controlled deletion-and-restore exercises with sample users and Shared Drives. The goal is to confirm that recovery works across core Google Workspace services using native tools.

📌 Use Cases: Verifying that recovery time objectives (RTOs) are achievable.

📌 Prerequisites:

• Admin access to the Google Admin Console.
• Test accounts

Steps:

1. Select test accounts and the Shared Drive.

💡 Tip: Use the representative users and the Shared Drive chosen in Step 1.

2. Delete test items.

• • For each selected user and one Shared Drive, delete:
    1. One non-critical email
    2. One calendar event
    3. OneDrive file

3. Restore data using the native paths (Step 3).
4. Measure RTO.

• • Record the time taken to complete each restore.

5. Confirm item integrity.

• • Check that restored items are complete, usable, and unchanged.
  • Note any errors, delays, or missing data.

Deliverable

Create a restoration test log showing:

• Test user or Shared Drive
• Items deleted and restored
• The restore method used
• Time taken (RTO)
• Integrity check result
• Notes on issues or improvements

Step 7: Establish a gap registry and action plan

After completing your backup health review, you must act on the findings. Build a gap registry that lists every issue and ties each to a clear action plan. This ensures results aren’t just observed but converted into improvements.

📌 Use Cases: Tracking coverage or retention gaps, resolving ownership issues, and preparing for audits and compliance reviews.

📌 Prerequisites:

• Completed backup health review (Steps 1-6)

Steps:

1. Record gaps.

• • Log issues such as:
    1. No vault coverage for certain organizational units (OUs).
    2. Shared Drives without assigned managers.
    3. Frequent mass deletions flagged in audit logs.
    4. Inconsistent restore success rates.

2. Map each gap to key attributes.

• • For each gap, document:
    1. Risk level
    2. Owner
    3. Due date
    4. Control type

3. Tie gaps to RTO/PTO targets.

• • Prioritize gaps that threaten your recovery objectives.

Deliverable

Create a living gap register that is:

• Reviewed monthly
• Updated with status changes

Step 8: Optional API-backed spot checks using PowerShell

You can add automation to your backup health review with API checks. If you prefer a scriptable method without third-party tools, use the Admin SDK Reports API to count Drive delete actions in the last N days. This step is optional, but it gives you a scalable way to cross-check activity across all users.

📌 Use Cases: Automating Drive activity checks across all users.

📌 Prerequisites:

• A Super Admin account in Google Workspace.
• A Google Cloud project with the Admin SDK API enabled.
• OAuth 2.0 credentials with domain-wide delegation.
• PowerShell is installed on your local machine or server.

Steps:

1. Enable the API.

• • Navigate to Google Cloud Console > APIs & Services > Library.
  • Enable Admin SDK API.

2. Create credentials.

• • Navigate to Google Cloud Console > Credentials, and create an OAuth 2.0 client ID.
  • Enable domain-wide delegation.

3. Acquire an OAuth access token for a Super Admin.
4. Run this minimal PowerShell snippet to query Drive activity:

5. View results in the PowerShell output or export to CSV for reporting.

Deliverable

Produce a simple CSV file or on-screen report showing Drive deletion events, including:

• Event ID
• Timestamp
• Actor (user who performed the action)

Use this report as a reference and extend queries with other Drive audit event names from the Reports API documentation.

Step 9: Last-resort coverage review with data export (break glass option)

If Vault, native restores, and other methods fail, the Google Workspace Data Export Tool is a last resort or a “break glass” option to retrieve organizational data. It’s designed for full tenant data exports in emergency or compliance scenarios.

📌 Use Cases: Recovering data when Vault or native restore paths are unavailable.

📌 Prerequisites:

• Super Admin access.
• A Google Workspace edition that supports the Data Export Tool.

Steps:

1. Review eligibility and constraints.

• • Path: Admin Console > Tools > Data Export.
  • Confirm that your edition and Super Admin role allow access.

2. Launch a data export run.

• • Click Start Export, and Google will prepare a downloadable archive of:
    1. Gmail
    2. Drive
    3. Calendar
    4. Contacts
    5. Sites and more

3. Locate and interpret the export report.

• • Google will email Super Admins when the export is ready.
  • Navigate to Admin Console > Tools > Data Export > View Export.
  • Review the export report for completeness.

4. Understand partial export remediation notes and limitations.

• • Export may be partial due to:
    1. Large data volumes
    2. API limits
    3. User permissions
  • Some data types may not be included.
  • Links are temporary and must be downloaded promptly.

Deliverable

Create a one-page SOP that includes:

• Who can initiate exports
• When and why to use this method
• Export steps and validation checks
• Security handling instructions

Verification

Once the backup health review is completed, you need to verify and document the results. This section provides evidence, metrics, and exceptions that validate whether your recovery objectives were met and where improvements are needed.

⚠️ Things to look out for

💡 Note: Google documents all retention rules, Trash behavior, and API controls. Reference these official sources in your review to support your findings and make your audit defensible.

NinjaOne integration

While this review deliberately avoids third-party backup tools, NinjaOne can still play a valuable role in supporting the process:

Troubleshooting

Here are common issues you might encounter and how to resolve them:

Expected item not visible after Drive restore

If a restored file is not visible, it’s often due to propagation delays. Restoration can take time depending on the data size. Confirm the selected date range volume and validate the user account before trying to restore again.

Calendar event not restorable

Calendar events can only be restored within 30 days. After that, they’re permanently lost. Confirm the deletion date and advise users to avoid manual purging unless required.

User deletion beyond 20 days

If a user account was deleted more than 20 days ago, recovery isn’t possible. To avoid this, update offboarding SOPs to suspend first, transfer data ownership, and delete the account.

Data export inconsistencies

Google’s Data Export Tool may produce partial exports due to API limits, large data volumes, or permission issues. Review the export report and remediation notes. Some items may require a repeat export or an alternate recovery method.

Run a Google Workspace health review to protect your data

Running a Google Workspace backup health review without extra tools is practical and effective. Validating retention, testing restores, and auditing risky events allows you to measure real RPO and RTO, uncover gaps, and create an action plan to reduce recovery risk. With these results documented, you also have the evidence to justify dedicated backup when required.

Related topics:

• How to Backup Google Workspace Drive
• SaaS Backup: Complete Guide & Best Practices
• Simple Guide to Recovering Deleted or Lost Gmail Data