Cloud backup: Yandex.Disk, Google Drive, S3, FTP, SFTP

What this solution does

The module automatically transfers standard 1C-Bitrix backup copies to external storage services: Yandex Disk, Google Drive, S3-compatible storage, as well as FTP, FTPS, and SFTP. Every transfer undergoes integrity verification. Old copies are removed according to configured retention rules, and any backup can be restored to the server with a single click.

A backup stored only on the same hosting as the website will be permanently lost in case of disk failure, hacking, account blocking, or hosting provider errors. The module solves this by placing copies in remote storage and ensuring their successful delivery.

How it works

Bitrix backup configuration is performed in the standard way: either automatically on a schedule or manually.

The module monitors for new copies. It learns about automatic backups from the Bitrix core and identifies manual copies by the moment file changes stop.

A copy is placed in a queue and sent to all connected storage services. If the connection is interrupted, transmission resumes from the point where it stopped.

After transmission completes, the module compares each volume with the original, removes outdated copies according to retention rules, and, if enabled, frees up space on the website.

Storage specifics

Yandex Disk: access is limited to the application folder only.

Google Drive: access is limited to files created by the module only.

The module supports uploading backups to S3-compatible cloud storage, including Beget, Yandex Object Storage, Selectel, VK Cloud, Timeweb Cloud, Amazon S3, MinIO, and other services. It also supports FTP and FTPS with mandatory certificate verification, as well as SFTP (SSH) with server key verification.

Multiple storage accounts of different types can be connected simultaneously. When triggered via cron, uploads occur in parallel, ensuring that a slow storage service does not block transfers to others.

Integrity is verified by comparing each volume with the original. For Yandex Disk and Google Drive, SHA-256 or MD5 checksums are checked. For S3, the MD5 of each part and the total checksum are verified. For FTP and SFTP, where servers do not provide checksums, file size is compared.

A .sha256 file is created alongside each copy. This file allows verification of the downloaded copy's integrity using the sha256sum -c command, even without access to the original site.

Files are uploaded under a temporary name and renamed in the storage only after the transfer is fully complete. An incomplete file never exists under its final name in the storage.

The module uses a reliable queue for failed transfers, implementing an increasing delay between retries. If the error is due to authentication failure or insufficient space, the delay is at least one hour to avoid overloading the service.

Large backup copies are transferred in parts with support for resuming interrupted transfers. Integration with Yandex Disk, Google Drive, S3, FTP, and SFTP works via Bitrix agents or through the cron scheduler, which is recommended for faster transfer speeds.

If the storage cannot accept copies in time, the module issues a warning. A new copy in the queue replaces older copies that have not yet started transferring.

All module actions are recorded in the Operation History: what was transferred, the destination, the verification method, and the reason for any errors.

Storage Rules

For each storage location, retention criteria can be defined:

- The last N copies;

- One copy per day, week, or month;

- Copies younger than N days;

- A total size not exceeding N GB;

- A minimum of N copies retained regardless of other rules.

Rules are calculated separately for full copies and for database-only copies. Frequent database copies do not displace full copies.

Important copies can be pinned so that no rule deletes them. The most recent verified copy of each type is also never deleted.

When the Free up space option is enabled, the module automatically deletes the oldest copy allowed by the rules upon storage overflow and retries the transfer.

The module allows configuring the transfer of backup copies to cloud storage services: Yandex Disk, Google Drive, S3, FTP, and SFTP. You can set the transfer frequency for each copy: every time, no more than once a day, or no more than once a week. For example, hourly snapshots can be kept on fast S3 storage, while only one daily copy is sent to Yandex Disk.

Hosting space management

When this setting is enabled, a copy is removed from the server after all connected storage services confirm receipt and verification. Before deletion, the module re-verifies the presence of files in the cloud. You can optionally retain several recent copies on the server for faster recovery.

Data restoration

Restoring a copy to the server is performed with a single click. The module downloads the data from the storage to the /bitrix/backup/ directory, verifies each volume, and adds the copy to the standard Bitrix backup list for standard restoration.

For restoration on a new server, each copy includes a step-by-step instruction. For FTP, SFTP, and S3 protocols, the instruction contains a command that allows downloading all volumes in a single line.

If a site has been restored from an old copy or migrated to a clean server, the module automatically locates snapshots of that site using its unique identifier and returns them to the list. Copies of other sites located in the same folder are not affected.

Security

Passwords, access keys, and tokens are stored in the database encrypted using the AES-256-GCM algorithm. The encryption key is stored in a separate file, not in the database. Sensitive data is hidden in event logs.

The module supports uploading backup copies to cloud storage services: Yandex Disk, Google Drive, S3, as well as FTP and SFTP servers. When working with cloud disks, the module is granted minimal access: it can only upload files and cannot read or delete other data on the disk.

For secure data transfer, FTPS verifies the server certificate by default. SFTP stores the server key and stops the transfer if the key changes, preventing password leakage to a spoofed server. The module deletes only the files it uploaded itself. Connecting two different storage locations to the same folder is not supported.

All operations in the admin panel are protected by session and permission checks. Only the site administrator can connect or remove storage locations. The module works correctly with encrypted Bitrix copies, transmitting them as-is without requiring the archive password.

