Nevertheless, in the cat-and-mouse game of hacking-for-profit, there are increasing levels of sophistication, and a good backup strategy should assume the ability to recover after a successful crypto attack. I appreciate the discussion, jeyare, friendly and only with a view to help.įor sure, we've hardened our security after learning how this other company was hacked. I'm continuing to do some testing to see if I can figure out a solution, but if there's a better way to solve the backup-taken-then-target-offline scenario, I'm all ears. My initial question re: apparent lack of de-dupe has not been answered, and maybe never will.
USB BACKUP DRIVER
We chose to use several USB external hard drive copies of our VEEAM backup in rotation offsite, encrypted, of course, so that if the external driver were physically stolen the data would still be inaccessible.
USB BACKUP OFFLINE
One sure way to prevent this scenario is to have a recent offline copy. Even though the company had multiple levels of backup, including cloud, the attackers gained access to the server itself, and since the cloud backup was online, the attackers were even able to wipe out the cloud backup, as well as encrypt all local online backups, leaving the company in a vulnerable position. We recently talked with a company that were targeted by a very sophisticated crypto attack. Are you suggesting HB is not trustworthy?įYI, the reason we are doing this, in addition to other backup levels, is that all of our other backup targets are online in some way. Backup systems have to be accurate and trustworthy, otherwise don't use them. I expect any reputable backup tool, including HB, to make an accurate copy of whatever data it backs up, and incrementally, accurate also, regardless of the mechanism (block-level vs file-level) it uses. We do have several other levels of backup that I haven't mentioned, since they are not relevant to my question. Your understanding is accurate, and I appreciate your critique of our backup operation. It seems, at least from the evidence, that is what is happening, but it is not what I should expect from block-level incremental. For "file-level" incremental backup, this would mean that every time I do the backup, this would have to be re-written to the USB drive. 4TB and the "updated" date changes nightly. The data I'm backing up to the USB drive is a VEEAM backup. HB advertises " block-level incremental backup". Then why, when it seems there is not much data change on the source, is HB adding 50-90% of the original size on the incremental? "After the first run, each time you back up, only the new and the changed data will be send to the backup" - exactly what I expect. I'm just saying that I've tried both types, with similar results, which infers that the "de-dup" that is supposed to kick in for the non-single-version doesn't seem to be making any difference, and I can't figure out why. I only need one version on the offsite disk. Understood, I don't care about older versions. Obviously for offsite backup purposes, the drive needs to be dismounted and removed.
Is there a setting I'm missing? Is this by design? Is there a way to do this so that it will de-dupe (e.g., put the USB drive on the remote NAS, so that it will de-dupe?) Second and subsequent, very little time or growth in destination file, presumably due to de-dupe, as advertised. There is not much change to the data between the two backups, so I would expect a similar result to another backup we do ("Remote NAS device", compressed, not encrypted, no rotation) to another ext4 NAS connected to the same LAN (in another building) different data set, but a lot of data.
My only alternative is to blow the job away and re-create it every time. I've tried both "Local Folder & USB" and "Local Folder & USB (single version)", with same results.
When I do the second backup on that same job, it again takes a long time, and then runs out of space. When I do the initial backup, it takes a long time (expected). I'm doing a Hyper backup to USB drive (dest: ext4, compressed, encrypted, no backup rotation, 8TB drive) for offsite, about 5 TB data.
0 kommentar(er)
