Jump to content

monoxide

Members
  • Posts

    29
  • Joined

  • Last visited

Everything posted by monoxide

  1. Are you trying to skip a dimension that doesn't actually exist? Because that won't work...
  2. Version 1.1.2 is released. This is purely a version bump to 1.5.2.
  3. http://forum.feed-the-beast.com/threads/feed-the-beast-redpower-and-1-5-x.18827/
  4. http://forum.feed-the-beast.com/threads/feed-the-beast-redpower-and-1-5-x.18827/
  5. Also, FYI, the FTB Ultimate pack should be updating to 1.5.1 within the next week or so, sans RP2.
  6. Also, FYI, the FTB Ultimate pack should be updating to 1.5.1 within the next week or so, sans RP2.
  7. The git mechanism is very much a proof of concept/experiment at this point. It was an initial attempt at incremental backups since git only stores diffs. If it doesn't work well for you, then I'm sorry and try something else.
  8. The git mechanism is very much a proof of concept/experiment at this point. It was an initial attempt at incremental backups since git only stores diffs. If it doesn't work well for you, then I'm sorry and try something else.
  9. Currently there's no way to turn off the default backups. I may look into that for the 1.5 version. You could use the bz2 method for the normal backup and set it up to backup daily and keep 3, and then no daily backups in the archives. Or just use bz2 regular backups all round. There's a reason the git option is an *option* and not required. With regards to rsync, I have no issue with it per ce, except that rsync excels at keeping two copies of a filesystem in sync, however the idea here is to create many copies at different points in time. If you rsync to an empty directory, you gain nothing. The two seem to be aimed at different tasks, so I'm not sure how rsync would help. I will look into the weekly backups issue, thanks for the bug report there.
  10. Currently there's no way to turn off the default backups. I may look into that for the 1.5 version. You could use the bz2 method for the normal backup and set it up to backup daily and keep 3, and then no daily backups in the archives. Or just use bz2 regular backups all round. There's a reason the git option is an *option* and not required. With regards to rsync, I have no issue with it per ce, except that rsync excels at keeping two copies of a filesystem in sync, however the idea here is to create many copies at different points in time. If you rsync to an empty directory, you gain nothing. The two seem to be aimed at different tasks, so I'm not sure how rsync would help. I will look into the weekly backups issue, thanks for the bug report there.
  11. Looks like I may have to retract my previous statement. Thanks to the wonderful work of cjo9900 we now have a 1.5.1 version working! I haven't done much testing on it myself, but he assures me it's working and there honestly wasn't too much to update the released version. This is essentially a straight port of the 1.4.7 version with a minor bug fix.
  12. Looks like I may have to retract my previous statement. Thanks to the wonderful work of cjo9900 we now have a 1.5.1 version working! I haven't done much testing on it myself, but he assures me it's working and there honestly wasn't too much to update the released version. This is essentially a straight port of the 1.4.7 version with a minor bug fix.
  13. Yea, git is funny in how it deals with submodules, and ForgeBackup doesn't know about them at all so expect weird behaviour in that situation. I might relax that behaviour so that it only requires a clean index, but I'm not sure about that. Also, the git folder you've already done there would still not get backed up at all. Got a few interesting ideas how to deal with all that, but don't want to promise anything just yet. Sadly, I won't be able to update any time real soon I don't think. Work has been hectic and I've just had a bunch of hardware blow up recently, including my Jenkins server.
  14. Yea, git is funny in how it deals with submodules, and ForgeBackup doesn't know about them at all so expect weird behaviour in that situation. I might relax that behaviour so that it only requires a clean index, but I'm not sure about that. Also, the git folder you've already done there would still not get backed up at all. Got a few interesting ideas how to deal with all that, but don't want to promise anything just yet. Sadly, I won't be able to update any time real soon I don't think. Work has been hectic and I've just had a bunch of hardware blow up recently, including my Jenkins server.
  15. The git backup is likely upset at the fact that the repo isn't clean when it tries to run a backup. The easiest way to verify that would be to check the actual server console which should tell you exactly what's wrong. What is in ftb2/computer? Did you add that folder/file yourself after the fact? ForgeBackup will only do a backup if the repo is currently completely clean and should commit everything it adds into the repo. It will also delete any files in the repo before adding a complete updated copy for the next commit. This means that it's a poor choice of location for you to be adding your own stuff to. For now at least, the messages reported in chat can be generic/poor, but looking at the console should tell you exactly what's going on.
  16. I can't reproduce this on linux, can you do a few things for me? First, are you using 1.0.2? If so, can you check if C:\Users\robin\Dropbox\FTBServerBackups exists after trying to run a backup? Failing all that, can you try build 74 from https://www.dropbox.com/s/hkl7lg13h1sb8xu/forgebackup-universal-1.4.7-1.0.2.74.jar There was some issues in the released version of 1.0.2 with absolute paths, though from your error I don't think that's what affecting you.
  17. Currently, yes you must do exactly this. Download, unpack and upload should be fine with mearly FTP access, as long as you can stop the server while you're doing it. In-game restores are planned for the future, hopefully 1.1, but I've been busy with other things. See up a few posts for the intended SSP version. I plan to make it as easy as possible for SMP also, with at least a `/backup restore <name>` and a way to list the backups.
  18. In general, the documentation for the configuration is in the configuration file itself. Unfortunately, the forge configuration format for lists is a bit weird. Each item should be on it's own line, so for your example: # Other files or directories to backup. S:other < configs world world_twilightforest > Note, the config folder and world folder should already be enabled anyway via the following options: # Backup config folder. B:configuration=true # Backup world folder. B:world=true
  19. 1.0.2 is released. It is a primarily a bugfix release. Also, a teaser for all you SSP players:
  20. 1.0.1 is released with just a few bugfixes, some urgent if you are using some features.
  21. Version 1.0 has been released! If you don't read the changelog, then there is one really important change. ForgeBackup is now a coremod. As of version 1.0, ForgeBackup must now be placed in your coremods folder, not your mods folder.
  22. Try ForgeBackup. There's no reason at all it shouldn't be compatible with Mindcrack. I use it regularly with the DW20 pack without issue, and it doesn't really touch Minecraft itself at all. 0.4.1 is out with some pretty cool features, and lots more planned to come still too.
  23. Currently it only does full backups. I plan to add different compression methods later though (only zip is supported currently), and one of the one's I've been toying with is a git-based method which would allow for incremental backups.
  24. Version 0.4.1 released! Click here to download it. Changelog:
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.