Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Hows R1Soft? Looking for cPanel Backup Solution - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Hows R1Soft? Looking for cPanel Backup Solution

2»

Comments

  • @coolice said:
    I took one for the team :) just upgraded one of mine small servers from 3 to 4 to see what is the difference

    Situation before

    It has a broken mysql table and do not clear cache, but upgrade process runned...

    I use dual backup destinations with dual backups It somehow messed up during upgrade so both jobs become set to same one backup destination and upgrade process only found half of backups, (which are on the first location ) :)

    (I'm sure setup was not such and I backup on both destinations even with the broken mysql table) as I
    have this afternoon backup snaps to second location....

    that issue before was easy fixable with clear cache

    but now

    jetcli backup -vfR clearcache
    jetcli: ***********************
    --run clearcache has been deprecated.

    and the fix was the procedure similar to what @desfire mention to do by just moving files between folders for the new server

    :) I can only imagin shitsorm support request which will happened around new year when version 3 EOL... :)

    @JetApps can we have clear cache working it will save you a lot of support requests

    How we mention it is usable for restorations and also for importing backups from couple of servers to one server...

    You had superior product in version 3 that worked even broken :) but now version 4 restricting us to be able to work :)

    Clear caché still works, it is just another command. I do not remember exactly why. That is not related to my issue, mine is related to "ownership", meaning that backups will be "owned" by a folder, if you move it to another folder it will just not work.

  • I'm in similar situation on location 2 as I manage to broke my Jetbackup that way to move accounts manually to the folder

    I found the command

    jetcli backup -vfR reindex

    But after every account it say
    DONE - 0 snapshots found for every account in location 2

    paths are correct and follow the structure after the strangely named folder as in my location 1

    where backups are

    DONE - 15 snapshots found

  • @coolice said:
    I'm in similar situation on location 2 as I manage to broke my Jetbackup that way to move accounts manually to the folder

    I found the command

    jetcli backup -vfR reindex

    But after every account it say
    DONE - 0 snapshots found for every account in location 2

    paths are correct and follow the structure after the strangely named folder as in my location 1

    where backups are

    DONE - 15 snapshots found

    Happened to me in one of the upgrades as well, submit a ticket..

  • MikePTMikePT Moderator, Patron Provider, Veteran

    The backup structure and db isnt the same. Open a ticket, they will fix it for you.

    Had to get them to do this for over 8TB data...

  • Hi,

    Just bumping in to clarify a few things :smile:

    JetBackup 4 introduced a new core in which we had to change the concept of how we deal with our files in the backup destinations.
    Basically the main idea is working with meta index files, rather then "running through" the entire backup destination.

    This change allowed us to dramatically improve the speed of the backup indexing as well as improve the reliability of the backups.

    So whats this have to do with reliability ?

    We've seen so many cases where users are using the same backup folder for multiple jobs... and even worse, the same backup folder for multiple servers.

    Let's focus on the "multiple jobs to the same folder":

    • Users were mistaken to think they are creating 3 separate Jobs
    • Monthly, Weekly, & Daily backups being stored in the same destination folder will create a multi-scheduled incremental job. However, most likely they will delete their retention snaps.

    For example -

    Daily job runs every day, saves 14 retentions
    Monthly job runs 1st of the month and saves 2 retentions.

    Daliy job will be executed every day, retentions will slowly gather up to 14. So far so good.

    Once the 1st of the month reaches, monthly jobs runs.

    How many retentions do we save for the monthly job ? 3
    How many do we currently have inside the backup destination ? 14 (reminder - we are sharing the same folder)
    How many snaps will the monthly job delete ? 11

    Next day, daily job will keep pushing incremental backups, and the reneton rate will grow up +1, at this point it will be 4 and so on.

    The new "Multi scheduling" feature we added inside JetBackup 4 eliminates this headache, and everything is calculated in the background. Even better, the monthly job doesn't even have to be actually executed, we simply "flag" a snap shot as "monthly" once he reaches a proper age.

    When using ssh / local backup destinations, It is very convenient that backups are saved in the "cpmove" structure and even better that we can manually reach these files, not related to JetBackup.

    We do understand the need for the "clear cache" function when doing maintenance / moving accounts. We have an open internal case about it, so it should be taken care of :smile:

    Thanks,
    Clark

    Thanked by 2Zerpy desfire
  • @JetApps said:
    Hi,

    Just bumping in to clarify a few things :smile:

    JetBackup 4 introduced a new core in which we had to change the concept of how we deal with our files in the backup destinations.
    Basically the main idea is working with meta index files, rather then "running through" the entire backup destination.

    This change allowed us to dramatically improve the speed of the backup indexing as well as improve the reliability of the backups.

    So whats this have to do with reliability ?

    We've seen so many cases where users are using the same backup folder for multiple jobs... and even worse, the same backup folder for multiple servers.

    Let's focus on the "multiple jobs to the same folder":

    • Users were mistaken to think they are creating 3 separate Jobs
    • Monthly, Weekly, & Daily backups being stored in the same destination folder will create a multi-scheduled incremental job. However, most likely they will delete their retention snaps.

    For example -

    Daily job runs every day, saves 14 retentions
    Monthly job runs 1st of the month and saves 2 retentions.

    Daliy job will be executed every day, retentions will slowly gather up to 14. So far so good.

    Once the 1st of the month reaches, monthly jobs runs.

    How many retentions do we save for the monthly job ? 3
    How many do we currently have inside the backup destination ? 14 (reminder - we are sharing the same folder)
    How many snaps will the monthly job delete ? 11

    Next day, daily job will keep pushing incremental backups, and the reneton rate will grow up +1, at this point it will be 4 and so on.

    The new "Multi scheduling" feature we added inside JetBackup 4 eliminates this headache, and everything is calculated in the background. Even better, the monthly job doesn't even have to be actually executed, we simply "flag" a snap shot as "monthly" once he reaches a proper age.

    When using ssh / local backup destinations, It is very convenient that backups are saved in the "cpmove" structure and even better that we can manually reach these files, not related to JetBackup.

    We do understand the need for the "clear cache" function when doing maintenance / moving accounts. We have an open internal case about it, so it should be taken care of :smile:

    Thanks,
    Clark

    Thanks, and please, something like "Import backup from other JetBackup destination" or something like that

  • WSWDWSWD Member, Host Rep

    I didn't really have a whole lot of problems initially with R1Soft, aside from it being slow. Then I ran into an issue that every time KernelCare would update the kernel, the server would have to be rebooted every single time, or R1Soft would fail. Kinda defeats the purpose. R1Soft finally admitted it was a bug, but working as designed, and they refused to fix the issue. All that along with shitty support and the massive price increase? Yeah...R1Soft can suck it.

    Went to Clusterlogics and never looked back. Was incredibly easy to set up and it's reasonably fast as well. I had a couple questions and their support team was excellent and very responsive.

Sign In or Register to comment.