Comments

  • Backup Agent 7.8 for Windows / Management Console 6.3
    The new backup format, as I understand it, will continue "where it left off" rather than having to start all over again. But the big thing is the synthetic fulls process data at a rate of 200-300 GB per hour using in-cloud copying. In my experience synthetic fulls take less than -20% of the time that the initial full took. So a full that took 4 days gets done in less than 15 hours - something easily doane over the wekend.
  • Cloud Files Not Being Deleted After Local Files Are Moved/Deleted
    Lukas - When you say you are “seeing things in wasabi that were uploaded over a year ago”, do you mean you are seeing files in backup storage that were deleted long ago? Or just valid undeleted files that were uploaded a year ago.
    If the former, then put in a support ticket. If it is the latter, I suggest you read my recent post here in this forum for an explanation as to how fulls and incrementals work.
  • How exactly does an incremental backup work?
    First of all, are you using the new backup format or the legacy format?
    The hardest thing to do is to wrap your head around what “incremental forever” means.
    In the legacy format, you take an initial full backup. That captures every file that is on source storage (that you included in the backup set)
    After that the ONLY things that get backed up are newly added files and modifications to existing files.
    Files that never change ( think .pdf files) are never backed up again. They stay forever or until someone deletes them. If someone deletes a file, it will be kept in backup storage for as long as you set in the “ keep files deleted on source for xx days”. A “ Full” in the legacy format is simply a reupload of the files that had block level incrementals captured after the previous full plus any new files added since the last incremental. These “ fulls” are only slightly larger than the incrementals.
    The New Backup format is much more in line with traditional tape backups. You do a full backup of everything - run some incrementals, then do another full backup of everything, even the files that have not been ( and never will be) modified.
    Until very recently you had to do a full backup at least once per month, meaning that if you have a 90 day version retention period you would have three complete backup sets in storage at any given time (
    (actually four but that is beyond this discussion)
    The only thing that makes this even remotely viable is that many ( but not all) backend storage providers have a feature called “ in-cloud copying” which allows the creation of synthetic fulls.
    A synthetic full takes all of the unchanged blocks of data in the previous full and copies them, behind the scenes, into a new full. This in cloud copying processes at a rate of between 200 GB and 300GB/ hr, or 55 - 83 MBps.
    Back to your question, in the new backup format, there is no separate setting for how long to save deleted files, you simply have x number of restore points based on the retention that you set in the plan. The setting applies to versions of files and deleted files.
    The latest feature Forever Full Incrementals (FFI), eliminates the 3x-4x storage consumption problem by keeping only one full followed by x numer of incrementals based on your retention setting.
    So if you have 30 day retention, on day 31, a new full will be created using the synthetic full process plus the oldest incremental. This process will happen every day going forward. You end up with a “rolling 30 days” of backup/ restore points.
    The only issue I see with this is that for very large backup sets, and/ or companies with very slow uplink speeds, the synthetic full might take longer than the hours available overnight. Not that this is a huge issue, but I have asked MSP360 to consider adding a feature that would allow us to specify when the synthetic full should run, perhaps once per week on weekends.
    And that is the short explanation.
    Hope it helps.
  • How exactly does an incremental backup work?
    When files get deleted on the source, they are flagged to be purged after the period of time set in the backup plan for keeping deleted files for x days/ weeks/ months.
    Incrementals backup new and modified files. The weekly full backs up all files that have outstanding block level incremental versions.
    Your full Quickbooks file for example might be 300MB. The daily incremental is probably around 10MB.
    When you run the next full, it backs up the entire 300MB.
  • Backup Agent 7.8 for Windows / Management Console 6.3
    The way I see it, they are mutually exclusive. The only value of FFI is to those of us who do not use GFS or immutability.
    It will hopefully make NBF file backups have similar storage consumption as Legacy format has.
    Am still trying to fully understand the new features, but when I do, I will write-up my assessment in this forum.
  • Bandwidth Settings
    I use the MSP version of the SW but I believe the code is the same.
    I set "When using Cloud/Local storage" to unlimited.
    I then specify the workday hours cloud bandwidth to something less as you have done, but leave local at unlimited since it has no impact on the performance of anything.
    During the workday the screen shows "specified" - and when I am in off-hours it shows Unlimited.
    I have not tested to see if perhaps the software is not using local time to adjust the bandwith.
    The most important thing is whether it is actually lowering your bandwidth during the peak hours - something that you can see when the plan is running.
  • "retrieving data" operation takes a lot of time, is it normal? How can I speed it up?
    The new format does not support incremental forever, so it is not a good fit for Cloud file backups as it required periodic "Fulls" which require re-uploading all 2TB of data.
    For Image and VHD CLoud backups - and for local drives - the new format works great. You would just need a larger NAS or USB drive.
    You could run a FULL once a month and incrementals each night.
    If you want to keep 90 days worth of backups of 2TB of data on a local drive, you will consume 8TB plus the daily incremental space consumption.
    I would recommend at least 10TB of backup drive space, preferrably12TB.
    I also recommend compression and encryption. They do not slow down the backups unless you are on a horrendoesly old slow machine.
    I would also encourage you to utilize Wasabi or Backblaze to keep a copy of the data using legacy mode incremental forever in the cloud as a local NAS device can break, get stolen (and not encrypting the data is asking for touble), or be destroyed in a disaster.
    Alex is correct, the new format is orders of magnitude faster in bringing up the contents of storage to view/restore than legacy mode for large file stores, but takes significantly more space.
    Local space is a one-time and relatively cheap.
    Hope this helps.
    - Steve
  • How to Restore to Azure VM
    HYPERV replication does not rely on backups. It is a windows feature that mirrors the state of the primary server and can be configured to keep multiple checkpoints to restart from on the HYPERV replication server. It is a manual failover - but can be completed in minutes.
    We use ramnode to host several clients' servers, as well as to spin up an instance in a disaster scenario where using our local spare server is not a viable option.
    Ramnode is significantly cheaper than Azure or AWS and has better, more accessible, technical support. We have used all three and prefer Ramnode overall.
    We only use he HYPERV replication feature for our largest, most critical customers, where downtime due to hardware or OS failures cannot exceed an hour.
  • Immutable Backups
    As for your dilemma, what you really want (and unfortunately cannot have) is the legacy format sent to Immutable storage.
    Why do you need immutable storage?
    Is the customer demanding that? Or are you just trying to us Immutability to protect your data?
  • How to Restore to Azure VM
    HyperV replication is what we use for clients that need fast recovery from major, non-Disaster events.
    We keep the old server when upgrading and make it the replica.
    Other MSP’s rely on Datto-type devices to spin up virtual machines on prem.
    Neither of these approaches help in a true Disaster where the client equipment and/or site is unusable for whatever reason.
    For that we rely on a spare server in our office that can quickly download the client’s image/vhdx file(s), or we spin-up a Ramnode hosted instance and do the recovery from there. We tell clients that in a true disaster scenario, we will aim to have core systems up and running in less than 24 hours from the time a disaster is declared, with data from the previous backup.
  • How to Restore to Azure VM
    We spun up a Ramnode instance and did a VHDx restore from Google Nearline. We achieved an average download speed roughly equivalent to a local USB drive - around 20MB/sec, 1.2 GB/minute. At that rate, a 100GB restore would take about 1.5 hours.
    Your mileage may vary.
  • Bad Gateway and 3015 internal storage error
    I am told by support that they have fixed the new Access/Refresh token authorization system. So far today have not received any more of these errors.
  • Issues with Cloud Backups
    Everyone’s requirements and preferences are different, but I can share with you what we do for clients with slow upstream connection speed ( anything under 15mbps).
    We send nightly legacy-format file backups to the local hard drive, and also to Amazon (ZIA).
    We keep the local file backups for a year and the cloud backups for three months.
    We also do weekly new format Image or VHDx backups, using the synthetic full feature which speeds up the weekly backup considerably. Once you complete the first full backup, the subsequent synthetic fulls take 1/6 the time on average.
    Wasabi, BackBlaze and Amazon support synthetic fulls.
    We do legacy format local image/VHDx backups to the USB drive, a full each week or month, and incrementals each night.
    We also do a separate local file backup and call it “recent files”. This runs every couple of hours during the workday to provide intra-day recovery, but we only keep these files for a month or so.
    New backup format is the way to go for all cloud Image or VHDx backups, but for everything else, we use the legacy format as it utilizes far less space in the cloud.
    Hope this helps.
  • Adding a new storage to multiple companies
    When you create a new storage destination, you can choose what companies get access to it, but I do not know of a way to assign an existing destination to multiple companies.
  • image restore verification
    Did you select a new format backup? It does not work with legacy format plans. Once you select the new format, each plan will have a panel where you can select restore verification.
  • Legacy and new format backup
    You are correct about the lifecycle policy behavior, I was asking if MSP360 backups would recognize the contents of the cbl files , old versions and all, such that I could “seed” 90 days worth of backups to the cloud that were originally on the local drive.
  • Legacy and new format backup
    They are anywhere from 3-17GB each.
    So this leads to my next question:
    Lets say i have files with 90 days worth of versions backed up in these CBL files (new format) on my local drive. If i were to copy those files to Amazon using CB Explorer into the appropriate MBS-xxxxx folder, would a subsequent repo sync see them and allow me to "continue on" with a new format Cloud Backup?
    Assuming that it would work, if i were to then use Bucket Lifecycle management to migrate CBL files to a lower tier of cloud storage, would every file contained in the CBL have to match the aging criteria?
    Or is there some intelligence as to what gets put into each CBL file?
  • Legacy and new format backup
    Thanks David. I will do a test tomorrow.
  • Immutable Backups
    The strategy we use to protect our local backups.
    - Put the backup USB HD on the hyperV host and then share it out to the guest VM’s.
    - Use a different admin password on the hyperV than is used on the guest VM’s ( in case someone gets into the file server guest vm where all of the data resides).
    - Do not map drives to the backup drive.
    - Use the agent console password protection feature including protecting the CLI).
    - Turn off the ability to delete backup data and modify plans from the agent console ( company: custom options). You can always turn it on/ back off as necessary to do modifications.)
    - Encrypt the local backups as well somthat if someone walks off with the drive it ismof no use to them.
    We also do image/ VHDx backups to the cloud and file backups to not one, but two different public cloud platforms.
  • 3-2-1 with the new backup format
    In a word, yes. It is a safe and effective way. It allows for flexibility in retention and in file format.