Jump to content
NAKIVO Backup & Replication v10.10 Beta is now available for testing! ×
NAKIVO Community Forum
  • Welcome to NAKIVO Community Forum!

    Sign up to start a discussion!

  1. General Discussions

    1. 189
      posts
    2. 362
      posts
  2. Deployment

    1. 132
      posts
  3. Configuration

    1. 51
      posts
    2. 32
      posts
    3. 208
      posts
  4. Backup

    1. 69
      posts
    2. 198
      posts
    3. Microsoft Office 365 Backup

      Microsoft Office 365 Backup

      103
      posts
    4. 48
      posts
    5. 22
      posts
    6. 40
      posts
    7. 16
      posts
    8. 46
      posts
  5. Replication

    1. 10
      posts
    2. 4
      posts
    3. 4
      posts
    4. 9
      posts
  6. Recovery

    1. 8
      posts
    2. 13
      posts
    3. 18
      posts
    4. 6
      posts
  7. Integration

    1. 20
      posts
  8. Automation

    1. 32
      posts
  9. Multi-tenant Mode

    1. 20
      posts
  • Member Statistics

    1343
    Total Members
    871
    Most Online
    FletcherTN
    Newest Member
    FletcherTN
    Joined
  • Posts

    • @cmangiarelli, I can recommend using the standard way to move the backup data to another repository. Did you have a chance to use a backup copy and use the retention that works for you (https://helpcenter.nakivo.com/User-Guide/Content/Backup/Creating-Backup-Copy-Jobs/Creating-Backup-Copy-Jobs.htm)? I am looking forward to hearing from you.
    • Hello @cmangiarelli. To address your inquiry effectively, we recommend generating and submitting a support bundle to support@nakivo.com by following the instructions outlined here: https://helpcenter.nakivo.com/display/NH/Support+Bundles By doing so, you will facilitate a thorough examination of your issue by our esteemed Technical Support team. Your cooperation in this matter is greatly appreciated.
    • As per another post, I am in the process of moving my Nakivo backups from older Data Domains to Synology NAS arrays. The process I plan to use is: Install Nakivo Transporter on the Synology NAS. Register Synology Transporter with Director. Create a new "local folder" repo on the Synology transporter. Configure a backup copy job to mirror the existing DD repo to the Synology Repo. Delete the backup copy job, as you can't edit the destination target of the backup job if the copy job exists, but tell it to "Keep existing backups". Edit the VM backup job to point the VMs to their new location (this is a pain when you have a lot of VMs, wish there was an easier way to do this or have Nakivo automatically discover existing backups). Run the VM backup job to start storing new backups on the Synology repo. I ran a test and this worked fine, except all of the old recovery points that were copied by the backup copy job in step #4 had their retention set to "Keep Forever". I'm guessing this occurred when I deleted the copy job but told it to keep the backups. I'm assuming this is operating as intended? With 200 VMs and each having 9-11 recovery points, I can't manually reset the retention on 2,200 recovery points to fix this. I understand why it might have gotten changed when the backup copy job was deleted, but the Director wouldn't let me re-point the backup job until those copied backups were no longer referenced by another job object. I can use the "delete backups in bulk" to manually enact my original retention policy, but that will take 3 months to run the cycle. Any ideas?
    • @tkriener Dear Mr. Kriener, thank you for your post, and I appreciate your inquiry. It has come to my attention that you are seeking clarification regarding the inclusion of support for backing up online archive mailboxes in the forthcoming release of NAKIVO Backup & Replication, specifically in version 10.10. While it is prudent to employ the term "planned" when discussing potential features, given the potential for evolving circumstances, I wish to affirm that this feature is unequivocally within our product roadmap. Best regards.
    • >>> Please add the screenshot with the detailed information about the newly created Repository. Not sure why this is necessary, as the transporter/repo functions perfectly fine. My post is mainly concerned with the proper way to integrate Synology with Nakivo. As for my repo, it's configured as follows:   Type: "Local Folder" Name & Location: Name: "DC local" Assigned transporter: "dc-bckp-003" Path to local folder: "/volume1/nakivo/dc-local" Options: Data Size Reduction: Enabled Compression: Fast Store backups in separate files: Not checked Deduplication: Checked Encryption: Disabled Enable automatic repository self-healing: Checked Run repository self-healing on: Not checked Run full data verification on: Not checked Reclaim unused space on schedule: Checked Schedule: once a day on every day at 8:00 pm - 12:00 am (UTC+00:00, UTC) Enforce explicit file system sync: Checked Detach this repository on: Unchecked   >>>> NAKIVO never tested Synology's data deduplication on the array, and we can not predict the level of the deduplication for this >>>> implementation. Based on our experience, the deduplication on the hardware level is more effective and saves more space. We >>>>  recommend using it.  >>>> The correct configuration for this environment: NAKIVO Transporter Installed on Synology host and Incremental with full Repository >>>> configured as the local folder on the array where Synology's data deduplication process is turned on. The Backup Jobs must be >>>> configured to create a full Active backup one per 15-20 runs.   I'm not too worried about the efficiency of the deduplication algorithm of the Synology vs Data Domain vs. Nakivo; I'm satisfied as long as they are on-par with each other. The low cost of the Synology NAS vs. a dedicated Data Domain device was more than enough to convince us to switch to the alternate solution. We do use Nakivo's deduplication at some of our customer sites where a dedicated backup storage array is not available (i.e. the repo is stored on the primary storage array and we need to save space). I will remove my current repo (mentioned above) and re-create it with the following options:   Options: Data Size Reduction: Enabled Compression: Fast Store backups in separate files: Checked Encryption: Disabled Enable automatic repository self-healing: Checked Run repository self-healing on: Not checked Run full data verification on: Not checked Enforce explicit file system sync: Checked Detach this repository on: Unchecked I will then enable Synology deduplication on /volume1.   >>>> For security reasons, we highly recommend manually creating a folder for the Repository without using the Shared folder wizard. >>>> Please do not create this folder in the NAKIVO application home directory (it can be destroyed during the update process). We >>>> have no information about data damage during the DSM update action; it is better to contact Synology support with this question. Sounds like I did it correct then. However, it would have been nice to have this documented somewhere so that a person like myself doesn't need to guess at the proper way to configure this. I couldn't find anything in the online Nakivo documentation on how to properly configure this type solution (Nakivo + Synology). Luckily I am versed enough in the technology to make somewhat intelligent decisions on how this should be working... that and Google is pretty good at pointing me to solutions of common problems/questions.
  • Forum Statistics

    • Total Topics
      361
    • Total Posts
      3k
×
×
  • Create New...