YANASBOPI - Yet Another NAS Built On PI

PIC, AVR, Arduino, Raspberry Pi, Basic Stamp, PLC mm.
Pen
Inlägg: 207
Blev medlem: 16 september 2006, 09:15:51
Ort: Stockholm

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av Pen »

säter skrev:Varför skriver du rubriken på engelska?
He, he - ja det brukar jag aldrig göra annars faktiskt. Det var just att prefixet "YA-" är allmänt vedertaget till skillnad från "ÄE-". I övrigt håller jag med om att det är dumt att skriva rubriken på engelska :wink:

Andemeningen med YA är att det redan finns många beskrivningar på NAS byggda på PI och att jag i detta fall försöker parera en del av de problem som det likaledes finns rätt många beskrivningar av.
Mindmapper
Inlägg: 6389
Blev medlem: 31 augusti 2006, 16:42:43
Ort: Jamtland

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av Mindmapper »

arvidb skrev:Jag har haft en server gåendes i omkring tio år nu, baserad på ett fläktlöst Mini-ITX-kort (enkärnig Via C7-processor på ~1 GHz, 1 GiB RAM). Lagring består av en vanlig HDD med ext4-filsystem. Ingen RAID, LVM eller så. Ingen UPS.

Den har havererat två gånger under de här åren, båda gångerna på grund av trasiga nätdelar. Nätdelen i denna dator består av ett 12 V-aggregat (av denna typ) och ett litet kretskort med 12 V in och ATX-kraftkablar ut. Båda gångerna har det varit 12 V-aggregaten som har havererat (först det som följde med datorn och sedan ersättaren från Kjell & Co).

Jag tröttnade på dessa aggregat och köpte ett MeanWell RSP-100-12 istället och byggde in i en aluminiumlåda. Än så länge har det tickat på utan problem...

TL;DR: Jag delar din bedömning att nätdelen är den största källan till nertid. Däremot har jag aldrig råkat ut för dataförlust trots problemen med nätdelarna plus säkert några tiotal strömavbrott.
De du har haft är väl inga 24/7 nätdelar. Undra vad som dödat dom? 100 - 240V är inspänningsområdet. Ligger man nära transformatorstationen, kanske man ligger över 230V. Lite transienter på det och lite insparande av transientskydd i nätdelen så är det kanske inte konstigt om de går "bye west".

Nätdel med bra transientskydd samt lite yttre skydd innan nätdelen skulle jag vilja ha. Speciellt om man bor i ett område som inte har så styft elnät.
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av xxargs »

Pen skrev:
xxargs skrev: Som filsystem för lagringsdisk så skulle jag överväga BTRFS - förutom att både data och metadata är checksummat så är den enormt flexibelt i att kunna öka och minska filystem på diskar, skarva i en disk till om platsen tryter, lätt att ta bort igen om det blir gott om plats igen välja olika raid-moder och kan konvererteras online medans systemet används.
BTRFS är säkert väldigt tillförlitligt som du säger, men jag tog in en annan aspekt som vägde tyngre (jag har inte heller något expanderbart system i åtanke - det är mera en boxtanke). Om något går permanent sönder så vill jag snabbt få till en "limpmode" (baserat på erfarenhet). Det jag tänker mig då är att om t.ex. RPi själv går sönder så ska jag kunna plugga in den externa hårddisken någon annanstans. Som jag ser det har jag tre val:

1. Jag har en ersättnings RPi liggandes (ingen limpmode egentligen)
2. Jag pluggar in disken i den laptop som för tillfället behöver åtkomst
3. Jag pluggar in disken i någon annan burk som kan hantera den - i mitt fall min Linksys router

I fall 1 går det att välja godtyckligt filsystem, i fall 2 är NTFS att föredra, i fall 3 är det ext3 eller NTFS som gäller. Det finns visserligen drivrutiner för ext3 till Windows men de verkar inte vara att lita på (och de kommer inte att vara installerade på alla laptops i familjen). Omvändningen (NTFS på Linux) verkar vara betydligt säkrare men någonting bär mig emot. Så jag lutar mot alternativ 3 och ext3 men är osäker.

