-
Notifications
You must be signed in to change notification settings - Fork 674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Disable tarring before uploading to Storage #662
Comments
Already suggested on the Feature issue tracker here backup/backup-features#25 It's accepted and implemented in the next major version. |
Tiny addition: We're not disabling tarring/compressing for most things. Unless no compressor is configured for the entire backup. So it's either compress everything or nothing. Sources (databases, files, etc) will be in separate archives when being backed up, so no more big archives. |
Awesome! Thanks for info. You are doing a great thing! |
+1 for skipping tar + gzip. We have large DB tables that we wish they'd stay per file for easier recovery. Any work around at the moment? |
@amerk86 you can create a model per configuration and run them separately |
@tombruijn Any example code or discussion thread to get me started? |
@amerk86 not really. Just create a new model for every database/table, share parts of the config in the config.rb perhaps? |
Brain-fart! That's what I did. I misunderstood your previous comment. Thanks :) |
I'd like to refer issue #255 and request that feature again with little more explanation why it is good.
I suppose that when we have separate files for db backups and different folder is way much better rather than having a single tar file or even tar splitted in chunks. That is because in case if nework connection will fail or external storage will get out of space or something else, it is more likely to be able to have at least part of data backed up with possibility ot be easily restored.
In case of tar splitted in chunks it'll probably be harder to restore it in case when one of the chunks got lost or not all chunks were properly uploaded to external storage (is it possible at all to restore it in that case???).
Taking into account the fact that backups could usually be pretty big in size, it makes it even more significant not to upload all the data in a single file, but have it splitted into a separate self-containing archives (not chunks) which could be restored separetly.
The text was updated successfully, but these errors were encountered: