Backup4all creates repeatable backup jobs for selected files, folders, and supported program settings. A job records what to copy, where to store it, which backup method to use, and when it should run. The result can be a direct mirror or a versioned archive on local storage, a network path, remote storage, or a configured cloud destination. Backup4all protects copies of existing data; it does not synchronize every edit instantly or repair a damaged source file before copying it.
Jobs keep four choices
The New Backup Wizard separates a job into destination, sources, method, and schedule. Sources can be selected manually or filled by a plugin that knows the usual files for a supported program. A plugin is a selection definition, not a copy of that program or proof that every custom data folder belongs to the job.
Filters can include or exclude names, types, dates, sizes, or attributes. An exclusion acts before the archive is written. A backup can finish successfully while omitting a wanted file that matched a broad filter, so inspect the source tree and filter result before relying on the first run.
Methods change recovery
A full backup copies every selected item into a self-contained set. An incremental backup stores changes since the latest relevant backup, while a differential backup stores changes since the last full set. Restoring an incremental chain depends on more pieces than restoring one full set.
Mirror creates a one-to-one copy instead of one versioned archive. It keeps familiar files at the destination and can preserve NTFS permissions and alternate streams. A mirror also follows the current source state, so replacing or removing source material can affect what remains after later mirror runs. It is not a permanent version history by itself.
Smart controls retention
Smart Backup starts with a full set and chooses later full, differential, incremental, merge, or cleanup work according to job settings and available destination space. The user can limit its storage by a fixed amount or a percentage of the destination.
This method reduces manual retention decisions, but it does not let the user demand an exact count of saved file versions. Tight space limits can cause earlier versions to leave sooner than expected. A recovery plan that needs a fixed monthly point should use a method and cleanup rule that states that requirement directly.
Catalogs track versions
Backup4all keeps a catalog separate from the backup payload. The catalog records which files and versions belong to each run, making it possible to browse an earlier state without scanning every archive first. Removing the catalog does not automatically erase every archive, but it removes the normal map used for restore and later backup decisions.
Keep catalog copies with the destination when the job supports that option. A catalog that points to missing archive parts cannot restore those parts. Repair Catalog Only removes missing or corrupted destination entries from the catalog so a later backup can copy them again; it does not reconstruct absent data from nothing.
Tests check archives
A test reads backup data and compares integrity information. Backup4all can test after a run or schedule a separate test for selected backup numbers. A successful write notification and an integrity test answer different questions, so a completed job should not become the only copy before a test succeeds.
Integrity testing confirms that the stored archive can be read consistently. It does not prove that an operating system, database, or program will work after individual files return. Restore a sample to another folder and open it when the recovery procedure matters.
Encryption needs custody
ZIP archives can use password protection and AES encryption. Encryption protects stored content from someone who has the archive but lacks the password. It also blocks the owner when the password is lost. Backup4all cannot make an encrypted recovery independent of that secret.
Store the password outside the protected destination and do not place the only copy inside the encrypted backup. Standard ZIP compatibility also differs by encryption method; a third-party archive reader must understand the chosen method before it can open the files without Backup4all.
Schedules can erase
A schedule can run a backup, integrity test, repair, or catalog repair. The Clear backup before run option deletes the existing catalog and associated ZIP files before the scheduled backup begins. If the new run then fails, the older recovery set has already gone.
Leave that option off unless the job deliberately replaces its history and another recovery copy exists. Scheduled work also depends on Windows Task Scheduler and access to the destination. A disconnected drive, expired remote credential, or sleeping computer can prevent the planned run even though the schedule remains listed.
