File-level backup from NAS, file shares and file servers
- Posts: 2
- Liked: 1 time
- Joined: Feb 08, 2018 11:20 pm
- Full Name: Todd Fatheree
We have a Synology NAS that we use to store about 9TB of archive data. To protect against ransomware, we had a file-to-tape job in 9.5. While attempting the upgrade to 10, I found that our SQL Express database was near capacity, which caused the upgrade to fail. Support noticed that the database table that keeps track of the file-to-tape catalogs was consuming most of the space, so they deleted it so we could get the upgrade going again.
Now that we're up to version 10, even though there is some improved capability for NAS backup, it seems that if I want to get the backups to tape that I'm still stuck with a file to tape job, if I read the other posts correctly. If that is the case, I'm going to need another option as the SQL Express database can't handle it and I don't see us upgrading to full SQL.
Is my understanding of the current situation correct and if so, can anyone offer another option?
- Veeam Software
- Posts: 1982
- Liked: 287 times
- Joined: Nov 17, 2015 2:38 am
- Full Name: Joe Marton
- Location: Chicago, IL
You are correct. NAS backup requires going to disk, not tape. If this data must go to tape you'll need to use files-to-tape which catalogs every fs object in the SQL database. That's why SQL Express may not be sufficient. There are options to secure Windows and Linux repos if you'd like to use NAS backup to disk, but to really protect against ransomware tape is definitely the "gold standard."
- Veeam Software
- Posts: 1528
- Liked: 346 times
- Joined: Jun 14, 2013 9:30 am
- Full Name: Egor Yakovlev
Technically, you can install Veeam Agent for Linux somewhere in your infrastructure and use snapshot-less file-level backup from said Synology Box share. Such backup will yield a compressed chain of .vbk(full) + .vib(incremental backups) and those could be offloaded to the tape using Backup to Tape, rather than File to Tape. That will reduce tape catalog footprint from millions to dozens of records but will require additional mid-man disk based repository storage.
Users browsing this forum: No registered users and 1 guest