crudeWWWutils: Bash scripts για γρήγορο backup/restore/cleanup δυναμικών websites

[parsifal]

Καλημέρα σε όλους.

 

 

Σε ένα από τα VPS που διαχειρίζομαι ξεκίνησα να γράφω μερικά scripts για να με διευκολύνουν στη δουλειά που αναφέρω στον τίτλο. Σκέφτηκα να τα μοιραστώ μαζί σας μπας και χρησιμεύσουν σε κανέναν ή υπάρχουν προτάσεις για bug fixes, βελτιώσεις κλπ.:

 

GitHub repository

 

 

Σκέψεις και σχόλια πάντα ευπρόσδεκτα!

[NullScan]

Πολύ καλή δουλειά! thanks

Έχω μερικές προτάσεις (και 8α μπορούσα να συνεισφέρω και patches αλλά αυτή τη στιγμή πνίγομαι) πάντως άν θές 2 πρόχειρες βελτιώσεις είναι οι εξής:

1. Σκέψου τη χρήση του pbzip2 για πιό γρήγορο compression του mysqldump άν είναι διαθέσιμο στο σύστημα. Στο ίδιο μοτίβο με ένα extra parameter θα μπορούσε να κάνει και encryption με openssl πχ.

2. Άν θέλεις μπορείς να προσθέσεις και το binlog position την ώρα πού παίρνεις το dump για την περίπτωση που θέλεις να το έχεις σαν reference για πιθανούς mysql slave servers.

 

Αργότερα ελπίζω να ρίξω μιά καλύτερη ματιά και να σου στείλω και patches αν θές.

[parsifal]

Γεια σου NullScan δύναμη!

 

Ευχαριστώ για τις ιδέες, τις κρατώ και εννοείται πώς patches είναι ευπρόσδεκτα!

 

 

Για την ώρα, προσπαθώ να καλιμπράρω το compression level του xz που χρησιμοποιείται για τη συμπίεση των αρχείων (όχι της βάσης) και θα ήθελα τη γνώμη σας. Έχω βάλει -8 αλλά είναι overkill τελικά. Θέλω να υλοποιήσω επιλεγόμενο από τον χρήστη επίπεδο συμπίεσης, αλλά με ενδιαφέρει μία βέλτιστη default τιμή. Ενδεικτικά αναφέρω πως δοκιμάζω με την default εγκατάσταση του PrestaShop 1.6.0.10 beta που έχει μέγεθος περίπου 63.26 MB και τα αποτελέσματα έχουν ως εξής:

xz -8:  21s - 11.55 MB
xz -7:  20s - 11.62 MB
xz -6:  20s - 12.01 MB
xz -5:  16s - 12.09 MB
xz -4:  12s - 12.40 MB
xz -3:   7s - 12.73 MB
xz -2:   6s - 12.95 MB
xz -1:   5s - 13.98 MB

Κλίνω περισσότερο προς το -3 ως default τιμή, ειδικά αν σκεφτεί κανείς πως ένα δυναμικό website τέτοιας φύσης, στο πέρασμα του χρόνου θα μεγαλώνει σε filesize κυρίως λόγω των images, τα οποία δεν είναι και ιδιαίτερα compressible. Τί λέτε...;

[NullScan]

Προσωπικά προτιμώ να γίνεται γρήγορα το backup αντί να πιάνει λιγότερο χώρο. Άλλωστε τα 2.5MB δέν είναι ιδιέταιρα μεγάλη διαφορά.

Άσε που το decompress θα γίνεται πιό γρήγορα κάτι που το θέλεις γιατί άν έρθει η ώρα να κάνεις τέτοιο restore, μάλλον θα καίγεσαι οπότε το κάθε δευτερόλεπτο μετράει.

Άρα ψηφίζω -1

Άν το μέγεθος μεγαλώσει πολύ και οι διαφορές είναι σημαντικές τότε ένα μύνημα στον χρήστη θα ήταν το καλύτερο νομίζω για να επιλέξει μόνος του.

Σκέψου και τη δυνατότητα του incremental χρησιμοποιόντας κάτι σάν το duplicity

[parsifal]

Θέλω να υλοποιήσω επιλεγόμενο από τον χρήστη επίπεδο συμπίεσης, αλλά με ενδιαφέρει μία βέλτιστη default τιμή.

Done, με default value -3! Κρίμα που στο Debian Wheezy το πακέτο xz-utils έγινε freeze στην έκδοση 5.1.0, γιατί από την 5.1.2 και πάνω έχει υλοποιηθεί multithreaded compression! Χαραμίζονται τα 4 vCPU cores του VPS μου.

 

 

NullScan, incremental backups με upload σε Amazon S3 θα είναι το επόμενό μου project!