It is important to understand the functional limitations. The module does not create backup copies itself; this task is handled by the standard Bitrix backup feature via the Settings > Tools > Backup section. The module also does not perform site restoration directly; this is done by the standard restore.php script. The module's role is to return the copy to the server and provide step-by-step restoration instructions.

The status "transferred" means that files have successfully reached the storage location in full volume without corruption. Archive integrity is verified during creation (using the Bitrix option "Check archive integrity") and during test restoration.

The module requires PHP 8.2 or newer, the main module version 24.0 or newer, UTF-8 encoding, and a MySQL database. Required PHP extensions include curl, openssl (with AES-256-GCM support), json, and hash. For SFTP functionality, curl must support SFTP (libssh2), which is available on most hosting providers; the module performs an automatic check for this capability.

Using a cron scheduler is highly recommended. For Yandex Disk, cron is mandatory because the service accepts files only in a single request without resumption support. The module does not create backups itself; these are generated by the standard Bitrix backup tool (Settings → Tools → Backup) in either automatic or manual mode. The module only retrieves the prepared archives and transfers them to cloud storage.

Without cron, the module operates via Bitrix agents in short steps, which works for Google Drive, S3, FTP, and SFTP. However, transfers to Yandex Disk are possible only from cron, as agents cannot handle the single-request requirement. The cron command is displayed in the module settings. If a backup is created manually, its transfer may take a significant amount of time.

The module does not receive notifications from the 1C-Bitrix core regarding the completion of manual backup creation. In this case, the system waits until the backup files stop changing; the default timeout is 10 minutes. If you are certain that the backup creation process is complete, click the "Backup completed — take now" button on the "Backups" page. The core independently confirms automatic backups, and they are transmitted to the storage immediately.

The status "transferred" means that the files have fully reached the storage and match the original. For Yandex Disk, Google Drive, and S3, the module verifies the file checksum provided by the cloud service. For FTP and SFTP protocols, the checksum is unavailable, so file size verification is used instead. Full integrity verification in any storage is ensured by the .sha256 file located next to the backup.

Can backups be deleted from the hosting after successful transfer?

Yes. Enable the "Delete backup from site after transfer" option. Deletion occurs only after all connected storage systems confirm receipt and verification of the data. Before deletion, the module re-locates the backup files in the storage. You can keep several recent backups on the site.

If you also save backups to the "1C-Bitrix" cloud, it is important to consider the specifics of synchronization and data integrity verification in this system.

Do not enable the option 'Delete local backups after successful transfer to the cloud' in Bitrix backup settings. This feature will remove the file before the module has time to upload it to all specified storage locations. Instead, configure automatic deletion of local files directly within the parameters of this module.

If the cloud storage runs out of space, the transfer will stop with an 'insufficient space' error. The module will attempt to retry the transfer with an interval of at least one hour. To avoid such delays, configure storage retention rules. You can also enable the 'Free up space for a new copy' function: in this case, the module will automatically delete the oldest copy allowed by the set rules. However, pinned copies and the most recent copy of each type will never be deleted.

Transferring copies to Yandex.Disk may be slow due to file reception speed limits imposed by the service. From a hosting environment, the speed is often between 150 and 200 KB/s, so uploading a 600 MB copy can take about an hour. If the frequency of backup creation exceeds the reception speed, the module will issue a warning and transmit only the most recent copy, ignoring the queue of older files. For frequent backups, it is recommended to configure the transfer of one copy per day to Yandex.Disk via the 'Which copies to transfer' setting, while storing the rest in S3 storage.

The website restoration process is described in the relevant documentation.

To restore a backup, open the Backups page and select the How to restore section. If the required copy is not on the server, use the button to retrieve it from the cloud storage. The file will then appear in the Bitrix list and can be restored using standard procedures. For new servers, this same page provides a step-by-step guide with commands for downloading archives.

If you have restored a site from an old copy, the module does not lose track of new backups. It automatically checks storage locations once daily or when you click the Sync with storage button, identifying copies of your site by their unique identifier and adding them to the list. Files already present in the storage are not uploaded again.

Can backups for multiple sites be stored in a single storage location? Yes, provided each site has its own dedicated folder (by default, the path is bitrix-backup/domain). The module deletes only the files it created itself and does not treat other users' copies as its own.

The module cannot see other files on Yandex.Disk or Google Drive. On Yandex.Disk, access is restricted to the application folder only, while on Google Drive, it is limited to files created by this module. These are technical limitations imposed by the services themselves, not features of the module.

Passwords and access keys for storage locations are stored securely within the site management system.

Site data is stored in the database in encrypted form using the AES-256-GCM algorithm. The encryption key is located in a separate file within the /bitrix/php_interface directory. If only the database is transferred without this file, the module will require re-entering passwords for all connected storage services.

The module fully supports encrypted Bitrix copies, transmitting them exactly as they are. The archive password is neither required nor known by the module; it must be entered manually in the restore.php file during the restoration process.

When connecting via SFTP, an error may occur stating that the server key does not match. This indicates that the server presented a key different from the one saved during the initial connection. Such a situation is common after a server migration or reinstallation but may also signal a potential impersonation attempt. Data transfer is halted until the password is confirmed. It is advisable to verify this with the hosting provider. If a key change is expected, enter the new key fingerprint in the Server key fingerprint field.

General iT can connect “Cloud backup: Yandex.Disk, Google Drive, S3, FTP, SFTP”, configure it and verify the integration with the existing website.