Changed-chunk (delta) transfers keep steady-state backups small by sending only modified parts of files. When these savings disappear—upload size jumps, cloud quota balloons, or bandwidth spikes—small businesses and IT teams face surprise costs and recovery uncertainty. This runbook helps you troubleshoot changed-chunk delta growth for Windows endpoints using clear checks, isolating tests and safe mitigations. AgooCloud (RVLWorks, SL) supports file-level changed-chunk uploads; these steps are vendor-agnostic but tailored to Windows realities.

Understand the likely causes

Start by mapping why deltas balloon. Common causes include:

  • Mass renames or path changes: Renaming many files or moving folders can look like new files to the agent, forcing large uploads.
  • Metadata-only churn: Frequent changes to timestamps, ACLs or extended attributes can invalidate chunk alignment or index entries.
  • Client-side encryption toggled or changed: Switching or reconfiguring encryption can convert stable deltas into full-file uploads if encryption happens after chunking.
  • Sparse, virtual or pre-allocated files: Virtual disk images, database files or sparse files sometimes change internal blocks unpredictably and defeat delta detection.
  • Antivirus or content rewriters: Real-time scanners, content filters or cloud sync tools that rewrite files (even harmless headers) change many bytes per file.
  • Agent or index corruption: A local agent index or checksum database reset (for example after a config change or upgrade) may force re-seeding of chunks.
  • Application-layer inconsistency: Copying a live database or mailstore without VSS/consistency produces large binary changes that look like full rewrites.

Quick checks to confirm the cause

Run these non-destructive checks before applying fixes.

  1. Top-uploaders report: Check your backup dashboard or agent logs for the specific files/folders that caused the spike. Identify patterns by extension, path or owner.
  2. Agent event/log review: Look for messages about "full-file upload", index rebuilds, or encryption changes. Note agent version and recent updates.
  3. System events: Inspect Windows Event Viewer (Application/System) around the spike window for VSS, filesystem, or driver errors.
  4. File metadata sampling: Compare timestamps, ACLs and sizes for a handful of affected files—did only metadata change, or did content change?
  5. AV and file-monitoring: Check antivirus logs or file-integrity tools for bulk scans or rewrites coinciding with the spike.
  6. Quota/time-series: Pull cloud quota and bandwidth graphs to see if the spike is sustained or a single event.

Reproducible tests to isolate the culprit

Use small, controlled experiments to confirm what defeats changed-chunk efficiency.

  1. Create a test folder: On the same machine, create a folder with representative files (a large VHD/VMDK stub, a PST/OST-like file, a large text file and a binary file).
  2. Baseline backup: Allow the agent to complete a normal backup of the test folder and record the uploaded bytes and number of chunks.
  3. Modify only metadata: Change file timestamps or ACLs on the text and binary file and run a backup. If uploads equal previous full-chunk sizes, metadata changes are the issue.
  4. Modify content vs rename: Make a small content edit to one file and rename another. Compare delta sizes—rename should trigger larger uploads if the agent treats path as identity.
  5. Disable AV rewrite (safe window): If you can safely pause real-time rewriting tools for a short test window, rerun the backup to see if churn disappears. Do this only during low-risk periods.
  6. Test with snapshot/export: For live apps (databases, mail stores), produce an application-aware export (or VSS snapshot) and back that export instead of the live file to observe reduced deltas.

Non-destructive mitigation options

Apply mitigations that avoid data loss and let you verify results.

  • Exclude or isolate problematic files: Use exclude rules for known dedup-unfriendly files (large VM images, OST/PST) or place them on a different backup policy with less frequent full backups.
  • Use application-aware exports: For databases or mail stores, schedule exports or VSS-aware snapshots and back those artifacts instead of live files.
  • Stagger and throttle: Introduce backup windows, bandwidth caps and staged processing to avoid simultaneous reuploads across many endpoints.
  • Re-seed carefully: If local index corruption caused a re-seed, consider a controlled re-seed: temporarily use a local seed device or perform a single full upload only for the affected endpoint. Coordinate this with quota owners and schedule off-hours.
  • Retain a temporary local copy: For large files, keep local-first backups so cloud reuploads won’t consume quota each time you need a local restore.
  • Adjust retention/tiers: Move infrequently changed large files into an archival tier or different retention policy to limit quota growth.

Vendor-ready diagnostic bundle (what to collect)

If you need provider support (for example AgooCloud support), gather these artifacts in a single, time-stamped bundle.

  • Agent version, OS build, machine name and user context at the incident time.
  • Agent log files covering the incident window (upload session logs, chunking logs, index rebuild messages).
  • List of the top 50 uploaded files with timestamps, sizes and paths from the admin UI or logs.
  • Sample file metadata and small sample checksums (for a few affected files) showing before/after if available.
  • Cloud quota and per-client upload totals (time-series screenshot or CSV) for the preceding 7–30 days.
  • Windows Event Viewer extracts (VSS, Application, System) and antivirus or file-monitoring logs from the same window.
  • Perf counters snapshot: network bytes/sec, Disk I/O (reads/writes), CPU, memory, and relevant Windows counters such as VSS and file system throughput.
  • Notes on recent changes: agent updates, policy edits, encryption toggles, or mass file operations.

Safe validation tests to confirm the fix

  1. After mitigation, run the same controlled test folder sequence and compare uploaded bytes and chunk counts to the original baseline.
  2. Perform a targeted restore of a changed file to verify both upload and restore paths function.
  3. Monitor quota and bandwidth for a full policy cycle; document that rates returned to expected steady-state.
  4. If you implemented exclusion or policy changes, validate they are applied and do not block critical data from being recoverable.

Decision guide: quick fixes vs deeper actions

  • If the spike was a single event tied to a known operation (mass rename, import): document and accept the one-time cost; consider scheduling such operations with a mitigation window.
  • If recurring and linked to file types or apps: Implement exclusion, dedicated policies, or application-aware exports.
  • If tied to agent/index corruption or encryption reconfiguration: coordinate a controlled re-seed or vendor-assisted index reconciliation while preserving existing cloud copies.

Changed-chunk savings usually return once the root cause is addressed, but verification is important. Use the diagnostic bundle above to shorten incident resolution and to provide reproducible evidence to support teams like AgooCloud support. These steps help European small businesses and IT administrators regain predictable quota and bandwidth behaviour without risking data integrity during troubleshooting.