- 13-12-18[Opgelost] Gedeeltelijke onbereikbaarheid BIT van/naar KPN en andere partijen
- 26-11-18Verstoring verbinding Ede-Londen
- 22-11-18Redundantie shared storage NetApp platform
- 06-11-18Storing NetApp cluster
- 29-10-18Temperatuurverhoging BIT-1
- 04-10-18Onverwachte overschakeling loadbalancers
- 28-09-18DDoS gericht op een klant van BIT
- 19-09-18Korte onderbreking internet toegang
- 17-09-18DDoS gericht op een klant van BIT
- 12-09-18Shared storage tijdelijk langzaam
A look in the spice cabinet of BIT
“Any sufficiently advanced technology is indistinguishable from magic.”
- Clarke’s First Law
We use ZFS as ‘backing storage’ for our network backup service. In Linux-land, ZFS is a relatively new filing system with many advantages compared to the old ‘tested’ filing systems that we know, like FAT, EXT4 or XFS.
One of those advantages is the option to make ‘snapshots’. A ‘snapshot’ is a picture. In the filing system world, a snapshot is often a recording of that status of a filing system at a certain moment in time. This way we can ‘go back in time’ in the filing system, like you would when looking at childhood pictures.
ZFS is very efficient when it comes to snapshots. It uses the so-called ‘COW’-principle. COW stands for ‘Copy on Write’. A snapshot that has just been made, does not take up any space. The snapshot will only start to take up space when bytes change in the ‘source volume’ of the snapshot. Before the changed data is saved in the filing system, a copy of that data is put on the snapshot. This does make it a little unclear where the usage of the network backup can be found. Occasionally we get questions about our network backup report, ranging from ‘what is the usage of the system’ to ‘if I delete this snapshot, do I get that amount of bites in free space back’.
It is often hard to give a clear answer to such questions.
With some hands-on examples, we hope to give you some insight in the effect of snapshots on the available ‘quota’ of the hired network backup service.
If you still have some questions despite (or because of) this technical explanation, please feel free to contact us!
By: Sander Smeenk