Följdfrågor:

Vad är nackdelen med NTFS på Linux? Finns mycket om detta på nätet men det besudlas av religiösa inställningar så jag får inget grepp om det. Både NTFS och ext3 är journalfilsystem.

Klarar RPi prestandamässigt BTRFS? Jag har väl inte helt uteslutit alternativ 1. Om jag bygger backup noden på samma sätt så går det ju att "låna" delar av den i nödfall (istället för att ha reservdelar i skrivbordslådan).

Jag som är analog-guy i grunden får rysning är det är mer än enstaka mV i HF-rippel - 50 till 250 mV anser jag inte är OK, likaså den usla lastregleringen.

Det är sådant som kan döda SD-brickor

---

När det gäller filsystem så kan du stoppa nästan vad fasen som helst i en linuxhink med tex ubuntu, udev där kommer att identifiera och montera en BTRFS lika säkert som någon av ext-filsystemen liksom NTFS då det är en del av kärnan numera.

skall du göra diskrecovery så gör det inte i en windows-burk - utan du gör det i en Linux-burk!! (även så startad på USB-sticka eller en live-CD)

NTFS på RPi - nej skulle jag vilja säga - med tanke på hur mycket CPU som dricks när man skall köra mot en NTFS-image även på vanlig linuxdator så skulle jag nog tänka mig något annat.

Sedan är NTFS ömtålig på ett par 4K-kluster [första 4KB av $MFT och hela $MFT_mirr överskriven med slump] och som jag har synnerligen dålig erfarenhet av i samband med externa hårddiskar av WD-book modell där man av dess USB-chip i vissa situationer får båda sönderskrivna samtidigt i ett enda moment i samband med stängning av filsystemet och man får en disk vars innehåll är i stort sett ej räddningsbar ens med kommersiella diskräddningsprogram utan det är bara datacraping kvar utan att veta om filkroppen är komplett eller sönderhackad med andra skrivningar för att filerna var fragmenterade och räddningsprogrammet försökte att läsa sekvensiellt...


Vill du inte experimentera - kör ext4, är du mer villiga att prova - prova BTRFS - när du väl provat att göra snapshot innan tex. en uppdatering av en backup från någon annan datorn som gör backup över nätverket - så vill du inte ha något annat i fortsättningen...

dock en sak som drar ned användandet av RPI3 som NAS är den begränsade hastigheten på dess USB2, som den också delar med nätverkstrafiken och det kommer inte att gå fort att fylla TB-stora diskar via nätverket - i så fall förfyll diskarna med annan Linux-hink om det handlar om mediabibliotek/foton och sedan koppla in RPI för till största delen bara läsning - räkna inte med mycket över 10 MB/s i överföringshastighet från disk till nätverk...

om RPI:s SoIC kunde köra med 1 GBIT internt så hade mycket varit förlåtet, men nu är den smala kanalen som USB2 ger en rejäl handikap för RPI:s totala prestanda om man skall ha den för filskyfflande
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av lillahuset »

Som jag ser det så är RPis flaskhals att man har en USB2 och en "switch" för nätverk och (om jag minns rätt) USB det tråkigaste med den. Annars tycker jag den är utmärkt trevlig.

BTRFS, du brukar propagera för det, kan du göra en kort sammanfattning med argument för och emot i "hemmamiljö" dvs några linuxservrar och några linuxburkar och blygsamma krav när det gäller lagringskapacitet och flexibilitet?
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av xxargs »

Det som kallas 'moderna filsystem' är nog det som går under begreppet BTRFS och ZFS, även ReFS som MS hastigt slängde ihop men idag verkar gömmas allt längre in i garderoben och finns snart bara på enterprise-versionerna av Windows...

