Title: Nimble Backup Author: nimbleplugins.com Published: 2026년 9월 17일 Last modified: 2026년 9월 30일 --- 플러그인 검색 ![](https://ps.w.org/nimble-backup/assets/banner-772x250.png?rev=3700784) ![](https://ps.w.org/nimble-backup/assets/icon-256x256.png?rev=3700784) # Nimble Backup 작성자: [nimbleplugins.com](https://profiles.wordpress.org/nimbleplugin/) [다운로드](https://downloads.wordpress.org/plugin/nimble-backup.1.45.4.zip) * [세부사항](https://ko.wordpress.org/plugins/nimble-backup/#description) * [평가](https://ko.wordpress.org/plugins/nimble-backup/#reviews) * [설치](https://ko.wordpress.org/plugins/nimble-backup/#installation) * [개발](https://ko.wordpress.org/plugins/nimble-backup/#developers) [지원](https://wordpress.org/support/plugin/nimble-backup/) ## 설명 Nimble Backup protects the WordPress database and `wp-content` on a schedule or on demand. A run produces one archive per part of the site — the database, plugins, themes, uploads, and the rest of wp-content — which share a date and an id, so they can be restored together as one backup or one at a time. Each finished backup can also be sent to storage you own: S3-compatible object storage, Dropbox, Google Drive or OneDrive/SharePoint. Nothing is sent anywhere until you set a destination up, and nothing passes through NimblePlugins at any point. It also includes a migration workflow for moving a WordPress site between servers without FTP. #### Backup and recovery * Create a backup on demand. * Schedule daily or weekly backups. * Choose what each run covers – must-use plugins, plugins, themes, uploads, the database – one archive per part, kept together as one backup. * Keep a configurable number of recent recovery points. * Build large backups in resumable chunks to reduce request-timeout and disk-I/ O pressure. * Verify new archives before they are marked successful. * Download, restore or delete backups from WordPress admin – a whole backup, or one part of it. * Send each finished backup off-site to S3-compatible storage, Dropbox, Google Drive or OneDrive/SharePoint, and bring it back down again when you need to restore from there. * Create a verified pre-restore safety point before a destructive restore. Restore stops if that safety point cannot be created. * Keep backup archives when the plugin is uninstalled, so removing the plugin never silently removes recovery data. #### Secure local storage Working data is stored below `wp-content/uploads/nimble-backup/`. Backup and migration directories receive Apache and IIS deny rules plus non-index files, and archive filenames include a random suffix. Local backups protect against application-level failures, bad updates and accidental changes. They sit on the same server as the site, and so are not a substitute for an off-site copy if the disk or the hosting account goes away — which is what the destinations above are for. #### Migration The Migration tabs create one package containing the WordPress database and `wp- content`, then transfer it directly from a source WordPress site to a destination WordPress site using a random, expiring token. The destination validates the archive before extraction, rejects unsafe paths and symbolic links, and creates a verified local pre-import recovery point before overwriting existing data. The transfer token can be manually revoked as soon as the migration is complete. Migration also supports different WordPress database table prefixes and performs serialization-safe source-to-destination URL replacement after import. #### Nimble Security integration Nimble Backup implements the public `nimble_security_recovery_point_providers` contract. When Nimble Security requires a recovery point before a destructive response action, Backup creates and verifies the recovery point synchronously. If it cannot do so safely, Security receives an error and can stop the destructive action. No incident content, credentials or archive contents are exchanged through this contract. Only the recovery-point reference is returned. #### Nimble Operations integration Nimble Backup exposes its native Operations health provider through `nimble_backup_operations_health` contract 1.1. The provider reports aggregate backup, schedule, storage, integrity, restore and migration state without exposing archive contents, filesystem paths, credentials, destination details or transfer tokens. #### Privacy Backup archives stay on the WordPress installation unless you configure an off-site destination yourself, in which case a copy also goes to the account you named with the provider you chose. Nimble Backup never uploads anything to NimblePlugins, and no NimblePlugins cloud service is involved in backup, restore or migration at any point. The optional migration feature only communicates with the source site URL explicitly entered by an administrator, authenticated by a short-lived token. ### Where the plugin writes Nimble Backup keeps everything it creates in one protected folder inside the uploads directory, resolved at runtime with wp_upload_dir(): backup archives, migration packages, database dumps and working files all live under `uploads/nimble-backup/`. That folder is created with an .htaccess file, a web.config file and an index.php silence file, so the archives are not reachable over the web. Restoring a backup, and completing a migration, writes files back into wp-content. That is the purpose of the plugin: a backup that cannot be restored is not a backup. The WordPress plugin guidelines allow this for backup and migration plugins, and Nimble Backup keeps that write as narrow as it can: * Only wp-content is ever written. The plugin does not back up or restore WordPress core, and it never writes to wp-admin, wp-includes or the site root. * A restore or migration only ever runs from an explicit action by a logged-in administrator, behind a capability check and a nonce. Nothing is restored automatically, on a schedule, or in the background. * A backup run produces one archive per part of the site, each containing only what that part holds: a database dump, or a copy of one directory under wp-content. * The plugin never writes to its own plugin folder, to other plugins’ folders or to any theme folder outside a restore. * The two working files a backup needs – the database dump it builds before zipping, and the directory a package is unpacked into before a restore – are both created inside `uploads/nimble-backup/` and deleted when the job finishes. A database dump is data, not something the server executes; it is only ever read back statement by statement through $wpdb during a restore the administrator started. * When an off-site destination is set up, each finished archive is also sent there. Nothing is ever read back from it on its own: bringing an archive back down happens only when an administrator asks for that archive by name, and it is written into` uploads/nimble-backup/` like any other. ### For developers Another plugin can offer credentials this site already holds, so a destination need not be set up twice: ``` add_filter( 'nimble_backup_credential_sources', function ( array $sources, string $provider ) { if ( 'dropbox' !== $provider ) { return $sources; } $sources['my-plugin'] = array( 'label' => 'My Plugin', // Called only when the administrator presses the button. Return this // plugin's own field names => values, or a WP_Error saying why not. 'fetch' => static function ( string $provider ) { return array( 'app_key' => '…', 'app_secret' => '…', 'refresh_token' => '…', ); }, ); return $sources; }, 10, 2 ); ``` The callable is what keeps this cheap and private: drawing the button costs nothing, and the credentials are read at the moment somebody asks for them rather than on every page render. Destinations themselves are pluggable the same way, through `nimble_backup_destinations`. ### External services Nimble Backup does not contact NimblePlugins. It sends nothing anywhere that you have not configured yourself. Off-site storage is the one feature that contacts a service outside your own servers, and only after you choose one and enter its credentials. Four are available, none of them enabled by default and none of them contacted until you set one up: * S3-compatible object storage. No default and no suggested provider; the endpoint, bucket, region and keys are all yours to enter. Tested against Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, Hetzner and MinIO. Requests go to the endpoint you entered. Terms: the provider you chose. * Dropbox – api.dropboxapi.com and content.dropboxapi.com. Used to hold your archives in a folder of your Dropbox. Terms: https://www.dropbox.com/terms and https:// www.dropbox.com/privacy * Google Drive – oauth2.googleapis.com and www.googleapis.com. Used to hold your archives in a folder of your Google Drive. Terms: https://policies.google.com/ terms and https://policies.google.com/privacy * OneDrive and SharePoint – login.microsoftonline.com and graph.microsoft.com. Used to hold your archives in a folder of your OneDrive or a SharePoint library. Terms: https://www.microsoft.com/servicesagreement and https://privacy.microsoft. com/privacystatement The same answers apply to all four: * What is used for: sending a copy of each finished backup archive somewhere the server itself cannot take with it when it fails, and reading it back when you restore from there. * What is sent, and when: the backup archive, which contains a dump of your database and a copy of wp-content – including any personal data those hold. It is sent over HTTPS after a backup completes, whether that backup was started by hand or by the schedule. Nothing is sent when no destination is set up, which is the default. * What is never sent: nothing else. No telemetry, no site identity, no usage statistics, and nothing at all to NimblePlugins. * Whose account, whose app: Dropbox, Google Drive and OneDrive each need an app registered by you, with keys you enter yourself. This plugin ships no keys of its own and contacts none of these services until you have entered yours. * Whose terms apply: the provider you chose. Their terms of service and privacy policy are the ones that govern the copy, because it is your account with them. There are two further outbound requests, and neither involves a third party: * Server-to-server migration. The destination site fetches the package directly from the source site over HTTPS, using the URL and token shown on the source site’s Export tab. You type that address in yourself, so the only host contacted is the one you chose. No copy passes through NimblePlugins. * A loopback request to your own site. Long backups are started in the background by having the site call its own home URL, so a slow job cannot be cut short by a reverse-proxy timeout. Nothing leaves the server. ### Privacy Backup archives contain whatever your site contains, including personal data in the database. They stay on your server unless you configure off-site storage, in which case a copy also goes to the bucket you named, under your own account with that provider. The plugin sends no telemetry, no usage statistics and no file contents to NimblePlugins, ever. The secret key for off-site storage is stored encrypted, with a key derived from this installation’s own salts. Define AUTH_KEY and AUTH_SALT in wp-config.php if they are not already: wp-config.php is never part of a backup, so the stored key then cannot be opened using the contents of an archive. Without them WordPress keeps the salts in the database, which is inside every archive. The settings screen says which of the two applies to your site. A migration token is valid for 24 hours from the moment it is generated, after which the download endpoint refuses it. You can revoke a token at any time from the Export tab. Migration packages are not deleted automatically once transferred, so remove the package from the source site when the migration is done. ## 스크린샷 [⌊Backup and Restore. Four lines say what is set up — how often it runs, what it covers, how many are kept, where the off-site copy goes — and the saved backups are listed below, each one openable into the parts it was taken in.⌉⌊Backup and Restore. Four lines say what is set up — how often it runs, what it covers, how many are kept, where the off-site copy goes — and the saved backups are listed below, each one openable into the parts it was taken in.⌉[ Backup and Restore. Four lines say what is set up — how often it runs, what it covers, how many are kept, where the off-site copy goes — and the saved backups are listed below, each one openable into the parts it was taken in. [⌊Integrations. One destination receives the backups; each row shows whether it is set up, when it last worked, and what it said if it did not.⌉⌊Integrations. One destination receives the backups; each row shows whether it is set up, when it last worked, and what it said if it did not.⌉[ Integrations. One destination receives the backups; each row shows whether it is set up, when it last worked, and what it said if it did not. [⌊Export on the source site. One package containing the full database and wp-content, ready to be pulled by the destination site.⌉⌊Export on the source site. One package containing the full database and wp-content, ready to be pulled by the destination site.⌉[ Export on the source site. One package containing the full database and wp-content, ready to be pulled by the destination site. [⌊Import on the destination site. The package is pulled directly from the source site over HTTP with the URL and token shown there, so nothing is downloaded or uploaded by hand.⌉⌊Import on the destination site. The package is pulled directly from the source site over HTTP with the URL and token shown there, so nothing is downloaded or uploaded by hand.⌉[ Import on the destination site. The package is pulled directly from the source site over HTTP with the URL and token shown there, so nothing is downloaded or uploaded by hand. ## 설치 1. Upload the plugin ZIP through Plugins > Add Plugin > Upload Plugin, or install it from the WordPress plugin directory when available. 2. Activate Nimble Backup. 3. Open the top-level **Nimble Backup** menu. 4. Choose a backup schedule and retention policy, or create the first backup immediately. If upgrading from the legacy `nimble-migration-tool` package: deactivate the legacy plugin first but do not delete it yet; install and activate the new `nimble-backup` package; open Nimble Backup once and confirm the schedule/backups are present; then delete the legacy package. Durable settings are migrated to `nimble_backup_*`, so the legacy uninstaller cannot reset the new plugin. ## FAQ ### What does a backup contain? The WordPress database and the site’s `wp-content` tree, excluding Nimble Backup’s own temporary/archive storage and common cache/backup working directories. Since 1.45 that arrives as several archives rather than one — must-use plugins, plugins, themes, uploads, everything else in wp-content, and the database, each on its own — sharing a date and an id so they stay one backup. The whole site is the default; taking only some of it is a deliberate choice on the Backup screen. ### Does it support WordPress Multisite? Not yet. Backup, restore and migration are deliberately disabled on Multisite until network-wide database and shared `wp-content` restore semantics can be guaranteed safely. A backup that cannot be restored with confidence is worse than none, because it is trusted. ### Does it back up wp-config.php or server configuration? No. `wp-config.php`, web-server configuration, PHP configuration and files outside` wp-content` are not included. Keep infrastructure secrets and server configuration in your normal hosting or infrastructure backup process. ### Are backups stored off-site? Only if you set it up. By default everything stays on this server. The Integrations screen offers four destinations — S3-compatible storage (Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, Hetzner, your own MinIO), Dropbox, Google Drive, and OneDrive/SharePoint — and each finished archive is then uploaded to the one you pick. The account is yours and the app is yours; nothing passes through NimblePlugins. Backups can also be brought back down from there: the archive is downloaded onto this server a piece at a time, verified, and then restored like any other. A copy on the same server protects you from a mistake. Only a copy somewhere else protects you from the server going away, which is the failure a backup exists for. ### Can I migrate between sites with different database table prefixes? Yes. Current-format packages include the source prefix, and the importer rewrites dump table identifiers to the destination prefix and repairs WordPress prefix-dependent option/usermeta keys. ### Does migration overwrite the destination? Yes. Migration is intentionally destructive. Nimble Backup first creates a verified pre-import recovery point and stops if that safety point cannot be created. ### What happens when I uninstall the plugin? Plugin settings and scheduled hooks are removed, but backup archives are intentionally retained. Recovery data should never disappear merely because the plugin is removed. ## 후기 이 플러그인에 대한 평가가 없습니다. ## 기여자 & 개발자 “Nimble Backup”(은)는 오픈 소스 소프트웨어입니다. 다음의 사람들이 이 플러그인에 기여하였습니다. 기여자 * [ nimbleplugins.com ](https://profiles.wordpress.org/nimbleplugin/) [자국어로 “Nimble Backup”(을)를 번역하세요.](https://translate.wordpress.org/projects/wp-plugins/nimble-backup) ### 개발에 관심이 있으십니까? [코드 탐색하기](https://plugins.trac.wordpress.org/browser/nimble-backup/)는, [SVN 저장소](https://plugins.svn.wordpress.org/nimble-backup/) 를 확인하시거나, [개발 기록](https://plugins.trac.wordpress.org/log/nimble-backup/) 을 [RSS](https://plugins.trac.wordpress.org/log/nimble-backup/?limit=100&mode=stop_on_copy&format=rss) 로 구독하세요. ## 변경이력 #### 1.45.4 * **Backups are now taken in parts.** A run produces one archive per part of the site — must-use plugins, plugins, themes, uploads, everything else in wp-content, and the database — sharing a date and an id so they stay one backup. Uploads is usually most of the size and almost never changes once written; the database is small and changes constantly. Sending forty gigabytes of photographs every hour to protect a settings table is why nobody backs up hourly, and the hourly database copy is the one that actually saves people. The whole site is the default; narrowing it is a deliberate choice. * **Three more off-site destinations:** Dropbox, Google Drive, and OneDrive/SharePoint, alongside the S3-compatible storage 1.44 introduced. Each is set up on a new Integrations screen with its own status, its own test and its own last result, and each needs an app registered by you, with keys you enter yourself. This plugin ships no keys and contacts nothing until you enter yours. * **Backups can be brought back down from off-site storage.** The archive is downloaded onto this server a piece at a time, verified, and then restored like any other. Until now the off-site copy was write-only in practice, which is the kind of thing found out on the worst possible day. * Every destination sends the archive a piece at a time and resumes where an interrupted run stopped. A multi-gigabyte archive does not fit in a PHP request, and a destination that cannot take one in pieces cannot hold a full-site backup. * Retention now counts backups rather than archives. A run leaves several files where it used to leave one, so “keep the last ten” would otherwise have quietly meant the last two nights. * Restoring a whole backup validates every part before it writes anything. A backup is restored in several steps and the site is halfway between them; discovering at step four that step five is damaged is discovering it too late. * An existing S3 setup is carried into the new Integrations screen on update and stays active. Nothing to re-enter, and the first night after the update sends its copy off-site exactly as before. * Another plugin on the same site can hand over credentials it already holds, through the new `nimble_backup_credential_sources` filter, so a destination need not be connected twice. The app key and secret can always be looked up at the provider; the refresh token cannot, which is what made copying one across by hand impossible rather than merely tedious. * The Backup screen was one long scroll where the settings, the file sizes and the log all carried the same weight as the backups themselves. It now opens on four lines saying what is set up, with the button underneath and the backups below that. The rest folds away. * The Integrations screen used WordPress’ own table and form styling, which rendered as a white panel in the middle of the plugin’s dark screen, and it never displayed the result of saving, testing or disconnecting — the outcome was passed back in the address and then ignored, so “Save and test” appeared to do nothing at all. * Code-quality fixes throughout, found by Plugin Check: the streaming file calls a backup is built on were annotated on the call that opens a handle but not on the ones that close it; one annotation named a sniff that does not exist and so had never suppressed anything; and the default Amazon endpoint read to the scanner as a plugin offloading its own assets to a CDN, which it is not. #### 1.44.1 * PHP execution limits are no longer set to unlimited. A backup, restore, export or import now raises the limit to a bounded 900 seconds, and only when the host allows it and the current limit is lower; memory is raised with wp_raise_memory_limit() instead of ini_set(). * A restore or a migration import no longer unpacks the archive to a folder first. The database dump is streamed out on its own, and everything under wp-content is streamed from the archive straight to its final path, so no plugin or theme source is ever written to the uploads folder in between. Every path in the archive is checked before a single byte is written, and a short write is now detected instead of being counted as a success. #### 1.44.0 * Off-site storage. Each finished backup can be uploaded to an S3-compatible bucket of your own – Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, Hetzner, or your own MinIO. Switched off until you enter a bucket and credentials. A backup on the same server shares that server’s bad days; this is the copy that does not. * The upload is part of the same paced batch process the archive is built with, so a multi-gigabyte archive is sent a piece at a time instead of in one request that a host would cut short. An interrupted upload resumes from the piece it reached rather than starting over, and an upload that cannot be finished is cancelled at the provider – an abandoned multipart upload keeps billing for the pieces already sent, and does not show up in a listing. * A failing upload gives up after five attempts instead of retrying for ever. A rotated key or a deleted bucket would otherwise have left the backup permanently“ running”, and a run in progress blocks the next one – every later scheduled backup would have been skipped in silence. * A failed upload never invalidates the backup. The archive is on disk and verified, so it is recorded as the success it is, with the off-site failure reported separately. * Remote copies follow the same retention count as local ones, and only ever delete archives this plugin wrote. Object storage is billed by the gigabyte-month, and a nightly backup that is never pruned becomes a bill nobody is watching. * The secret key is stored encrypted, never rendered back into the page, and can be removed by clearing the field. The settings screen says whether this installation keeps its salts in wp-config.php, where a backup cannot reach them. * “Test the connection” proves the credentials before a backup depends on them, rather than finding out at three in the morning after the archive is built. #### 1.43.0 * Every declaration, hook and stored name now carries the full `nimble_backup` /` Nimble_Backup_` / `NIMBLE_BACKUP_` prefix. The short `NMT_`, `NB_` and `nmt_` names are gone. Settings saved by earlier versions are migrated automatically, and cron events scheduled under the old hook names are still picked up. * Uploaded migration packages go through wp_handle_upload() instead of move_uploaded_file(), with the upload directed at the plugin’s own protected folder and restricted to zip files. * Restoring a database dump now runs through $wpdb->query() rather than the raw mysqli handle. Checked against WordPress core: wpdb::query() neither adds nor removes placeholder escapes, so the “%” corruption the raw handle was meant to avoid was never caused by it. The repair tool stays for sites damaged by versions before 1.41. * A restore no longer activates or deactivates anything. It only rewrites the plugin’s own entry in the active list when the restored database still names the 1.40. x folder, so an administrator’s existing choice survives the rename. * A restore now stops at the first statement the database refuses, and names the table, instead of running the rest of the dump into a database that is already half replaced. * The options cache is flushed the moment a database import finishes. Without it every option read for the rest of that request still answered with the values from before the restore. * Other plugins can no longer touch a restore or a package upload in flight: the` query` filter is lifted for the duration of the import, and the upload filters that media-offload plugins use are lifted while the package is stored, so a database archive is never copied to third-party storage. * An uploaded package keeps a high-entropy filename, and is deleted on every failure path, not just some of them. * While the legacy 1.40.x package is active this one stands down and says so, whichever of the two WordPress loads first. #### 1.42.4 * Screenshot captions in the readme now describe the three screens the plugin actually has. No code changes. #### 1.42.3 * Documents where the plugin writes: everything it creates stays in a protected folder inside the uploads directory, and the only write outside it is restoring wp-content, which is what a backup plugin is for. * No functional changes. #### 1.42.2 * Moves the admin stylesheet and script into real files loaded through wp_enqueue_style() and wp_enqueue_script() instead of being printed inline on the page. * No backup, restore or migration behaviour changes. #### 1.42.1 * Documents why the server-to-server download endpoint has no nonce: the caller is another site rather than a browser session, and authentication is a random expiring token compared with hash_equals(). The existing annotation sat one line below the line that needed it. * Documents the usermeta prefix rewrite during migration, where meta_key is the column being written rather than a query argument. * No behaviour change. #### 1.42.0 * Removes the cross-promotion sidebar. It accounted for 94 percent of the plugin’s download size: 3.98 MB of images against 216 KB of code. The package is now 240 KB. * Internationalises the interface. 89 previously untranslated strings now use the standard WordPress translation functions, and the plugin ships a .pot file for the first time. * Documents the two outbound requests the plugin makes, neither of which involves a third party, and adds External services and Privacy sections to the readme. * Corrects the Contributors username. #### 1.41.2 * The admin header mark was an inline SVG drawn in PHP with no class names; it now uses the shipped brand file like every other surface. * The three cross-product promo images carried the old mark baked in. Each now shows the promoted product’s own colour. * Replaces the placeholder mark with the real Nimble logo across the plugin, in the product’s own colour so the WordPress admin menu stays readable when several Nimble plugins are installed side by side. * No behaviour change. #### 1.41.0 * Renamed the install package and plugin root to `nimble-backup/nimble-backup.php`. * Migrates durable 1.40.x settings into the `nimble_backup_*` namespace so deleting the legacy package cannot reset the new plugin. * Moves primary cron workers to `nimble_backup_*` hooks while retaining legacy action aliases for compatibility. * Preserves legacy `nmt_*` admin/action aliases and the public Security/Operations contracts while moving persistent runtime state to the new namespace. * Moves new private working data below `uploads/nimble-backup/` and adds Apache/ IIS deny files plus randomized archive filenames. * Migrates compatible legacy backup archives into the new protected backup directory. * Validates migration and restore ZIP files before extraction, rejecting unsafe paths, unexpected top-level entries and symbolic links. * Adds verified archive metadata and only marks new backups successful after ZIP/ manifest/database validation. * Creates a verified safety recovery point before restore and migration import and stops destructive work if that point cannot be created. * Fixes destination URL capture so migration URL replacement uses the real destination URL even after the source database has been imported. * Adds migration support for differing WordPress database table prefixes. * Sends the migration token in a request header on new transfers while retaining legacy query-token compatibility on the source endpoint. * Adds a one-click transfer-token/package revoke action. * Fixes top-level admin navigation so Backup, Export and Import use the real `admin. php?page=nimble-backup` route. * Records migration success/failure telemetry for the existing Operations 1.1 health provider. * Keeps the Nimble Security recovery-point provider contract intact and fail-closed. * Fails closed on WordPress Multisite instead of exposing unsafe network-wide restore/ migration behavior. #### 1.40.2 * Keeps the Nimble Security recovery-point provider registered while Backup is temporarily running, continuing or locked. * Separates durable provider capability from per-request readiness so Operations no longer reports a false missing-provider issue during normal backup activity. * Preserves the fail-closed response gate while Backup is busy. #### 1.40.1 * Registers Nimble Backup through the public Nimble Security recovery-point provider contract. * Creates and verifies a complete local recovery point before Security may continue destructive automatic quarantine. * Refuses the recovery request when storage, ZipArchive or backup concurrency is unsafe. #### 1.40.0 * Moves Nimble Backup to its own top-level admin menu. #### 1.39.0 * Adds the Operations native health provider contract 1.1 and privacy-bounded backup/ restore outcome telemetry. ## 기초 * 버전 **1.45.4** * 최근 업데이트: **9시간 전** * 활성화된 설치 **10보다 적음** * 워드프레스 버전 ** 6.0 또는 그 이상 ** * 다음까지 시험됨: **7.1.2** * PHP 버전 ** 7.4 또는 그 이상 ** * 언어 * [English (US)](https://wordpress.org/plugins/nimble-backup/) * 태그: * [backup](https://ko.wordpress.org/plugins/tags/backup/)[cloud backup](https://ko.wordpress.org/plugins/tags/cloud-backup/) [Dropbox](https://ko.wordpress.org/plugins/tags/dropbox/)[migration](https://ko.wordpress.org/plugins/tags/migration/) [restore](https://ko.wordpress.org/plugins/tags/restore/) * [고급 보기](https://ko.wordpress.org/plugins/nimble-backup/advanced/) ## 평점 아직 제출된 리뷰가 없습니다. [Your review](https://wordpress.org/support/plugin/nimble-backup/reviews/#new-post) [모든 리뷰 보기](https://wordpress.org/support/plugin/nimble-backup/reviews/) ## 기여자 * [ nimbleplugins.com ](https://profiles.wordpress.org/nimbleplugin/) ## 지원 할 말 있으신가요? 도움이 필요하신가요? [지원 포럼 보기](https://wordpress.org/support/plugin/nimble-backup/)