Title: Yedekalma — Yedek Alma, Geri Yükleme ve Taşıma
Author: kamkactemha
Published: ޖުލައި 15, 2026
Last modified: ސެޕްޓެމްބަރ 3, 2026
---
Search plugins
# Yedekalma — Yedek Alma, Geri Yükleme ve Taşıma
By [kamkactemha](https://profiles.wordpress.org/kamkactemha/)
[Download](https://downloads.wordpress.org/plugin/yedekalma.1.63.0.zip)
* [Details](https://dv.wordpress.org/plugins/yedekalma/#description)
* [Reviews](https://dv.wordpress.org/plugins/yedekalma/#reviews)
* [Installation](https://dv.wordpress.org/plugins/yedekalma/#installation)
* [Development](https://dv.wordpress.org/plugins/yedekalma/#developers)
[Support](https://wordpress.org/support/plugin/yedekalma/)
## Description
Yedekalma, **WordPress yedekleme** işini tek ekranda toplayan **ücretsiz bir yedek
alma eklentisidir**. Tek tıkla sitenizin **tam yedeğini** alır — dosyalar _ve_ veritabanı—
ve aynı ekrandan **geri yükler**. Ayrıca **WordPress site taşıma** (yeni sunucu
veya yeni alan adı) yapar ve **virüs / zararlı yazılım taraması** ile bulaşmış dosyaları
temizler. Yedekleme, geri yükleme, taşıma ve güvenlik tek eklentide toplandığı için
her iş için ayrı bir araca ihtiyacınız olmaz.
Her şey kendi sunucunuzda çalışır. Hesap, kayıt veya API anahtarı gerekmez: kurun,
etkinleştirin, **Yedek Al**‘a basın. **Yedek dosyalarınız kendi hostingunuzda kalır**
ve dilediğiniz zaman ZIP olarak indirebilirsiniz.
#### Neler yapar?
* **Site yedekleme** — tema, eklenti ve yüklemeler dahil tüm dosyalar.
* **Veritabanı yedekleme** — gzip sıkıştırmalı MySQL dökümü (`.sql.gz`), büyük
siteler için uygun.
* **Paylaşımlı hostingde çalışır** — `exec()` kapalı ve PHP limitleri dar olsa
bile parçalı (zaman dilimli) çalışıp yedeği tamamlar.
* **Artımlı yedekleme** — dosyaların gerçek değişiklik zamanına bakar, değişen
dosya asla atlanmaz.
* **Tek tıkla geri yükleme** — veritabanı, eklentiler, temalar ve yüklemeler; ya
da yalnızca seçtiğiniz parça.
* **Elinizdeki arşivden geri yükleme** — `.zip`, `.sql` veya `.sql.gz` dosyasını
sürükleyip bırakın.
* **Site taşıma / alan adı değiştirme** — geri yükleme sırasında site adresi veritabanında
otomatik güncellenir.
* **Virüs tarama** — WordPress çekirdeği, eklentiler ve aktif temada kod enjeksiyonu,
web shell ve arka kapı arar; bulunanları toplu silebilirsiniz.
* **Kendi bulutunuza gönderim (isteğe bağlı)** — Google Drive, Dropbox, OneDrive,
Amazon S3 / S3 uyumlu, FTP / SFTP.
* **Zamanlanmış otomatik yedekleme (isteğe bağlı)** — günlük, haftalık, saatlik
veya birkaç dakikada bir; saklama kuralı ile.
* **AES-256 uçtan uca şifreleme (BYOK)** — parola sitenizden çıkmaz.
Ücretsiz bir **yedekleme eklentisi** arıyorsanız: geri yükleme, taşıma ve virüs
taraması dahil hepsi ücretsizdir; hiçbiri “premium” kilidinin arkasında değildir.
#### In English
Yedekalma is a free **WordPress backup plugin** that takes a one-click **backup**
of your entire site — files _and_ database — and **restores** it again from the
same screen. It also **migrates** your WordPress site to a new host or domain and**
scans** it for **malware**. One backup plugin covers backup, restore, migration
and security, so you do not need a separate tool for each job.
Everything runs on your own server. No account, no sign-up and no API key: install,
activate, click **Take Backup**. Your backup archives stay on your hosting, and
you can download them as a ZIP at any time.
Looking for a **free backup plugin** that also does migration and malware scanning
without a paywall? Yedekalma gives you a full **WordPress backup**, a **database
backup**, one-click **restore**, site **migration** and a **malware scanner** in
a single plugin — no premium unlock required for any of it.
#### Backup
* **Full backup** — every file (themes, plugins, uploads) plus the complete database.
* **Database backup** — MySQL dump only, gzip compressed (`.sql.gz`) for large
sites.
* **Files backup** — site files only, without the database.
* **Works on shared hosting** — chunked, time-sliced backup that finishes even
when `exec()` is disabled and PHP limits are strict.
* **Incremental backup** — compares real file modification times, so a changed
file is never skipped.
* **Safe storage** — local backups live in a hardened, non-browsable folder with
unguessable file names.
#### Restore
* **One-click restore** of the database, plugins, themes and uploads straight from
your dashboard.
* **Restore only what you need** — pick just the database, just uploads, just plugins
or the whole site.
* **Restore from an archive you already have** — drag & drop a `.zip`, `.sql` or`.
sql.gz` file and restore from it.
* **Integrity checked** — a truncated or corrupt archive is refused instead of
half-applied, so a bad file can never damage a working site.
* **SHA-256 verification** of every archive before a restore begins.
#### Migration
* **Move your site to a new host** — download the backup, install Yedekalma on
the target server and restore.
* **Change domain safely** — site URL and home URL are rewritten in the database
automatically during the restore.
* **New database server** — `wp-config.php` credentials can be updated as part
of a restore.
* **Clone your website** to a fresh install for disaster recovery or a redesign.
#### Malware scanner
* **Security scan** of PHP, JS and configuration files across WordPress core, your
plugins and the active theme.
* Detects **code injections, web shells and backdoors** using malicious-pattern
matching.
* **Persistent results** — the scan report survives page reloads, so you can review
it whenever you like.
* **Bulk clean** — select detected files and delete them in one click.
* **Core protection** — WordPress core files are shielded from accidental deletion
while planted files can still be removed.
#### Optional cloud service — backup to your own cloud storage
Local backup, restore, migration and the malware scanner are complete on their own
and never contact an external server. If you also want **off-site backup** copies,
you can connect the optional Yedekalma cloud service (see _External services_ below)
to:
* **Backup to Google Drive** — stream backups straight to your own Google Drive.
* **Backup to Dropbox and OneDrive** — send archives to your own Dropbox or Microsoft
OneDrive account.
* **Backup to Amazon S3** and S3-compatible storage — Backblaze B2, Wasabi, Cloudflare
R2 and MinIO.
* **Backup to FTP / SFTP** — upload to any FTP or SFTP server you control.
* Run **scheduled automatic backups** — daily, weekly, hourly or as often as every
few minutes for busy sites — with retention rules.
* **Table-level incremental database backup** — only the database tables that actually
changed are exported, so even very frequent backups stay small and fast; unchanged
runs are skipped automatically.
* Encrypt archives with **client-side AES-256 (BYOK)** before they leave your server—
the passphrase never leaves your site.
#### Languages
Yedekalma ships with English, Turkish (Türkçe), German, Russian and Arabic translations.
### External services
This plugin can optionally connect to the Yedekalma cloud service (an external SaaS)
to perform off-site backup and restore operations, package backups for delivery
to your own cloud storage, check subscription state, and monitor backup quota. This
connection only happens if you choose to use the cloud service (by entering an API
token, by clicking the optional “Connect with Google” button, by clicking the optional“
register this site” button, or by sending a support request from the Support screen—
all described below); the plugin’s local backup, restore, migration and malware-
scanner features work with no external connection at all.
* **Service URL:** https://yedekalma.com
* **Terms of Service:** https://yedekalma.com/legal
* **Privacy Policy:** https://yedekalma.com/legal#privacy
* **Connect with Google (opt-in):** The dashboard shows an optional “Connect with
Google” button. It does nothing unless you click it. If you click it, your browser
is sent to https://yedekalma.com where you sign in with Google; Yedekalma then
creates or finds your account from your Google e-mail address and links this
site (identified by its Site URL) to it. Only your e-mail address and the Site
URL are used for this; no Google Drive or other Google data permission is requested,
and no site content is sent. A one-time connection token is returned to your
site and stored encrypted locally.
* **Optional site registration (opt-in):** The dashboard also shows an optional“
register this site with Yedekalma” button. It does nothing unless you click it.
If you click it, the plugin sends only your Site URL and technical version info(
plugin, WordPress, PHP version and locale) to https://yedekalma.com so the site
can be listed in your Yedekalma panel; no site content or personal data is sent.
If you also enter a notification e-mail, that address and your marketing-consent
choice are sent as well. You can ignore the button entirely and every built-in
feature still works.
* **Support form (opt-in, no account needed):** The plugin has a **Yedekalma Support**
screen. It sends nothing until you fill it in and press “Send”. When you do,
the message you typed, the reply e-mail address and name you entered, the chosen
category and your Site URL are sent to https://yedekalma.com so the support team
can answer you by e-mail. A separate checkbox — shown ticked, and you can untick
it — additionally sends technical details of this installation: plugin, WordPress,
PHP and MySQL versions, web server, site language, multisite flag, active theme
name, the _number_ of active plugins, PHP limits (`memory_limit`, `max_execution_time`,`
upload_max_filesize`), whether ZipArchive and `exec()` are available, free disk
space, whether the backup folder is writable, whether the site is connected to
the cloud service, and the date and count of your local backups. The full list
is shown on screen before you send it. No site content, database content, passwords,
plugin list or user data is sent, and no Yedekalma account is required to use
this form.
* **Data Transmission:** When connected (or after opt-in registration), the plugin
sends requests to the Yedekalma API containing your Site URL, active plugin features,
backup metadata (such as file lists, sizes, and checksums), and your API token(
or anonymous install id) to perform secure backup and restore tasks.
## Screenshots
[⌊Dashboard — one-click full, files-only or database backup; runs on your own server,
no account needed.⌉⌊Dashboard — one-click full, files-only or database backup; runs
on your own server, no account needed.⌉[
Dashboard — one-click full, files-only or database backup; runs on your own server,
no account needed.
[⌊All backups — one-click restore or download, each with size and SHA-256 checksum.⌉⌊
All backups — one-click restore or download, each with size and SHA-256 checksum
.⌉[
All backups — one-click restore or download, each with size and SHA-256 checksum.
[⌊Built-in malware scanner — scan WordPress core, plugins and the active theme for
injected code, web shells and backdoors.⌉⌊Built-in malware scanner — scan WordPress
core, plugins and the active theme for injected code, web shells and backdoors.⌉[
Built-in malware scanner — scan WordPress core, plugins and the active theme for
injected code, web shells and backdoors.
[⌊Settings — interface language and safe uninstall data handling.⌉⌊Settings — interface
language and safe uninstall data handling.⌉[
Settings — interface language and safe uninstall data handling.
[⌊Optional Yedekalma Pro — connect to schedule off-site backups straight to your
own cloud (Google Drive, S3, FTP) with client-side AES-256.⌉⌊Optional Yedekalma
Pro — connect to schedule off-site backups straight to your own cloud (Google Drive,
S3, FTP) with client-side AES-256.⌉[
Optional Yedekalma Pro — connect to schedule off-site backups straight to your own
cloud (Google Drive, S3, FTP) with client-side AES-256.
## Installation
1. In your WordPress admin, go to **Plugins Add New**.
2. Search for **Yedekalma**.
3. Click **Install Now**, then **Activate**.
4. Open **Yedekalma** in the admin sidebar.
5. Click **Start without an account** and take your first backup.
Manual installation: upload the `yedekalma` folder to `/wp-content/plugins/` and
activate it from the Plugins screen.
## FAQ
### WordPress sitemin yedeğini nasıl alırım?
**Yedekalma Kontrol Paneli**‘ni açın ve **Yedek Al**‘a basın. **Tam Yedek** (dosya
+ veritabanı), **Sadece Dosya** veya **Sadece Veritabanı** seçebilirsiniz. Yedekleme
kendi sunucunuzda parça parça çalışır; bittiğinde arşivi ZIP olarak indirebilirsiniz.
### Veritabanı yedeği nasıl alınır?
**Yedek Al Sadece Veritabanı** deyin. Sıkıştırılmış bir MySQL dökümü (`.sql.gz`)
elde edersiniz; indirebilir veya daha sonra geri yükleyebilirsiniz.
### Yedek alma eklentisi ücretsiz mi?
Evet. Yedekleme, geri yükleme, taşıma ve virüs taraması hesap açmadan ve ücret ödemeden
tam olarak çalışır. İsteğe bağlı Yedekalma bulut hizmeti site dışı (off-site) depolama
ekler ve ücretsiz bir başlangıç paketi vardır.
### WordPress site taşıma nasıl yapılır?
Evet. Yedeği indirin, yeni sunucuda Yedekalma’yı kurun ve arşivden geri yükleyin.
Site adresi ve ana sayfa adresi veritabanında otomatik olarak yeni alan adına göre
güncellenir.
### Yedekler nerede saklanıyor?
Varsayılan olarak kendi hostingunuzda, dışarıdan listelenemeyen korumalı bir klasörde
ve tahmin edilemez dosya adlarıyla. İsterseniz isteğe bağlı bulut hizmetiyle kendi
Google Drive, Dropbox, OneDrive, S3 veya FTP alanınıza gönderebilirsiniz — yedeğin
içeriği Yedekalma sunucularında tutulmaz.
### Paylaşımlı hostingde çalışır mı?
Evet. Yedekleme zaman dilimli parçalar halinde ilerler; `exec()` kapalı olsa ve
PHP zaman/bellek limitleri dar olsa bile tamamlanır. Sunucu yoğunluk nedeniyle isteği
reddederse eklenti bekleyip kaldığı yerden devam eder.
### WordPress virüs temizleme yapar mı?
Evet. **Yedekalma Zararlı Yazılım Taraması** ekranından tarama başlatın: WordPress
çekirdeği, eklentiler ve aktif tema PHP/JS ve yapılandırma dosyaları için kod enjeksiyonu,
web shell ve arka kapı kalıplarına karşı taranır. Bulunan dosyaları tek tıkla toplu
silebilirsiniz; WordPress çekirdek dosyaları yanlışlıkla silinmeye karşı korunur.
Virüs temizleme ücretsizdir, hesap açmanız gerekmez.
### Otomatik (zamanlanmış) yedekleme var mı?
Evet, isteğe bağlı bulut hizmetiyle. Günlük, haftalık, saatlik ya da yoğun siteler
için birkaç dakikada bir otomatik yedekleme kurabilir, her biri için saklama kuralı
tanımlayabilirsiniz. Tek tıkla manuel yedek her zaman ücretsizdir ve zamanlama gerektirmez.
### Büyük siteleri (5 GB, 10 GB) yedekleyebilir mi?
Evet. Yedekleme küçük zaman dilimlerine bölünerek ilerler ve veritabanı doğrudan
gzip sıkıştırmalı döküme akıtılır; böylece PHP süre ve bellek limitlerine takılmadan
tamamlanır. Çok büyük siteler için isteğe bağlı bulut hizmetiyle arşivi hostinginizi
doldurmadan doğrudan kendi Google Drive, S3 veya FTP alanınıza gönderebilirsiniz.
### WooCommerce mağazamı yedekler mi?
Evet. Tam yedek tüm WordPress veritabanını içerir — WooCommerce siparişleri, ürünler,
müşteriler ve ayarlar dosyalarla birlikte kaydedilir. Yoğun mağazalarda isteğe bağlı
bulut hizmetiyle sık artımlı yedekleme kurup iki yedek arasındaki yeni siparişleri
de koruyabilirsiniz.
### Nasıl destek alabilirim? Üye olmam gerekiyor mu?
Hayır, üyelik gerekmez. WordPress yönetim panelinizde **Yedekalma Destek** ekranını
açın, sorununuzu yazın ve gönderin. Site adresiniz otomatik olarak eklenir; isterseniz
PHP/WordPress sürümü ve sunucu limitleri gibi teknik bilgileri de tek tıkla iletebilirsiniz(
ne gönderileceğini göndermeden önce ekranda görürsünüz). Yanıt, yazdığınız e-posta
adresine gelir — yedekalma.com hesabınız olmasa bile.
### Yedeklerimi Google Drive’a gönderebilir miyim?
Evet, isteğe bağlı Yedekalma bulut hizmetiyle. Arşiv sunucunuzdan doğrudan **kendi**
Google Drive, Dropbox, OneDrive, Amazon S3 / S3 uyumlu veya FTP / SFTP alanınıza
aktarılır; Yedekalma bir kopyasını saklamaz.
### Is this backup plugin free?
Yes. Backup, restore, migration and the malware scanner are fully functional with
no account and no payment. The optional Yedekalma cloud service adds off-site storage
and has a free tier.
### Is this a good free backup plugin for WordPress?
Yedekalma is a free WordPress backup plugin that bundles full-site backup, database
backup, one-click restore, site migration and a malware scanner — features that
many plugins split between free and premium tiers. Everything runs on your own server
and needs no account.
### How do I back up my WordPress site?
Open **Yedekalma Dashboard** and click **Take Backup**. Choose **Full** (files
+ database), **Files Only** or **Database Only**. The backup runs in time-sliced
chunks on your own server and you can download the archive as a ZIP when it finishes.
### How do I back up my WordPress database?
Open **Yedekalma Dashboard**, click **Take Backup** and choose **Database Only**.
You get a compressed MySQL dump (`.sql.gz`) that you can download or restore later.
### Can I back up a WooCommerce store?
Yes. A full backup includes your entire WordPress database — WooCommerce orders,
products, customers and settings — together with your files, so your whole store
is captured. For very busy stores you can schedule frequent incremental backups
through the optional cloud service so new orders are protected between runs.
### Can it back up large sites (5 GB, 10 GB or more)?
Yes. Backups run in small time-sliced chunks and the database is streamed to a gzip-
compressed dump, so large sites finish without hitting PHP time or memory limits.
For very large sites, connecting the optional cloud service lets archives stream
straight to your own Google Drive, S3 or FTP storage instead of filling your hosting
disk.
### Does it work on shared hosting, cPanel, Plesk or DirectAdmin?
Yes. Yedekalma is a pure-PHP plugin with no server dependencies, so it works on
any standard WordPress host — shared hosting, cPanel, Plesk, DirectAdmin or a managed
platform. It does not need `exec()`, shell access or SSH.
### Does it work on LiteSpeed, Nginx and Apache?
Yes. The plugin runs inside WordPress itself and does not depend on the web server,
so it works the same on LiteSpeed, Nginx, Apache or any other server that runs PHP.
### Can I use it to migrate my site to a new host or domain?
Yes. Take a full backup, download the ZIP, install Yedekalma on the target site
and restore the archive there. The site URL and home URL in the database are updated
for the new domain automatically.
### Can I clone my website for disaster recovery?
Yes. Take a full backup and restore it onto a completely separate install; the site
URL is rewritten for the new domain automatically. Your original site is never modified.
### Where are my backups stored?
In `wp-content/uploads/yedekalma-backups/` on your own server. The folder is protected
from directory browsing and the archive names include a random token, so nobody
can guess the URL. If you connect optional cloud storage, backups go to your own
Google Drive, Dropbox, OneDrive, S3 or FTP account instead.
### Can I back up to Google Drive?
Yes, through the optional Yedekalma cloud service. Backups stream directly from
your server to **your own** Google Drive; Yedekalma never keeps a copy.
### Can I back up to Dropbox or OneDrive?
Yes. With the optional cloud service you can send scheduled backups to your own
Dropbox or Microsoft OneDrive account.
### Does it support Amazon S3, Backblaze B2 or Wasabi?
Yes. The optional cloud service supports Amazon S3 and any S3-compatible storage—
Backblaze B2, Wasabi, Cloudflare R2 and MinIO. Uploads use a client-side signed (
SigV4) request and your secret key is AES-256 encrypted on your own site, never
sent to Yedekalma.
### Can I back up to FTP or SFTP?
Yes. The optional cloud service can upload backups to any FTP or SFTP server you
control. The credentials are encrypted on your own site.
### Does it support scheduled automatic backups?
Yes, through the optional cloud service. You can schedule automatic backups daily,
weekly, hourly or as often as every few minutes for busy sites, each with its own
retention rules. One-click manual backups are always available for free without
any schedule.
### What is incremental backup and does it support it?
An incremental backup only saves what changed since the last run, so it stays small
and fast. Yedekalma compares real file modification times for files and, with the
cloud service, exports only the database tables that actually changed — unchanged
runs are skipped automatically.
### Can I encrypt my backups?
Yes. With the optional cloud service you can turn on client-side AES-256 (BYOK)
encryption. Archives are encrypted on your own server before they leave it, and
the passphrase never reaches Yedekalma.
### How does the malware scanner work?
It scans PHP, JS and configuration files in WordPress core, your plugins and the
active theme for malicious patterns, code injections, web shells and backdoors.
Results are saved so you can review them later, and you can delete detected files
in bulk. Core WordPress files are protected from deletion.
### How do I restore a WordPress backup for free?
Open **Yedekalma Backups**, find the backup you want and click **Restore**. You
can restore the database, plugins, themes and uploads separately or all at once.
You can also drag & drop a `.zip`, `.sql` or `.sql.gz` archive you already have
and restore from it — no account and no payment required.
### Can I restore only the database?
Yes. When restoring, pick the **Database** section on its own and the rest of the
site is left untouched. This is handy for rolling back a bad content change without
reverting files.
### Can I restore only the uploads, media or a single component?
Yes. Restore offers each section your backup contains — database, plugins, themes
and uploads — so you can restore just your media/uploads, just plugins or any single
part instead of the whole site.
### Is there a free WordPress migration plugin here?
Yes. Yedekalma migrates your WordPress site to a new host or domain for free: take
a full backup, download the ZIP, install Yedekalma on the target site and restore.
The site URL and home URL are rewritten in the database automatically, and `wp-config.
php` credentials can be updated during the restore.
### How can I scan WordPress for malware without a subscription?
The built-in malware scanner is completely free and needs no account. Open **Yedekalma
Malware Scanner** and start a scan; it checks WordPress core, your plugins and the
active theme for injected code, web shells and backdoors, then lets you delete detected
files in bulk while protecting core files.
### How often should I back up my WordPress site?
For most sites a weekly full backup plus a daily database backup is a good baseline;
busy or e-commerce sites should back up daily or more often. You can run a one-click
backup any time for free, and the optional Yedekalma cloud service adds scheduled
automatic backups with retention rules.
### What happens to my backups if I delete the plugin?
Nothing. Local archives under `wp-content/uploads/yedekalma-backups/` stay where
they are unless you remove them yourself, and anything in your own cloud storage
stays there too.
### Türkçe destekliyor mu?
Evet. Yedekalma tamamen Türkçe arayüze sahiptir: site yedekleme, veritabanı yedekleme,
yedekten geri yükleme, site taşıma ve virüs/zararlı yazılım taraması işlemlerinin
tümünü Türkçe olarak yapabilirsiniz.
### Is Multisite supported?
Not in version 1 — a separate plugin instance per site is required. Full Multisite
support is on the roadmap.
### Is it GDPR / KVKK compliant?
Yes. The plugin makes no external connection at all unless you deliberately connect
the optional cloud service, and explicit consent is collected for that data transfer.
## Reviews
There are no reviews for this plugin.
## Contributors & Developers
“Yedekalma — Yedek Alma, Geri Yükleme ve Taşıma” is open source software. The following
people have contributed to this plugin.
Contributors
* [ kamkactemha ](https://profiles.wordpress.org/kamkactemha/)
[Translate “Yedekalma — Yedek Alma, Geri Yükleme ve Taşıma” into your language.](https://translate.wordpress.org/projects/wp-plugins/yedekalma)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/yedekalma/), check
out the [SVN repository](https://plugins.svn.wordpress.org/yedekalma/), or subscribe
to the [development log](https://plugins.trac.wordpress.org/log/yedekalma/) by [RSS](https://plugins.trac.wordpress.org/log/yedekalma/?limit=100&mode=stop_on_copy&format=rss).
## Changelog
For the full history of older releases, see `changelog.txt` in the plugin folder.
#### 1.63.0 — 2026-09-03
**GUVENLIK + GERI YUKLEME surumu. Her kuruluma onerilir.**
**Geri yukleme, sizin secmediginiz seye artik DOKUNMUYOR.**
* URL arama-degistirme adimi (geri yuklemeden sonra eski alan adini yenisiyle
degistiren adim) bilesen ve veritabani secim kapilarinin HICBIRINI tasimiyordu.“
Veritabanimi geri yukleme” secili olsa bile sitenin CANLI veritabanindaki tum
onekli tablolarda metin ve blob sutunlari yeniden yaziliyordu; geri alma yoktu.
Ayni sekilde eklentinin kendi ayarlarinin geri yazimi da kosulsuzdu. Ikisi de
artik ayni kapidan geciyor.
* Panelden “yalnizca su posta kutularini geri yukle” secildiginde eklenti bu
secimi
HIC okumuyordu: isaretini kaldirdiginiz kutularin iletileri de canli IMAP hesabina
yaziliyordu. Bu geri alinamaz bir kirlenmedir. Secim artik uygulaniyor (PHP modulu
bunu aylardir yapiyordu).
* Arsivdeki EK veritabanlari (`veritabani/.sql.gz`) yedege giriyor ama geri
yuklemede HIC uygulanmiyor ve islem yine “basarili” raporlaniyordu. Her ek veritabani
artik kendi hedefine, kendi kimligiyle geri yukleniyor; secim her veritabani
icin AYRI soruluyor ve uygulanamayan bir veritabani islemi BASARISIZ yapiyor (
sessiz gecmiyor).
**Ek veritabani yedegi artik gercekten aliniyor.**
* 1.62.1’de eklenen ek veritabani dokumu, panelin hic kullanmadigi bir kod
dalina
yazilmisti: panel her WordPress yedegini PARCALI modda calistirir, dokum ise
yalnizca parcasiz dalda vardi. Sonuc, urunun en pahali arizasidir — panelde “
2 veritabani” yazar, arsivde yalniz WordPress’in kendi veritabani bulunur ve
eksik ancak felaket gunu gorulur. Dokum parcali akisa tasindi; her tur en az
bir veritabani doker, boylece buyuk veritabanlari hosting’in istek suresini asmaz.
Yedegin icerik envanteri de artik gercekten arsive gireni bildiriyor (once parcali
yolda daima bostu).
**Yedek dosyalariniz ve sifreleme anahtariniz geri yuklemede korunuyor.**
* Korunan dosya listesi yalnizca site KOKUNDEKI `wp-config.php`, `.htaccess` ve
.
user.ini ile eslesiyordu. Yedek klasorunuzun kendi “erisimi engelle” (`.htaccess`)
dosyasi bu listeye girmiyordu; disaridan aktarilan bir tam site arsivi onu ezdiginde
o klasordeki TUM arsivler ve veritabani dokumleri dogrudan URL ile indirilebilir
hale geliyordu — ve dosya kendiliginden geri gelmiyordu. Sifreleme anahtari diziniz
de ayni sekilde korumasizdi; eski bir arsivden geri gelen anahtar, kayitli sirlarinizi
cozulemez yapip siteyi sessizce yedeksiz birakabiliyordu. Iki dizin de artik
her derinlikte, hem YAZMA hem SILME adiminda korunuyor ve geri yukleme sonunda
sertlestirme dosyalari yeniden kontrol ediliyor.
* E-posta geri yuklemesinde posta kutusu adlari arsiv icerigiden suzgecsiz
turetiliyordu;
artik temizleniyor ve derinligi sinirlaniyor.
* Panel imzasinin zaman penceresi PHP moduluyle esitlendi: gelecege damgali bir
jeton icin tolerans 10 dakikadan 1 dakikaya indi.
**Basarili bir yedek, gecici bir ag hatasi yuzunden “basarisiz” gorunmuyor.**
* Yukleme izni ve kayit istekleri tek denemelikti. Arsiv o noktada depolama
hedefinize
ZATEN yuklenmis oluyor; istek gecici bir 502/503 alirsa yedek basarisiz sayiliyor,
hedefte panelin bilmedigi bir arsiv kaliyor ve bir sonraki tur her seyi bastan
uretiyordu. Bu iki istek artik 3 kez, artan beklemeyle deneniyor (PHP modulundeki
kural).
* Yedek raporu “N tablo atlandi” derken hangi tablolarin atlandigini da
soyluyor;
dogrulama ucunun indirdigi gecici arsiv artik her durumda siliniyor.
#### 1.62.1 — 2026-09-02
**Parcali yedek artik kendi hiz sinirimiza takilmiyor (buyuk siteler).**
* Yedek istegi hiz siniri, parcali (chunked) yedegin HER parcasi icin ayri ayri
sayiliyordu. Buyuk bir sitede parca sayisi saatlik kovayi kacinilmaz olarak doldurup
yedegi 429 ile dusuruyordu — yani yedegi kendi savunma mekanizmamiz olduruyordu.
Parcali istekler artik muaf (kimlik dogrulamasi degismedi).
**Geri yuklemede veritabani secimi ARTIK ONURLANDIRILIYOR.**
* Panelden “yalnizca su veritabanini geri yukle” secildiginde eklenti bu secimi
okumuyor ve sitenin canli veritabanini kosulsuz uzerine yaziyordu. Secim artik
hem `.sql.gz` hem zip dallarinda uygulaniyor; secilmeyen veritabanina DOKUNULMUYOR
ve panele acik gerekce donuyor.
#### 1.62.0 — 2026-08-31
**GÜVENLİK — panel ile eklenti arasındaki kimlik doğrulaması sıkılaştırıldı.**
* `direct-restore` ucu artık SÜRESİZ statik sırla ÇAĞRILAMAZ. Panel her istekte
zaman sınırlı (±10 dk) ve TEK KULLANIMLIK bir imza gönderir; yakalanan bir istek
tekrar oynatılamaz. Bu koruma PHP modülünde zaten vardı, eklentiye taşındı (SEC-
902).
* Geri yükleme arşivlerine **zip-bomb tavanı** eklendi: açılmış toplam boyut 20
GB’ı
aşarsa arşiv AÇILMADAN reddedilir (yalnız metadata okunur, ek maliyeti
yoktur). yedekalma_max_uncompressed_bytes filtresiyle yükseltilebilir (SEC-907).
* REST uçlarına **hız sınırı** eklendi: geri yükleme 5/dk · 60/saat, yedek tetikleme
60/dk. Yedek kovası bilinçli olarak fail-open’dır — sayaç bozulursa yedekleme
durmaz.
* **wp-admin’den baslatilan geri yukleme, HMAC zorunlulugu eklendiginde kirilmisti—
yayin oncesi duzeltildi (WP-201).
Eklentinin kendi ic cagirisi (`ya_call_direct_restore`)
istegi HTTP uzerinden degil surec icinde kurup uca DOGRUDAN veriyor; yani ayni
kapidan geciyor. Yeni zorunlu `X-Yedekalma-Auth` basligini uretmedigi icin panel
disindan baslatilan HER geri yukleme (yerel arsiv ve bulut bileti dallarinin
IKISI de) “stale_or_missing_auth” ile reddedilecekti. Token artik elde bulunan
sirdan uretiliyor; “guvenilir ic cagri” muafiyeti EKLENMEDI — o, SEC-902’yi geri
alirdi.
⚠ **YÜKSELTME SIRASI:** bu sürüm paneli 2026-08-31 ve sonrası bir sürümde olan
kurulumlar içindir. Panel eski ise **panelden** başlatılan geri yükleme “stale_or_missing_auth”
ile reddedilir (yedekleme etkilenmez; wp-admin’den başlatılan geri yükleme WP-201
düzeltmesiyle panelden bağımsız çalışır). yedekalma.com panelini kullanıyorsanız
yapmanız gereken bir şey yok.
#### 1.61.1 — 2026-08-29
* **Panel bir yedegi silmek istediginde, arsiv diskinizde KALDIGI HALDE “silindi”
sayilabiliyordu (CORE-622).
Indirme defterinde karsiligi olmayan bir jeton
“
adreslenemez” degil “dosya yok” gibi ele aliniyordu; panel kaydi dusuruyor, arsiv
sunucunuzda duruyordu — yani disk dolmaya devam ederken panel “yer acildi” diyordu.
Iki uc birden duzeltildi: (1) adreslenemeyen jeton artik HATA doner, panel kaydi
KORUR ve yeniden dener; (2) defterin 500 kayitlik tavani, isaret ettigi dosya
HALA DISKTE olan bir kaydi artik dusurmez (ayni kural TTL budamasinda zaten vardi,
tavana uygulanmamisti).
* **Veritabani dokumu GORUNUMLERI (VIEW) tablo saniyordu; TRIGGER ve saklı yordamlar
hic
yedeklenmiyordu (CORE-603).
Tablo listesi `SHOW TABLES` ile aliniyordu
ve o liste
gorunumleri de dondurur: dokum bir gorunum icin `DROP TABLE` + `CREATE
VIEW` yaziyor, ardindan satirlarini `INSERT INTO ` olarak dokuyordu.
Boyle bir sitede geri yukleme ILK HATADA duruyor ve veritabaninizi YARIM birakiyordu.
Artik BASE TABLE ile VIEW ayriliyor; gorunumler, tetikleyiciler, sakli yordamlar
ve olaylar tum tablolardan SONRA ve dogru soz dizimiyle yaziliyor.
* **Bir e-posta hesabina baglanilamadiginda bu size HIC bildirilmiyordu (WP-602).**
Yedek
“basarili” damgasi aliyor, eksik hesap yalnizca o anki gecici kayitta
goruunup siliniyordu. Artik atlanan hesaplar panele raporlaniyor.
* **Parcali yedekte “okunamayan klasor” sayaci panele hic gitmiyordu (WP-601).**
Izin hatasi
ya da bozuk bir baglama yuzunden hic gezilemeyen bir klasor arsivden
dusuyor, panelin kapsama denetimi ise bunu goremeden yedegi “tam” sayiyordu.
* **`component=email` istegi sessizce “tum site” yedegine donusuyordu (WP-603).**
Artik
desteklenmeyen bilesen acik bir hata donduruyor; sessiz genisletme yok.
* **Geri yuklemede adinda iki nokta gecen mesru dosyalar (`foto..jpg`) sessizce
atlaniyordu
(WP-604).
Dizin-atlatma korumasi yol ayracina bakmiyordu; artik
bakiyor ve elenen girdi
ayri bir sayaca yaziliyor.
* Guvenlik/temizlik: hata mesaji ayristirmasi artik `DOMParser` kullaniyor (WP-
605); panel
adresinin `https` zorunlulugu tek bir okuma kapisina alindi (WP-
606); menuden kaldirilmis “Yedekleme Ayarlari” ekraninin olu kodu ve ona bagli
olu betikler paketten cikarildi.
* **Veritabani geri yuklemesinden sonra sitedeki yedeklerinize ulasilamiyordu (
WP-901).**
Geri yukleme oncesi korunan eklenti ayarlarinin listesi ELLE tutuluyordu
ve iki kritik kayit o listede YOKTU: yedek klasorunuzun (rastgele uretilen) ADI
ve indirme jetonu defteri. DB geri yuklendikten sonra eklenti YENI bir klasor
adi uretiyor, diskte duran ESKI klasoru ise hicbir yerde aramiyordu — arsivleriniz
yerli yerinde dururken panelde listelenen her yedegin indirme / geri yukleme /
silme baglantisi 404 veriyordu. Liste artik elle tutulmuyor: `yedekalma` onekli
TUM ayarlar varsayilan olarak KORUNUYOR (yani ileride eklenecek bir ayar da kendiliginden
korunur). Hicbir yedek dosyasi kaybolmamisti; kaybolan yalnizca onlara ulasan
yoldu.
* **“Artik dosyalari temizle” ekrani, artiklarin YARISINI goremiyordu (WP-907).**
Yonetim
ekranindan baslatilan yedeklerin biraktigi gecici dosyalar (`.tmp-full-…`,`.
tmp-db-…`, .tmp-list-…) ve Pro zamanlayicinin artiklari ekranin tanidigi listede
yoktu. Ekran “temizlenecek artik dosya yok” derken GB’larca yarim arsiv diskinizde
duruyordu — WP-Cron kapali sitelerde bu ekran tek cikis kapisidir. Artik iki
dosya ailesini de goruyor ve siliyor. Calisan bir yedege ait dosyalara dokunmayan
koruma her iki aileye de uygulaniyor. Ayni artiklar bundan boyle yedeginizin
ICINE de girmiyor.
* **Sembolik bagli `uploads` klasorunde geri yukleme medya kutuphanenizi dusurebiliyordu
(
WP-913).
Bazi paylasimli hostinglerde `wp-content/uploads` baska bir diske BAG
ile
bagli olur. O sitelerde geri yukleme uploads altindaki her dosyayi sessizce
atliyor, kok dizindeki dosyalar yazildigi icin de “basarili” donuyor ve ardindan
silme adimini calistiriyordu. Yazma ve silme koruma cemberi artik WordPress’in
kendi yapilandirilmis dizinlerini de taniyor.
* **URL degistirme, birincil anahtari olmayan tablolarda yanlis satirlari yazabiliyordu
(
WP-914).
Geri yukleme sirasinda site adresi degistiginde ucuncu taraf eklenti
tablolarinda arama/degistirme kosuyor. Boyle bir tabloda anahtar yoksa ILK SUTUN
anahtar sayiliyordu: ayni degeri paylasan tum satirlar birlikte yaziliyor, o
sutun bos (NULL) ise degisim hic uygulanmiyordu. Artik satir tum sutunlariyla
eslestiriliyor ve bos degerler dogru sinaniyor.
* **Zararli yazilim taramasi, eklenti klasoru TAKLIDI eden yollari atliyordu (WP-
912).**
Muafiyet yalnizca yolun SEKLINE bakiyordu; bu yuzden `uploads` altina
birakilan yedekalma/includes/… gorunumlu bir dosya uc tarayicinin ucunden de
muaf kaliyor ve taranan sayisina bile girmiyordu. Muafiyet artik konuma duyarli:
yuklemeler klasorunde gecerli degil, diger yerlerde ise kopyanin gercekten eklentiye
ait oldugu dogrulaniyor. Mesru kopyalar (WordPress guncelleme kalintisi, elle
birakilmis eski surumler) eskisi gibi muaf kalmaya devam ediyor.
* **Site boyutu olcumu, yedege GIRMEYECEK dosyalari sayiyordu (WP-910).** Panelin
gosterdigi “kaynak boyutu” — kapasite ve paket kararlarinin girdisi — kendi gecici
artiklarimizi, sifreleme anahtari klasorunu ve okunamayan dosyalari da topluyordu.
Olcum artik yedegin kendi eleme kurallarinin AYNISINI kullaniyor.
* **Sifreleme anahtarini kaybetmis sitelerde her istek bir kayit yaziyordu (WP-
917).**
Panel sirri cozulemeyen (zaten bozuk) bir kurulumda, kimlik dogrulanmadan
ONCE calisan kontrol her istekte veritabanina yazip hata gunlugune satir ekliyordu;
disaridan gelen istek seli gunlugu sisirebiliyordu. Uyari artik bir kez birakiliyor.
* Ic tutarlilik: indirme baglantisi yenilemede klasor siniri kontrolu kardes yollarla
ayni hale getirildi (WP-909); yedek tamamlama bildiriminde iki alan yola gore
degisiyordu, artik dort yol da ayni govdeyi uretiyor (WP-920).
#### 1.61.0 — 2026-08-26
* **Yonetim ekranlarindaki JavaScript metinleri artik cevriliyor (WP-956).** PHP
tarafi bes
dilde tam cevriliydi; ama yedegin en kritik akisini yazan JavaScript—
ilerleme adimlari, “Yedek basarisiz.”, “Iptal ediliyor…”, geri yukleme sonuc
karti — TURKCE gomuluydu. Yabanci bir kullanici yedeginin basarili mi basarisiz
mi oldugunu okuyamiyordu. Bu dizgeler artik eklentinin normal ceviri katalogundan(`.
pot`/`.po`/`.mo`) geciyor. Davranis DEGISMEDI: ceviri gelmezse eskisi gibi ayni
metin gosterilir.
* **Sifreleme anahtariniz artik DB parolanizi degistirince kaybolmuyor (QA-960).**
WordPress
guvenlik anahtari (`AUTH_KEY`) tanimsiz olan kurulumlarda sirlarinizi(
panel baglantisi, depolama hedefi parolalari, sifreleme parolasi) cozün anahtar`
uploads/.yedekalma/` altinda saklanir ve govdesi `wp-config.php` sabitlerinden
turetilen bir maskeyle kariştirilir. O maskenin malzemesine **veritabani bilgileri
de** dahildi: DB parolasi rotasyonu, `localhost` ↔ `127.0.0.1` degisimi ya da**
siteyi tasima/geri yukleme** anahtari okunamaz yapiyor, eklenti de dosyanin uzerine
YENI bir anahtar yazip eskisini GERI DONUSSUZ yok ediyordu. Iki degisiklik: (
1) maske artik yalniz guvenlik tuzlarindan turer, veritabani bilgilerinden DEGIL;(
2) anahtar okunamazsa dosya **artik ezilmiyor** — kopyasi `fbk-onceki.php` olarak
saklaniyor ve yonetim panelinde bir uyari cikiyor, yani eski `wp-config.php`
degerlerini geri koyarsaniz anahtar kurtarilabiliyor. Mevcut kurulumlar kendiliginden
yeni bicime tasinir; elle bir sey yapmaniz gerekmez.
* **Bazi yedeklerde butunluk ve veritabani dogrulamasi hic olculemiyordu (WP-951).**
Panel,
her yedek icin arsivin uctan uca SHA/MD5 esligini ve dokumun tam olup
olmadigini olcer. Yuklemeyi tamamlayan dort koddan biri bu iki olcumu (`md5`,`
db_summary`) hic gondermiyordu — o yoldan gecen her yedekte iki dogrulama katmani
kalici olarak “olculemedi” kaliyordu. Dort yol da artik AYNI govdeyi uretiyor.
* **Pro zamanli e-posta yedeginde uc hata (WP-955).** (1) Ayni sunucuda ikinci
bir posta
hesabi yedeklenirken birinci hesabin oturumu devralinabiliyor ve **
yanlis hesabin postasi arsive girebiliyordu. (2) Bazi Turk cPanel/Plesk sunucularinda
baglanti hic kurulamiyordu (bilinen SASL duzeltmesi bu yola uygulanmamisti). (
3) `INBOX/Sent` gibi alt klasorler `INBOX_Sent` olarak kaydediliyor, geri yuklemede
klasor agaci duzlesiyordu — postaniz dogru kutuya donmuyordu. Ucu de duzeltildi.
* **Eklenti silinince sifreleme anahtari diskte kaliyordu (WP-957).** `uploads/.
yedekalma/`
klasoru kaldirma listesinde yoktu. Artik siliniyor (yedek dosyalarinizin
silinmesi ise eskisi gibi yalniz siz isaretlerseniz olur — o ayar DEGISMEDI).
#### 1.60.1 — 2026-08-26
* Duzeltme (AGT-960): sifreli arsiv yerine konurken once silinip sonra yeniden
adlandiriliyordu.
rename() POSIX’te hedefi zaten ATOMIK degistirir; onceden
silmek gereksizdi ve rename duserse (izin / farkli dosya sistemi / kota) HER
IKI kopya da yok oluyordu — saatler suren paketleme + sifreleme tek bir basarisiz
islemle cope gidebiliyordu. Artik duz arsive dokunulmuyor ve hata halinde `.enc`
kopyasi da diskte birakiliyor (elle kurtarilabilir).
#### 1.60.0 — 2026-08-25
* **Aynı sitede iki yedek birden başlayabiliyordu — son iki yol da kilide bağlandı.**
Panelden
başlatılan bir yedek sürerken sitenin kendi zamanlayıcısı (WP-Cron)
İKİNCİ bir tam arşiv üretmeye başlayabiliyordu: iki kat disk, iki kat CPU ve
çoğu zaman ikisinin de bitememesi. Canlıda ölçülmüştü — 6,5 GB’lık bir arşiv
aynı akşam iki kez üretildi. Koruma daha önce panel ve yönetim ekranı yollarına
konmuştu; zamanlanmış (cron) iki yol onu ALMAMIŞTI. Artık altı yedek üreticisinin
hepsi TEK bir ortak kilitten geçiyor, yani ileride eklenecek bir yol da korumayı
kendiliğinden alır. Meşgulken cron sessizce çekilir ve sıradaki turda yeniden
dener — yedek ATLANMAZ, yalnız çakışma önlenir.
* **Şifreleme anahtarı, olağandışı kurulumlarda yedeğe geri girebiliyordu.** Anahtar
dosyası
arşivden SABİT bir yol yazılarak eleniyordu; oysa yolu hesaplanıyor.
Yükleme klasörü varsayılan yerinde değilse (çoklu site alt sitesi, taşınmış “
uploads”, özel sabitler) o sabit yol tutmuyor ve anahtar arşive giriyordu — arşiv
aynı zamanda şifreli ayarları da taşıdığı için tek bir arşiv sızıntısı hepsini
çözebilirdi. Artık anahtar klasörü, yedek klasöründe zaten kullanılan gerçek-
yol yöntemiyle eleniyor. Varsayılan kurulumlarda davranış DEĞİŞMEDİ; hariç-tut
ekranındaki rozet de aynı kararı gösteriyor.
* **Hariç tutma ekranı, eski yedek klasörünü tanımıyordu.** 1.x’ten kalan `yedekalma-
backups`
klasörü arşive zaten girmiyordu, ama Pro etki tahmini, hariç-tut gezgini
ve klasör boyutu ekranları onu normal bir klasör gibi GB’larca boyutla listeliyor
ve ona “hariç tut” düğmesi gösteriyordu. Üç ekran da artık yedeği üreten kodla
aynı klasör listesini kullanıyor: ekranda gördüğünüz sayı, arşive gerçekten girecek
olanı anlatıyor.
* **30 günden eski yedekler yeniden “kayıp” görünebiliyordu.** 1.59.9 indirme bağlantısının
tazelenmesini getirmişti, ama bağlantı defteri 30 gün sonra yine de temizleniyordu—
oysa arşivlerin ömrü sınırsız. Sonuç, 1.59.9’da kapatılan sorunun 30 gün sonra
aynen dönmesiydi. Defter artık takvime değil, **arşivin diskte olup olmadığına**
bakıyor: dosya duruyorsa kaydı korunuyor. Defter dolduğunda da yalnız süresi
geçmiş kayıtlar budanıyor; kullanımdaki bir bağlantı artık silinmiyor.
* **Karantinadaki zararlı dosya, yedek arşivine artık ham hâlde girmiyor.** Temizlenen
dosyalar
“Geri Yükle” ile kurtarılabilsin diye karantinada saklanıyor ve yedeğe
de giriyor (bu bilinçli — aksi hâlde yanlış pozitif bir dosya geri getirilemezdi).
Ama içerik düz durduğu için bazı virüs programları TÜM yedek arşivini karantinaya
alıp erişilemez kılabiliyordu. Karantinaya alınan dosya artık etkisizleştirilmiş
biçimde saklanıyor; “Geri Yükle” onu birebir eski hâline döndürüyor. Eski karantina
kayıtları da okunmaya devam ediyor.
* **Çeviri kataloglarındaki boşluk artık ölçülüyor.** Şablon (`.pot`) 1.59.8’de
tamamlanmıştı
ama dil dosyaları (`.po`) geride kalmıştı ve bunu ölçen bir kontrol
YOKTU. Artık her dil için eksik/bayat girdi sayılıyor; dil dosyaları şablonla
eşitlendi ve kullanılmayan 50 bayat girdi temizlendi. Çeviri metinleri UYDURULMADI—
boş kalan girdiler çevrilene kadar kaynak metinle gösterilmeye devam eder.
#### 1.59.9 — 2026-08-25
* **Panel, sunucunuzda DURAN yedekleri “kayıp” gösteriyordu.** İndirme bağlantısı
72 saatte
güvenlik gereği ölüyor (bu doğru ve kalıyor) — ama süresi dolan bağlantının
kaydı da siliniyordu, dolayısıyla panel onu tazeleyemiyor ve arşivi silinmiş
sanıyordu. Ölçüldü: dört sitede 72 saatten eski yedeklerin **tamamı** panelde“
kayıp” görünüyordu, oysa dosyaların hepsi sunucularında duruyordu. En ağır sonucu,
o yedekler için **geri yüklemenin kapanmasıydı. Panelin aylardır çağırdığı tazeleme
ucu eklentiye eklendi; bağlantı artık kimlik doğrulamalı olarak yenileniyor.
Hiçbir yedek kaybolmamıştı. ⚠ Güvenlik gevşemedi: süresi dolmuş bağlantı hâlâ
reddediliyor; yalnızca yetkili panel yeni bir bağlantı isteyebiliyor.
#### 1.59.8 — 2026-08-24
* **Kontrol Paneli ile Yedekler sayfası aynı yedeği farklı sayabiliyordu.** İki
ekran
“tek kaynak”tan besleniyordu ama tekilleştirme KURALI ayrıydı: Yedekler
sayfası önce içerik özetine (checksum), Kontrol Paneli yalnız dosya adına bakıyordu—
oysa bulut kayıtlarında dosya adı gerçek değil, üretilmiş bir addır. Sıralama
da ayrıydı: tamamlanmamış bir yedek Kontrol Paneli’nde listenin sonuna düşüyordu,
oysa en yeni koşu odur. İkisi de tek ortak kurala bağlandı.
* **“1 hariç yol” yazan rozet, klasörün içini hariç tutmuyordu.** Eğik çizgi içermeyen
joker kalıplar (`logs[0-9]`, `cache*`) yalnız DOSYA adlarıyla eşleşiyor; aynı
adlı klasörün İÇİNDEKİ dosyalar yedeğe girmeye devam ediyordu. Kural gerçekten
çalıştığı için rozet onu sayıyordu — yani ekrandaki sayı doğru, kullanıcının
anladığı şey yanlıştı. Artık böyle kalıplar sarı bir notla işaretleniyor ve çalışan
doğru biçim (`logs[0-9]/*`) öneriliyor. Davranış DEĞİŞMEDİ: hiçbir dosya yedekten
düşmedi.
* **Çeviriler tamamlandı — özellikle KVKK rıza ekranı.** Eklenti arayüzünün büyük
bölümü
çeviri şablonunda (`.pot`) hiç görünmüyordu; İngilizce, Almanca, Rusça
ve Arapça kullanan müşteriler o ekranlarda **Türkçe** metin görüyordu. Bunlardan
biri hesap açan **açık rıza ekranıydı** — yani kullanıcı anlamadığı bir dilde
bir metne “onaylıyorum” işaretliyordu. Rıza ve onay dizgeleri dört dile çevrildi;
şablon artık kaynaktan otomatik üretiliyor ve eksik kalırsa yayın öncesi kapı
uyarıyor.
* **Şifreleme anahtarı yedek arşivinin içine giriyordu.** Tam yedek arşivi hem
şifreli
ayarları hem onları açan anahtar dosyasını taşıyordu; tek bir arşiv
sızıntısı tüm sırları çözebilirdi. Anahtar klasörü artık yedeğe hiç girmiyor.
* **Şifreleme anahtarı kaybolduğunda artık SESSİZ KALMIYOR.** Site taşındığında
ya da
WordPress güvenlik anahtarları (AUTH_KEY) değiştiğinde eklenti panel bağlantı
sırrını çözemiyordu ve o durumda **sessizce yeni bir sır üretip üzerine yazıyordu**.
Panel eski sırrı tuttuğu için siteye gelen her istek reddediliyor, site tarafında
ise hiçbir hata görünmüyordu — domain sessizce yedeklenmez hâle geliyordu. Artık
sır ezilmiyor, yöneticiye açık bir uyarı ve tek tıkla sıfırlama düğmesi gösteriliyor.
* **Anahtar dosyasının yolu doğrulanıyor.** Taşınmış sitede `wp_upload_dir()` eski
sunucunun mutlak yolunu döndürüyor ve o klasör yeni sunucuda yok; eklenti bunu
fark etmeden oraya yazmaya çalışıyordu. Yol artık var-mı/yazılabilir-mi diye
sınanıyor.
* **Aynı sitede iki yedek aynı anda çalışamaz.** wp-admin’deki “Şimdi Yedekle”,
panelden
ya da zamanlayıcıdan gelen bir yedek sürerken artık uyarı verip duruyor;
kendi yedeği de ortak kilidi gerçekten tutuyor. Öncesinde iki yol birbirini göremiyor
ve aynı arşiv iki kez üretilebiliyordu.
* **Yedek doğrulamasının iki katmanı bu kanalda kördü — artık ölçüyor.** Eklenti,
arşivin
md5 özetini ve veritabanı döküm özetini (kaç tablo / kaç satır / kaynakta
kaç tablo vardı) panele **hiç göndermiyordu**. Panel bu yüzden “veritabanı doğrulaması”
katmanını hiçbir zaman hesaplayamıyor ve — üstelik — _“Modül tablo/satır sayısı
bildirmedi (eski sürüm)” diyerek yanlış bir teşhis gösteriyordu. Bütünlük katmanı
da uçtan uca karşılaştırma yapamadığı için kesik/bozuk bir yüklemeyi yakalayamıyordu.
* **Ek depolama hedefine giden kopya artık birincille aynı bilgiyi taşıyor.** Aynı
arşivin
ikinci kopyası, arşive giremeyen dosya bilgisini taşımadığı için farklı
bir doğrulama rozeti alabiliyordu.
* **Arşive giremeyen dosyalar artık raporlanıyor.** Okunamayan ya da eklenemeyen
dosyalar
sessizce atlanıyor, yedek yine de “Başarılı” damgası alıyordu; eksiklik
ancak geri yükleme günü anlaşılıyordu. Böyle yedekler artık **“Uyarılı”** olarak
işaretleniyor, kaç dosyanın etkilendiği yazılıyor ve geri yükleme yine yapılabiliyor.
#### 1.59.7 — 2026-08-24
* Yalnızca eklenti sayfası metinleri: WordPress.org’daki “Upgrade Notice” bölümü
1.57.8’de kalmıştı; 1.58–1.59 hattının kullanıcıyı ilgilendiren değişiklikleri(
devralınan sitede önceki sahibin arşivleri, Kontrol Paneli’nin “yedeğiniz yok”
demesi, çeviri metinlerindeki ters bölü işaretleri) orada hiç görünmüyordu.
* **Eklenti kodunda değişiklik YOKTUR** — 1.59.6 ile aynı dosyalar.
#### 1.59.6 — 2026-08-22
* **Site el değiştirdiğinde önceki sahibin arşivleri artık işaretleniyor.** Bir
site başka
bir Yedekalma hesabına bağlandığında, diskte duran eski arşivler “
Önceki dönem” rozetiyle gösterilir. O arşivler önceki sahibin veritabanını içerir(
müşteri kayıtları, e-posta adresleri); kime ait olduklarını bilmek hem yeni hem
eski sahip için önemlidir. Arşivler **gizlenmez** — gizlemek, onları silme imkânını
da ortadan kaldırırdı.
* **Önceki döneme ait bir yedeği geri yüklemek artık ayrı onay istiyor.** Böyle
bir arşivi
geri yüklemek sitenizin içeriğini önceki sahibin verisiyle değiştirir;
kullanıcı hesapları ve müşteri kayıtları dahil. Artık tek tıkla yapılamıyor.
#### 1.59.5 — 2026-08-22
* **Kontrol Paneli hâlâ “yedeğiniz yok” diyordu — asıl sebep bulundu.** 1.59.4’
teki
düzeltme yalnız hesapsız (yerel) kuruluma dokunuyordu. Yedekalma hesabına
BAĞLI kurulumlarda Kontrol Paneli sadece panele soruyor, sitenin kendi diskindeki
yedekleri hiç görmüyordu. Artık Yedekler sayfasıyla aynı kaynağı kullanıyor ve
aynı listeyi gösteriyor. Aynı yedek iki kaynakta birden varsa tek kez gösterilir.
* **Sol menüde Destek, Ayarlar’ın üstüne alındı.** Yardım arayan kişi menünün dibine
bakmak zorunda kalmasın.
#### 1.59.4 — 2026-08-22
* **Kontrol Paneli “hiç yedeğiniz yok” diyordu, oysa yedekler duruyordu.** Yedekler
sayfası
üç başarılı yedeği listelerken Kontrol Paneli aynı anda “Henüz yedek
alınmamış” gösteriyordu. Sebep: panel üzerinden alınan (ya da kaydı düşmüş) arşivler
diskte durur ama WordPress kaydında bulunmaz; Yedekler sayfası bunları tarayıp
buluyordu, Kontrol Paneli taramıyordu. Artık ikisi de aynı şeyi gösteriyor.
* **Metinlerdeki ters bölü işaretleri temizlendi.** Çeviri dosyalarında çift kaçış
vardı;
ekranda `\"Tam Yedek\"` gibi görünüyor, bazı yerlerde de bağlantıları
bozuyordu. Beş dilin tamamında düzeltildi.
#### 1.59.3 — 2026-08-22
* **Sayfa başlığındaki uzun açıklama kaldırıldı.** Dört satırlık paragraf, mavi
bilgi
kutusu ve ayrı bir yönlendirme satırı vardı; üçü birden ekranın üstünü
dolduruyor ve aynı bilgiyi bağlanma kartındaki açıklamayla ikinci kez tekrar
ediyordu. İki kez söylenen şey bir kez bile okunmuyor.
* Yerine tek satır: hizmetin ne yaptığı + iki yön tarifi — **yerel yedekleme**
Kontrol
Paneli’nde, **geri yükleme ve .zip/.sql içe aktarma** Yedekler sayfasında.
Bu ikisi anlatım değil, yanlış sayfada arama hatasını önleyen kısayol.
#### 1.59.2 — 2026-08-22
* **Bağlanma ekranı sadeleşti.** Dört özellik alt alta madde olarak yer kaplıyordu;
artık
yan yana kısa etiketler hâlinde. Yerine, asıl merak edilen soruya tek
cümleyle cevap veren bir açıklama kondu: yedeğin nerede hazırlandığı, nereye
gittiği ve bağlanmanın ne işe yaradığı.
* **“Google ile bağlan” düğmesi boydan boya.** Küçük bir düğmeyi aramak yerine,
yapılacak
işlem doğrudan görünüyor.
* **Bağlı değilken “Ayarları Kaydet” çubuğu artık çıkmıyor.** O ekranda kaydedilecek
bir
ayar yok; çubuk yine de görünüyor ve yapılacak bir iş varmış izlenimi veriyordu.
Anlamsız bir eylem çağrısı, gerçek olanların da güvenilirliğini düşürür.
#### 1.59.1 — 2026-08-22
* **Bağlanma ekranı toparlandı.** “Google ile bağlan” düğmesi ve seçimler artık
sayfanın
en üstünde, tek bakışta görünüyor. “Yedekalma nedir, verim nereye gidiyor”
anlatımı aşağıya alındı — okumak isteyen için orada duruyor, ama karar vermek
için sayfayı aşağı kaydırmanız gerekmiyor.
* **Otomatik temizlemenin isteğe bağlı olduğu netleştirildi.** Kutunun altında
artık şu
yazıyor: şimdi kaldırabilirsiniz, ya da bağlandıktan sonra yedekalma.
com panelinizden dilediğiniz zaman açıp kapatabilir, sayıları değiştirebilirsiniz.
Sağdaki kutuda da sayıların sabit olmadığı ve her domain için ayrı ayrı ayarlanabildiği
belirtiliyor.
#### 1.59.0 — 2026-08-22
* **Bağlanma ekranı iki sütuna ayrıldı.** Solda onaylar ve “Google ile bağlan”,
sağda
onayladığınız saklama politikasının içeriği: dosya, veritabanı, e-posta
ve tam yedekten kaçar tane saklanacağı. Neyi kabul ettiğinizi sayısıyla, aynı
ekranda görüyorsunuz.
* **Otomatik eski yedek temizleme artık bir seçim.** Kutu işaretli gelir ama
kaldırabilirsiniz;
tercihiniz hesabınıza kaydedilir ve bağlandıktan sonra panelden dilediğiniz zaman
değiştirebilirsiniz. Diğer iki onaydan farkı budur: bu isteğe bağlıdır.
* Saklama sayıları eklentiye gömülü değil, panelden gelir. Politika güncellenirse
ekranda
gösterilen sayı da kendiliğinden güncellenir — yani gördüğünüz sayı
ile hesabınıza uygulanan sayı her zaman aynıdır.
#### 1.58.2 — 2026-08-22
* **“Pro özelliklerini açmak için bağlanın” başlığı yeniden en üstte.** 1.58.1’
de tanıtım
bölümü onay kutularının üstüne alınırken başlığın da üstüne geçmişti;
ekranın ne için olduğunu söyleyen çağrı, uzun anlatımın altında kalıyordu. Sıra
artık şöyle: **başlık kısa özet “Yedekalma nedir / verim nereye gidiyor” onay
bağlan.** Böylece hem çağrı ilk görünen şey oluyor, hem de aydınlatma rızadan
önce geliyor.
#### 1.58.1 — 2026-08-22
* **Bağlanmadan önce ne olduğunu okuyorsunuz.** “Yedekalma nedir, yedeğim nerede
hazırlanıyor, verim nereye gidiyor” anlatımı artık onay kutularının ve “Google
ile bağlan” düğmesinin **üstünde**. Önceden düğmenin altındaydı; yani kullanıcı
önce karar verip sonra okuyordu. Onay ancak bilgilendirmeden sonra anlamlıdır—
KVKK’da da aydınlatma, açık rızadan önce gelir.
* Sözleşme bilgisi alınamadığında artık **“Tekrar dene”** bağlantısı var. Önceden
tek çare
koca yönetim sayfasını yeniden yüklemekti; geçici bir ağ hatası gereksiz
bir çıkmaza sokuyordu.
#### 1.58.0 — 2026-08-22
* **Yedekalma hesabı açılırken artık açık rıza alınıyor (KVKK).** “Google ile bağlan”
düğmesi yalnız bağlantı kurmuyor — yedekalma.com’da sizin adınıza bir **müşteri
hesabı açıyor. Panelden kayıt olurken Kullanım Koşulları ve KVKK aydınlatma metni
onayı zorunluyken, bu yol onları hiç sormuyordu. Artık iki onay kutusu işaretlenmeden
düğme açılmıyor; onayınız tarih, sürüm ve IP ile birlikte kaydediliyor.
* Sözleşme bağlantıları yeni sekmede yedekalma.com üzerinden açılır. Metinler ve
sürüm
bilgisi eklentiye gömülü DEĞİL, panelden çekilir — böylece belgeler güncellendiğinde
eklentiyi yeniden yayınlamak gerekmez ve onay kaydınız her zaman gerçekten okuduğunuz
metnin sürümünü gösterir.
* Sözleşme bilgisi alınamazsa bağlantı **başlatılmaz** ve sebebi ekranda yazılır.
Bilinçli
bir karar: hangi metne onay verildiği bilinmeden hesap açmak, kaydı
baştan değersiz kılar.
#### 1.57.13 — 2026-08-21
* **Büyük satırlı veritabanlarında yedek artık bellek yetmediği için durmuyor.**
Veritabanı
dökümü partileri şimdiye kadar SATIR SAYISIYLA ölçülüyordu (sabit
500). Satır sayısı belleği ölçmez: şişmiş bir ayar kaydı ya da serileştirilmiş
büyük bir meta değeri tek başına megabaytlarca olabilir. Böyle bir sitede 500
satır PHP bellek sınırını aşıyor ve yedek her denemede aynı noktada, birkaç saniye
içinde ölüyordu. Parti boyutu artık tablonun ortalama satır büyüklüğüne göre
BAYT bütçesiyle belirleniyor; ölçüm alınamazsa eski davranış aynen korunur (parti
yalnızca küçültülür, asla büyütülmez).
* **Her partiden sonra WordPress’in tuttuğu ikinci kopya serbest bırakılıyor.**
WordPress
sorgu sonucunu ayrıca kendi içinde saklar ve bir sonraki sorguya kadar
bırakmaz; bu, döküm sırasında tepe bellek kullanımını gereksiz yere iki katına
çıkarıyordu. Düzeltme yedekleme, döküm ve geri yükleme (ara/değiştir) yollarının
ÜÇÜNE de uygulandı.
#### 1.57.12 — 2026-08-20
* **Yedek biletleri artık adres satırında taşınmıyor.** Yükleme/indirme isteklerinde
kullanılan tek kullanımlık bilet, sunucu erişim kayıtlarına ve aradaki vekillere
düşmesin diye yalnızca istek başlığında gönderiliyor. Eski sürüm alıcı modüllerle
uyum korunuyor: karşı taraf yeni biçimi tanımıyorsa önceki yöntem kullanılmaya
devam eder.
#### 1.57.11 — 2026-08-20
* **Yarım kalan yükleme artık kilitlenmiyor.** Büyük bir yedek parça parça gönderilirken
son parçanın yanıtı kaybolursa, eklenti “her şey karşıda” cevabını alıp gönderimi
tamamlanmış saymıyor; tamamlama sinyalini yeniden gönderiyor. Önceden bu durumda
arşiv hedefe hiç taşınmıyor, her yeni deneme aynı noktada başarısız oluyor ve
yedek tamamlanamıyordu.
* **Yedek biletleri artık istek başlığında da gönderiliyor.** Sunucu erişim kayıtlarına
ve
aradaki vekillere adres satırıyla birlikte düşmemesi için; eski sürüm alıcılarla
uyum korunuyor.
#### 1.57.10 — 2026-08-20
* **Yedek klasörü artık kendi kendini yedeklemiyor.** Klasör adı yeniden adlandırılamayıp
eskisi yerinde kaldığında, eski klasör yedeğin içine giriyordu — arşiv kendi
eski arşivlerini taşıyor ve gereksiz yere büyüyordu. Hariç tutma artık tüm yedek
klasörlerini tanıyor (yalnızca güncel adı değil).
* **Sağlaması olmayan katman artık geri yüklemede açık onay ister.** Bütünlük doğrulaması
yapılamayan bir yedek katmanı sessizce uygulanmıyor; ne olduğu ekranda yazıyor
ve kullanıcı bilerek onaylamadan işlem başlamıyor.
#### 1.57.9 — 2026-08-20
* **Parçalı yedekte kesik arşiv koruması.** Arşiv, büyük sitelerde birden çok istekte
parça parça yazılır. Bir parça yarıda kesilirse (hosting zaman aşımı, bellek
sınırı) aynı dosya ikinci kez yazılabiliyor ve arşiv tutarsız hâle gelebiliyordu.
Yazıcı artık arşivin yan kaydını okuyup hangi dosyaların gerçekten TAM yazıldığını
doğruluyor; yarım kalmış bir girdi “tamam” sayılmıyor.
* **Virüs tarama ekranında dosya adı kaçışı.** Taranan bir dosyanın adı ekrana
kaçırılmadan basılıyordu; siteye kötücül adlı bir dosya bırakabilen biri, tarama
ekranını açan yöneticinin tarayıcısında kod çalıştırabilirdi.
* **Yedek klasörü adı.** Klasör adı yeniden oluşturulurken tahmin edilebilir bir
ada
düşebiliyordu; artık her durumda rastgele ad üretiliyor ve mevcut yedek
kayıtları öksüz kalmıyor.
* **Manuel yedekte geçici dosya konumu.** wp-admin üzerinden alınan yedeklerde
veritabanı dökümü ve arşiv, bazı sunucularda web’den erişilebilen bir klasöre
yazılabiliyordu; artık sertleştirilmiş geçici klasör kullanılıyor.
* **Hariç tutma listesi.** Virgülle ayrılmış satırlar ve nicelik aralığı içeren
düzenli
ifadeler (`\d{1,3}` gibi) artık modülle birebir aynı biçimde yorumlanıyor—
panelde görünen kural sayısı ile yedeğe gerçekten uygulanan kural aynı.
#### 1.57.8 — 2026-08-19
* **Güvenlik/kararlılık: bozuk ya da kötücül bir şifreli yedek artık belleği tüketip
geri yüklemeyi öldüremiyor.
Şifreli arşivler çerçeve çerçeve okunur ve her çerçevenin
başında 4 baytlık bir uzunluk alanı vardır. Doğrulama geçişinde (HMAC) bu uzunluk
için bir üst sınır YOKTU — dosya bozulmuş ya da kasten değiştirilmişse tek bir
çerçeve 4 GB’a kadar okuma istetebiliyor ve PHP “Allowed memory size exhausted”
ile ölüyordu; WordPress tarafında bu, geri yüklemenin 500 ile düşmesi demek.
Çözme geçişinde sınır zaten vardı ama doğrulama geçişi ONDAN ÖNCE koştuğu için
sıra ona hiç gelmiyordu. Sınır artık her iki geçişte de var (meşru azami çerçeve
1 MB; sınır 5 MB).
* Not: bu, aynı hatanın üçüncü kopyasıydı. Panel modülü ve sunucu tarafındaki kopyalar
aynı
gün düzeltilmişti; eklentideki kopyayı otomatik “ikiz parite” kapımız yakaladı.
#### 1.57.7 — 2026-08-19
* **Yeni: geri yüklemede “sunucu yapılandırma dosyalarını da geri yükle” seçeneği.**
1.57.6’dan
beri `wp-config.php`, `.htaccess` ve `.user.ini` geri yüklemede korunuyordu—
doğru varsayılan, çünkü yedek alındığından bu yana veritabanı bilgileriniz ya
da hosting sunucunuz değiştiyse eski ayarların geri gelmesi siteyi ONARMAK yerine
DÜŞÜRÜR. Ama bu üç dosyayı _bilerek_ geri istemenin hiçbir yolu yoktu (sunucu
taşımasından sonra eski `.htaccess` kurallarını geri almak gibi). Artık geri
yükleme penceresinde açık bir onay kutusu var: işaretlemediğiniz sürece davranış
aynı (dosyalar korunur), kutu her açılışta kapalı başlar ve “Sadece Veritabanı”
modunda hiç görünmez.
* **Yeni uyarı: geri yüklenen wp-config.php farklı bir AUTH_KEY taşıyorsa artık
söylüyoruz.**
Panel bağlantınız ve yedek şifreleme (BYOK) parolanız bu sitede
AUTH_KEY’den türetilen bir anahtarla şifreli saklanır. Eski bir sunucudan gelen
wp-config.php geri yüklenirse ikisi de okunamaz hâle gelir — önceden bunu hiçbir
yerde göremiyor, ancak bir sonraki yedek başarısız olunca fark ediyordunuz. Artık
dosya yazılmadan ÖNCE ölçülüyor ve sonuç ekranında ne yapmanız gerektiği yazıyor(
paneli yeniden bağlayın, şifreleme parolanızı yeniden girin).
* **Geri yükleme sonucu artık ne olduğunu SÖYLÜYOR.** “Başarıyla tamamlandı” mesajının
altında
yapılandırma dosyalarının korunup korunmadığı ve — yedek bir sağlama(
SHA-256) kaydı taşımıyorsa — arşivin yalnızca YAPISAL olarak doğrulandığı yazıyor.
Bu bilgiler 1.57.6’dan beri üretiliyordu ama ekrana hiç gelmiyordu; üretilip
gösterilmeyen uyarı, verilmemiş uyarıdır.
* **Düzeltildi: “Alıcı Modül” hedefine yedek yüklenemiyordu.** Kendi sunucunuza
kurduğunuz
Alıcı Modül’ü depolama hedefi olarak seçtiyseniz, WordPress eklentisi
bu yükleme yöntemini HİÇ uygulamıyordu: yedek hazırlanıyor, sonra yükleme adımında
düşüyordu. (Panel modülü bu yöntemi destekliyordu, eklenti desteklemiyordu.)
Artık destekleniyor — büyük arşivlerde parçalı ve kopan bağlantıda kaldığı yerden
devam edebilen biçimde.
#### 1.57.6 — 2026-08-19
* **Düzeltildi: wp-admin’den BULUT yedeğini geri yükleme her zaman “403” veriyordu.**
Yerel
(bu sunucudaki) yedeklerden geri yükleme çalışıyordu, ama bulut hedefinizdeki(
Google Drive/S3/FTP) yedeği wp-admin’den geri yüklemeye çalıştığınızda işlem
daima yetki hatasıyla düşüyordu. Gerekli kimlik başlığı iki çağrı yerinden yalnız
birine eklenmişti. Felaket anında ilk basacağınız düğme buydu; artık iki yol
da TEK bir kapıdan geçiyor.
* **Düzeltildi: sembolik bağlı site kökünde geri yükleme “başarılı” diyor ama HİÇBİR
dosyayı
yazmıyordu.
Birçok paylaşımlı hostingde `public_html` gerçek bir klasör
değil, başka bir
yola işaret eden bir bağdır. Eklenti site kökünü çözümlemeden
karşılaştırdığı için o sunucularda arşivdeki her dosya sessizce “atlandı” sayılıyor,
işlem yine de “Geri yükleme başarıyla tamamlandı” diyordu — site ONARILMAMIŞ
oluyordu ve bu ancak felaket gününde anlaşılıyordu. Kök artık çözümleniyor; ayrıca
arşivde dosya varken hiçbiri yazılamadıysa bu artık bir HATADIR, başarı değil.
Aynı kök neden Pro klasör gezginini de o hostlarda kullanılamaz hâle getiriyordu;
o da düzeldi.
* **Geri yükleme öncesi arşiv doğrulaması sertleşti.** Bir yedek katmanı sağlama(
SHA-256)
taşımıyorsa eskiden HİÇBİR bütünlük kontrolü yapılmıyordu; indirmenin
başarısı yalnızca “dosya 22 bayttan büyük mü” ile ölçülüyordu (22 bayt = boş
bir zip). Artık indirilen boyut sunucunun bildirdiği boyutla karşılaştırılıyor(
HTTP/FTP/SFTP), arşiv sitenizin üzerine yazılmadan ÖNCE içerik tutarlılığı denetleniyor
ve yarım/kesik aktarım “başarılı” sayılmıyor.
* **Düzeltildi: hariç tutma kalıpları hostinga göre FARKLI davranıyordu.** `logs[
0-9]` gibi
karakter aralıkları ve büyük/küçük harf duyarlılığı, PHP’nin `fnmatch`
fonksiyonu …
## Meta
* Version **1.63.0**
* Last updated **9 hours ago**
* Active installations **Fewer than 10**
* WordPress version ** 5.8 or higher **
* Tested up to **7.1**
* PHP version ** 7.4 or higher **
* Language
* [English (US)](https://wordpress.org/plugins/yedekalma/)
* Tag
* [backup](https://dv.wordpress.org/plugins/tags/backup/)
* [Advanced View](https://dv.wordpress.org/plugins/yedekalma/advanced/)
## Ratings
No reviews have been submitted yet.
[Your review](https://wordpress.org/support/plugin/yedekalma/reviews/#new-post)
[See all reviews](https://wordpress.org/support/plugin/yedekalma/reviews/)
## Contributors
* [ kamkactemha ](https://profiles.wordpress.org/kamkactemha/)
## Support
Got something to say? Need help?
[View support forum](https://wordpress.org/support/plugin/yedekalma/)