Dear @jamie
Thanks a lot for your time and attention (and code, of course). 😉
I am about to go to a Conference in Helsinki and will be back on the 30th, so no hurry. I will try to move the thesis #tem25 in the in-between times but I'm afraid there won't be much of those in the next days. ;D
And, for sure, will try your code once I'm there and will report back. :)))
Again, thanks a lot. Your sharing helps us all to keep hope in people and work towards a better world in these dark times.
Best.
@Eduardo Mercovich (él)
One more humdrum piece of advice: backups!
A version control repository is not a replacement for backups. Repos need backing up too.
It achieves one function that backups help with, that's getting back to previous versions.
However, if it's on the same computer or drive, it does not help with hardware failure / loss of the computer / catastrophic operator error.
(It's also possible to ruin your repository if you're 'clever' enough. I've been this clever in the past. Not if you stick to absolutely simple things as per my recommendation, tho.)
The usual recommended minimum is the original plus two backup copies. Neither backup should be on the same hardware, and one should be in a different location (e.g. in the cloud, emailed regularly to a friend).
Backup regularly. Every day, or more frequently if you're doing a lot of work. How much lost work can you easily shrug off if your computer dies?
And the backups should be checked occasionally to make sure you really are backing up.
A remote repository (e.g. codeberg) counts as one backup, but only if your push changes to it regularly.
(Sorry if I'm telling you what you already know, with this and my last message about git. However, in the case of backups it's common for people to be terrible about it, even if they know better. For example, while I backup semi-regularly, the 'other location' is just a different room, which doesn't help if the house burns down. So some degree of exhoration/nagging seems appropriate...)
#tem25 #backups #versioncontrol
Je ne sais pas si la doc de Borg est très clair (et j'ai à chaque fois un doute), mais oui un simple :
🖥️ borg check /repo
relit l'intégralité des données (et méta-données) du disque et vérifie leur checksum. C'est suffisant pour tester l'intégrité de votre repo entier. Cela détecte le bitrot ou les corruptions de fichiers.
(Ajoutez -v --progress pour voir la progression).
et (suite)
Restic backup is tonight's presentation @PLUG in Phoenix, AZ
We start at 19:00, but please arrive early due to building access
a true cross platform system that allows performing classic full and differential backups.
https://github.com/garethgeorge/backrest
1702 E Highland Ave
Suite 300
Phoenix, AZ 85016
#Stammtisch is a week from Tuesday
#restic #backups #restores #DataIntegrity#PLUG#LocalGroup @FLOSS_Stammtisch
Restic backup is tonight's presentation @PLUG in Phoenix, AZ
We start at 19:00, but please arrive early due to building access
a true cross platform system that allows performing classic full and differential backups.
https://github.com/garethgeorge/backrest
1702 E Highland Ave
Suite 300
Phoenix, AZ 85016
#Stammtisch is a week from Tuesday
#restic #backups #restores #DataIntegrity#PLUG#LocalGroup @FLOSS_Stammtisch