Discussion :

[rnd]

Bonjour à tous,

Récemment chez un client (09/18), on à effectué la migration en version 100c (auparavant le client était en 8.50) qui tourne sous SQL Express 2012-64.

J'avais en place une sauvegarde, par script, quotidienne complète chaque soir (Lundi-Vendredi) avec conservation sur 30 jours. ( taille du fichiers bak +/- 350 Mo, stables) Jusque là tout va bien.

Depuis la mise a niveau vers la 100c, de nouvelle contrainte sont apparue (lois anti-fraude) et la solution retenus par les pignoufs de SAGE, est de générer en dur tout les documents clients (BC, BL, Fact) en PDF, non optimiser (1.8 Mo par fichier) et stocker dans le Filestream.
Résultat je me retrouve après 3 mois avec un fichier bak qui pèse aujourd'hui 2 Gb (+ 600 Mo de PDF/mois) Un rapide calcul, dans 1 an, mon bak va faire 7.2 Gb, et pour aller plus loin, x par 5 ans d'exercices 36Gb.

A aujourd'hui la sauvegarde ce fait en local, sur stockage NAS, mais courant 2019 copie/réplication sur site distant de la sauvegarde (cout en bande passante)

J'aurais aimé pouvoir dissocier la base et les fichiers Filestream, mais visiblement pas possible sous SQL Express (option grisé dans SMS, de même que la compression

J'ai aussi testé la compression du fichier bak par zip, mais pour ce que l'on y gagne

Je pense donc a faire une complète puis incrémental, mais je ne sais pas encore si je fais:

• Complète le lundi puis incrément mardi-vendredi
• Complète début de mois puis incrémental tous le mois

J'imagine que parmi vous il y en a qui ont des cas similaires, comment faite vous?

Un avis externe ne serait pas de refus. Cdt.

[i.chafai]

Si je ne dit pas de bêtises, la sauvegarde des filegroup sera une bonne solution.
Je l'ai utilisé pour mon client pour une base 100c aussi

[rnd]

Bonjour,

Merci de te pencher sur mon cas,
La sauvegarde des filegroupe, ce n'est pas l'option fichiers groupés justement, chez mon client ne doit être disponible (version express) pas active dans la console; A moins que l'on puisse le lancer quand même via script sqlcmd.

[alevi7856]

J'avais en place une sauvegarde, par script, quotidienne complète chaque soir (Lundi-Vendredi) avec conservation sur 30 jours. ( taille du fichiers bak +/- 350 Mo, stables) Jusque là tout va bien.
Depuis la mise a niveau vers la 100c, de nouvelle contrainte sont apparue (lois anti-fraude) et la solution retenus par les pignoufs de SAGE, est de générer en dur tout les documents clients (BC, BL, Fact) en PDF, non optimiser (1.8 Mo par fichier) et stocker dans le Filestream.
Résultat je me retrouve après 3 mois avec un fichier bak qui pèse aujourd'hui 2 Gb (+ 600 Mo de PDF/mois) Un rapide calcul, dans 1 an, mon bak va faire 7.2 Gb, et pour aller plus loin, x par 5 ans d'exercices 36Gb.

Bonjour,
Je me retrouve dans le même cas de figure : fichiers de base 300-350Mo (.mdf / .ldf) + 850Mo de .pdf et autres dans le répertoire FILESTREAM, et nous ne sommes même pas à mi-parcours de l'exercice fiscal (qui commence le 1er avril chez nous) !
As-tu trouvé une solution de contournement pour éviter ce 'bloating' inconsidéré avec des .bak qui pèsent de + en + lourd au fil des mois ?
Merci à toi

[Invité]

1.2 Go, tu trouves ça vraiment gros ?

[alevi7856]

Bonjour également,
Disons que tout est relatif ... lorsque l'on passe de 350Mo à 1.2Go, ce dernier chiffre apparait subitement bien plus gros qu'il n'est, surtout dans la réalité de ceux qui n'avaient connu jusqu'alors que cette première échelle de valeurs !
Appelons-ça un changement de paradigme contrariant ...
Cdlt.

[rnd]

Bonjour,
Je me retrouve dans le même cas de figure : fichiers de base 300-350Mo (.mdf / .ldf) + 850Mo de .pdf et autres dans le répertoire FILESTREAM, et nous ne sommes même pas à mi-parcours de l'exercice fiscal (qui commence le 1er avril chez nous) !
As-tu trouvé une solution de contournement pour éviter ce 'bloating' inconsidéré avec des .bak qui pèsent de + en + lourd au fil des mois ?
Merci à toi

Bonjour,
Pour ma pars, pas trouvé de solution, je reste sur de la sauvegarde local en full, avec copie sur disque externe une fois par semaine. J'ai regardé auprès des solution de sauvegarde en ligne qui prend en chrge SQL Server, mais a chaque fois cela fonctionne sur le VSS de Windows et une copie pure et dure du fichier .mdf , les puristes vont aimés

[rnd]

Bonjour également,
Disons que tout est relatif ... lorsque l'on passe de 350Mo à 1.2Go, ce dernier chiffre apparait subitement bien plus gros qu'il n'est, surtout dans la réalité de ceux qui n'avaient connu jusqu'alors que cette première échelle de valeurs !
Appelons-ça un changement de paradigme contrariant ...
Cdlt.

Le problème ,c'est pas la taille en soit, seulement d’être mis pied au mur:

1, ces abru... de SAGE confonde archivage et sauvegarde , tout le Fillestrean ce n'est que des copie des factures.

2, impossible de faire de l'incrémentale, et si on souhaite conserver, disons 30 jours de restauration possible, ça fait 30 x taille exponentielle de .bak, pour externaliser, bonjour la bande passante.

[alevi7856]

Bonjour,
Pour ma pars, pas trouvé de solution, je reste sur de la sauvegarde local en full, avec copie sur disque externe une fois par semaine. J'ai regardé auprès des solution de sauvegarde en ligne qui prend en chrge SQL Server, mais a chaque fois cela fonctionne sur le VSS de Windows et une copie pure et dure du fichier .mdf , les puristes vont aimés

Bonjour,
Merci pour ton retour : je vais donc continuer à zipper pour pouvoir remonter les uploads des .bak dans le cloud (pour info 1.1Gb se zippe en 110Mb avec 7z en compression max).
Mais pourquoi ont-ils pris ce pli (FILESTREAM) chez Sage, je comprends la contrainte LAF mais pas la solution technique adoptée ...
Cordialement.

[rnd]

Le pire c'est qu'il n'y a pas de contrainte, c'est eux qui l'on inventer, chez les autre éditeur il ne procèdent pas de cette manière. En fait ils ont du découvrir la nouveauté FS à sa sortie; le R&D, qu'est ce que l'on va pouvoir faire avec? Tient si y mettait les archives des factures clients, ca bouffe de la place pour rien, bah on s'en tape

[rnd]

Bonjour,
Merci pour ton retour : je vais donc continuer à zipper pour pouvoir remonter les uploads des .bak dans le cloud (pour info 1.1Gb se zippe en 110Mb avec 7z en compression max).
Mais pourquoi ont-ils pris ce pli (FILESTREAM) chez Sage, je comprends la contrainte LAF mais pas la solution technique adoptée ...
Cordialement.

Tu fait comment avec 7z, en script?

[alevi7856]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SET FICHIER2=%REPERTOIRE2%\SAGE100_%J%-%M%-%A%-%H%h%MN%.bak
SET FICHIER4=%REPERTOIRE2%\SAGE100_%J%-%M%-%A%-%H%h%MN%.7z
(...)
rem -mx4 est un compromis taille versus rapidité de compression (aux alentours de 100Mo en 05/19)
7z a -mx4 %FICHIER4% %FICHIER2%

[rnd]

[alevi7856]

En générant sur le serveur TOUTES LES DEMI-HEURES un .bak de ma base SQL et en zippant 7z ce .bak vers mon NAS Synology équipé d'un CloudSync, j'ai une actualisation quasi temps-réel de ma base dans le Cloud (Dropbox) sans bouffer trop de temps machine.
Not so bad of a disaster recovery plan, isn't it ?
---
C'est pour ça que je veux limiter les dégâts en évitant de me retrouver avec des .bak qui font des Gigabytes et des Gigabytes à cause du FILESTREAM, car là, ça peut commencer à se sentir un peu sur le réseau ...

[rnd]

Le fond du problème est là, l’idéal serait de pouvoir différencié le .mdf et les FS, mais visiblement pas prévu dans la version express
Peut être passer à la version SQL supérieure, les pro SQL pourrait peut être nous dire si cela permet de faire le choix des fichiers a sauvegarder ou pas dans SSM.
Je viens de regarde mon backup aujourd'hui est à 6 Gb, en a peine 1 an (350-450 Mo à l’origine)

[alevi7856]

6Gb, partant de 400Mb ... ça fout les boules, franchement ...
Par contre, je crains que même si nous arrivions à ne sauvegarder que le .mdf, cela pourrait présenter A UN MOMENT OU A UN AUTRE un problème dans la 100c en cas de restoration, en particulier lors de la SAUVEGARDE FISCALE car il pourrait y avoir des incohérences conduisant à un plantage, je ne sais pas comment ils gèrent ça, il y a peut-être des index dans leur code ...

[rnd]

Faire 2 jeux de backup quotidiens , le .mdf petit et léger pour externaliser, le plus vulnérable (gestion compta) et les FS .pdf sur back local, et une fois par moi un full sur disque externe et stocker en dehors des locaux (ce que je fais d'ailleurs sur un petit NAS).

Après pour avoir tester, (parce que je fais aussi du dev lier à la base SQL, et que j'ai autre chose a faire que de stocker des fichiers inutile sur mon petit SSD) j'ai restaurer une sauvegarde, puis supprimer le contenus du FS) la gestion fonctionne normalement sans message d'erreur, mais bon.

Pour les impôts, en cas de contrôle, la seule chose qui demande c'est le fichier FEC.

[alevi7856]

C'est quoi le FEC ?

[rnd]

Fichier d' Ecriture Comptable, au format texte, à exporter à chaque clôture d'exercice et à conserver religieusement; c'est la première chose que les services fiscaux demande en cas de contrôle. La compta doit savoir

[i.chafai]

Une solution de contournement que j'utilise chez mes clients sur la 100c afin d'éviter la génération des pdf inutiles.
un trigger sur la table F_DOCENTETE et au changement de statut de la facture vers A COMPTABILISE (Do_STATUT =2) je fais un update sur DO_VALIDE =1 après la comptabilisation et l'impression se passe sans aucun problème. Aucun test sur l'existance d'une copie de la facture.