Είναι ασφαλές το 'docker system prune -a';

Αφαιρεί σταματημένα containers, αχρησιμοποίητα δίκτυα, ορφανή build cache και κάθε image που δεν χρησιμοποιεί κάποιο container σε λειτουργία. Τα δεδομένα σας μένουν, εκτός αν προσθέσετε --volumes. Με --volumes διαγράφονται και τα αχρησιμοποίητα volumes — και το volume ενός σταματημένου container βάσης δεδομένων θεωρείται αχρησιμοποίητο. Αν δεν είστε σίγουροι, παραλείψτε αυτή τη σημαία.

Έσβησα ένα μεγάλο αρχείο log, αλλά το df δείχνει ακόμα γεμάτο δίσκο. Γιατί;

Μια διεργασία σε λειτουργία κρατά ακόμα το αρχείο ανοιχτό, οπότε ο πυρήνας δεν αποδεσμεύει τον χώρο. Βρείτε την με 'lsof +L1' και επανεκκινήστε την υπηρεσία. Την επόμενη φορά αδειάστε ένα ενεργό log με 'truncate -s 0 αρχείο' αντί να το σβήσετε.

Πόσο ελεύθερο χώρο πρέπει να αφήνω;

Τουλάχιστον 10–15%. Οι βάσεις δεδομένων, οι ενημερώσεις πακέτων και τα pulls του Docker χρειάζονται προσωρινό χώρο, και ένας δίσκος στο 100% μπορεί να καταστρέψει μια βάση στη μέση μιας εγγραφής.

Μπορώ να πάρω περισσότερο δίσκο χωρίς επανεγκατάσταση;

Ναι. Η αναβάθμιση σε μεγαλύτερο πλάνο μεγαλώνει τον δίσκο επιτόπου και κρατά τα δεδομένα σας — το Nano έχει 15 GB, το Micro 25 GB, το Small 35 GB, το Medium 45 GB. Η αναβάθμιση επανεκκινεί τον server μία φορά.

Τι γεμίζει συνήθως ένα μικρό VPS;

Από την εμπειρία μας: images και build cache του Docker, το journal του systemd, logs εφαρμογών που κανείς δεν κάνει rotate, και ξεχασμένα dumps βάσεων ή αρχεία αντιγράφων στο /root.

Πώς να ελευθερώσετε χώρο στον δίσκο ενός VPS χωρίς να χαλάσετε τίποτα

Γέμισε ο δίσκος του VPS; Βρείτε με du και ncdu τι πιάνει χώρο και καθαρίστε cache του apt, journal, υπολείμματα Docker και logs χωρίς απώλεια δεδομένων.

Το "No space left on device" δεν εμφανίζεται ποτέ σε βολική στιγμή. Η βάση δεδομένων σταματά να δέχεται εγγραφές, το apt δεν μπορεί να ολοκληρώσει μια αναβάθμιση και το Docker αρνείται να κατεβάσει ακριβώς το image που χρειάζεστε τώρα. Τα καλά νέα: σε ένα μικρό VPS ο ένοχος είναι σχεδόν πάντα ένα από πέντε πράγματα, και τον βρίσκετε σε δύο λεπτά.

1. Πόσο άσχημα είναι τα πράγματα;

df -h /
df -i /

Η πρώτη γραμμή δείχνει τον χρησιμοποιημένο χώρο. Η δεύτερη δείχνει τα inodes — αν τα inodes φτάσουν στο 100% ενώ ο χώρος φαίνεται εντάξει, έχετε εκατομμύρια μικροσκοπικά αρχεία (αρχεία συνεδριών, ουρά αλληλογραφίας, φάκελο cache). Άλλο πρόβλημα, ίδιο σύμπτωμα.

2. Βρείτε τι είναι μεγάλο

Διατρέξτε το δέντρο από την κορυφή και ταξινομήστε κατά μέγεθος:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

Το -x μένει σε ένα σύστημα αρχείων, ώστε να μη χαθεί μέσα στο /proc. Μετά μπείτε σε ό,τι είναι μεγαλύτερο. Για διαδραστική περιήγηση, το ncdu είναι πολύ πιο βολικό:

apt install -y ncdu
ncdu -x /

Βελάκια για πλοήγηση, d για διαγραφή. Προσοχή με το τελευταίο.

3. Οι γρήγορες νίκες

Αυτά είναι ασφαλή σε κάθε server με Ubuntu ή Debian:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

Το apt autoremove καθαρίζει και παλιούς πυρήνες. Το journal του systemd είναι αυτό που εκπλήσσει τους περισσότερους — αν το αφήσετε ανεξέλεγκτο, μπορεί να φτάσει αρκετά gigabytes. Για να το περιορίσετε μόνιμα, ορίστε SystemMaxUse=200M στο /etc/systemd/journald.conf και εκτελέστε systemctl restart systemd-journald.

4. Υπολείμματα του Docker

Αν τρέχετε Docker, κοιτάξτε εδώ πρώτα. Παλιά images και build cache συσσωρεύονται σε κάθε deploy:

docker system df
docker image prune -a
docker builder prune

Το docker image prune -a διαγράφει images που δεν χρησιμοποιεί κανένα container σε λειτουργία. Συνήθως αυτό θέλετε, αλλά το επόμενο deploy θα τα κατεβάσει ξανά.

Το επικίνδυνο είναι το docker system prune -a --volumes. Τα volumes κρατούν τα δεδομένα σας, και ένα volume συνδεδεμένο σε σταματημένο container θεωρείται αχρησιμοποίητο. Έτσι χάνει ο κόσμος βάσεις δεδομένων. Μην το επικολλήσετε από απάντηση σε φόρουμ.

Ο άλλος κρυφός καταναλωτής χώρου είναι τα logs των containers. Περιορίστε τα στο /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Μετά επανεκκινήστε το Docker. Το όριο ισχύει μόνο για containers που δημιουργούνται στη συνέχεια, οπότε αναδημιουργήστε τα «φλύαρα» με docker compose up -d --force-recreate.

5. Logs και ξεχασμένα αρχεία

Βρείτε μεγάλα αρχεία οπουδήποτε στον δίσκο:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Τα συνηθισμένα ευρήματα: ένα backup.tar.gz πριν από έξι μήνες στο /root, ένα dump βάσης που κάποιος ήθελε να κατεβάσει, ένα log εφαρμογής που δεν γίνεται ποτέ rotate.

Ένα log στο οποίο γράφει ακόμα μια υπηρεσία δεν το σβήνετε με rm — το αδειάζετε:

truncate -s 0 /var/log/myapp/app.log

Αν έχετε ήδη σβήσει ένα και ο χώρος δεν επέστρεψε, κάποια διεργασία το κρατά ακόμα ανοιχτό:

lsof +L1

Επανεκκινήστε την υπηρεσία που εμφανίζεται εκεί και ο χώρος επιστρέφει.

Όταν το καθάρισμα δεν αρκεί

Μερικές φορές τα δεδομένα είναι απλώς πραγματικά — μια βάση που μεγαλώνει, αρχεία χρηστών, ένα αρχείο μοντέλου. Τότε η ειλικρινής λύση είναι περισσότερος δίσκος. Η αναβάθμιση του πλάνου μεγαλώνει τον δίσκο επιτόπου και κρατά τα πάντα: το Nano έχει 15 GB, το Micro 25 GB, το Small 35 GB, το Medium 45 GB. Ο server επανεκκινείται μία φορά. Λεπτομέρειες στην τεκμηρίωση των πλάνων.

Κάτι ακόμα που τρώει χώρο αθόρυβα: το αρχείο swap. Αν ακολουθήσατε τον οδηγό για swap, αυτά τα 1–2 GB είναι δεσμευμένα σκόπιμα. Κι αν ο μεγαλύτερος καταναλωτής είναι το Docker, ο οδηγός εγκατάστασης Docker και ο οδηγός για Compose stacks δείχνουν πώς να κρατάτε τα images υπό έλεγχο.

Η συνήθεια που τα αποτρέπει όλα αυτά: περιορίστε το journal και τα logs του Docker από την πρώτη μέρα. Δύο γραμμές ρυθμίσεων, και το «γεμάτος δίσκος» πρακτικά σταματά να συμβαίνει.