Omvang van Backup wijkt af van omvang bron

[Zeist]

Ik map min gedeelde mappen op mij nas als een netwerkdrives en gebruik daarvoor network drive manager van suncross

[Robbedoes]

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.

[Zeist]

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

[Zeist]

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?

[Robbedoes]

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.

[Hofstede]

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.

[Zeist]

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

[Birdy]

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).

[Zeist]

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.

[Birdy]

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.

[Zeist]

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.

[Birdy]

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

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  (Blijft een hobby hè ?)

[Zeist]

Idd hobby en nog verslavend ook

[Birdy]

Yep 

[Ben(V)]

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.