2

A question has come up regarding how we deal with bitrot, and if we need to do more.

We have a very simple setup; a single 4TB HDD (NTFS formatted) which is backed up to another larger HDD using weekly VSS Full backups (losing a week of data is not a problem for us). Offsite backups are also done. Over the years we have been keeping historical records on this 4TB disk - e.g. reports from 2010 - and these are never checked unless we need them (very rarely, if at all). The concern is some may be getting silently corrupted and we'd never know.

The question is - what should we be doing to detect and manage bitrot? does Windows Server 2016 handle it out of the box? does VSS Full detect and correct bitrot?

Edit: I should have phrased this "how should we be handling bitrot in a small business setup? or do small business just accept this gradual corruption?"

Incipient
  • 21
  • 2
  • Windows Backup cannot identify and handle bitrot, it relies on file system error corection. NTFS protects only file table, but not the data itself. ReFS does checksums of data and during "scrubbing" check the integrity of data. – batistuta09 Feb 05 '21 at 11:47
  • Thanks for the confirmation! ReFS however isn't really a 'daily driver' filesystem. Integrity Streams (which includes checksums) only does integrity, not redundancy - it needs a full Storage Spaces setup for that. Reflecting on the original question, I was really just after "how does small business deal with bitrot?" – Incipient Feb 06 '21 at 05:08

2 Answers2

0

I always recommend using a real backup solution, which should take this problem into account. It does require an investment in hardware - owned or leased - and in time, money, or more usually a little of both.

In the end it's a sort of insurance premium: try to strike a balance where you don't end up paying more for a solution than you stand to lose when data is lost.

Mikael H
  • 5,031
  • 2
  • 9
  • 18
  • Thanks Mikael - that was the intention with onsite windows backup, as well as offsite backups. Unless you're proposing a more "real" backup than windows server backup? We're just trying to avoid here corrupt files creeping into the backups. – Incipient Feb 06 '21 at 10:44
  • I have to confess I don't know enough about the capabilities of Windows backup, but at least a few years ago it wasn't exactly impressive. Something like the Veeam agent for Windows will at least be able to inform you whether bit rot has occurred even if it can't fix it. There are third-party backup solutions out here with even better capability, but at some point they start costing real money. The best you can do is to read up on it. Don't forget to take into account services like Backblaze for your off-site backup needs. – Mikael H Feb 06 '21 at 11:09
  • I think you're right - I am currently looking at some alternative paid and oss backup offerings such as Veeam and bb. – Incipient Feb 12 '21 at 02:48
0

Windows Server Backup does not have integrated protection against bit-root; rather, it depends on the one provided by the underlying filesystem (read: ReFS). However, even a checksum-enabled filesystem will need a second copy (or parity info) of the affected data to recover them. For that reason, I generally store my offline backup on a remote server which runs over ZFS RAIDZ2.

If your offsite backup are simple unpowered disks or tapes, you can use something as parchive or par2cmdline to store additional parity info for specific archive files. For Windows ports of these software, you can look here

shodanshok
  • 47,711
  • 7
  • 111
  • 180
  • Thanks for this - our 'second copy' is the backup. Basically NTFS could be more robust for a server environment! I'm going to look at a ReFS deployment on a test server to see how it goes. Would be great if ReFS could automaticallty recover from Server Backup rather than just Storage Spaces, but hey! ZFS seems like the best "99% solution" (I have used ZFS in linux, which was why I was asking this question for a windows environment) – Incipient Feb 12 '21 at 02:47