WordPress Auto Backup

Author:	Ahmed KHABER (profile at wordpress.org)
WordPress version required:	3.1
WordPress version tested:	4.3
Plugin version:	1.0
Added to WordPress repository:	14-08-2015
Last updated:	02-09-2015 Warning! This plugin has not been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.
Rating, %:	100
Rated by:	1
Plugin URI:	http://www.sl3-unlocking.com/plugins.php
Total downloads:	2 348
Active installs:	10+
Click to start download

Description: This security plugin detects and backup wordpress database and WP CONTENT folder automatically in function to frequency time that is adjusted in admin panel, without need to back up them manually every time, these backed up automatically when visitor access to your web site pages or when you get access to your WordPress administrator interface, so this plugin useful in case you have loosed or modified your databases either deleted accidentally or hacked, so you have a chance 100% to recover them safely!

A few notes about the sections above:

"Contributors" is a comma separated list of wp.org/wp-plugins.org usernames
"Tags" is a comma separated list of tags that apply to the plugin
"Requires at least" is the lowest version that the plugin will work on
"Tested up to" is the highest version that you've successfully used to test the plugin. Note that it might work on higher versions... this is just the highest one you've verified.
Stable tag should indicate the Subversion "tag" of the latest stable version, or "trunk," if you use /trunk/ for stable.

Note that the readme.txt of the stable tag is the one that is considered the defining one for the plugin, so if the /trunk/readme.txt file says that the stable tag is 4.3, then it is /tags/4.3/readme.txt that'll be used for displaying information about the plugin. In this situation, the only thing considered from the trunk readme.txt is the stable tag pointer. Thus, if you develop in trunk, you can update the trunk readme.txt to reflect changes in your in-development version, without having that information incorrectly disclosed about the current stable version that lacks those changes -- as long as the trunk's readme.txt points to the correct stable tag.

If no stable tag is provided, it is assumed that trunk is stable, but you should specify "trunk" if that's where you put the stable version, in order to eliminate any doubt.