Ευχαριστώ για την πλήρη απάντηση. Τώρα τη διάβασα (στα γρήγορα) επειδή δεν την έβρισκα επειδή... (άσε, άλλη ιστορία, για μια άλλη φορά για πολύ γέλιο :D).
[snip-ped] Apollon Koutlidis wrote: > >> - Τι μέσο αποθήκευσης θέλεις / προτιμάς / μπορείς να χρησιμοποιήσεις > >> για τα αντίγραφα ασφάλειας; ταινία, δίσκος, μηχανογραφικό χαρτί... Nikos Alexandris wrote: > > Εξωτερικός(-οί) σκληρός(-οί) δίσκος(-οί) με θύρα firewire(x800) ή USB2. On Wed, 2009-11-04 at 19:09 +0000, Apollon Koutlidis wrote: > Η χρήση εξωτερικού δίσκου για αντίγραφα ασφαλείας είναι θεμιτή αλλά όχι > ιδιαίτερα scalable (κλιμακώσιμη!;) λύση. Για 2 clients καλό το ακούω, αν > αυξηθούν μάλλον είναι σκόπιμο να αρχίσεις να σκέφτεσαι δικτυακές λύσεις > με κεντρικό backup server. Σημαντικό είναι οι δίσκοι να μην είναι > μονίμως συνδεδεμένοι στα αντίστοιχα συστήματα, ειδ' άλλως αυξάνεις την > πιθανότητα να συμβεί κάτι στα αντίγραφά σου. > >> - Τι είδους δεδομένα θα ασφαλίσεις; Πόσο συχνά αλλάζουν; Λάβε υπ' όψη > >> ότι κάποιοι τύποι δεδομένων (π.χ. databases) χρήζουν ειδικής > >> μεταχείρισης - ένα απλό cp / rsync δεν αρκεί (όχι από μόνο του). > >> > > > > (1) - Από τα πιο "συνηθισμένα" (φωτογραφίες, μουσική, ντοκουμέντα), > > > > - μέχρι απλά σενάρια (bash, python, R για τα οποία ήδη χρησιμοποιώ > > το git τοπικά) > > > > - και "πολύπλοκα" (γεω-χωρικά δεδομένα με τα μετα-δεδομένα τους, > > βάσεις γεω-δεδομένων == συνηθισμένοι κατάλογοι με υποκαταλόγους και > > αρχεία υπό το GRASS-GIS, αρκετά sqlite.db's, πιθανόν και άλλες βάσεις > > -φερ' ειπείν PostGIS(PostgreSQL)-) > > > > (2) Αλλάζουν καθημερινά. > > > > Ερώτηση: ποια είναι η απαιτούμενη ειδική μεταχείριση που χρήζουν κάποιες > > βάσεις δεδομένων; > > > Άρα έχεις ανάμεικτα δεδομένα ως προς τύπο, και δε μας είπες τι ποσοστό > των δεδομένων σου αλλάζει :) λογικό είναι βέβαια να μην ξέρεις κιόλα > αφού δεν έχεις ακόμα λύση backup. Εμμ... είναι πολύ δύσκολη η εκτίμηση αυτή. - Ξεκίνησα (πάλι) ερασιτεχνικά να φωτογραφίζω και (ίσως) κακώς αλλά οι φωτογραφίες τρώνε αχόρταγα τα GBs. - Τα κείμενα, ντοκουμέντα είναι αστείο να πει κανείς ότι είναι πρόβλημα για ένα μέσο χρήστη (προς λίγο πιο αφοσιωμένο). - Τα γεω-δεδομένα είναι πολλά και θα γίνουν ακόμη πιο πολλά (χοντρικά ~300GB). - Η μουσική είναι αρκετή αλλά όχι πάρα πολύ. Δεν ασχολούμαι με "κατεβάσματα" οπότε απλά τη θέλω σε μια γωνιά ασφαλισμένη. --%<--- > Οι βάσεις δεδομένων - όπως και πολλές άλλες εφαρμογές - δεν προσφέρονται > για αντίγραφα ασφαλείας ως έχουν, διότι η κατάστασή τους βρίσκεται εν > μέρει στον δίσκο και εν μέρει στη μνήμη. Οι διαθέσιμες μέθοδοι ασφάλισης > είναι πολλές και εξαρτώνται από την εφαρμογή. Η απλούστερη λύση είναι να > κλείσεις την εφαρμογή από την αρχή μέχρι το τέλος της αντιγραφής. Οι > περισσότερες βάσεις δεδομένων διαθέτουν και μεθόδους hot / warm backup > (π.χ. mysqldump [4]) εάν το downtime είναι πρόβλημα. Σε αυτές τις > περιπτώσεις τυπικά κάνεις ένα αντίγραφο σε αρχείο στον δίσκο και > αντιγράφεις μόνον αυτό. Ένας λόγος που χρησιμιποιώ sqlite ως backend στο GRASS είναι και αυτός. Είναι απλά αρχεία (όχι client-server) και απλά τα συμπιέζει/αντιγράφει κανείς. Αλλά πιθανόν να υπάρξουν και άλλα δεδομένα που απαιτούν κάτι άλλο από sqlite. --%<--- > Μία ακόμα παράμετρος που αξίζει να έχεις υπ' όψη: Όπου υπάρχουν πολλά, > μικρά αρχεία (π.χ. email), εμφανίζεται το πρόβλημα της διαμεταγωγής των > μεταδεδομένων - συνήθως αυτό μεταφράζεται σε μειωμένες ταχύτητες > αντιγραφής και αυξημένο όγκο των καταλόγων των αντιγράφων. Ενδιαφέρον. --%<--- > >> - Τι μέσο μετάδοσης θα χρησιμοποιηθεί; Ethernet / Fibre channel / > >> SCSI / USB...; Και με τι ταχύτητα διαμεταγωγής; > >> > > > > Firewire (up to ~115MB/s), USB2 (up to ???) > > > Όπως είπα και παραπάνω, όσο έχεις λίγους clients και δε χρειάζεσαι > κεντρικό server τα πράγματα είναι γενικώς πιο απλά. Προς το παρόν θα παραμείνουν απλά. --%<--- > >> - Τι βάθος ιστορικού θέλεις; > >> > > > > Θέλω να υπάρχουν όλα και να αποφασίζω εγώ τι θα χάνεται για πάντα > > ανάλογα με το διαθέσιμο ελεύθερο χώρο. > > > > > Εδώ μου τα μπερδεύεις. ;-) --%<--- > Δεν έχω υπ' όψη μου κάποια λύση που να κάνει αυτή > τη δουλειά (ίσως με εξαίρεση τα αμφιβόλου ωριμότητας logging filesystems > τύπου NILFS / JFFS [5] αλλά δε θα σου συνιστούσα να κολυμπήσεις σε αυτή > τη θάλασσα!). Το git είναι κάτι το φανταστικό. Γι' αυτό έχει κολλήσει το μυαλό μου στο git. Δεν αντιγράφει νέα αρχεία, αλλά μόνο τις αυτές καθ'αυτές αλλαγές (σωστά). Αλλά πάλι, είπαμε, δεν είναι για binary αρχεία. --%<--- > Είτε θα κάνεις καθημερινά πλήρη αντίγραφα (κάτι που απαιτεί πολύυυ > αποθηκευτικό χώρο), είτε θα κάνεις περιοδικά (π.χ. εβδομαδιαία) πλήρη > και στο ενδιάμεσο incremental / differential (τα πρώτα αποθηκεύουν μόνο > τις αλλαγές από το προηγούμενο incremental και τα δεύτερα, όπου είναι > διαθέσιμα, τις αλλαγές από το τελευταίο πλήρες). Όσο μεγαλύτερο το > διάστημα μεταξύ των πλήρων, τόσο πιο πολύπλοκη είναι η ανάκτηση (και > προφανώς το ρίσκο αποτυχίας). Σε κάθε περίπτωση καθορίζεις τη διάρκεια > τήρησης κάθε αντιγράφου και το λογισμικό θα "ανακυκλώσει" τα ληγμένα > αντίγραφα μόλις χρειαστεί το χώρο (ή το μέσο όταν χρησιμοποιείς ταινίες). > > Ένα λίγο-πολύ κλασικό σενάριο: > - Πλήρη κάθε μήνα το Σάββατο, τήρηση για ένα έτος > - Πλήρη κάθε εβδομάδα το Σάββατο εκτός από τις ημέρες των μηνιαίων, > τήρηση για 4 εβδομάδες > - Incremental κάθε μέρα εκτός Σαββάτου, τήρηση για 2 εβδομάδες > > Κατ' αυτό τον τρόπο έχεις ημερήσιο ιστορικό για 2 εβδομάδες, εβδομαδιαίο > για άλλες 2 και μηνιαίο για ένα έτος. > > >> Πόσο αποθηκευτικό χώρο μπορείς να διαθέσεις; > >> > > > > Τώρα 1,3 ΤΒ και άμεσα αν παραστεί ανάγκη επιπλέον 2 ΤΒ. > > > Χωρίς να ξέρουμε όμως τον όγκο των δεδομένων που θα ασφαλίσεις και τον > ρυθμό μεταβολής τους, αυτή η πληροφορία είναι μάλλον άχρηστη :( Σωστά. Νομίζω ότι τώρα αγγίζω το μισό τέρα(ς). --%<--- > >> - Πόσα συστήματα (clients) θα ασφαλίσεις; Πόσο απομακρυσμένα είναι > >> γεωγραφικά; > >> > > > > * 2 laptop, local > > * 1 directory σε ftp server (το πολύ 1χλμ. σε ευθεία απόσταση), σύνδεση > > τοπικού δικτύου μέσω WLAN με το δίκτυο του πανεπιστημίου. > > > Για το ftp directory μάλλον θα χρειαστεί νά κάνεις καθημερινά τοπικό > mirroring πριν το αντίγραφο ασφαλείας. Ευτυχώς εκεί είναι πολύ λίγα τα δεδομένα. --%<--- > >> - Πόσο χρόνο την εβδομάδα μπορείς να διαθέσεις για να "νταντεύεις" τα > >> αντίγραφα ασφαλείας σου; > >> > > > > Όσο χρειαστεί για να γίνει σωστά η δουλειά αρχικά ώστε να χρειάζεται όλο > > και λιγότερο human input αργότερα. > > > Το αρχικό (όπως πιθανότατα έχεις αρχίσει να υποψιάζεσαι) μπορεί να είναι > ΠΟΛΥ, μα ΠΑΡΑ πολύ! Μάλλον έχεις δίκιο και είναι κάτι που δεν το υπολόγιζα/ υπολογίζω. --%<--- > Στις περισσότερες περιπτώσεις η προσπάθεια που θα > χρειαστεί αργότερα είναι αντιστρόφως ανάλογη του τετραγώνου της αρχικής > προσπάθειας (ναι, το μοντέλο είναι ολοσχερώς αυθαίρετο και δεν πρέπει να > το πάρεις τοις μετρητοίς). Τα υπόλοιπα ελπίζω ότι θα τα συνάγεις από τα > συμφραζόμενα. > > >> - Υπάρχει (ή είναι πολύ πιθανό να υπάρξει σύντομα) ανάγκη προστασίας > >> από φυσική καταστροφή που απαιτεί αντίγραφα να βρίσκονται σε > >> απομακρυσμένη τοποθεσία; > >> > > > > Δεν ξέρω τι εννοείς εδώ με το "φυσική καταστροφή" (δηλ., σεισμός, > > πυρκαγιά, πλημμύρα ή απλά να τα παίξει ο δίσκος από "φυσική" φθορά;) > > αλλά σε κάθε περίπτωση *πάντα* υπάρχει η ανάγκη προστασίας από "φυσική" > > καταστροφή γενικότερα. Όλα είναι πιθανά! > > > Εννοώ κυρίως την πυρκαγιά / πλυμμήρα και οτιδήποτε είναι πιθανόν να > καταστρέψει μονοκοντυλιά τόσο τα πρωτογενή δεδομένα όσο και τα > αντίγραφα. Για αυτές τις περιπτώσεις, οι συνήθεις λύσεις είναι η > μετακίνηση π.χ. των μηνιαίων ταινιών / δίσκων σε άλλη τοποθεσία, ή η > πραγματοποίηση κάποιων (ή όλων) των αντιγράφων κάπου αλλού μέσω δικτύου. > Οι περιορισμοί και τα κόστη σε κάθε περίπτωση είναι, νομίζω, προφανή. Αλήθεια, εμπιστέυεσαι( -στε) τις on-line λύσεις που προσφέρονται; Για πολλούς λόγους επιμένω να τις αντιμετωπίζω με (ιδιαίτερα σκληρό) σκεπτικισμό. --%<--- > Δευτερευόντως, πρέπει να λάβεις υπ' όψη σου και την πιθανότητα αστοχίας > υλικού στα αντίγραφά σου (οι πλέον παρανοϊκοί εφαρμόζουν σατανιστικές > λύσεις τύπου RAIT [6] ή mirrored δίσκους). > > >> - Πόσο συχνά χρειάζεται να είναι τα αντίγραφα; (μεταφράζεται σε: πόσες > >> ώρες / μέρες αλλαγών μπορείς να ανεχτείς να χαθούν;) > >> > > > > Κάθε μέρα νομίζω είναι απαραίτητο για όσα δεδομένα υφίστανται αλλαγές. > > > > > >> Όσο για το git (ή οποιοδήποτε άλλο VCS)] > >> - πρώτον: ΔΕΝ είναι backup, > >> > > > > Σύμφωνοι. Αλλά, κατά τη γνώμη μου, έχει κανείς λόγους να ασχοληθεί αυτό > > ακόμη και αν δεν είναι υπερ-προγραμματιστής (βλέπε και [*]). Συν τοις > > άλλοις, χρησιμοποιώ το git για τα όλα τα ντοκουμέντα μου είναι (αρχεία > > LyX == απλό κείμενο ουσιαστικά :-). > > > > > >> δεύτερον: πολύ σπάνια είναι η καλύτερη λύση για δεδομένα που διαφέρουν > >> δραστικά από πηγαίο κώδικα. > >> > > > > Προφανώς και δεν είμαι ειδήμων και καταλαβαίνω όσα μπορώ να εκμαιεύσω > > από συζητήσεις όπως αυτή στο [3]. > > > > > Εφ' όσον κατανοείς ότι τα VCS αποθετήρια δεν είναι από μόνα τους > αντίγραφα αλλά χρήζουν ασφάλισης, έχεις πιάσει την ουσία :-) Λάβε και > πάλι υπ' όψη ότι ενδεχομένως να χρειαστεί ειδική μεταχείριση όπως στην > περίπτωση των βάσεων δεδομένων. Σωστά... :-Ο --%<--- > Επί της ουσίας τώρα: > > Η βασική επιλογή σου είναι μεταξύ δύο κατευθύνσεων - είτε θα > χρησιμοποιήσεις κάποιο "απλό" εργαλείο (π.χ. fwbackup, sbackup, rbackup, > hashbackup, κάποιο τυχαίο ή αυτοσχέδιο shell script) ή θα πας σε > "ενήλικα" backup περιβάλλοντα όπως το bacula ή το amanda. [7], [8] > > Τα δεύτερα είναι πολύ πιο πολύπλοκα, απαιτούν πολύ διάβασμα, σκέψη και > προσπάθεια για να υλοποιηθούν και συνήθως προϋποθέτουν αυτόνομο (ή > σχεδόν αυτόνομο) εξυπηρετητή. Τα πλεονεκτήματά τους είναι ότι είναι πολύ > πιο ευέλικτα, μεγαλώνουν μαζί σου (εκατοντάδες clients, petabytes > αντιγράφων) και κάνουν τη ζωή σου απλή εκεί που μετράει περισσότερο: > Στην ανάκτηση. > > Τα απλούστερα εργαλεία θέλουν λίγη (η και ελάχιστη) προσπάθεια > υλοποίησης και συνήθως απευθύνονται σε οικιακούς χρήστες με απλές ανάγκες. > > Για κλείσιμο, μια επισήμανση: Ό, τι και να διαλέξεις, όπως και να το > υλοποιήσεις, μην παραλείψεις για κανένα λόγο να κάνεις μια δοκιμαστική > ανάκτηση μετά από μερικές ημέρες. Ναι, είναι τεράστιος μπελάς (ο > "σωστός" τρόπος είναι να ξεκινήσεις με έναν καινούργιο ή πρόσφατα > formatted υπολογιστή) αλλά το μόνο χειρότερο από το καθόλου backup, > είναι το backup που δε δουλεύει όταν το χρειαστείς! > > Καλό κουράγιο και αχρείαστο να 'ναι ;-) > > > [...] > > > > Ελπίζω να είναι χρήσιμη η συζήτηση και σε άλλους φίλους της λίστας. > > > Επειδή εγώ είμαι πολυ-asshole-ος (διάβαζε τεμπέλαρος), αν έχει κανείς > την όρεξη να μαζέψει τα παραπάνω σε κάποιο wiki / forum. +1 υποδύομαι τον πολυπράγμωνα :-p ( Πιθανότατ όταν στήσω το μηχανισμό [=όχι σύντομα] να έχω κάτι που να μπορεί να ανέβει σε κάποιο wiki επειδή έχω την τάση -εδώ και 1+χρόνο- να ντοκουμεντάρω με άφθονα σχόλια ό,τι κάνω ## ευχαριστώ έναν πραγματικά πολύπειρο φίλο που μου δίδαξε τη διαφορά του "θορύβου" από την "πληροφορία" ## ) > > Milles mercis, Νίκος > > > > Φιλικά, > Απόλλων Ευχαριστώ! --%<--- > >>> --- > >>> [1] > >>> > >>> > >> http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html > >> > >>> [2] http://eigenclass.org/hiki/gibak-backup-system-introduction > >>> > >>> [3] http://kerneltrap.org/mailarchive/git/2006/12/12/233113/thread > >>> > > > > [*] > > http://mendicantbug.com/2008/11/30/10-reasons-to-use-git-for-research/ > > > [4] > http://www.devarticles.com/c/a/MySQL/Backing-Up-Your-MySQL-Databases-With-MySQLDump/ > [5] http://en.wikipedia.org/wiki/Log-structured_file_system > [6] http://www.thic.org/pdf/Oct00/stk.mfisher.pdf > [7] http://blogs.techrepublic.com.com/10things/?p=895 > [8] http://linux.about.com/od/softbackup/Linux_Software_Backup_Solutions.htm
signature.asc
Description: This is a digitally signed message part
-- Ubuntu-gr mailing list Ubuntu-gr@lists.ubuntu.com If you do not want to receive any more messages from the ubuntu-gr mailing list, please follow this link and choose unsubscribe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-gr