ZFS är inget för småmaskiner som RPI (även om det finns dem som försökt) då den vill ha en stor footprint i form av RAM-minne redan som start. Det är en filsystem-plattform för större servrar med ECC-RAM, cache/journal-diskar och förstås sina lagringsdiskar. Jag har jobbat för lite med dom för att egentligen ha en åsikt över dem.

BTRFS är för små till medelstorlek på servrar.

finesser:

Checksummande både på data och metadata, det gör att den kan lösa inkonsistensproblem även när det är konflikter mellan 2 RAID1-halvor när uppdateringen inte blev exakt lika pga. tex strömavbrott mitt i skrivandet. - detta kan inte en MDADM-RAID lösa om man inte slår på relativt nyinförda journaler (?) (och oftast inte är påslagen i en standardinstallation)

Det är COW-filsystem vilket innebär att allt som skrivs är alltid på nya sektorer - de gamla är kvar tills sista referensen är borta och så småningom återanvänds.

snapshot (görs alltid på en subvolym ej på root-filsystem)

tex 'btrfs su snap volym1 volym1_snap'

går på max 2 sekunder även om subvolymen är flera TB stor.

Subbvolymen blir som en helt egen entitet och har inget med filerna som det nyss gjordes kopia ifrån utan kan modifieras, raderas fritt utan att det påverkar orginalfilerna som det nyss gjordes kopia på, det är alltså inte 'hardlink' utan har egna inoder - det enda gemensam är att inoderna pekar till samma datablock som orginal-subvolymen - med COW-filsystem så kommer alla ändringar att peka på nya sektorer och aldrig ändra de gamla sektorerna (som tex fortfarande refereras i orginal sub-volymen)


Man kan slå på kompression av filsystem/direktory träd i en subvolym och alla nya filer och nya direktorys som skapas där, komprimeras

subvolymerna kan göra readonly - dvs. kan inte ändras av filhanteringsoperationer av OS
(dock går det att slå på och av med flaggor i 'chattr', precis som kompression)

Det är en av styrkorna om man gör regelbunden snapshot i RO av ett direktory och som är åtkommliga mha. samba och är då skyddad mot modifiering om en av klientdatorerna är infekterad av en ransomware-virus och krypterar allt den ser i filväg.

Det finns en 'scrub' och rättar givetvis hittade fel om det finns redudans för aktuella påverkade filer (läs minst RAID1) även balance rättar om den hittar felaktigheter i RAID-system med redundans, men arbetar då i chunknivå.

Man kan exportera en subvolym seriellt till annan media och återuppbygga denna exakt på en annan BTRFS-disk på någon annan dator (samma som ZFS kan, ja, funktionen är faktiskt snodd rätt av från ZFS) kan också göra diffar mellan två subdir mellan olika btrfs-filsystem och skicka diffar mellan dem för att synka upp

---

Diskhantering:

BTRFS verkat vara synnerligen tålig mot 'taskig hantering' av filsystem i form av glappa USB-kablar, rycka ur strömvårtan till externa disken mitt under full skrivning och andra fulheter man kan göra under praktiskt handhavande. Jag har inte råkat ut för filförluster ännu eller oläsbar filsystem. Det kan dock ta lite tid att montera en sådan disk om det är väldigt många subvolymer och ev. oren stopp av filsystemet ovanpå alltihop - men bli inte nervös utan ge den tiden som behövs för att slutföra monteringen och du kommer åt innehållet.

Om btrfs-filsystemet börja bli full, enkelt, anslut en disk till - identifiera denna nya disk med lsblk

därefter

"btrfs dev add /dev/sdx /mnt" (sdx är device för den nya disken, 'mnt' är där man har btrfs-filsystemet monterat), skrammel i HD, 2 sekunder senare är det klart och man kan mata på med mer data.

Vill man jämna ut fyllnaden mellan diskarna så kan man köra 'balance'. Balance utan argument flyttar på all data i filsystemet till ny plats och är en väg att fräscha upp samtliga sektorer med data på en (eller flera kopplade i jbod/RAIDx) (snurr)diskar som hållit data lång tid och man vill säkra sig att alla sektorer med data blir omskrivna och kontrollerade - obs. Detta tar lång tid och proceduren tar inte bort gammal läsbar data på gamla platsen innan den försäkrat sig att nyskriven data är läsbar. vilket också gör processen tålig för strömavbrott och annat bus under processen.

