A data backup is a separate, recoverable copy of business information created to protect against deletion, corruption, device failure, account loss, cyberattack, software error, and provider failure.
For a solopreneur, losing data may mean losing more than files. The business could lose:
- Unfinished client work
- Customer and order records
- Website content and databases
- Financial documentation
- Product source files
- Subscriber lists
- Contracts and licenses
- Code repositories
- Automation configurations
- Research and content archives
- Access to essential accounts
- Years of accumulated operating knowledge
A good backup strategy defines what must be protected, how frequently copies are created, where they are stored, how long they are retained, who can access them, and how restoration is tested.
What Is a Data Backup?
A data backup is a copy of information maintained specifically so the information can be recovered after the original becomes unavailable, damaged, altered, or deleted.
The copy must be sufficiently independent from the original. Copying a file into another folder on the same laptop does not protect it from device failure, theft, ransomware, or loss of the account controlling the device.
A complete backup process has five stages:
- Identify the data that requires protection.
- Create a separate recoverable copy.
- Protect the copy from alteration and unauthorized access.
- Retain appropriate historical versions.
- Test that the required information can be restored.
The final stage is the one most frequently assumed rather than verified.
Backup vs. Sync, Archive, Snapshot, and Export
Several technologies create additional copies of data, but they serve different purposes.
| Method | Primary purpose | Main limitation |
|---|---|---|
| Backup | Recover lost, damaged, or compromised data | Must be configured, monitored, and tested |
| Synchronization | Keep current files consistent across devices | Deletion or corruption may synchronize everywhere |
| Version history | Recover earlier versions within one service | Retention may be short or controlled by the same account |
| Archive | Preserve inactive records for future reference | May not support rapid operational recovery |
| Snapshot | Capture a system or storage state at one point | May depend on the original provider or infrastructure |
| Replication | Maintain a current copy for availability | Can immediately replicate corruption or unauthorized changes |
| Export | Create a portable copy from an application | Often excludes settings, relationships, or metadata |
| Recycle bin | Temporarily retain deleted items | Has limited retention and does not cover every loss event |
One system can use several of these methods. A cloud document platform may provide synchronization, version history, a recycle bin, and provider-managed infrastructure recovery. An independent backup is still useful when the same account can delete or alter all those copies.
Why Cloud Storage Is Not Automatically a Backup
Cloud storage protects against some physical failures, but it does not automatically protect against:
- Accidental deletion synchronized across devices
- Ransomware encrypting synchronized folders
- Compromised administrator accounts
- Subscription cancellation
- Account suspension
- Provider-specific retention limits
- Application-level corruption
- Malicious deletion
- Loss of encryption keys
- Inability to export information
- Failure of a connected automation
- Closure of the service
Cloud providers generally protect the operation of their infrastructure while customers retain responsibility for how their data is classified, configured, accessed, retained, and exported. Current Microsoft guidance explicitly assigns customers responsibility for their data, accounts, devices, and many application-level controls even when the underlying service is managed.
The important question is therefore not, “Is this information in the cloud?” It is, “Can I recover the required information independently if the application, account, or provider becomes unavailable?”
What Data Should a Solopreneur Back Up?
Start with a data inventory. Do not begin by buying storage and copying everything indiscriminately.
Revenue-Critical Data
This is information required to deliver, sell, invoice, or collect revenue:
- Active client projects
- Customer accounts
- Order records
- Product files
- Subscription records
- Sales pipeline
- Proposals and signed agreements
- Deliverable history
- Pricing and offer configurations
- Payment reconciliation records
- Affiliate transaction exports
- Sponsorship commitments
- License and royalty records
Financial and Legal Records
Protect records required for accounting, tax, contractual, insurance, or ownership purposes:
- Invoices
- Receipts
- Bank statements
- Expense records
- Tax filings
- Payroll or contractor records
- Contracts
- Insurance policies
- Corporate records
- Intellectual-property documentation
- Software licenses
- Consent records
- Required compliance evidence
Retention periods for these records depend on jurisdiction and document type. A backup policy should follow the applicable legal requirement rather than applying one period to every file.
Website and Ecommerce Data
A website backup may require more than a copy of its visible pages:
- Database
- Uploaded media
- Custom themes
- Custom plugins
- Application code
- Product catalogue
- Order data
- Customer accounts
- Forms and form submissions
- Redirect rules
- Server configuration
- Environment configuration
- Scheduled tasks
- Analytics configuration
- Tag-management configuration
- DNS records
- Email delivery settings
For a WordPress website, backing up only wp-content preserves many files but not the posts, users, settings, and other information stored in the database. Backing up only the database omits uploaded images and custom code. A recoverable WordPress backup normally needs both.
Marketing and Audience Data
Protect information that would be costly or impossible to reconstruct:
- Email subscriber lists
- Suppression and unsubscribe lists
- Segments and tags
- Campaign templates
- Automated sequences
- Lead-magnet source files
- Customer research
- Search-performance exports
- Advertising configurations
- Original creative assets
- Content calendars
- Published-content inventory
- Partnership and media contacts
Unsubscribe and suppression records are especially important. Restoring an old subscriber list without the latest opt-outs can cause messages to be sent to people who have already withdrawn permission.
Operating Knowledge
A business may retain its files but lose the knowledge required to use them.
Back up:
- Standard operating procedures
- Checklists
- Decision logs
- Naming conventions
- Publishing processes
- Financial definitions
- Supplier instructions
- Contractor handover notes
- Data dictionaries
- System diagrams
- Recovery instructions
- Current commitments
- Renewal schedules
Code, Automation, and Configuration
Modern businesses depend on configuration as much as on traditional documents.
Include:
- Source code
- Repository history
- Deployment configuration
- Automation workflows
- Database schemas
- API configuration documentation
- Webhooks
- Scheduled jobs
- Infrastructure definitions
- Custom scripts
- No-code application exports
- Integration maps
- Plugin and extension lists
- Dependency lock files
- Environment-variable names
Do not place live API keys, unencrypted credentials, or other secrets casually inside ordinary backups. Back up secrets through an appropriate encrypted secret-management and recovery process.
AI Workflow Assets
When AI is part of production work, consider protecting:
- Approved prompt libraries
- System instructions
- Source datasets
- Retrieval documents
- Evaluation criteria
- Tested output examples
- Model and version records
- Human review decisions
- Custom tool configurations
- Generated assets that cannot be reproduced reliably
- Licensing and provenance records
A generated output should not be treated as reproducible merely because the original prompt survives. Models, external sources, settings, and connected tools may change.
Classify Data Before Designing the Backup
Not every file deserves the same frequency, retention, or recovery speed.
| Class | Meaning | Examples | Typical treatment |
|---|---|---|---|
| Critical | Loss immediately affects revenue, customers, or obligations | Orders, active client work, current database | Frequent automated backup and rapid restore testing |
| Important | Loss creates substantial cost but not immediate interruption | Content archive, financial documents, product sources | Daily or weekly backup with version retention |
| Replaceable | Can be recreated from another source | Installers, public reference files, software packages | Limited backup or documented source |
| Temporary | Has no continuing business value | Caches, intermediate exports, duplicate downloads | Exclude from backup |
| Restricted | Requires additional confidentiality controls | Personal data, financial records, credentials | Encrypted backup with limited access |
| Retained record | Must remain available for a defined period | Contracts, tax records, consent evidence | Policy-based retention and controlled deletion |
Data classification controls cost and risk simultaneously. Backing up unnecessary personal data forever increases exposure without improving recovery.
Set Backup Frequency From Acceptable Data Loss
Backup frequency should be based on how much recent work or transaction data the business can afford to lose.
This limit is called the recovery point objective.
Recovery point objective = maximum acceptable period of data loss
Examples:
- A static reference website may tolerate 24 hours of lost changes.
- A busy online store may tolerate only minutes of lost orders.
- Active client documents may require several versions per day.
- Monthly accounting reports may be adequately protected by daily backups.
- An archived design library may need a new backup only when files change.
| Data | Acceptable loss | Suggested backup pattern |
|---|---|---|
| Ecommerce orders | 15 minutes | Continuous or frequent database protection |
| Active client files | 1–4 hours | Versioned synchronization plus independent daily backup |
| Website database | 4–24 hours | Automated daily backup, more often during campaigns |
| Email contacts | 24 hours | Daily provider backup or scheduled export |
| Accounting records | 24 hours | Daily backup or export |
| Content archive | 24 hours | Daily incremental backup |
| Contracts | One completed document | Back up immediately after signing |
| System configuration | One approved change | Back up before and after material changes |
| Media archive | One working session | Daily or after each major import |
A daily backup does not guarantee that the maximum loss will be one day. A failed job can double the exposure before anyone notices. Monitoring and failure alerts must therefore be part of the frequency decision.
Set a Recovery Time Requirement
The recovery time objective is the target period for making the required data usable again.
Recovery time objective = target time to restore usable access
Frequency and recovery speed are separate. A backup may be only one hour old but require two days to download, decrypt, rebuild, and verify.
Estimate the full restoration time:
Total restoration time = detection + access + download + rebuild + validation
Storage volume can materially affect recovery. Transferring 500 GB over a connection that sustains 100 megabits per second takes approximately 11.1 hours under ideal conditions. Encryption, small files, provider limits, network variation, and verification increase the actual time.
A low-cost archival service may be appropriate for historical assets but unsuitable for a system that must return within two hours.
Use the 3-2-1 Backup Rule
The established 3-2-1 rule means maintaining:
- 3 copies of important data
- 2 different storage types
- 1 copy off-site
The three copies normally consist of the working copy and two backups. The CISA guidance recommends the 3-2-1 structure while also emphasizing encryption, offline copies, and restoration testing.
A simple solopreneur implementation could be:
- Working files on the primary computer or business application
- Automated versioned backup to an independent cloud service
- Encrypted backup on an external drive stored separately
Using two folders in the same cloud account does not provide meaningful independence. A compromised account, provider failure, or erroneous retention rule may affect both.
Extend 3-2-1 for Cyber Recovery
Some backup practitioners extend the rule to 3-2-1-1-0:
- 3 copies
- 2 storage types
- 1 off-site copy
- 1 offline or immutable copy
- 0 unverified backup errors
The additional numbers are not a substitute for risk analysis. They highlight two weaknesses in a basic backup design: attackers may reach connected backups, and successful backup jobs may still produce unusable copies.
Offline Backup
An offline backup is physically or logically disconnected from the normal production environment when it is not being used.
Examples include:
- Disconnected encrypted external drive
- Removable media stored securely
- Backup repository inaccessible through normal user accounts
- Isolated recovery environment
An external drive left permanently connected can be encrypted or deleted by the same attack that affects the computer.
Immutable Backup
An immutable backup cannot be altered or deleted during a defined retention period, including by a compromised normal administrator account.
Possible controls include:
- Object-lock retention
- Write-once storage
- Provider-enforced immutability
- Locked snapshots
- Separate backup administration
- Delayed deletion
- Multi-person approval for destructive changes
Immutability must cover the backup data and the controls governing its retention. If the same compromised account can disable protection and delete every copy, the design is not meaningfully immutable.
Zero Unverified Errors
Zero does not mean failure is impossible. It means backup jobs, integrity checks, and restore tests have no unresolved errors before the system is considered healthy.
A dashboard showing “backup completed” establishes only that a process ran. It does not prove that:
- All required data was included
- The data is internally consistent
- Encryption keys are available
- The copy is free from corruption
- The application can be rebuilt
- The correct version can be located
- Restoration will finish within the required time
Choose the Right Backup Type
Full Backup
A full backup copies the entire selected dataset.
Advantages:
- Simple restoration
- Fewer dependencies between backup sets
- Easy to understand
Limitations:
- Requires more storage
- Takes longer to create
- May consume more bandwidth
Incremental Backup
An incremental backup copies changes made since the previous backup of any type.
Advantages:
- Fast and storage-efficient
- Suitable for frequent automated backups
Limitations:
- Restoration may depend on a full backup and several incremental sets
- One damaged link can affect recovery
- Recovery can take longer
Differential Backup
A differential backup copies changes since the last full backup.
Advantages:
- Restoration typically needs only the full backup and latest differential
- Less complex than a long incremental chain
Limitations:
- Each differential grows until the next full backup
- Uses more storage than incremental backups
Image Backup
An image backup captures an entire device, disk, virtual machine, or system state.
Advantages:
- Can restore operating system, applications, settings, and files
- Useful after complete device failure
Limitations:
- Larger than file-level backups
- Hardware or platform differences may complicate restoration
- Does not replace portable exports of important application data
Snapshot
A snapshot records the state of a system or storage volume at a particular time.
Advantages:
- Fast creation
- Rapid rollback
- Useful before updates or configuration changes
Limitations:
- Often stored within the same infrastructure
- May depend on the original platform
- May not protect against provider or account loss
Application Export
An export creates a portable copy from a SaaS platform or application.
Advantages:
- Reduces provider lock-in
- Can preserve business records in common formats
- Useful when native backup controls are limited
Limitations:
- May omit settings, automations, attachments, relationships, history, or permissions
- Importing the data elsewhere may require substantial work
- A successful export does not prove successful restoration
Most solopreneurs need a combination rather than a single type.
Back Up SaaS Applications Independently
Software-as-a-service platforms may maintain internal backups to operate their service, but those backups are not always customer-accessible or designed to reverse every user-level mistake.
Before relying on a SaaS platform, verify:
- What information can be exported
- Whether exports include attachments and metadata
- Available file formats
- Version-history retention
- Deleted-item retention
- Account-closure retention
- Restoration granularity
- Restoration cost
- Whether administrators can delete all copies
- Whether provider backups can recover individual records
- Whether integrations and automations are included
- How long a complete export takes
- Whether another application can import the result
Create scheduled exports for systems containing material business data, including:
- CRM
- Email marketing
- Accounting
- Ecommerce
- Help desk
- Project management
- No-code databases
- Form systems
- Digital-product platforms
- Cloud documents
- Password and identity systems, using their approved secure process
A spreadsheet export may preserve CRM contacts while losing custom fields, activity history, attachments, and pipeline logic. Test whether the exported information is sufficient for the intended recovery.
Create Versioned Backups
Keeping only the latest copy protects poorly against slow or delayed problems.
Examples include:
- Corruption discovered weeks later
- Malicious changes made gradually
- A formula error copied into later files
- Incorrect data imports
- Deleted content noticed after the recycle bin expires
- A compromised website backed up after infection
- An automation overwriting records silently
A versioned retention schedule might keep:
- Hourly versions for 24 hours
- Daily versions for 30 days
- Weekly versions for 12 weeks
- Monthly versions for 12 months
- Annual versions for the required archival period
This is an example, not a universal schedule. Retention should reflect:
- How quickly errors are detected
- How frequently information changes
- Legal recordkeeping requirements
- Personal-data minimization
- Storage cost
- Contractual obligations
- The value of historical versions
- The likelihood that current copies are already compromised
Longer retention increases the chance of finding a clean recovery point, but it also retains confidential and obsolete information for longer.
Protect Backups Against Ransomware
Ransomware can encrypt, delete, or exfiltrate production data and then target connected backups.
The 2026 Verizon report found that ransomware was involved in 48% of the breaches in its dataset, up from 44% in the previous report. This makes backup isolation a practical requirement rather than an advanced precaution.
The CISA ransomware recommendations include maintaining offline, encrypted backups and regularly testing their availability and integrity.
A ransomware-resilient design should:
- Separate backup credentials from everyday accounts
- Prevent normal devices from deleting historical backups
- Use immutable or offline copies
- Retain versions old enough to predate delayed detection
- Protect backup administration with multifactor authentication
- Alert on mass deletion or configuration changes
- Keep recovery instructions outside the affected environment
- Scan or inspect restored data before reconnecting it
- Restore into an isolated environment when compromise is suspected
- Preserve evidence before overwriting affected systems
Do not automatically restore the most recent copy after a cyberattack. It may contain malicious software, compromised configuration, encrypted files, or unauthorized accounts.
Encrypt Backup Data
Backups frequently contain a broader concentration of information than any single working system. They may include customer data, financial documents, private communications, contracts, and intellectual property.
Protect sensitive backups:
- During transfer
- At rest
- On removable media
- In cloud storage
- During restoration
- When being retired or destroyed
Encryption is effective only when key management works. If the only decryption key is stored on the failed laptop or inside the inaccessible account, the encrypted backup is unrecoverable.
Document:
- What is encrypted
- Where encryption keys are held
- Who can use them
- How recovery keys are protected
- How key access is audited
- What happens if the owner is unavailable
- How old encrypted backups remain readable
- How keys and copies are securely destroyed
The EDPB guide explains that encryption helps protect confidentiality, but encrypted personal data remains personal data. Encryption therefore does not remove retention, access, or governance responsibilities.
Separate Backup Access From Production Access
A backup controlled by the same identity as production may share the same failure.
Improve separation by using:
- Different administrative credentials
- Separate multifactor authentication
- Dedicated backup accounts
- Restricted deletion permissions
- Independent recovery email addresses
- Separate billing and renewal alerts
- Least-privilege access
- Alerts for administrative changes
- Delayed or protected deletion
- An emergency recovery method
Avoid placing backup credentials in:
- Unencrypted notes
- The same folder being backed up
- Browser bookmarks
- Shared project documents
- Source-code repositories
- Automation logs
- Email messages without appropriate protection
Separation should not make legitimate recovery impossible. Test the emergency access route as well as the backup itself.
Automate Backup Creation
Manual backups are appropriate before major changes, but they are unreliable as the primary system.
People forget to:
- Connect the external drive
- Export the database
- Copy newly created folders
- Check whether the upload finished
- Update the backup after a busy day
- Remove failed jobs
- Verify available storage
- Test restoration
Automate:
- Backup schedules
- Version retention
- Failure notifications
- Storage-capacity alerts
- Integrity checks
- Export generation
- Backup replication
- Expiration of obsolete copies
- Reports of unprotected systems
Automation must fail visibly. A silent backup failure can continue for months while giving the owner false confidence.
Send alerts through a channel that does not depend entirely on the system being protected. If an expired credit card stops the backup service, the renewal notice should not go only to an email account that may also be inaccessible.
Create Manual Backups Before High-Risk Changes
Scheduled backups may not align with operational changes.
Create a verified recovery point before:
- Website migration
- Software upgrade
- Theme or plugin update
- Database import
- Bulk content edit
- Domain or DNS change
- Major automation change
- New integration
- Device replacement
- Account restructuring
- Data cleanup
- Application cancellation
- Contractor handover
- Security remediation
Label the backup with the event and time. “Pre-migration — verified” is more useful than an unidentified file among hundreds of automated copies.
Retain the pre-change copy until the new state has operated successfully for an appropriate period.
Back Up the Complete Recovery Chain
Restoration may fail because one dependency is missing even when the main data survives.
For a website, the chain may include:
- Domain access
- DNS configuration
- Hosting account
- Application files
- Database
- Runtime version
- Encryption or application keys
- Email configuration
- Third-party integrations
- Recovery instructions
For an online store, the chain may also include:
- Product catalogue
- Customer records
- Current orders
- Payment references
- Inventory
- Tax settings
- Shipping rules
- Email templates
- Consent records
- Refund history
For an AI-assisted content workflow, it may include:
- Source documents
- Prompts
- model settings
- Custom instructions
- Structured output definitions
- Human-edited drafts
- Final assets
- Publication records
The backup inventory should identify these relationships. A database without its application, schema, encryption key, or version documentation may be technically intact but operationally unusable.
Monitor Backup Health
Review backup status as an operating measure, not only after an incident.
Useful measures include:
- Percentage of critical systems covered
- Successful jobs divided by scheduled jobs
- Age of the latest successful backup
- Age of the latest verified restore
- Number of unresolved backup errors
- Percentage of copies encrypted
- Percentage with offline or immutable protection
- Actual recovery point achieved
- Actual restoration time
- Difference between actual and target restoration time
- Number of systems without documented recovery instructions
- Number of backups approaching capacity or expiration
- Percentage of SaaS platforms with current portable exports
A basic coverage calculation is:
Backup coverage = protected critical datasets ÷ total critical datasets × 100
Coverage should measure recoverable datasets, not merely systems with a backup feature enabled.
Test Backup Restoration
A backup test should prove that the correct data can be located, decrypted, restored, opened, and used.
The July 2026 initial NIST draft recommends testing backups at least monthly for critical data and using end-to-end restoration tests for applications with strict recovery requirements. Because the publication is a draft, treat its timing as current proposed guidance rather than a finalized universal rule.
File-Level Test
Restore several individual files and verify:
- Correct file
- Correct version
- Complete content
- Original metadata where required
- Successful decryption
- Usability in the relevant application
Folder or Project Test
Restore a complete project, including its structure, attachments, and related files.
This reveals missing subfolders, broken links, incomplete permissions, and excluded file types.
Application Test
Restore the database, files, settings, and dependencies in a safe environment. Verify important functions rather than checking only whether the application opens.
For a website, test:
- Pages
- Images
- Login
- Forms
- Search
- Checkout
- Transaction records
- Redirects
- Scheduled tasks
- Email delivery
- Security controls
Clean-Recovery Test
When testing cyber recovery, restore into an isolated environment and confirm that the selected recovery point is not already compromised.
Full Device Test
Where device images are part of the strategy, verify that the image can restore to supported hardware or a compatible virtual environment.
SaaS Export Test
Open the export, examine its completeness, and test whether records can be reconstructed in the same or an alternative application.
Use a Defined Testing Schedule
| Frequency | Test |
|---|---|
| Daily | Automated job status and failure alerts |
| Weekly | Review unresolved errors and storage capacity |
| Monthly | Restore selected critical files and verify current exports |
| Quarterly | Restore one complete project, website, database, or SaaS dataset |
| Twice yearly | Test a full priority-system recovery |
| Annually | Review the complete inventory, retention policy, access, encryption, and recovery order |
| After major change | Create and verify a new recovery point |
| After a failure | Correct the cause and repeat the failed test |
Testing frequency should increase when data changes rapidly, recovery is complex, or the business has recently changed systems.
Record:
- Backup selected
- Recovery point
- Test environment
- Start and finish time
- Data restored
- Functions verified
- Errors found
- Actual recovery time
- Corrective action
- Next test date
Verify Data Integrity
Integrity means that restored information is complete and has not been altered unexpectedly.
Possible verification methods include:
- Checksums
- Hash comparison
- Backup-software integrity checks
- Database consistency checks
- Record-count comparison
- File-count comparison
- Transaction reconciliation
- Application validation
- Manual sampling
- Digital signatures
- Media health checks
Integrity checks do not replace functional testing. A database file can pass a storage-level checksum while containing incomplete or logically incorrect business records.
For transactional systems, compare restored records with an independent source such as payment settlements, order confirmations, or accounting records.
Establish a Retention and Deletion Policy
A backup retention policy defines how long each copy is kept and when it is destroyed.
The policy should specify:
- Data category
- Backup frequency
- Version intervals
- Minimum retention
- Maximum retention
- Legal or contractual basis
- Storage location
- Destruction method
- Exception process
- Person responsible
Backups should not become a permanent warehouse for information that the business has decided to delete.
The ICO guidance advises defining retention periods for archived and backed-up personal information. It also notes that information cannot be retained indefinitely merely because it may become useful.
Where immediate deletion from a protected backup is technically impractical, a documented process may keep the information beyond ordinary use until the backup expires through its controlled deletion cycle. The precise requirement depends on the applicable law and circumstances.
Handle Personal Data in Backups
A backup copy of personal data remains subject to applicable privacy and security requirements.
Consider:
- Lawful purpose for retention
- Data minimization
- Storage duration
- Access restrictions
- Encryption
- Storage country
- International transfers
- Processor contracts
- Retrieval for valid requests
- Correction and deletion procedures
- Breach response
- Secure destruction
Avoid restoring obsolete data into production without considering changes made after the recovery point.
For example, an older customer database may contain:
- People who subsequently unsubscribed
- Accounts that were deleted
- Corrected personal information
- Expired permissions
- Completed deletion requests
- Old staff or contractor access
- Superseded contractual records
After restoration, replay legitimate changes from an independent record before resuming ordinary processing.
Control Backup Storage Costs
A backup strategy should protect economic value rather than maximize stored volume.
Estimate annual cost using:
Annual backup cost = storage + transfer + retrieval + software + testing + administration
Include expenses that are easy to overlook:
- Minimum storage periods
- Download or retrieval charges
- API export costs
- Additional user licenses
- External drives
- Replacement media
- Encryption or key management
- Technical assistance
- Time required for testing
- Temporary recovery infrastructure
Reduce cost safely by:
- Excluding replaceable and temporary data
- Compressing appropriate files
- Deduplicating repeated data
- Moving old copies to archival tiers
- Applying different retention by data class
- Deleting expired records
- Backing up source assets rather than disposable derivatives
- Monitoring abnormal storage growth
Do not reduce cost by keeping only one recent backup. That removes the historical depth needed to recover from delayed corruption or compromise.
A Practical Backup System for a Solopreneur
Assume a solopreneur operates a consulting service, several content websites, an email newsletter, and cloud-based accounting.
Primary Systems
- Laptop
- Cloud document platform
- Website hosting
- Email marketing platform
- Accounting application
- Code repository
- Password manager
Backup Design
| Data | Primary copy | Second copy | Independent copy | Frequency | Retention |
|---|---|---|---|---|---|
| Active client files | Cloud documents | Versioned cloud backup | Encrypted external drive | Continuous plus daily | 90 daily, 12 monthly |
| Website files | Hosting server | Automated off-site backup | Monthly encrypted archive | Daily | 30 daily, 12 monthly |
| Website database | Hosting database | Independent cloud backup | Encrypted monthly copy | Every 6 hours | 30 days plus 12 monthly |
| Email subscribers | Email platform | Automated export | Encrypted offline copy | Daily | 30 days |
| Accounting records | Accounting SaaS | Monthly full export | Encrypted offline copy | Daily provider protection plus monthly export | Legal retention period |
| Content source files | Laptop and cloud drive | Versioned backup | External drive | Daily | 12 months plus annual archive |
| Code | Git repository | Mirrored repository | Offline release archive | Every commit plus release | Project life plus required archive |
| Procedures | Cloud documents | Backup service | Printed or encrypted emergency copy | After change | Current plus prior versions |
Testing Schedule
- Restore a client file every month
- Restore one website quarterly
- Validate subscriber exports monthly
- Open accounting exports quarterly
- Recover one code release twice yearly
- Test the external drive twice yearly
- Review encryption keys and recovery access annually
This design is only an example. A high-volume store would require more frequent database protection and transaction reconciliation, while a low-change informational website could use a simpler schedule.
Data Backup Policy Template
Policy Details
- Business:
- Policy owner:
- Version:
- Effective date:
- Last review:
- Next review:
Backup Objectives
- Maximum acceptable data loss:
- Maximum acceptable recovery time:
- Critical data categories:
- Regulatory or contractual requirements:
- Required offline or immutable protection:
Data Inventory
| Dataset | Business owner | Location | Classification | Backup method | Frequency | Retention |
|---|---|---|---|---|---|---|
Storage Locations
| Location | Provider or device | Data stored | Encryption | Administrator | Deletion protection |
|---|---|---|---|---|---|
Access
- Backup administrator:
- Emergency access holder:
- Authentication method:
- Recovery-key location:
- Access review frequency:
- Administrative-change alerts:
Monitoring
- Failure notification:
- Capacity notification:
- Expiration notification:
- Person responsible for resolving errors:
- Maximum permitted unresolved error period:
Restore Testing
| System | Test type | Frequency | Target recovery time | Last result | Next test |
|---|---|---|---|---|---|
Retention and Destruction
- Daily-copy retention:
- Weekly-copy retention:
- Monthly-copy retention:
- Annual-copy retention:
- Legal holds:
- Destruction method:
- Destruction record:
- Exceptions:
Common Data Backup Mistakes
Treating Synchronization as Backup
Deletion, encryption, or corruption is propagated to every synchronized device.
Depending Entirely on the Provider
Provider recovery may protect infrastructure but not support the required record, version, retention period, or account-loss scenario.
Keeping Only the Latest Copy
A delayed problem makes the only retained backup unusable.
Using One Account for Everything
Compromising the main identity also compromises cloud files, backups, billing, and deletion controls.
Leaving the External Drive Connected
The drive becomes vulnerable to the same malware, electrical event, or user error as the computer.
Backing Up Files but Not Databases
Visible assets survive while posts, customers, orders, or application settings disappear.
Backing Up a Database Without Its Dependencies
The data survives but cannot be used without the application version, schema, keys, or configuration.
Ignoring SaaS Data
The business assumes provider availability is equivalent to customer-controlled recoverability.
Storing Credentials in the Backup Folder
The backup exposes the secrets required to compromise the systems it protects.
Encrypting Without Protecting the Key
Loss of the device or account containing the only key makes the backup permanently unreadable.
Retaining Everything Forever
Storage costs, breach exposure, privacy obligations, and retrieval difficulty all increase.
Trusting Completion Notifications
The backup job succeeds while excluding a new folder, corrupted database, or unsupported file type.
Failing to Test a Full Restore
Individual files work, but the complete application cannot be reconstructed.
Restoring the Newest Copy Automatically
The latest backup may contain the same corruption or malicious change as production.
Ignoring Recovery Bandwidth
The backup exists but cannot be downloaded within the required time.
Forgetting Configuration and Automations
Business data returns while forms, integrations, webhooks, and scheduled processes remain broken.
Implement a Backup Strategy
Step 1: Inventory Business Data
List every location where valuable information is created or stored.
Step 2: Remove Unnecessary Data
Delete duplicates, temporary files, and records that no longer have a valid purpose.
Step 3: Classify the Remaining Data
Separate critical, important, replaceable, temporary, restricted, and retained records.
Step 4: Define Acceptable Loss
Set a recovery point objective for each critical dataset.
Step 5: Define Required Recovery Speed
Set a realistic recovery time objective, including download, rebuild, and verification.
Step 6: Select Backup Methods
Choose the appropriate combination of full, incremental, versioned, image, snapshot, and export backups.
Step 7: Apply the 3-2-1 Rule
Maintain the working copy, a separate backup, and an off-site backup across at least two storage types.
Step 8: Add Offline or Immutable Protection
Ensure that compromise of an everyday account cannot delete every recovery point.
Step 9: Encrypt Sensitive Copies
Protect the data and create a separate, tested recovery process for encryption keys.
Step 10: Automate Schedules and Alerts
Make failures, low capacity, billing problems, and retention changes visible.
Step 11: Document Dependencies
Record the applications, versions, configurations, keys, and accounts required for restoration.
Step 12: Perform the First Restore Test
Recover an important dataset in a safe environment and measure the result.
Step 13: Correct Missing Coverage
Add excluded folders, incomplete exports, unavailable keys, and undocumented configuration.
Step 14: Establish Retention
Keep enough history to recover from delayed problems without retaining data indefinitely.
Step 15: Schedule Future Tests
Assign monthly, quarterly, and annual verification activities.
Data Backup Checklist
- Inventory all business data.
- Identify where each dataset is stored.
- Mark critical and important datasets.
- Identify personal and confidential information.
- Remove unnecessary data.
- Define the maximum acceptable loss for each critical dataset.
- Define the required recovery time.
- Select appropriate backup types.
- Maintain at least three copies of critical data.
- Use at least two storage types.
- Keep at least one copy off-site.
- Add an offline or immutable recovery copy.
- Separate backup and production credentials.
- Enable multifactor authentication.
- Encrypt sensitive backup data.
- Protect encryption recovery keys.
- Automate backup schedules.
- Configure failure notifications.
- Configure capacity alerts.
- Monitor billing and renewal failures.
- Keep historical versions.
- Define daily, weekly, monthly, and annual retention.
- Back up website files.
- Back up website databases.
- Back up application configuration.
- Back up DNS and domain records.
- Export important SaaS data.
- Verify that exports contain attachments and metadata.
- Protect subscriber suppression records.
- Back up financial and legal records.
- Back up active client work.
- Back up product source files.
- Back up code and deployment configuration.
- Document required software versions.
- Record dependencies and restoration order.
- Create manual backups before high-risk changes.
- Test individual file restoration.
- Test a complete project restoration.
- Test a database or application restoration.
- Test an independent SaaS export.
- Scan restored data after a suspected compromise.
- Compare restored transaction counts.
- Record actual restoration time.
- Resolve every backup error.
- Review access permissions.
- Delete expired backup data securely.
- Update the policy after system changes.
- Set the next restore-test date.
Frequently Asked Questions
What is the best backup strategy for a solopreneur?
A strong starting point is the 3-2-1 strategy: maintain the working copy and two backups, use at least two storage types, and keep one copy off-site. Add an offline or immutable copy for critical data and test restoration regularly.
Is Google Drive, Dropbox, OneDrive, or iCloud a backup?
These services may provide synchronization, version history, and deleted-item recovery, but those features do not cover every loss event. An independent versioned backup protects against account compromise, synchronized deletion, retention limits, and provider dependence.
How often should business data be backed up?
Backup frequency should match the maximum amount of recent data the business can afford to lose. Transactional data may require protection every few minutes, active files every few hours, and low-change archives daily or weekly.
What is the 3-2-1 backup rule?
The rule means keeping three copies of important data on two different storage types, with one copy stored off-site. The three copies normally include the production copy and two backups.
What is the 3-2-1-1-0 backup rule?
It extends 3-2-1 by adding one offline or immutable copy and requiring zero unresolved verification errors. It emphasizes cyber resilience and tested recoverability.
What is an immutable backup?
An immutable backup cannot be changed or deleted during a defined retention period. It helps protect recovery copies from ransomware, compromised accounts, and accidental deletion.
Is an external hard drive enough?
Not by itself. It can protect against some device and provider failures, but it may be lost, damaged, stolen, or compromised while connected. Combine it with an automated off-site copy and test both.
Should an external backup drive remain connected?
Normally, at least one recovery copy should remain disconnected or otherwise isolated. A permanently connected drive may be affected by ransomware, power events, or accidental deletion.
Are website hosting backups sufficient?
Hosting backups are useful, but they may have short retention, remain inside the same provider, or become unavailable with the hosting account. Maintain an independent copy and test restoration outside the production website.
What should a WordPress backup contain?
It should normally include the database, uploads, custom themes, custom plugins, configuration, and any files required to reconstruct the site. Domain, DNS, email, and external integration settings should also be documented.
Should email be backed up?
Yes, when email contains contracts, customer commitments, financial records, or other information that cannot be reconstructed. Consider message exports, attachments, contacts, calendars, and required retention.
How should SaaS data be backed up?
Use provider-native backups where available and create independent exports or third-party backups for important records. Verify that the method includes attachments, metadata, relationships, settings, and historical records needed for recovery.
How long should backups be retained?
Retention depends on how quickly problems are detected, how frequently data changes, legal requirements, customer obligations, privacy considerations, and storage cost. Use several historical intervals instead of keeping only the newest copy.
Should backups be encrypted?
Sensitive and personal data should be encrypted when appropriate to the risk. The encryption keys must be stored and recoverable independently; otherwise, encryption can prevent legitimate restoration.
How often should backup restoration be tested?
Critical files may be tested monthly, complete systems quarterly or twice yearly, and the full backup policy at least annually. Test again after major migrations, system changes, or failed recovery attempts.
How can I tell whether a backup worked?
Restore the selected data, decrypt it, open it, verify its contents, compare important record counts, and test the functions that depend on it. A successful job notification alone is insufficient.
What is the difference between RPO and RTO?
The recovery point objective defines how much recent data loss is acceptable. The recovery time objective defines how quickly usable access must be restored.
Can ransomware affect backups?
Yes. Ransomware and compromised administrators may encrypt or delete connected backups. Use separate credentials, historical versions, immutable storage, and offline copies.
Should passwords and API keys be included in ordinary backups?
Not in unencrypted files or normal backup folders. Use an approved password manager or secret-management system with its own secure recovery procedure.
What is the most important backup for a solopreneur?
The most important backup is the one covering data whose loss would prevent revenue, customer service, legal compliance, or control of the business. Its value is established only after a successful restore test.