Synology-Forum.nl
Overige software => Data replicator & overige backupsoftware => Topic gestart door: Zeist op 19 september 2014, 14:30:37
-
Beste mensen,
Ik heb een breinbreker. Eens kijken of we hier met z’n allen uitkomen.
Ben in het gelukkige bezit van een 2-tal Nas’sen. Beide geheel identiek. Synology 1010+ met elk 5 ook identieke harddisks in JBOD-configuratie. Op beide Nas’sen is 1 volume aangemaakt. Firmware ook het zelfde: DSM 5.0-4493 Update 5
De volumes zijn beide groot 9.146,75 GB
Elke nacht maakt NAS1 (bron) een netwerkbackup naar NAS2 (doel). De volledige NAS1 gaat in de backup. Ik bewaar daarbij ook nog 5 systeemconfiguratiebestanden. Ik draai op de NAS’sen geen app’s. Daarvan hoef ik dus ook geen backup te maken en daarom ook uitgevinkt.
Als ik op de Nas’sen naar opslagbeheer kijk zie ik na een geslaagde backup nu het volgende:
Volume Gebruikt % Vrij
NAS1 9.146,75 7.232,87 80 1.913,88
NAS2 9.146,75 7.187,44 79 1.959,31
Omdat op de doelnas meer wordt weggeschreven dan op de bronnas staat (configuratiebestanden bronnas) zou je verwachten dat de omvang van de backup groter is dan het totaal van de bronbestanden. Dat is dus niet zo.
Integendeel, de backup is 45,43 gb kleiner.
Omdat dit me verbaasde, ben ik vanuit Windows alle gedeelde mappen gaan vergelijken qua omvang, aantal mappen en aantal bestanden. Opvallend is dat Windows 7 mij meldt dat elke gedeelde bronmap even groot is als de overeenkomstige doelmap. M.a.w.: ik heb dus van al mijn bestanden een backup en dat geeft me een veilig gevoel. Ook de reden dus dat ik zonder RAID werk.
Nog een bijkomstigheid: als ik handmatig een tussentijdse backup maak, meldt dsm op de bronnas mij dat ca, 2,7 TB moet worden bewerkt. Dat lijkt dus veel te weinig!! De backup vangt aan en telt naar de 2,7 tb en geeft op enig moment aan dat 99% van de bewerking is voltooid. Dan begint het cijfer van de oorspronkelijk te backuppen omvang op te lopen, waarbij de voltooide omvang constant op 99% blijft staan. Komen we dan op het einde van de backup bij ca 7,2 TB, dan wordt de backup netjes afgerond en als geslaagd gerapporteerd.
Wat is hier aan de hand? Is dit nou een foutje in DSM of zou er iets ernstigers aan de hand kunnen zijn.
Ben nieuwsgierig naar jullie reacties.
Willem (die inmiddels in Putten woont maar zijn oude gebruikersnaam nog heeft)
-
Niet echt op de hoogte van de ins- en outs, maar met het back-uppen van de data (enkel de data zonder DSM zelf) lijkt me dat er op de 1e NAS wel een hele administratieve waslijst wordt bijgehouden door het back-up programma van wat er allemaal wordt geback-upped. Die administratieve waslijst is nodig om bij een volgende back-up, alleen de veranderingen mee te nemen als back-up. (Vandaar mogelijk ook een verschil in omvang als zijnde 2,7 TB te back-uppen data, terwijl de totale back-up data die reeds is geback-upped uit vorige sessie aanzienlijk groter is).
Die hele "waslijst" administratie om dit netjes bij te houden valt zelf niet onder te back-uppen data. Dus NAS1 heeft die data extra erbij ten opzichte van NAS2. Ruim 45 GB verschil op 7,2 Terrabyte zou een reëel verschil kunnen zijn om dat als waslijst bij te kunnen houden (??).
-
Waar ik eerder aan zou denken is zaken zoals de prullenbak. Heb je die op de source NAS de prullenbak aanstaan? Die gebruikt ruimte maar wordt niet meegenomen met de backup.
-
Fff een reactie op de vorenstaande reacties:
De omvang van de administratieve waslijst van ruim 45 gb lijkt mij extreem groot.
Alle prullenbakken zijn leeg en ook uitgeschakeld
Overigens: iemand dan enig idee waar de adm. Waslijst wordt opgeslagen? Ben benieuwd. W
-
Ik weet niet hoe je alles precies hebt ingesteld, maar normaal doet backup een incremental.
Dus de eerste backup is een full backup en de volgende werkt hij alleen de veranderingen bij.
Je kunt in de instellingen kiezen of je alles wilt bewaren, of dat je wat op het orgineel "gedelete" hebt, in de backup ook "gedelete" moet worden. Als je dat niet doet zal de target backupset steeds groter worden dan het orgineel elke keer dat je in het orgineel iets "delete".
-
@Ben(V)
Het probleem is dat de doel NAS minder in gebruik heeft dan de bron NAS.
Omdat op de doelnas meer wordt weggeschreven dan op de bronnas staat (configuratiebestanden bronnas) zou je verwachten dat de omvang van de backup groter is dan het totaal van de bronbestanden. Dat is dus niet zo.
-
Ik heb alleen een full backup. Dus dat wat op de bronader is verwijderd wordt ook op de Dorland
-
Sorry, te snel verzonden. Ik heb alleen een full backup. Dus hetgeen op de bronnas is verwijderd wordt ook verwijderd op de Doelnas.
-
Dus dat wat op de bronader is verwijderd wordt ook op de Dorland
Zeker auto correctie aan :lol:
-
Ja op zo'n krakkemikkige iPad
-
Sorry niet goed gelezen. :x
Heb je misschien compressie aangezet voor je backup set?
-
Nee geen compressie. Gewoon 1:1. De bestanden in mijn backup kan ik net zo benaderen als die op mijn bronnas. Ik "map" daartoe de gedeelde mappen als een netwerkschijf in MS Windows en zie geen verschil met mijn "normale" bestandsbewerkingen vanaf de bronnas.
-
Probeer winmerge eens.
Die kan hele directories inclusief subdirectories vergelijken.
Kun je zien of er echt geen verschillen zijn en als ze er wel zijn waar.
http://winmerge.org
-
Winmerge ken ik niet maar keek even op internet. Lijkt een heel zinvolle tip mits winmerge ook werkt op "getapte" netwerkdrives
-
Geloof wel dat hij dat ook met een netwerkshare kan.
Als hetniet gaat dan kun je altijd nog even een driveletter mappen.
Dan gaat et zeker.
-
Ik map min gedeelde mappen op mij nas als een netwerkdrives en gebruik daarvoor network drive manager van suncross
-
Overigens: iemand dan enig idee waar de adm. Waslijst wordt opgeslagen? Ben benieuwd. W
Volgens mij heb je hier nog geen antwoord op gekregen.
In mijn beleving staan die op je doel NAS, daar zitten extra mappen in voor de administratie.
Niet dat veel impact op het volume heeft.
Overigens controleert de taal wat er nog ge-update moet worden aan de hand van die data in @app met name de submap @metadata.
Als je durft dan kun je die map @app hernoemen en ook de 2 bestandjes in de root van de share en dan je taak opnieuw openen en doorlopen zodat er een nieuwe database aangemaakt wordt.
Risico is wel dat hij wel alles weer gaat updaten.
-
Het is niet eens zo zeer een kwestie van durf, maar een volledige backup van ruim 7TB is een langdurige bezigheid. Tijdens die tijd voel ik me niet zo zeker van mijn bronbestanden. Hoewel, gedurende alle jaren dat ik al Syno's heb (ooit begonnen met 2 207's) heb ik mijn backup nog nooit nodig gehad.
Maar ik zei al, dit is een breinbreker en inderdaad het antwoord heb ik nog niet
-
Vanochtend in alle vroegte met behulp van Winmerge mijn bron en backupbestanden vergeleken. Goed nieuws! Winmerge vond geen verschillen. Daarmee is mijn vraagstelling overigens nog niet opgelost. Waarom melden mijn nassen verschil in omvang van bron- en doelvolume?
-
Mooi dat je data in orde is.
Als je verder naar de 45,43 GB wilt zoeken kun je dat op ook via SSH op de onderliggende Linux mappen zoeken.
Misschien heb je ooit CloudStation of een ander pakkage eens op je bron NAS geprobeerd en is daar wat van achter gebleven.
-
Cloudstation kan hier ook de oorzaak van zijn.
Anders via SSH inloggen en dan naar de inhoud van volume1 kijken. Mogelijk staat er nog een verborgen map.
-
IK heb op mijn Nassen nog nooit Packages gebruikt. Ik zou niet eens weten wat Cloudstation doet.
SSH ken ik ook niet, maar ik zal hier ter lering ende vermaak eens induiken. Kom ik iets tegen dan houd ik jullie op de hoogte
-
SSH ken ik ook niet, maar ik zal hier ter lering ende vermaak eens induiken.
WinSCP (GUI browser):
1 - Zorg ervoor dat SSH-Service aan staat: Configuratiescherm > Terminal.
2 - Download: http://winscp.net/eng/download.php
3 - Installeer WinSCP
4 - Start WinSCP klik op nieuw
5 - Bestandsprotocol: SCP
6 - Adres doelcomputer: <NAS-IP>
7 - Poortnummer: 22
8 - Gebruikersnaam: root
9 - Opslaan
10 - Inloggen (Password van je admin)
PuTTY (CLI, enige Linux kennis vereist):
1 - Zorg ervoor dat SSH-Service aan staat: Configuratiescherm > Terminal.
2 - Download putty.exe
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
3 - Start putty.exe
4 - Geef je IP-adres van je NAS op
5 - Zorg dat SSH aangeklikt is
6 - Save....geef een naam in "Saved Sessions"
7 - Klik op Open
8 - Je krijgt Putty scherm met "login as:"
9 - Geef in: root <enter>
10 - password: <Admin password> <enter> (PS: je ziet de cursor niet verplaatsen).
-
Kijk, dit vind ik van Birdy nou een prima reactie. Hier kan ik iets van leren. Hulde. Zodra ik meer weet horen jullie weer van mij.
-
Ik heb natuurlijk niet dezelfde configuratie: 2 gelijke NASsen dus ik heb een test gedaan op map nivo.
Kwam tot de volgende ontdekking:
Om te beginnen, op de DOEL NAS wordt ALLEEN op volume1 (dus niet ergens in de root) extra data weggeschreven:
8 DS111_1/@app/@metadata/1
12 DS111_1/@app/@metadata
36 DS111_1/@app <<<<<<<<<<<<<<<Totaal in kilobytes dus, te verwaarlozen.
Als ik kijk in de mappen zelf:
BRON te backuppen Map DS111: 1427704 kilobytes
DOEL backup Map DS411: 1360672 kilobytes
Hier zie ik dus ook dat de Backup Map kleiner is n.l. 67032 kilobytes = 4.92639 %
Echter, als ik kijk in de backup map dan zie ik geen verschil in de file groottes waarvan de backup is gemaakt.
Die conclusie had jij ook.
Waarom dan dat verschil ?
Misschien dat de verklaring te zoeken is in het feit dat de backup data efficiënter weg wordt geschreven, dus de blokken waarin geschreven worden, worden volledig benut t.o.v. de BRON ?
Om dat te bewijzen vergt meer onderzoek.
Het belangrijkste is dat je backup data overeen komt met de BRON.
-
Birdy, dank voor je extra onderzoek. Mijn backup vertrouw ik volledig. Geen zorg daaromtrent. Ik vroeg me alleen af waar het verschil in omvang vandaan zou kunnen komen. Je gedachte dat de backup efficiënter wordt weggeschreven dan op de bronschijf vind ik een interessante gedachtengang. Het zou i.d.d. Best kunnen dat de blokken op de harddisk beter worden benut. Ik heb te weinig verstand van Linux en hun diskgebruik. Onder Windows ben ik geneigd te zeggen dat de kans groot is dat dit de oorzaak is. Wat nu dan weer bij me opkomt dat ik onder Linux nog nooit een defragmenteringsoptie heb gezien. Onder Windows kom je dat wel vaak tegen.
-
Heb me nooit bezig gehouden met het hoe Linux opslag werkt echter, wel dit gevonden:
Linux’s ext2, ext3, and ext4 file systems – ext4 being the file system used by Ubuntu and most other current Linux distributions – allocates files in a more intelligent way.
Instead of placing multiple files near each other on the hard disk, Linux file systems scatter different files all over the disk, leaving a large amount of free space between them.
When a file is edited and needs to grow, there’s usually plenty of free space for the file to grow into.
If fragmentation does occur, the file system will attempt to move the files around to reduce fragmentation in normal use, without the need for a defragmentation utility.
BRON (http://www.howtogeek.com/115229/htg-explains-why-linux-doesnt-need-defragmenting/)
Wat mij opvalt is wat ik in bold heb aangegeven.
Misschien dat "leaving a large amount of free space between them" een standaard optie is (verwacht ik) die tijdens de backup kan worden uitgezet.
Dat zou een verklaring zijn maar, ook daar, zou ik mij verder in moeten verdiepen ;D (Blijft een hobby hè ?)
-
Idd hobby en nog verslavend ook
-
Yep :lol:
-
Linux file systems scatter different files all over the disk, leaving a large amount of free space between them.
Dit is uiteraard correct maar dit zie je niet aan de buitenkant van het fielsystem. Die ruimte die hij openlaat wordt gewoon als vrij ruimte gerapporteerd.
Wat er waarschijnlijk aan de hand is, is dat de housekeeping van de files in de backupset veel efficienter door het filesystem gedaan wordt dan de gegroeide situatie van het orgineel. Daar zijn veel blokken "verspilt" omdat file's groter of kleiner werden, directories extend moesten worden etc.
Bij een backup is de afmeting van met name een directory file al bekend dus die worden niet meer extend en ook de bestanden zelf niet meer.
Als je het orgineel zou deleten en de backup terug zou zetten zou je hetzelfde effect krijgen.
Sterker nog als je alles wat in die backup gewoon naar een andere plek op dezelfde schijf zou copieren wordt hij ook kleiner.
Overigens ben je die winst zo weer kwijt als binnen die directories weer gaat werken en daar weer files bijplaatst, want dan wordt die dat moment zeer efficiente "houskeeping" weer verstoort.
-
in dos had ik altijd een defragmentatie programaatjes, zou dat bestaan of zin hebben in Linux?
-
Op de Mac heeft dat met OSX 10 in elk geval geen zin meer. Daar zit het ingebouwd in het OS (http://macs.about.com/od/faq1/f/defrag.htm). En sinds OSX 10 is het OS op Unix gebaseerd. :D
-
De enige reden voor defragmenteren was snelheidswinst. Iets wat tegenwoordig helemaal niet meer relevant is met de snelheid van de moderne schijven. Bij SSD's is defragmentatie zelfs uit den boze. Daar is het af en toe uitvoeren van de trim functie voldoende.
-
Defragmenteren had eigenlijk alleen bij fat geformateerde schijfen zin.
Het werd voornamelijk vanwege performance redenen gedaan. Je kreeg er niet meer ruimte van.
Bij de ext serie filesystemen is er geen performance voordeel te halen, wel een klein ruimte voordeel. De ontwerpers hebben het een voor het ander ingeruild.
Met de huidige diskcapaciteiten is een beetje ruimte verspilling ten opzichte van stabiele performance volgens mij een goede afweging.
Ik ken ook geen defragmentatie programma's voor ext en al zouden die er zijn weegt dat beetje extra diskruimte niet op tegende extra vlieguren die de schijfkoppen moeten maken (= extra slijtage).
Edit: Hofstede was me te snel af. :lol:
-
:)
-
Op de Mac heeft dat met OSX 10 in elk geval geen zin meer. Daar zit het ingebouwd in het OS (http://macs.about.com/od/faq1/f/defrag.htm). En sinds OSX 10 is het OS op Unix gebaseerd. :D
Impliceert dat het voor 10.2 wel nodig was terwijl die ook gebaseerd op Unix waren toch? Anyway, het is me duidelijk, FAT heeft dat wel nodig en Linux-familie niet. Gelukkig maar... Ik zie me nog zitten vorige eeuw, met PcTools en die oranje blokjes met kruisjes en bolletjes erin...
-
Ach je kon de tijd toch doden met je ping pong spel op de tv ;D
-
Bij grote schijven is het voor FAT ook niet meer aan te bevelen.
Onderzoek heeft uitgewezen dat de gemiddelde leestijd ophoog gaat als alles bij elkaar gezet wordt. De onderlinge afstanden en daarmee de zoektijden worden dan gemiddeld iets hoger dan dat het willekeurig op de schijf staat.
En tegenwoordig met de SSD's moet je het al helemaal niet meer doen.
-
Wat mij betreft nu tijd om dit draadje af te sluiten. Ik houd het erop dat de backup kleiner is dan de bron omdat in de backup de schijfruimte efficiënter wordt gebruikt. Iedereen bedankt voor de antwoorden en het meedenken. Vriendelijke groet, Willem