DVC disaster recovery

[haimat]

So far we had all the datasets (with images) for each project on our server in their respective folders. That whole data folder has been backed-up to an offsite storage. Thus in the worst case we still had all our images/datasets for all projects in a secure location. In that worst case we could find all the images based on the project name and sub folders.

Now with DVC all the images from the various projects/datasets end up in our DVC remote server. That DVC data store is of course also backed-up to the offsite storage. However, since DVC stores all the files via their MD5 hash, we cannot find individual files by their names or file system paths any longer.

Now my question: In the worst case scenario, when we would loose all of our Git history (for whatever reason) and with it also the MD5 hashes from the DVC-tracked files, we could then never ever restore the original files from the DVC storage, since (AFAIK) it doesn't know about the file or folder names. What is the "official" approach to handle this problem with DVC (except "don't loose your Git history")?

[pmrowla]

If you are only tracking directories with DVC (and not individual files), it is possible to recover the structure of those directories via the <md5>.dir files (which are just JSON files containing the hashes and relative paths for each tracked file inside that version of the directory). But if you are tracking individual files this will not work, and there is still the limitation that you would lose the name/path for the directory itself.

You could also consider using the new cloud versioning remote format, which does preserve the original directory/filename structure for tracked files (but this requires using an object-storage remote that supports cloud versioning).

But really, DVC is not intended to function without the corresponding .dvc files (even in the cloud-versioning remote scenario). In all cases, the "official" best practice would still be "don't lose your Git history" (and ideally keep remote/offsite backups of your git repository).

[haimat]

Thanks for your response. It is a valid input. So far we fully rely on Github as our git storage.
But that reminds me that we might want to additionally backup everything from Github offsite as well ...

[peterjcarr]

I am thinking of this as well. one idea ... for disaster recovery is to take advantage of the distributed nature of git. And make sure you have a clone, regularly synced up with your main repo(s) in GitHub.

For extra redundancy, you can keep both the Git working copy and the cache backed up to a NAS.