Om man behöver frigöra en disk - se dock till att det finns tillräcklig plats på disk(arna) som är kvar.

"btrfs dev del /dev/sdx /mnt" ; nu kommer den att flytta chunks efter chunks från disken som skall frigöras till disk(arna) som är kvar. Detta kan ta en del tid och låt det göra jobbet färdigt.


Byte av RAID-nivå, minst två diskar i filsystemet monterat

"btrfs balance start -dconvert=raid1 -mconvert=raid1 -sconvert=raid1 /mnt"

gör om diskarnas innehåll till RAID1-version, både metadata, data och system.

med detta garanteras att varje fil finns i 2 exemplar på 2 olika fysiska diskar, likaså dess metadata.

Man kan ha udda antal diskar (3 st tex.) och olika storlekar och BTRFS fyller dem efter bästa förmåga så att varje fil alltid finns på 2 av fysiska diskarna och man tål _1_ diskbortfall (även om RAID1 skulle består av 5 diskar) - det är lite annorlunda än traditionell MDADM RAID som är sektorspeglande.

Med detta slipper man en tidsödande sektorspeglande av tomdata och behöver bara hantera datat som är lagrad på diskarna - inte dess lediga utrymme - man kan också plocka in fler diskar likväl ta bort diskar om tillräcklig plats finnes.

Att göra RAID5 eller 6 är bara andra argument i 'balance och under en tidperiod så är det blandad RAID-nivå på diskarna tills 'balance' har gjort jobbet färdigt.

Man kan också göra 'dup' med 2 exemplar av samma fil på en enda fysik disk och den vägen har redundans (redundans för sektorfel men ej för komplett diskkrasch)

Det var tänkt att man skulle kunna sätta individuell RAID-nivå på varje fil om man så önskade, infrastrukturen för detta finns redan på plats men är inte implementerar i några kommandon (i balance gissar jag) för att kunna sätta Raid-nivå individuellt för filerna

---

Det finns givetvis nackdelar med BTRFS, största problemet är att utvecklingen är underfinansierad efter att novell fått sitt RAID1 att fungera i BTRFS och drog undan resurser och det är för få som jobbar med betalning för att få till de andra RAID-moderna att bli bra.

Det är inte den snabbaste filsystemet som finns - COW har ett pris. Om man jämför mellan BTRFS och ZFS då är det bra på olika saker och dåliga på andra saker i avseende prestanda. ZFS behöver större footprint avseende RAM-mängd i jämförelse med BRTFS för ungefär samma prestanda i små system medans ZFS förmodligen skalar bättre än BTRFS i stora system med gott om RAM.

Är snabbhet viktigt så är varken ZFS eller BTRFS förstahandsvalet - utan kanske hellre XFS eller EXT4...

Filsystemet fragmenterar sig till sin natur i och med att det är en COW-system och det finns defrag-verktyg för det, dock inte subvolym-medveten (är inte färdigt, man körde det ett kort tag men hade för mycket buggar) - det gör att om man kör defrag på en disk med flertal subvolymer så kommer gemensam data att dela sig till egna exemplar och diskförbrukningen kan explodera - nej, det är inte bra men så är läget idag.

Det finns fristående körande dedupliceringsprogram som också utför defragmentering och möjlig att köra deduplicering över flera subvolymer samtidigt - de kan vara bättre i dessa fall.

somliga program som rmlint kan köra 'reflink' för att koppla ihop olika filer med samma innehåll så att olika filer pekar med sina inoder till sektormässigt samma datamängd på disken - denna funktion är inbyggd i linux-kärnan i att jämföra sektorer mellan olika filer och verifiera att block inom filerna är exakt lika innan inoderna ändras till att peka på samma block och frigör kopiorna som ledigt utrymme.

