Configurând copia de rezervă a următorului site, am observat că unele dintre arhivele au fost sparte. Am fost foarte surprins de o astfel de surpriză. După ce am studiat situația, am găsit cazul.
Mai întâi de toate, trebuie să aflăm pe scurt cum funcționează backup-urile pentru mine:
- Pe serverul cu site-urile, în anumite perioade, scriptul bash este lansat
- Scriptul stochează baza de date, arhivează dosarul site-ului și, dacă este necesar, diferite suplimente. fișiere (cum ar fi coroane).
- La numele fișierelor primite, se adaugă o marcă de timp și toate acestea se adaugă în dosarul de rezervă al site-ului corespunzător
- Apoi, fișierele sunt copiate pe serverul de la distanță folosind utilitarul ftp
- În cele din urmă, vom curăța dosarul cu copii de siguranță pentru a stoca numai ultimele versiuni de backup pe serverul sursă
După cum este scris, sistemul de backup face mai multe arhive (minimum 2-a: baza de date + folderul site-ului). Deci, pe serverul de backup, am descoperit că unele arhive sunt deschise în mod normal (a se vedea lista fișierelor), iar unele sunt corupte. Faptul că o parte din arhive era normal pentru mine și m-au adus într-o stupoare. Fișierul deteriorat a fost de aproximativ aceeași dimensiune ca și serverul original, dar fișierul nu a fost corupt pe serverul sursă. De aceea am bănuit că lucrează în mod incorect transferul ftp direct între servere.
Problema sa dovedit a fi destul de simplă: în urmă cu câteva luni, am redirecționat toate copiile de rezervă către un server care rulează Windows Server. În consecință, serverul FTP a fost creat pentru Windows Server. Un google puțin, am învățat următoarele: cu transferul ASCII de la serverul Linux la Windows, căruța de transport (feed line) este tratată diferit. Transferurile Linux "\ n", Windows folosește "\ r \ n". În consecință, fișierul se rupe.
Acum, să vedem de ce s-au luptat unele dintre dosare, iar altele nu. În arhive, unde exista un singur fișier în interiorul (de exemplu, o bază de date bazată pe date), arhivatorul putea citi numele fișierului și mi-a arătat-o. În arhive unde au existat mai multe fișiere, arhivatorul nu poate citi cel de-al doilea fișier și, prin urmare, a raportat imediat o eroare. Ei bine, ca o chestiune de fapt, la o încercare de a dezarhiva arhiva eroarea a fost în ambele cazuri. Ie considerați că dacă arhivatorul (WinRar, 7Zip) a deschis arhiva și vedeți numele fișierului, aceasta nu înseamnă că întreaga arhivă.
Bine, cred că deja ați înțeles că am multe arhive sparte. După căutarea soluției, am dat peste acest post: Reparați fișiere binare corupte transferate prin ftp în modul ASCII. Descrie o situație similară cu cea a mea, dar cel mai important lucru pe care îl descrie este modul în care se pot restaura astfel de fișiere. Este foarte simplu să faceți acest lucru:
Acum trebuie să ne dăm seama cum să rezolvăm scriptul bash, astfel încât fișierele să fie trimise, nu rupte? În acest lucru vă vom ajuta manualul pe utilitarul ftp, care poate fi găsit aici: man ftp. suntem interesați de această parte, care descrie comenzile disponibile după stabilirea conexiunii:
binary Setează modul de transfer de fișiere pentru a sprijini transferul de imagini binare.
Adăugăm această comandă înaintea comenzii put, obținem ceva de genul:
Articole similare
-
Boots pentru recuperare după un accident vascular cerebral, vitaportal - sănătate și medicină
-
Refacerea airbag-urilor după un accident sau apariția unor erori în Perm
Trimiteți-le prietenilor: