Afdrukvoorbeeld
Ik was ze al kwijt toen ze alle accounts opnieuw handmatig gingen aanmaken op de nieuwe server, de reden dat ik nu met een reeks lege accounts zit waarin ik ook alle mailboxen en instellingen opnieuw moet gaan maken.Citaat:
Oorspronkelijk geplaatst door Apoc
Nog beter - ik wist niet eens dat je meerdere DB's in een bestand kon proppen. Voor zover ik weet, elke tabel heeft eigen bestandje (ongeacht of het InnoDB / MyISAM of iets anders is)Citaat:
Oorspronkelijk geplaatst door Wynand
Enige bestanden dat voor alle DB's gelijk kan zijn, zijn log file en replicatie bestand.
Dus ik vind het een zeer vreemd verhaal. Wat Apoc ook zegt - door bestand te kopiëren, zou deze wellicht door verse MySQL installatie op te pakken zijn (al dan niet met wat corrupte data).
@ Apoc,
Ik lees 2 dingen op hun site, een veiligheidscopie is dus geen klantencopie lijkt mij maar kan het mis hebben.
Mijns inziens wordt er dus nergens gezegd dat het anders zou zijn, indien deze backup corrupt is is het overmacht.
Citaat:
Wekelijkse server backup
Wekelijks worden er veiligheidskopiën gemaakt van alle bestanden op de servers van DreamHost.nl Web hosting, zodat - in geval er een onoverkoombaar hardware probleem optreedt - direct naar een andere server kan worden overgestapt.
Citaat:
M.b.v. het cPanel 11 Controle paneel kunt u via uw browser het merendeel aan mogelijk-heden van uw Web hosting pakket beheren; het is dan ook ontworpen met de intentie om de cliënt zoveel mogelijk de controle over zijn/haar Web hosting pakket te laten behou-den, zonder dat deze ingewikkelde commando's uit dient te voeren. Via het cPanel Con-trole paneel krijgt u de mogelijkheid om o.m. alle aspecten van uw e-mail, bestanden, back-ups, FTP, CGI scripts en web site statistieken te beheren
@BsHosting: dan zou ik (btw, ben geen klant bij ze) verwachten dat mijn website verschijnt met maximaal 1 week oude data, toch? Daarom hebben ze ook die backups. Echter, ze leveren nu - zoals ik het hier lees - kale hosting pakketten. Dat is toch wereld van verschil...
Ben ik met je eens dat het een wereld van verschil is.
Maar er is maar 1 persoon die kan zeggen wat er fout is aan de huidige backups.
Ik lees dat er wel ftp toegang is en die open blijft als er geen data opstaat vraag ik me dan toch af waarom die nog een maand openblijft staan.
Er is wel data van de bestanden - maar niet van de DB. Dus je kan je php / html bestandjes ophalen, maar niet de DB. Als ze wekelijks backup maken - waarom zetten ze deze niet terug (mits deze ook corrupt is). Maar normaal gesproken maak je meerdere backups (ik maak zelf van me desktop backups tot 7 dagen).
Tja, blijft een vreemd verhaal.
Buiten dat welles nietes spelletje vraag ik me toch echt iets af.
als de site data wel beschikbaar is(Al sinds de melding van de storing), mag je concluderen dat de schijf niet gecrashed is. Waar is dan die mysql data....
ok prima, stel dat de mysql extern is en die schijf is gecrashed...
waarom is apache dan ook ineens dood .....en waarom is het zo ingewikkeld apache weer aan te slingeren.
Kortom, dit mag wel een exotisch probleem zijn anders zie ik neit in dat het niet te repareren is.
Ben wel benieuwd wat dat toch is met die MySQL, lijkt meer aan de hand.
@marsipulami: wat ik uit het verhaal opmaak gaat het om een read-only filesystem. De meeste daemons draaien daar niet op (i.v.m. PID files en andere files die aangemaakt moeten worden bij het starten). De gebruikte FTP daemon heeft dat schijnbaar niet nodig.
@T. Verhaeg: ik vermoed onkunde.
@Apoc: zelfs met read only kan je DB bestanden kopiëren, toch?
Ik verbaas me technisch ook een beetje over dit verhaal. Zelfs met ruwe Mysql data kun je erg ver komen. Maar goed, blijft gissen natuurlijk.
Aan de andere kant. Ik kan me niet voorstellen dat Dreamhost er niet alles aan doet om de boel weer aan de praat te krijgen. Hoeveel kost het inhuren van een externe nou in verhouding met de kosten van deze reputatie schade?
Normaal wel, zolang die sectors/partitie niet beschadigd is. Maar met een read only hd moet het zeker mogelijk zijn om alle bestanden (die niet corrupted zijn) gewoon te copieren naar een nieuwe hd. Heb dit zelf al een paar keer voor klanten gedaan en daar was zelf nog een dd mogelijk.Citaat:
Oorspronkelijk geplaatst door SmilieBG
Maar zolang alle details niet bekend zijn over het probleem blijft het enkel gissen naar de oorzaak en/of mogelijke oplossing hiervoor. Het kan bvb zijn dat er niks aan de hd's is maar dat de sata/raid/... controler hier op flipt en alles in read only komt te staan. Of het read only verhaal is rookgordijn om het echte probleem niet te moeten vermelden.
Dat zou ik me ook niet kunnen voorstellen, maar die indruk krijg ik wel steeds meer. Ik heb zelf de indruk dat er de eerste dagen gedacht werd in de trend van "het omzetverlies is beperkt, dus we nemen het verlies voor lief". Ik kan me er absoluut niets bij voorstellen, maar ik kan eigenlijk geen enkele andere verklaring bedenken voor het feit dat het nu al zo lang plat ligt.Citaat:
Oorspronkelijk geplaatst door Bart L
Ik vermoed een archive (zip/tar/oid) van /var/lib/mysql... scheelt weer ruimte op je backup-space :)Citaat:
Oorspronkelijk geplaatst door SmilieBG
en die is corrupted geraakt...
'k Zei toch ook dat ik nieuwsgierig was naar hoe ze dat deden? :pCitaat:
Oorspronkelijk geplaatst door SmilieBG
Een groot bestand wil je niet, zowel naar performantie als veiligheid, maar ik weet niet eens hoe dat zou gaan. :P
Het encrypten van die files op een shared bak snap ik vanuit technisch oogpunt evenmin, maar misschien heeft er ooit iemand wel wat voor geschreven...
Archives kan je niet gebruiken om zo je "live" data uit te fetchen/modifyen.Citaat:
Oorspronkelijk geplaatst door davinci
@marsipulami: als de FTP verwijst naar een NAS/SAN en de webserver daar z'n spullen weer van haalt klopt het hele verhaal. ;)