Εν συντομία: Μια ανθεκτική στρατηγική backup για διακομιστές ακολουθεί τον κανόνα 3-2-1: τρία αντίγραφα, δύο τύποι αποθήκευσης, ένα αντίγραφο εκτός έδρας. Για να επιβιώνουν τα backups μιας επίθεσης, τουλάχιστον ένα αντίγραφο χρειάζεται προστασία από διαγραφή από τον ίδιο τον διακομιστή. Και μόνο μια επιτυχημένη δοκιμή επαναφοράς δείχνει ότι το αντίγραφο ασφαλείας λειτουργεί σε πραγματική ανάγκη.
Τι σημαίνει ο κανόνας 3-2-1
Ο κανόνας 3-2-1 είναι μια απλή αρχή για τη διάσωση δεδομένων, δοκιμασμένη επί χρόνια:
- 3 αντίγραφα: τα αρχικά δεδομένα και δύο αντίγραφα ασφαλείας.
- 2 τύποι αποθήκευσης: για παράδειγμα τοπικός δίσκος και αποθήκευση αντικειμένων, ή αποθήκευση διακομιστή και ταινία.
- 1 αντίγραφο εκτός έδρας: σε άλλη τοποθεσία, σε άλλον πάροχο ή εκτός σύνδεσης.
Για διακομιστές ιστού αυτό σημαίνει συγκεκριμένα: ένα αντίγραφο στον ίδιο σκληρό δίσκο με τον ιστότοπο δεν μετρά ως αυτόνομο αντίγραφο. Αν ο διακομιστής τεθεί εκτός λειτουργίας ή παραβιαστεί, χάνονται και τα δύο. Για τη διοίκηση το κεντρικό ερώτημα δεν είναι γι' αυτό «Έχουμε backups;», αλλά «Μπορούμε να επαναφέρουμε τη λειτουργία από ένα αντίγραφο που το περιστατικό δεν έφτασε;»
Μια στρατηγική backup για διακομιστές που επιβιώνει μιας επίθεσης
Οι επιτιθέμενοι γνωρίζουν ότι τα backups ακυρώνουν τη δουλειά τους. Όποιος έχει πρόσβαση σε έναν διακομιστή αναζητά γι' αυτό συχνά και αντίγραφα ασφαλείας, για να τα διαγράψει ή να τα κρυπτογραφήσει. Μια σύγχρονη στρατηγική επεκτείνει γι' αυτό συχνά τον κανόνα 3-2-1 σε 3-2-1-1-0: ένα αντίγραφο επιπλέον εκτός σύνδεσης ή αμετάβλητο, και μηδέν σφάλματα στη δοκιμή επαναφοράς.
Τρεις αρχές κάνουν τα backups ανθεκτικά:
- Pull αντί για push: Ένα ξεχωριστό σύστημα backup παραλαμβάνει τα δεδομένα από τον διακομιστή ιστού. Ο ίδιος ο διακομιστής ιστού δεν έχει διαπιστευτήρια με τα οποία θα μπορούσε να διαγράψει backups.
- Αμεταβλησία: Αποθήκευση αντικειμένων με κλείδωμα διατήρησης ή snapshots που δεν μπορούν να διαγραφούν για καθορισμένο χρονικό διάστημα.
- Χωριστές προσβάσεις: Ο λογαριασμός backup δεν είναι ο ίδιος με τον λογαριασμό πελάτη της φιλοξενίας και έχει δικό του δεύτερο παράγοντα.
Κρυπτογραφήστε τα backups που βρίσκονται εκτός έδρας και φυλάξτε το κλειδί χωριστά. Ένα κλειδί που χάθηκε κάνει το backup άχρηστο, ένα κλειδί που αποθηκεύτηκε μαζί κάνει την κρυπτογράφηση άνευ αξίας.
Τι πρέπει να διασώζεται
Στους διακομιστές ιστού διασώζεται συχνά μόνο το webroot. Για μια πλήρη επαναφορά λείπουν τότε σημαντικά μέρη.
| Τομέας | Παραδείγματα | Υπόδειξη |
|---|---|---|
| Αρχεία εφαρμογής | Webroot, uploads, θέματα, επεκτάσεις | Τα uploads αλλάζουν συχνά |
| Βάσεις δεδομένων | MySQL/MariaDB, PostgreSQL | διάσωση με συνέπεια, όχι απλή αντιγραφή αρχείων |
| Διαμόρφωση | Διακομιστής ιστού, pools PHP-FPM, php.ini, cronjobs | απαραίτητη για γρήγορη ανοικοδόμηση |
| Πιστοποιητικά και κλειδιά | Πιστοποιητικά TLS, κλειδιά εφαρμογής | αποθήκευση κρυπτογραφημένα και χωριστά |
| Τεκμηρίωση | Προσβάσεις, εξαρτήσεις, διαδικασία επαναφοράς | χωρίς αυτήν κάθε ανοικοδόμηση διαρκεί περισσότερο |
Παράδειγμα: διάσωση βάσης δεδομένων και αρχείων
Το παρακάτω παράδειγμα δείχνει τα βασικά συστατικά μιας καθημερινής διάσωσης. Στην πράξη ένα εργαλείο backup με κρυπτογράφηση, αφαίρεση διπλοτύπων και κανόνες διατήρησης αναλαμβάνει τη μεταφορά εκτός έδρας.
#!/bin/bash
set -euo pipefail
DATUM=$(date +%F)
ZIEL=/srv/backup/$DATUM
mkdir -p "$ZIEL"
chmod 700 "$ZIEL"
# Συνεπής διάσωση της βάσης δεδομένων· διαπιστευτήρια από προστατευμένο αρχείο, όχι στην εντολή
mysqldump --defaults-extra-file=/root/.backup-my.cnf \
--single-transaction --routines --triggers shopdb | gzip > "$ZIEL/shopdb.sql.gz"
# Αρχεία εφαρμογής και διαμόρφωση
tar -czf "$ZIEL/webroot.tar.gz" -C /var/www shop
tar -czf "$ZIEL/config.tar.gz" /etc/nginx /etc/php /etc/cron.d
# Αθροίσματα ελέγχου για μεταγενέστερο έλεγχο
sha256sum "$ZIEL"/* > "$ZIEL/SHA256SUMS"
Το αρχείο .backup-my.cnf περιέχει τα διαπιστευτήρια ενός χρήστη βάσης δεδομένων που επιτρέπεται μόνο να διαβάζει και έχει δικαιώματα 0600. Το --single-transaction εξασφαλίζει σε πίνακες InnoDB μια συνεπή κατάσταση, χωρίς να σταματήσει το κατάστημα.
Στη συνέχεια ένα ξεχωριστό σύστημα μεταφέρει το αντίγραφο εκτός έδρας. Σημαντικό είναι να παρακολουθείται αυτό το βήμα: μια εργασία backup που αποτυγχάνει σιωπηλά εδώ και ημέρες γίνεται αλλιώς αντιληπτή μόνο σε πραγματική ανάγκη. Αρκεί ένα καθημερινό μήνυμα για την επιτυχία, το μέγεθος και τη διάρκεια, εφόσον κάποιος το διαβάζει και ακολουθεί τις αποκλίσεις.
Αν χρησιμοποιείτε επιπλέον backups ή snapshots του παρόχου σας, ξεκαθαρίστε γραπτώς πόσο διάστημα διατηρούνται, αν μπορείτε να κάνετε οι ίδιοι την επαναφορά και αν τα αντίγραφα διατηρούνται σε περίπτωση λογαριασμού που έχει καταγγελθεί ή κλειδωθεί. Αυτά τα αντίγραφα αποτελούν καλή συμπλήρωση, δεν αντικαθιστούν όμως ένα δικό σας, ανεξάρτητο αντίγραφο.
Διατήρηση: γιατί οι παλαιότερες καταστάσεις έχουν σημασία μετά το PHP2Shell
Μετά από μια επίθεση δεν είναι το νεότερο backup το πολυτιμότερο, αλλά το νεότερο καθαρό. Στο PHP2Shell παρατηρήθηκε, σύμφωνα με δημοσιεύματα, στις 17.10.2026 μια πρώτη απόπειρα επίθεσης, ενώ τα patches κυκλοφόρησαν στις 21.10.2026. Όποιος διατηρεί μόνο επτά ημέρες, ίσως δεν έχει πλέον κατάσταση που βρίσκεται με ασφάλεια πριν από την πιθανή εισβολή.
Ένα δοκιμασμένο σχήμα συνδυάζει διάφορα χρονικά διαστήματα, για παράδειγμα καθημερινές διασώσεις για μερικές εβδομάδες, εβδομαδιαίες για μερικούς μήνες και μηνιαίες για ένα έτος. Τα ακριβή διαστήματα εξαρτώνται από την ανάγκη προστασίας σας και από τις υποχρεώσεις διαγραφής βάσει προστασίας δεδομένων.
Σημαντικό είναι επίσης: ένα backup από την περίοδο μετά από μια εισβολή μπορεί να περιέχει webshells ή τροποποιημένα αρχεία. Μην επαναφέρετε ποτέ τυφλά μετά από ένα περιστατικό, αλλά συγκρίνετε τα αρχεία με μια καθαρή κατάσταση και ελέγξτε τα προτού ο ιστότοπος επανέλθει στο διαδίκτυο. Υποδείξεις για το τι πρέπει να προσέξετε θα βρείτε στη σελίδα Ενδείξεις παραβίασης. Ένα patch δεν αφαιρεί κακόβουλο λογισμικό που έχει εισαχθεί, και ένα backup δεν το κάνει επίσης από μόνο του.
Δοκιμή και τεκμηρίωση της επαναφοράς
Ένα backup χωρίς δοκιμή είναι μια υπόθεση. Μόνο η επαναφορά δείχνει αν υπάρχουν όλα τα μέρη, αν λειτουργεί το κλειδί και πόσο διαρκεί πράγματι η διαδικασία.
- Επαναφέρετε τακτικά μια πλήρη διάσωση σε περιβάλλον δοκιμών, μαζί με βάση δεδομένων και διαμόρφωση.
- Ελέγξτε αν ο ιστότοπος λειτουργεί στη συνέχεια πλήρως: σύνδεση, παραγγελίες, φόρμες, email.
- Μετρήστε τη διάρκεια και καταγράψτε ποια βήματα ήταν χειροκίνητα. Συγκρίνετε το αποτέλεσμα με τον μέγιστο χρόνο που αντέχει η επιχείρησή σας χωρίς ιστότοπο.
- Φυλάξτε τον οδηγό επαναφοράς σε σημείο προσβάσιμο και όταν ο διακομιστής είναι εκτός λειτουργίας, για παράδειγμα στο σχέδιο έκτακτης ανάγκης IT.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Ελέγχουμε τα υπάρχοντα backups σας ως προς την πληρότητα, τη διατήρηση, τον διαχωρισμό από τον διακομιστή και την προστασία από διαγραφή.
- Στήνουμε μια διάσωση 3-2-1 με αμετάβλητο αντίγραφο και δοκιμάζουμε την επαναφορά μαζί σας.
- Μετά από ένα περιστατικό εντοπίζουμε την τελευταία καθαρή κατάσταση και την επαναφέρουμε σε ενημερωμένο σύστημα στο πλαίσιο της αφαίρεσης κακόβουλου λογισμικού.
- Στη σύμβαση συντήρησης ασφάλειας παρακολουθούμε διαρκώς τα αντίγραφα ασφαλείας και πραγματοποιούμε τακτικές δοκιμές επαναφοράς.
Συχνές ερωτήσεις
Τι σημαίνει ο κανόνας 3-2-1 στα backups;
Τρία αντίγραφα των δεδομένων σας, σε δύο διαφορετικούς τύπους αποθήκευσης, εκ των οποίων ένα σε άλλη τοποθεσία. Ο κανόνας φροντίζει ώστε ούτε μια βλάβη υλικού ούτε μια επίθεση ή μια πυρκαγιά να πλήξει ταυτόχρονα όλα τα αντίγραφα.
Αρκεί το backup του παρόχου φιλοξενίας μου;
Αποτελεί καλή συμπλήρωση, σπάνια όμως είναι επαρκές. Ξεκαθαρίστε πόσο διάστημα διατηρεί ο πάροχος τις καταστάσεις, αν μπορείτε να κάνετε οι ίδιοι την επαναφορά και αν ένας επιτιθέμενος με τον λογαριασμό πελάτη σας θα μπορούσε να διαγράψει τα backups. Συνιστάται ένα δικό σας, ανεξάρτητο αντίγραφο.
Μπορώ μετά από hack να επαναφέρω απλώς το τελευταίο backup;
Μόνο με προσοχή. Το τελευταίο backup μπορεί να περιέχει ήδη κακόβουλο κώδικα και η ευπάθεια από την οποία μπήκε ο επιτιθέμενος παραμένει ανοιχτή μετά. Πρώτα ξεκαθαρίστε και κλείστε την αιτία, έπειτα επαναφέρετε μια ελεγμένη κατάσταση σε ενημερωμένο σύστημα.
Πόσο συχνά πρέπει να δοκιμάζω την επαναφορά;
Τακτικά και μετά από μεγαλύτερες αλλαγές στο σύστημα. Ένας σταθερός ρυθμός, π.χ. μία πλήρης επαναφορά ανά τρίμηνο σε περιβάλλον δοκιμών, έχει αποδειχθεί αποτελεσματικός. Σημαντικό είναι ότι η δοκιμή τεκμηριώνεται και ότι τα κενά αντιμετωπίζονται.