RegistrarTrek<p><strong>Let’s Talk About Data Security – Backups</strong></p><p>As collections professionals we are trained to think about security. We constantly make sure that nothing gets damaged and lost, may it be in our own storage or while on loan, perhaps traveling from continent to continent for a new exhibition. But when it comes to data security we often rely on our IT departments and database managers. In a changing world we need to add data security to our registrar’s toolkit because if we don’t care about it, perhaps no one will be left to care about it. So, I am planning on writing a series of short articles on that topic.</p><p>Now, I am not an IT expert by any means. I am basically pulling together what I have learned over the years, drawing from resources I have at hand, ready to stand corrected and update you if something I wrote could be done better, easier, and/or more secure. I am thinking in this day and age, any guidance and ideas on how to safeguard our intellectual heritage is better than doing nothing at all. Feel free to contribute with your own sources and ideas.</p><p>I am starting with what I feel most comfortable writing about: Backups.</p><p><strong><strong>How often should I back up my database?</strong></strong></p><p>This is a risk analysis: How serious will losing all your data since you backed up the last time be? In some cases, once a week can be sufficient if you are the only person who works with it, you have all your changes tracked in another medium (for example written notes on paper), and you don’t enter more than just a few records a day. But if multiple people enter and change data during the day? Well, once a day seems highly recommendable, then.</p><p><strong><strong>What is the difference between full backup and differential backup?</strong></strong></p><p>A full backup stores ALL data of your database. A differential backup only records the changes to the last time you did a full backup. Which one to use when is about analyzing the risks associated with it. A database can get compromised without you noticing right away. In this case it is good if you can revert back to a full backup of an earlier stage, before it became corrupted and then try to extract the data that was added at a later stage from the other backups.</p><p><strong><strong>What backup method should I choose and how many backups shall I retain?</strong></strong></p><p>There are no hard rules and usually it is best to talk to experienced users of the same collections management system and to the vendor about what makes sense in your use case.</p><p>My rule of thumb: If I know I am entering more than ten records each day and do a lot of updating of other records, I will go with a differential backup every day and a full backup once a week. I will keep the backup of the last three days and a full backup from each of the previous four weeks.</p><p>But this is tailored for the case where only I enter data and nobody else. If you have a lot of people entering data there are more options of something going wrong, therefore you will want to do backups more often. This is of course also a question of how much storage space you can afford, but then again, you have to factor in the costs of losing data and the hours it takes to re-enter it. Do a proper risk analysis for your institution, then set up a fitting backup routine.</p><p><strong><strong>Where shall I store my backup?</strong></strong></p><p>Storing your database backup on the same computer you took it is as good as having not stored it at all! When your computer is destroyed either physically pr by a virus, you will have lost both your original database AND your backup.</p><p>Best practice is to have three instances of your data:</p><ul><li>the original</li><li>a backup on site</li><li>a backup offsite</li></ul><p>A cloud storage might be a good idea for the latter. In this day and age, maybe even a cloud storage outside of your own country. That way, if you are forced to delete data from your database (if this sounds like a far-fetched idea, let me remind you of this <a href="https://www.theguardian.com/us-news/2025/mar/07/military-images-trump-dei" rel="nofollow noopener noreferrer" target="_blank">https://www.theguardian.com/us-news/2025/mar/07/military-images-trump-dei</a>) your data will still be somewhere safe and unchanged.</p><p>You can also use an external hard drive that you store somewhere safe, preferably outside of the town or city your original database is situated because if there is a catastrophe in this area, your data might still be safe somewhere else. It has the advantage that you pretty much can control where your data goes and that it can’t be hacked, but the disadvantage is that if something happens to that hard drive, the data is lost.</p><p>In comparison, a cloud usually has its own backup routines that make sure that your data is safe. Ask the provider about it. Also ask them about their security measures and what data they share with third parties. Only you should have access to your data, nobody else.</p><p><strong><strong>Heads up: Make sure your data is actually backed up!</strong></strong></p><p>Just because you have taken a backup doesn’t necessarily mean you have a working backup. Once you have created a backup file, try if you can restore it. Caution: Restore it to a separate space, don’t use it to restore your actual database because you risk damaging a working database with a corrupted backup. Check this regularly and don’t assume that just because you can see a backup file on your drive your data is actually fine.</p><p><strong><strong>Final thoughts on when to delete backups</strong></strong></p><p>As said before, it is good to retain some backups because not all problems are discovered right away and it might take weeks to discover them. This is about keeping your current data safe and retrievable.</p><p>But you also might want to preserve the state of your current research. In the future, you might want to come back and compare how facts were recorded in 2024 and how that changed going forward. Your past records may become sources for future scientists and historians. So, it might be a good idea to take a backup NOW and keep that backup in a safe space for the future.</p><p>Next up I will be showing you how to take a backup if you are using TMS or TMS Collections. The way it is done in your software might be different, but perhaps it is a bit similar.</p><p>Take a backup now and take care!</p><p><em>Angela</em></p><p><a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/backup/" target="_blank">#backup</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/collections-management/" target="_blank">#collectionsManagement</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/data/" target="_blank">#data</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/data-security/" target="_blank">#dataSecurity</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/documentation/" target="_blank">#documentation</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/how-to/" target="_blank">#howTo</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/museum/" target="_blank">#museum</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/restore/" target="_blank">#restore</a> <a rel="nofollow noopener noreferrer" class="hashtag u-tag u-category" href="https://world.museumsprojekte.de/tag/safeguarding-data/" target="_blank">#safeguardingData</a></p>