Är det någonting som kan skotta fram plats på en disk så är det deduplicering - det är mycket mer 'värt' än att tex köra komprimering på disk, som med dagens hashade temporärfiler, skyddad content (tex spotify) och mediafiler knappt ger någon komprimering alls. deduplicering är inte alls i samma klass som tex. i ZFS utag görs idag med fristående program som får snurra och göra reflink på filnivå om det är samma innehåll och somliga kan också göra det på blocknivå.

RAID5 och 6 lider av 'write hole' ännu om man skulle få strömavbrott mitt under skrivning _och_ en diskhaveri samtidigt (det är faktiskt många andra RAID-system som har samma problem i samma situation - men där är det inte rödflaggat för på samma sätt som i BTRFS...)

'balance' är en funktion som ZFS egentligen skulle behöva i någon form då det skulle göra diskhanteringen avsevärt flexiblare och tex. att kunna Byta RAID-nivå om man vill. ZFS är system där man skall bestämma sig redan från början hur upplägget skall se ut - väl satt så är det omständligt att ändra, medans BTRFS är hur formbar som helst i antal diskar, vilka RAID-moder och växla mellan dem etc. efter behov.


Slutligen, BTRFS gillar verkligen diskar med mycket lokal RAM i diskdriven och därför kan skjuta in anständigt lång kö av kommandon och hanteras mha. diskens NCQ som sedan sorteras i rätt ordning av diskkontrollern själv - har alltid kört mot stora diskar som 6-8TB diskar med 128 - 256 MB intern RAM i kontrollern och när jag provade på en 'liten en' som WD2TB-green med 32 MB RAM så blev jag helt shockad.

Det som förut gick med en liten blink mot diskarna - var plötligt en kö av kommandon i många tusental som tog evig tid att beta av i en takt som påminde väldigt starkt om varvtalet på skivorna på WD-Green-disken (titta med atop för detaljer) - man märkte inte så mycket av det när man fyllde på disken med data - men skulle man konvertera mha 'balance' så fick man i resultat som hårdfusen sirap då disken bara stod och tuggade och uppenbart skrev inte fortare än en sektor per varv...

Om detta är ett problem som i grunden finns i BTRFS och den skrivordningen som OS:t skicka sektorerna vidare till disk eller om det var driver-beroende så vet jag inte - men om man märker att det är skitsegt så kan man fundera på ovanstående stycke och att diskbufferstorlek verkar vara viktig för prestandan i somliga fall. i sådana fall så kanske man med smartctrl eller hdpar prova med att slå på write cachen på disken och se om det blir bättre... (men också mer ömtålig mot skador om man får strömavbrott under skrivning, inte för att jag tror det gör så mycket för just BTRFS eftersom den jobbar som mot en databas med en commit med jämna mellanrum och har det skitigt sig så kan den backa till den föregående att utgå ifrån.)
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av lillahuset »

Intressant, tack!
tgr
Inlägg: 725
Blev medlem: 10 maj 2006, 09:17:07
Ort: Mölndal

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av tgr »

Du har inte funderat på något med USB3? T.ex. http://rockpi.org
Användarvisningsbild
arvidb
Inlägg: 4537
Blev medlem: 8 maj 2004, 12:56:24
Ort: Stockholm

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av arvidb »

Tack xxargs för den intressanta jämförelsen mellan ZFS och Btrfs!
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av lillahuset »

tgr: Den kände jag inte till men den verkar intressant.
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av xxargs »

Kan inte säga att jag jämfört med zfs - har kört för lite med det för att ha åsikt om det.

Tänkte titta lite på det med FreeNas på en större maskin med mycket RAM och se hur det fungerar

Det jag har läst och tolkat hittills så vill man har säker lagring (men lite stel i flexiblitet och kräver viss planering redan från början) och har lite maskin och RAM så kör man ZFS, för mer flexibelt och kan tulla en smula tryggheten BTRFS och den behöver heller inte lika mycket maskin och minne för att fungera.

