Je kan ook een blauwdruk maken van je system qua chmod en chown rechten. Deze zou je mee kunnen laten backuppen en indien nodig weer gebruiken.
Je kan ook een blauwdruk maken van je system qua chmod en chown rechten. Deze zou je mee kunnen laten backuppen en indien nodig weer gebruiken.
"Zo zijn ook wij één leverancier. Dé leverancier in gedegen Linux kennis, wanneer jij dat nodig hebt."
Boek je admin vandaag nog via : www.admin.nu
Gevestigd in Nederland en Moldavië
Lees hier de webhostingtalk.nl forum regels en voorwaarden!
Je kunt ook gewoon full backups maken ipv alleen een "scriptje" ..
Skynet ICT B.V. - The cause of the problem is: the printer thinks its a router.
Er zijn altijd meerdere oplossingen mogelijk.
Backups zijn van levensbelang in de IT. Hetkangaat namelijk altijd wel een keer fout.
Regelmatige full backups, gevolgd door incrementals en/of differentials is het meest gangbare. Maar persoonlijk maak ik bij een belangrijke update/wijziging extra een lokale backup zodat deze in geval van nood snel terug gezet kan worden. Verder is een backup niets waard zolang je nog nooit getest hebt hoe deze terug te zetten.
Maar om terug te komen op de problemen.
Blijft natuurlijk gis-werk waarom hun backupscript de problemen veroorzaakt heeft. Maar het klinkt alsof er een chmod/chown is uitgevoerd met een variabele die waarschijnlijk leeg was, en dus werd het commando vanaf de uitvoer directory (/ ?) uitgevoerd.
Vindt dat ze netjes gereageerd hebben, en dat ze relatief veel details hebben prijs gegeven. En voor het gros van de klanten zal dit al teveel technische informatie geweest zijn.
Overigens dat ze praten over kapotte servers zal waarschijnlijk inhouden dat ze (terecht) de installatie niet meer vertrouwden. Die servers zullen wel niet fysiek stuk zijn, maar de installatie is dusdanig corrupt, (rechten incorrect) dat het herstellen ervan potentieel meer werk kost dan opnieuw inrichten.
Ik voel mee met de technische mannen die daar een paar dagen hebben lopen zweten om de boel weer in de lucht te krijgen. Is nooit fijn zo'n outage :sweatdrop:
Vervelend voor Ermis! Hopelijk is alles inmiddels helemaal goed gekomen en weer up and running. Sterkte jongens!
Het is per hoster verschillend of Fallback wel/niet standaard is. Wij hebben de faalback mail servers inderdaad volledig buiten het netwerk staan en updaten nooit de hoofd/fallback servers tegelijk .
DA zal hier zeker niet de oorzaak geweest zijn.
Marin Heideman (DigiState B.V.)
Tijdens de storing kregen klanten eerst een 404 melding, vervolgens kreeg niemand een 404 melding meer. Vlak voor de oplossing van de storing kregen de klanten weer een 404 melding om vervolgens weer online te komen.
Handig zo'n tool om de route te bekijken!
Ook handig voor in de toekomst!
In dat geval, zie mijn eerste post :-)Dan vooral NIET aan beginnen ;-)
Dan zou je een keuze kunnen maken tussen IMAP accounts (regel wel een SMTP server) of Active Sync accounts.Je kunt prima mailaccounts huren waar fallback geregeld is.
Je betaalt een vast bedrag per gebruiker en de werkelijk verbruikte storage waardoor je precies weet hoeveel je verdient en nooit verassingen hebt.
Dat is precies wat we zoeken!
We hebben al wat aanbieder gemaild.
Het gekke is dat wij verschillende reacties krijgen, bij de ene kan het wel, en bij de ander moet je bij hen zelf een hostingpakket afsluiten wanneer je gebruik wilt maken van hun fallback diensten.
Het schijnt dat hun reactie naar alle kanten is gemaild.
We hebben de mail niet ontvangen, maar we hebben hun reactie gelezen op hun site en hier eerder in een aparte bericht geplaatst. Zodat iedereen het kan terug lezen,
We zijn maar een klein bedrijf dus we hebben gewoon een shared hostingpakket.
Dat is ook inderdaad een optie, waar we nog niet aan hebben gedacht.
Dan kan onze ruimte bij Ermis misschien ook naar beneden!
Inderdaad!
Het is inderdaad belangrijk dat de fallback service buiten het netwerk van een webhost geregeld is.
In antwoord op onze vragen bij enkele aanbieders die een fallback aanbieden, wordt het volgende op het hart gedrukt:
"Voor een domein dat wel fallback mailserver record heeft, maar die in hetzelfde netwerk staat als de primaire mailserver. Heeft dus alleen nut, op het moment dat de primaire mailserver uitvalt. Indien er een netwerkstoring is, heeft dat geen enkel nut."
Ook wordt ons gewaarschuwd voor instellingen:
"Belangrijk is wel, dat de eerste MX offline moet zijn; mocht de eerste MX wel bestaan (reageren), maar niet goed zijn geconfigureerd, dan zal de eerste MX email afwijzen. In dat geval komt de email niet bij de tweede MX (en niet bij onze fallback)."
Een ander bedrijf mailt ons:
"De totale werking van het mail verkeer is echter wel afhankelijk van de mail conf. van de huidige mail provider, namelijk:
- Het kan zijn dat de huidige mail server de mail wel accepteert maar niet goed behandeld, doordat de mail wordt geaccepteerd komt die niet in onze fallback servers aan.
- Ook als onze fallback server probeert de mail weer af te leveren en dit wel wordt geaccepteerd door de mail server, maar niet correct behandeld wordt."
Tja, we wilden gisteren een back-up maken van onze webruimte, maar zagen nadat de back-up klaar was een map die we nog nooit eerder hadden gezien. Map heette "non_readable_files". Nadat we dit melden bij Eermis werd ons verteld dat er nog steeds een probleem was met rechten, als uitloop van de storing van afgelopen weekend.
Laatst gewijzigd door matthijs0027; 04/11/15 om 17:53.
Tja, wij weten het ook niet. Misschien moet je dit aan kaarten bij Eermis?
Het verhaal is mooi maar het is wel heel slordig gegaan denken wij achteraf.
Nee, Ermis bied waarschijnlijk geen fallback service aan!
Hebben dit ook al gezien in de DNS, te laat eigenlijk...
Alle e-mails die later na de storing alsnog bezorgd zijn, is "waarschijnlijk" puur op 'retry's' service van de verzenders!
Maar als je als andere klanten bijna tot maandagmiddag/avond offline bent...
Vreemd dat het eigenlijk zo kan! En dat er geen wettelijke regels zijn als het er op komt qua fallback/back-up service!
Zal wel weer niet kosten/techniesch niet mogelijk zijn..