Backups, Migration & Recovery
Οργανώστε σωστά αντίγραφα ασφαλείας, επαναφορά, αλλαγή hosting, αλλαγή domain και disaster recovery χωρίς να χαθούν patients, appointments, protected files, tokens ή integration mappings.
Τι πρέπει να περιλαμβάνει το backup
Ένα απλό backup της WordPress database δεν αρκεί. Το Nutrition Hub χρησιμοποιεί συνδυασμό database records, protected files, plugin configuration και integration metadata.
WordPress database
Patients, appointments, measurements, plans, notes, files metadata, logs, settings, license status και mappings.
Αρχεία ασθενών
PDF, εικόνες, reports και uploads που δεν βρίσκονται σε δημόσιο Media Library URL.
Plugin και custom code
Nutrition Hub plugin, must-use plugins, child theme και σχετικές custom integrations.
Server και environment settings
Cron, environment variables, firewall rules, email provider, WebSocket host και PHP configuration.
License secrets, API keys, OAuth tokens και webhook secrets δεν πρέπει να αποθηκεύονται σε μη κρυπτογραφημένα κοινόχρηστα backups ή να αποστέλλονται με απλό email.
Προτεινόμενη στρατηγική αντιγράφων ασφαλείας
| Τύπος backup | Συχνότητα | Διατήρηση | Σκοπός |
|---|---|---|---|
| Database | Καθημερινά ή συχνότερα | 30–90 ημέρες | Γρήγορη αποκατάσταση operational data. |
| Protected files | Καθημερινά | Ανάλογα με retention policy | Αποκατάσταση patient documents και reports. |
| Full site | Εβδομαδιαία και πριν από updates | Τουλάχιστον 4–8 εκδόσεις | Ολοκληρωμένο rollback. |
| Configuration export | Μετά από σημαντική αλλαγή | Μέχρι να αντικατασταθεί με νεότερο | Cron, integrations, server settings. |
| Off-site copy | Σε κάθε backup cycle | Σύμφωνα με business continuity plan | Προστασία από απώλεια hosting account. |
Διατηρείτε τουλάχιστον 3 αντίγραφα, σε 2 διαφορετικά μέσα, με 1 αντίγραφο εκτός του βασικού hosting.
- Τα backups είναι κρυπτογραφημένα σε μεταφορά και αποθήκευση.
- Υπάρχει παρακολούθηση αποτυχίας backup job.
- Γίνεται περιοδικός έλεγχος ότι τα αρχεία ανοίγουν.
- Το retention συμφωνεί με τη νομική και επιχειρησιακή πολιτική.
- Δεν διατηρούνται άσκοπα παλιά backups με ευαίσθητα δεδομένα.
Διαδικασία επαναφοράς
Ένα backup θεωρείται αξιόπιστο μόνο όταν έχει δοκιμαστεί επιτυχώς η επαναφορά του.
Καταγράψτε το περιστατικό
Σημειώστε ώρα, έκταση, επηρεαζόμενα δεδομένα και την τελευταία γνωστή σωστή κατάσταση.
Σταματήστε νέες εγγραφές όπου χρειάζεται
Ενεργοποιήστε maintenance mode ή περιορίστε actions για να μην δημιουργηθεί νέο conflicting data.
Επιλέξτε το σωστό restore point
Προτιμήστε το πιο πρόσφατο καθαρό backup πριν από το συμβάν.
Επαναφέρετε πρώτα σε staging
Ελέγξτε database integrity, protected files, login και βασικά workflows πριν από production restore.
Επαναφέρετε production
Εκτελέστε controlled restore και καθαρίστε caches, transients και stale queue locks.
Κάντε post-restore validation
Ελέγξτε license, appointments, files, email, Calendar, portal, cron και integrations.
Η database και το protected-file storage πρέπει να προέρχονται από συμβατό restore point ώστε να μην δημιουργηθούν orphaned ή missing files.
Μεταφορά σε νέο hosting
Ελέγξτε τις απαιτήσεις του νέου server
PHP, database, memory, cron, HTTPS, REST API, storage και outbound connectivity.
Δημιουργήστε πλήρες migration backup
Database, WordPress files, protected storage και τεχνική configuration.
Αντιγράψτε σε staging URL
Δοκιμάστε πρώτα σε προσωρινό hostname ή hosts-file mapping χωρίς να αλλάξετε άμεσα DNS.
Εκτελέστε database search/replace όπου χρειάζεται
Χρησιμοποιήστε εργαλείο που χειρίζεται σωστά serialized WordPress data.
Ρυθμίστε cron και external services
Email, Soketi, Google callbacks, payment webhooks και firewall allowlists.
Μειώστε DNS TTL και κάντε controlled cutover
Προγραμματίστε μικρό maintenance window και επιβεβαιώστε propagation.
Διατηρήστε το παλιό environment προσωρινά read-only
Μην το διαγράψετε μέχρι να ολοκληρωθούν όλοι οι έλεγχοι.
Αλλαγή domain
Η αλλαγή domain επηρεάζει περισσότερα από τα WordPress URLs. Χρειάζεται έλεγχος άδειας, OAuth callbacks, webhooks, email links και security settings.
| Στοιχείο | Απαιτούμενη ενέργεια |
|---|---|
| WordPress Home / Site URL | Ενημέρωση στο νέο HTTPS domain. |
| License | Deactivate/transfer ή reset του domain binding. |
| Google OAuth | Ενημέρωση redirect URI και πιθανό reconnect. |
| Payment webhooks | Νέα webhook URLs και δοκιμή signatures. |
| Email links | Νέα portal, booking και manage URLs. |
| Cookies / sessions | Έλεγχος domain scope και forced logout όπου απαιτείται. |
| CORS / firewall | Ενημέρωση allowlists και trusted origins. |
| Search engines | 301 redirects για δημόσιες σελίδες όπου χρειάζεται. |
Η ίδια άδεια δεν πρέπει να παραμένει ενεργή ταυτόχρονα σε δύο production domains, εκτός αν το πλάνο το επιτρέπει ρητά.
Τι ελέγχουμε μετά τη μεταφορά
OAuth και sync
Redirect URI, connection status, token validity, calendar ID και test appointment.
Webhooks και checkout
Endpoint URL, signature verification, success/failure event και idempotency.
Sender και links
SPF/DKIM/DMARC, queue, new-domain URLs και test delivery.
Soketi / WebSocket
Host, TLS, auth endpoint, private channels και reconnect.
Central proxy
License validation, outbound access, quota status και test task.
Download access
License status, short-lived token και write permissions.
OAuth ή provider credentials μπορεί να συνδέονται με callback URLs, domain restrictions ή environment settings και να χρειάζονται νέα authorization.
Disaster recovery plan
| Στόχος | Τι σημαίνει | Παράδειγμα πολιτικής |
|---|---|---|
| RPO | Μέγιστη αποδεκτή απώλεια δεδομένων. | Έως 24 ώρες ή μικρότερο για κρίσιμη λειτουργία. |
| RTO | Μέγιστος χρόνος αποκατάστασης υπηρεσίας. | 4–24 ώρες, ανάλογα με το πακέτο υποστήριξης. |
| Restore owner | Ποιος εκτελεί και εγκρίνει το restore. | Hosting admin και εξουσιοδοτημένος account owner. |
| Escalation | Ποιος ενημερώνεται σε σοβαρό περιστατικό. | Webion, clinic owner, hosting και DPO όπου απαιτείται. |
Ελάχιστο recovery runbook
- Πώς αποκτούμε πρόσβαση στο τελευταίο καθαρό backup.
- Ποιος έχει δικαίωμα να εγκρίνει restore.
- Πώς δημιουργείται προσωρινό recovery environment.
- Πώς ελέγχεται database και protected-file consistency.
- Πώς επαναφέρονται DNS, SSL, cron και integrations.
- Πώς ενημερώνονται οι χρήστες για downtime ή data loss.
- Πώς καταγράφεται το περιστατικό και τα διορθωτικά μέτρα.
Εκτελέστε τουλάχιστον περιοδική δοκιμή restore σε staging. Ένα recovery plan που δεν έχει δοκιμαστεί είναι απλώς υπόθεση.
Checklist πριν και μετά τη μεταφορά
Τελικός έλεγχος λειτουργίας
| Περιοχή | Test |
|---|---|
| Authentication | Doctor, secretary και patient login. |
| Patients | Άνοιγμα καρτέλας, measurements και notes. |
| Appointments | Create, update, cancel και public booking. |
| Files | Upload, authorized download και denied access. |
| Queue, delivery και correct-domain links. | |
| Google Calendar | Connect status και test event sync. |
| Payments | Test event ή provider sandbox validation. |
| Realtime | Private channel authorization και reconnect. |
| Cron | Scheduled jobs εκτελούνται χωρίς backlog. |
Συχνές ερωτήσεις
Αρκεί το backup που προσφέρει το hosting;
Όχι πάντα. Πρέπει να επιβεβαιωθεί ότι περιλαμβάνει database, protected files, σωστή διατήρηση και δυνατότητα πραγματικής επαναφοράς.
Χρειάζεται reconnect το Google Calendar μετά από migration;
Μπορεί να χρειάζεται, ειδικά όταν αλλάζει domain, callback URI, encryption key ή token storage. Ελέγξτε πάντα με test sync.
Μπορώ να αφήσω ενεργό το παλιό site;
Προσωρινά μόνο για rollback και κατά προτίμηση read-only. Δύο ενεργά production sites μπορεί να δημιουργήσουν διπλοκρατήσεις, διπλά emails και conflicting webhooks.
Τι γίνεται με τα scheduled jobs μετά τη μεταφορά;
Πρέπει να απενεργοποιηθούν στο παλιό environment και να επιβεβαιωθούν στο νέο, ώστε να μην εκτελούνται δύο φορές.
Πότε διαγράφουμε το παλιό hosting;
Μόνο αφού ολοκληρωθεί το agreed validation period, υπάρχει νέο επιβεβαιωμένο backup και έχουν ελεγχθεί integrations, DNS, cron και files.
Security Guide
Η επόμενη σελίδα καλύπτει access control, tenant isolation, encryption, protected files, sessions και incident response.