Har kört btrfs som lagringssystem på backuppdiskar (även multivolym) i nu 4 år och det har inte krångla med ej accessbarhet eller tappat filer hittills i användarsituationer som jag inte är helt säker på att NTFS eller ext4 skulle ha klarat sig helskinnad ifrån (glappa USB-ledningar, strömfrånslag mitt under full skrivning mm.). har även börjat köra 'osäker' RAID5 i en NAS sedan över halvår tillbaka och det har inte 'gått sönder' hittills och då har jag ändå stresstat med att skriva över en av diskarna med 'dd' under full användning med den ganska 'ointressanta' resultatet att den reparerar sig löpande allt eftersom den upptäcker inkonsekvens och med en 'scrub' så gås allt igenom och efteråt är det som inget alls har hänt. skillnaden mellan en mdadm-RAID och det här är att det bara bry sig om data som är skrivet - inte ledig utrymme medans mdadm-RAID måste gå igenom samtliga volymers sektorer vid en check vare sig det valid data eller inte.

Hur eller hur när man börja köra dom filsystemen med dom finesser som de erbjuder så är det motigt att gå tillbaka till mer traditionella 'gamla' filsystem som NTFS, ext3-4 och även XFS med en äldre syn på hur det skall lösas.
Användarvisningsbild
arvidb
Inlägg: 4537
Blev medlem: 8 maj 2004, 12:56:24
Ort: Stockholm

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av arvidb »

xxargs sa: "Det jag har läst och tolkat hittills så vill man har säker lagring (men lite stel i flexiblitet och kräver viss planering redan från början) och har lite maskin och RAM så kör man ZFS, för mer flexibelt och kan tulla en smula tryggheten BTRFS och den behöver heller inte lika mycket maskin och minne för att fungera."


Du menar mycket maskin och RAM va? :humm:
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av xxargs »

givetvis - kanske en underdrift som inte gick fram riktigt i text...
Användarvisningsbild
arvidb
Inlägg: 4537
Blev medlem: 8 maj 2004, 12:56:24
Ort: Stockholm

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av arvidb »

Ja det var en aning tvetydigt. :)
Pen
Inlägg: 207
Blev medlem: 16 september 2006, 09:15:51
Ort: Stockholm

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av Pen »

Efter denna utmärkta utläggning om det lokala filsystemet, skulle jag gärna få en liknande diskussion på helheten.

Mina filer kommer (om vi bortser från backup) huvudsakligen (eller kanske uteslutande*) accessas från fjärrklienter via SMB/Samba. Jag kommer inte att ha UPS på vare sig ethernetswitchar eller accesspunkter, men man kan väl anta att de flesta klienter normalt har ett batteri. Givet ett väldigt bra lokalt filsystem, hur bra blir då det totala systemet med avseende på nätbortfall? Och följdfrågan: Är det fortfarande signifikant bättre med ett lokalt superbt filsystem?

* Detta till skillnad från min nuvarande servercentrerade setup med delad NAS/Server där data accessas på alla möjliga vis (t.ex. samallokerade mediakonverterare/DLNA som UMS och Serviio).
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: YANASBOPI - Yet Another NAS Built On PI

Inlägg av xxargs »

Tja om ethernetswitchar går ner så spelar det ingen roll att NAS och/eller har god strömförsörjning - sådant måste säkras hela vägen och så kan man tjöta om kedjan och svagaste länken.

Men med SMB-server och vars inkopplade klient försvinner pga. Ethernet försvinner någonstans i kedjan ställer inte till alls samma skador - eller snarare risk för skador i filsystem som om man rycker strömmen till NAS själv medan den skriver filer.

Visst - filen som klientprogrammet arbetade på just när avbrottet sker - är förmodligen bara att slänga, samma saker med klienter som gräver direkt i databasfiler i servern (tänk liknande sqlite) och inte anropar via databasmotor lokalt på servern (som också lagrar databasfilerna) så är det inte säkert att det alltid går att göra check/reparationer som lyckas alla gånger...
Skriv svar